questions regarding master key enctype migration
William.Fiveash at sun.com
Tue Mar 11 19:40:43 EDT 2008
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.
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)
More information about the krbdev