Update to the design of the Master Key Migration project

[Will Fiveash]

On Tue, Sep 23, 2008 at 07:59:55PM -0500, Will Fiveash wrote:
> 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.   

I thought about this some more and have a modification to the definition
of the data stored in KRB5_TL_CURKVNO.  It should be an array holding a
variable number of these structs:

struct krb5_curkvno  {
    krb5_kvno curkvno;
    krb5_timestamp start_time;
}

The idea is that a number of these structs could be stored in the
KRB5_TL_CURKVNO.  start_time would hold a timestamp indicating when
curkvno should be used.  The algorithm used to determine which entry to
use would choose the closest start_time to the present time that isn't
in the future when processing the entries.

In some future project a new kadmin command could be introduced along
these lines:

use_key <KVNO> [start date/time]

This command would create a new KRB5_TL_CURKVNO entry.  If the start
date/time isn't provided it would use the current time so the entry
would take effect immediately.  It would also delete obsolete entries
that have been overridden by the more current active entry thus keeping
the growth of KRB5_TL_CURKVNO in check.

Thoughts?

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