questions regarding master key enctype migration

[Will Fiveash]

On Tue, Feb 26, 2008 at 10:46:46PM -0500, Tom Yu wrote:
> Will Fiveash <William.Fiveash at sun.com> writes:
> 
> > I have a question concerning the use of the krb5_key_data.key_data_ver
> > field.  After examining the MIT krb code my understanding is that
> > currently the key_data_ver field is used to indicate how many of the
> > krb5_key_data arrays (types, lengths, data contents) are in use.  At
> > this point however key_data_ver is either 1 or 2.  As I'm working on a
> > way to migrate the master key enctype what I'd like to do is add a
> > masterkey KVNO field to the krb5_key_data structure and use the high bit
> > in the key_data_ver field to indicate that this field exists.  To deal
> > with the current logic that uses the value of key_data_ver for salt
> > store, the high bit would be masked off to avoid changing this code too
> > much.  Is this reasonable?
> 
> This could potentially cause problems because an earlier KDB library
> version would interpret the key_data_ver value as a count of array
> members.  This might be acceptable because we could warn people that
> the database format would no longer be backwards-compatible.  (Dump
> code would also need to be updated to handle the new interpretation of
> key_data_ver, I think.)  Keeping the mkvno in a parallel array in the
> tl_data might also work and probably requires the least amount of
> twisting of the API.

That is something I did not consider.  I think using TL data to hold the
mkvno used to protect the princ's secret key as Ken suggests is a better
approach, in part to avoid the issue you raised.  It's one thing for a
KDC not to be able to decrypt a princ's key if it has been encrypted
with a keytab based master key but it's another for the KDC to try to
process the key based on a bogus value in key_data_ver which may cause
the KDC to panic or worse.  Using TL data is a safer because it will not
cause an older KDC this sort of problem. 

> Also, it turns out that the kadm5 API has a mkvno field in its
> principal entry structure, but the KDB API does not.
> 
> > Note, the fundamental idea I have regarding master key enctype migration
> > is that, as Ken Raeburn suggested, master keys would be stored in a
> > keytab with an associated KVNO.  As principal keys are created or
> > changed, the most current key in the masterkey keytab would be used to
> > encrypt the princ's keys and that master key KVNO would be associated
> > with that princ's keys.  This will allow the KDC to determine when
> > decrypting the princ's keys which master key to use from the master key
> > keytab.  In the case that the KDC is dealing with an old version of
> > krb5_key_data that doesn't have a masterkey KVNO field, the KDC would
> > access the original stash file and use that master key to decrypt.
> > Thoughts?
> 
> Would multiple master key versions be stored on the master key
> principal entry?  Also, some people might want to purge their old
> master key versions, so having some way to ensure that no remaining
> keys are encrypted using an old master key version might be useful as
> well.

Good points.  Ken's design addresses this by using a new TL data type,
KRB5_TL_MKEY_AUX.  To quote from his e-mail:

  The second, KRB5_TL_MKEY_AUX, would apply only to K/M, which still
  has one key encrypted in itself.  This new TL data would contain
  all the additional master-key related info that needs to be
  introduced by this change:
 
   * The default master key version number for principals that have
  not yet had the other TL-data type added.  (Optional; must be used
  when this TL data is initially created, but can be removed when the
  indicated mkvno is purged.)
 
   * The master key version number that should be used when changing
  database entries.  (I think it would actually be safe to always use
  the latest, because principal data encrypted in it should never
  reach a slave server before the updated K/M, but do we require that
  all database back ends that handle propagation of changes do so
  fully serialized?  If we make that assumption, this field goes
  away.  But if there's any doubt, we should use it.  Alternatively,
  the lists below could include future key versions if the current
  key isn't the just-added one.)  This field (or the current kvno)
  would probably be cached along with the keys, so after a new key is
  introduced, at some point, servers using the database should be
  restarted or otherwise told to re-check K/M.  Trying to decrypt a
  principal key encrypted using the newest mkvno would trigger a re-
  read of the K/M key data, and this cached datum should probably be
  updated at the same time.

Also, he states that KRB5_TL_MKEY_AUX will store two lists of mkeys:

    1. The old mkey list

       All non-current mkeys (encrypted with the current mkey) which are
       still needed to decrypt princ records that are not encrypted by
       the current mkey.

    2. The current mkey list

       A set of current mkeys each encrypted by one of the old mkeys.
       This allows KDCs that do not have the current mkey in their stash
       file to access the current mkey and then be able to decrypt princ
       records that are protected by the current mkey.

In addition his design has suggestions concerning the management of the
old mkeys via the kdb5_util command.

One thing I wonder about given the above is whether it is reasonable to
allow kprop (or the Solaris iprop) to update the KDCs stash file (if it
exists) with the new current mkey in the K/M princ entry assuming it can
determine that the K/M princ's mkey is newer.  Thoughts?

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