Update to the design of the Master Key Migration project

[Nicolas Williams]

On Wed, Sep 24, 2008 at 03:43:33PM -0500, Will Fiveash wrote:
> 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.

Excellent idea!  (This addresses one long thread we had a while back
about just this topic.)

> 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:

I like that -- it could be used for any principal, not just K/M or
krbtgt/<realm>@<realm>.

> struct krb5_curkvno  {
>     krb5_kvno curkvno;
>     krb5_timestamp start_time;
> }

Why not also end_time, with 0 -> never?

> 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]

getprinc should list these for any one principal.
modprinc should allow setting these for any one principal.

Something like:

    kadmin:  getprinc krbtgt/FOO.EXAMPLE
    Principal: krbtgt/FOO.EXAMPLE at FOO.EXAMPLE
    ...
    Number of keys: 5
--->Key version numbers in use: 4
    Key: vno 4, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
    ...
    kadmin:  
    kadmin:  modprinc krbtgt/FOO.EXAMPLE -use_kvno 5 start ... end ...
--->kadmin:  randkey krbtgt/FOO.EXAMPLE
    kadmin:  getprinc krbtgt/FOO.EXAMPLE
    Principal: krbtgt/FOO.EXAMPLE at FOO.EXAMPLE
    ...
    Number of keys: 10
--->Key version numbers in use: 4
    Key: vno 5, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
    ...
    Key: vno 4, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
    ...
--->kadmin:  modprinc krbtgt/FOO.EXAMPLE -use_kvno 5 start now end never
    kadmin:  getprinc krbtgt/FOO.EXAMPLE
    Principal: krbtgt/FOO.EXAMPLE at FOO.EXAMPLE
    ...
    Number of keys: 10
--->Key version numbers in use: 5, 4
    Key: vno 5, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
    ...
    Key: vno 4, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
    ...
--->kadmin:  modprinc krbtgt/FOO.EXAMPLE -use_kvno 4 end now
    kadmin:  getprinc krbtgt/FOO.EXAMPLE
    Principal: krbtgt/FOO.EXAMPLE at FOO.EXAMPLE
    ...
    Number of keys: 10
--->Key version numbers in use: 5
    Key: vno 5, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
    ...
    Key: vno 4, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
    ...
--->kadmin:  delkeys -v 4 krbtgt/FOO.EXAMPLE
    kadmin:  getprinc krbtgt/FOO.EXAMPLE
    Principal: krbtgt/FOO.EXAMPLE at FOO.EXAMPLE
    ...
--->Number of keys: 5
    Key version numbers in use: 5
    Key: vno 5, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
    ...
    kadmin:  exit

Everything that's highlighted is new: 'randkey' and 'delkeys'
sub-commands, kvnos in use output line, and modprinc '-use_kvno' option.

Yes, I realize that 'delkeys' would require a protocol change, so phat
chance of that.  I can live without 'delkeys'.  (Or can the randkey RPCs
be twisted to do a don't-add-keys-just-delete-old-keys RPC?  Do we even
care?)

Nico
--