From nw141292@sac.sfbay.sun.com Fri Apr 10 14:26:55 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3ALQsIs001413 for ; Fri, 10 Apr 2009 14:26:54 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3ALQi57005570; Fri, 10 Apr 2009 22:26:53 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHW0010ZM8SLO00@brm-avmta-1.central.sun.com>; Fri, 10 Apr 2009 15:26:52 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHW00HJWM8RN130@brm-avmta-1.central.sun.com>; Fri, 10 Apr 2009 15:26:52 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3ALQpej055916; Fri, 10 Apr 2009 14:26:51 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3ALQiEN001408; Fri, 10 Apr 2009 14:26:44 -0700 (PDT) Received: (from nw141292@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n3ALQiPL001404; Fri, 10 Apr 2009 14:26:44 -0700 (PDT) Date: Fri, 10 Apr 2009 14:26:44 -0700 (PDT) From: Nicolas Williams Subject: Kerberos Master Key Migration [PSARC/2009/233 FastTrack timeout 04/17/2009] To: PSARC-ext@sun.com Cc: kerberos-discuss@opensolaris.org Message-id: <200904102126.n3ALQiPL001404@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 7248 I'm sponsoring this fasttrack for Will Fiveash. We request Micro/Patch release binding (though with no intention to backport) the timeout is set for 2009-04-17. Nico This information is Copyright 2008 Sun Microsystems ABSTRACT -------- This case will provide the ability to add a new master key (with an enctype differing from the current master key) to the master key principal and stash file and then migrate the encryption of existing principals long term keys to use the new master key. In addition deletion of master keys will be provided. This function will be provided by resyncing that functionality that currently exists in the MIT Kerberos Consortium code base. BACKGROUND ---------- OpenSolaris Kerberos is based on MIT Kerberos V5 and is currently fully synced fully with 1.4 and parts of 1.6 (see http://opensolaris.org/os/project/kerberos/). The current release of MIT Kerberos is 1.7 and the new features include support for migrating the master key enctype (encryption type) to a new (and likely stronger) enctype. Previously it was not possible to change the enctype of the master key which is established at the time a principal DB (KDB) is created. Note that prior to Solaris 10 the only supported enctype was DES which is now regarded as a weak thus any KDCs created on earlier versions of Solaris are stuck with a DES master key. * See Also MITKC Projects/Master Key Migration http://k5wiki.kerberos.org/wiki/Projects/Master_Key_Migration PROPOSAL -------- In MIT Kerberos 1.7 support for master key enctype migration is introduced and will be added to OpenSolaris. The following is from the MITKC Projects/Master Key Migration webpage: =Functional Requirements= The KDC must be able to deal with multiple master keys and determine which key to use when decrypting a principal's long term secret key. The KDC must be able to access any of the master key (K/M) principal's keys as long as it has access to a master key that is in use. The administrator must be able re-encrypt principal keys using a specified mkey and be able to specifying the set of principals is to be re-encrypted. The command doing this must be able to determine if a principal's keys are protected by the current master key or not. This implies that some set of principals may be protected with a non-current master key. Slave KDCs must be able to access all master keys currently protecting principal entries and therefore have access to the principal's secret keys regardless of which master key is used to encrypt the key. The administrator will be able to: - Add a new master key to master key principal and optionally to the masterkey keytab stash. - Enable a new master key (make it the current master key used to protect newly created principals or principal rekeys). - List all master keys associated with the master key principal. - Delete a particular master key from the master key principal and optionally from the masterkey keytab stash. - Purge unused master keys (keys not used to protect any principal). Fundamentally the current implementation must be changed to support multiple master keys. And possession of any master key stored with the K/M principal allows access to all master keys. In addition, a principal's secret key may be encrypted by any of the master keys in use and the KDC retains in-use master keys in order to be be able to decrypt that principal's key. kdb5_util will be modified to support these new commands: add_mkey [-e etype] [-s] Adds a new master key to the K/M (master key) princi- pal. Existing master keys will remain. The -e etype option allows specification of the enctype of the new master key. The -s option stashes the new master key in a local stash file which will be created if it doesn't already exist. use_mkey mkeyVNO [time] Sets the activation time of the master key specified by mkeyVNO. Once a master key is active (i.e. its activa- tion time has been reached) it will then be used to encrypt principal keys either when the principal keys change, are newly created or when the update_princ_encryption command is run. If the time argument is provided then that will be the activation time otherwise the current time is used by default. The format of the optional time argument is that speci- fied in the Time Formats section of the kadmin man page. list_mkeys List all master keys from most recent to earliest in K/M principal. The output will show the KVNO, enctype and salt for each mkey similar to kadmin getprinc output. A * following an mkey denotes the currently active master key. purge_mkeys [-f] [-n] [-v] Delete master keys from the K/M principal that are not used to protect any principals. -f do not prompt user. -n do a dry run, shows master keys that would be purged, does not actually purge them. -v verbose output. update_princ_encryption [-f] [-n] [-v] [princ-pattern] Update all principal records (or only those matching the princ-pattern glob pattern) to re-encrypt the key data using the active database master key, if they are encrypted using older versions, and give a count at the end of the number of principals updated. If the -f option is not given, ask for confirmation before start- ing to make changes. The -v option causes each princi- pal processed (each one matching the pattern) to be listed, and an indication given as to whether it needed updating or not. The -n option causes the actions not to be taken, only the normal or verbose status messages displayed; this implies -f since no database changes will be performed and thus there's little reason to seek confirmation. The existing stash command will change from: stash [-f keyfile] Creates a stash file. If -f was not specified, the default stash file name is /var/krb5/.k5.realm. You will be prompted for the master database password. This command is useful when you want to generate the stash file from the password. to: stash [-f keyfile] Stores the master principal's keys in a stash file. The -f argument can be used to override the keyfile specified at startup. The stash command will retrieve the keys stored in the K/M master principal entry and store them in a stash file which will either be the default or that specified by the -f flag. DOCUMENTATION ------------- * Man page updates will be given for kdb5_util(1). * http://docs.sun.com the Kerberos chapter will also be updated. INTERFACE STABILITY AND RELEASE BINDINGS ---------------------------------------- Interface Stability Release Binding new kdb5_util args Volatile Micro/Patch From Nicolas.Williams@sun.com Fri Apr 10 14:50:37 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3ALoaBS001764 for ; Fri, 10 Apr 2009 14:50:36 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3ALoZAv007643 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 10 Apr 2009 15:50:35 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHW00F0BNCBS100@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 10 Apr 2009 14:50:35 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHW005WINCATB60@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 10 Apr 2009 14:50:34 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3ALf7tX008529; Fri, 10 Apr 2009 16:41:07 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3ALf70h008528; Fri, 10 Apr 2009 16:41:07 -0500 (CDT) Date: Fri, 10 Apr 2009 16:41:07 -0500 From: Nicolas Williams Subject: Re: Kerberos Master Key Migration [PSARC/2009/233 FastTrack timeout 04/17/2009] In-reply-to: <200904102126.n3ALQiPL001404@sac.sfbay.sun.com> To: Nicolas Williams Cc: psarc-ext@sun.com, kerberos-discuss@opensolaris.org Message-id: <20090410214107.GI1500@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200904102126.n3ALQiPL001404@sac.sfbay.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 614 Note: I asked Will why make these interfaces Volatile, and it seems that for now the Solaris Kerberos team wishes to go with Volatile for new interfaces from any latest MIT krb5 release (that was done in the PKINIT case, for example). MIT does not commit to interface stability, only to ABI stability (the MIT krb5 ABI is effectively Committed). CLIs are part of the Solaris ABI, but it's not clear that MIT considers CLIs part of their ABI. I think Volatile is reasonable for now, but I'd like to see all these interfaces' stability upgraded later on. Nico -- From Darren.Moffat@Sun.COM Tue Apr 14 01:15:37 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3E8FbHc003236 for ; Tue, 14 Apr 2009 01:15:37 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3E8FZF8019001 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 14 Apr 2009 01:15:37 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KI30011D0A09Z00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 14 Apr 2009 02:15:36 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI300G6E09YCPB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 14 Apr 2009 02:15:35 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3E8FYnC028218 for ; Tue, 14 Apr 2009 08:15:34 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KI200200Z9KWN00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 14 Apr 2009 09:15:34 +0100 (BST) Received: from [129.156.173.251] ([unknown] [129.156.173.251]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KI300L4109U2460@fe-emea-09.sun.com>; Tue, 14 Apr 2009 09:15:30 +0100 (BST) Date: Tue, 14 Apr 2009 09:15:30 +0100 From: Darren J Moffat Subject: Re: Kerberos Master Key Migration [PSARC/2009/233 FastTrack timeout 04/17/2009] In-reply-to: <200904102126.n3ALQiPL001404@sac.sfbay.sun.com> Sender: Darren.Moffat@Sun.COM To: Nicolas Williams Cc: PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org Message-id: <49E44622.2010400@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904102126.n3ALQiPL001404@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090223) Status: RO Content-Length: 132 I'm happy with the case as specified and I understand the rationale for the low interface taxonomy assignment. -- Darren J Moffat From Nicolas.Williams@sun.com Thu Apr 23 09:44:59 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3NGiwjk025394 for ; Thu, 23 Apr 2009 09:44:59 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3NGisLj005642; Thu, 23 Apr 2009 10:44:57 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIK0050DBUWLX00@nwk-avmta-2.sfbay.sun.com>; Thu, 23 Apr 2009 09:44:56 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIK003S7BUVI140@nwk-avmta-2.sfbay.sun.com>; Thu, 23 Apr 2009 09:44:55 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3NGZPOc017034; Thu, 23 Apr 2009 11:35:25 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3NGZPLO017033; Thu, 23 Apr 2009 11:35:25 -0500 (CDT) Date: Thu, 23 Apr 2009 11:35:25 -0500 From: Nicolas Williams Subject: Re: Kerberos Master Key Migration [PSARC/2009/233 FastTrack timeout 04/17/2009] In-reply-to: <49E44622.2010400@Sun.COM> To: Darren J Moffat Cc: Nicolas Williams , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Message-id: <20090423163525.GQ1500@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200904102126.n3ALQiPL001404@sac.sfbay.sun.com> <49E44622.2010400@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 271 On Tue, Apr 14, 2009 at 09:15:30AM +0100, Darren J Moffat wrote: > I'm happy with the case as specified and I understand the rationale for > the low interface taxonomy assignment. Given your +1 and that the timer has expired I've marked the case as approved. Nico --