Update to the design of the Master Key Migration project

[Will Fiveash]

Tom Yu requested that I look into modifying the design for the master
key migration/rollover project to facilitate support for service key
rollover.

The idea here is to provide a facility that would, among other things,
allow an admin to specify which service key version the KDC will use
when issuing tickets for that service.  This would allow an admin to use
ktadd to rekey a service principal, store the new keys in a keytab and
distribute the keytab to whatever systems were hosting that service
prior to the KDC using the new service keys when generating tickets for
that service.  Once the keytab distribution was complete, the admin
could then "enable" use of the new service keys thus ensuring no
interruption of service.

Currently the master key migration design defines a new TL-data type, KRB5_TL_MKEY_AUX, would
apply only to the K/M principal. This new TL data contains:

    - The current master key version number that should be used when
      changing database entries. This may not be the latest key and is
      set by the administrator. If this TL-data type is not found in the
      K/M record then the default value for this will be 1 which is the
      default MKVNO.

    - A set of copies of the latest master key, each encrypted by one of
      the other supported mkeys, in {old-mkvno, keydata} tuples. Thus
      the "master key" used in DAL (DB abstraction layer) need only be
      any one of these keys.

    - Trailing stuff is ignored for now, making the structure
      extensible. 

To enable service key rollover I propose removing the current master key
version number in the KRB5_TL_MKEY_AUX and creating a new TL data type,
KRB5_TL_CURKVNO, that could be associated with any principal.  When set
for the K/M principal it would function as described above in the
KRB5_TL_MKEY_AUX definition.  When set for a service principal it would
indicate the key version to be used when the KDC issues service tickets.
And like KRB5_TL_MKEY_AUX, any trailing data would be ignored to make
this data type extensible.  For example Tom mentioned that it might be
good to support the ability to set an activation date/time for keys and
so on.   

At some point in the future, service key rollover could be implemented
using this new TL data type.

Note that I am not planning on modifying the current master key
migration design other than to add support for the KRB5_TL_CURKVNO as it
pertains to the K/M principal.  And I wasn't planning on adding support
for date/time key activation unless that is deemed to be important.

Thoughts?

On Tue, Sep 02, 2008 at 07:25:34PM -0500, Will Fiveash wrote:
> I've added a page on the MIT Kerberos Consortium wiki for the Master Key
> Migration project.  The URL to the page is:
> http://k5wiki.kerberos.org/wiki/Projects/Master_Key_Migration
> 
> This project 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. 
> 
> The review period runs Sept 2-16.
> 
> -- 
> Will Fiveash
> Sun Microsystems Inc.
> http://opensolaris.org/os/project/kerberos/
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev

-- 
Will Fiveash
Sun Microsystems Inc.
http://opensolaris.org/os/project/kerberos/