The history key

[ghudson@mit.edu]

To implement the password history feature of the standard MIT krb5
policy objects, we encrypt people's old keys in a history key, found
in the key data of kadmin/history.  The history key is itself
encrypted in the master key.  In the current trunk, kadmind and
kadmin.local will refuse to start if they can't determine the history
key, and allow_weak_crypto=false will prevent that code from reading
the history key if it is a DES key.

Although we implemented master key rollover support in 1.7, we do not
(to my knowledge) have a documented way of rolling over the history
key.  We had a discussion about this today; the summary is:

1. For 1.8, we will make allow_weak_crypto=false not apply to the
history key, just as it doesn't apply to the master key.

2. For 1.8, we will make sure it is possible to change the history key
(with cpw -randkey) and still have password changes work, although old
password history will effectively be lost if you do this.  (This just
means ignoring integrity error codes from krb5_dbekd_decrypt_key_data
in check_pw_reuse, I think.)

3. In the long term, we would like to phase out the history key and
use the master key instead, as we don't believe there is any security
advantage to using the history key.  This project would probably
involve creating a new tl_data type for history entries encrypted in
the master key, and then extending the master key rollover code to
password history.  We haven't chosen a milestone for this work (except
to declare it out of scope for 1.8) or done detailed design work.

Feedback is welcome.