questions regarding master key enctype migration

[Will Fiveash]

On Tue, Mar 11, 2008 at 05:44:18PM -0500, Will Fiveash wrote:
> On Tue, Mar 11, 2008 at 09:03:44AM -0400, Ken Raeburn wrote:
> > Oh, my scheme should probably be checked for race conditions...  For 
> > example, can we have a key change operation look up the mkvno to use, then 
> > another process update the database to a new mkvno, re-encrypt the keys 
> > (small database?), and remove the old master key, before the key change 
> > operation gets around to storing new newly changed key, encrypted in a 
> > master key we've just deleted?

BTW, I just realized that what I wrote below is similar to what you
(Ken) wrote about removing old keys in your design outline.  So we're in
agreement on the fundamental approach.

> Yeah, that race condition could be a problem esp. in a multi-master KDC
> scenario where the KDB is LDAP based.  To avoid it, the purging of
> unneeded mkeys should only be done after all KDC's are using the same,
> current mkey.  Any princ rekeying at that point would be using the
> current mkey.  
> 
> This would require that when a K/M princ is updated with a new current
> mkey no older mkeys are deleted at this point and it would then be
> propagated to all KDC's.  If kprop/iprop is used then this would sync up
> the KDC's set of mkeys in the local keytab mkey stash with those in the
> K/M princ which would essentially be adding the new mkey.  If some other
> method of propagation was used then the KDC could have a cron job that
> runs a new kdb_util command once a day to do this sync.  Either way,
> since no older mkeys were removed it would not be a problem if a princ
> was being rekeyed with an older mkey.
> 
> After a enough time had passed to ensure that the above was completely
> successful and all KDCs were using the same current mkey a new kdb5_util
> command to purge old mkeys from the K/M princ would be then run on a
> master KDC.  (Whether this command can determine if a mkey is still
> required to decrypt a princ record in a reasonable amount of time may be
> an issue.  Ken, any idea here?  Anyway, I'm going to assume it is
> feasible for either a db2 or LDAP KDB.)  This updated K/M princ would
> then be propagated and the kprop/iprop/cron job that syncs the local
> keytab mkeys with the K/M princ would remove the unneeded mkeys from the
> keytab stash that were removed from K/M's set.
> 
> Thoughts?

-- 
Will Fiveash
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)