questions regarding master key enctype migration

[Will Fiveash]

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?

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?

> Perhaps not in db2, if we lock the database for the whole sequence of mkvno 
> lookup through updated key store, but what about in the LDAP world?

Yeah, for an LDAP based KDB it is more likely that DS specific
replication will be used instead of kprop/iprop.  That's why I think
having at least three separate kdb5_util commands to admin mkeys would
be useful.  One just adds a new mkey to the K/M princ, another syncs a
local mkey stash with the mkeys in the K/M princ and the third purges
unneeded mkeys from the K/M princ.  This would allow the scenario I
described earlier to work, either for db2 or LDAP KDBs.

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