questions regarding master key enctype migration

[Tom Yu]

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.

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.

---Tom