Changing password for a principal reverts master key used

[Greg Hudson]

On 07/31/2013 01:11 AM, David Shrimpton wrote:
> KNVO: 2, Enctype: aes256-cts-hmac-sha1-96, Active on: Wed Jul 31 14:45:32 EST 2013 *
> KNVO: 1, Enctype: des-cbc-crc, Active on: Wed Jul 31 14:45:32 EST 2013

This is a weird state.  Both master keys have the same "Active on" time,
and they are both in the future (as of when you sent the message).  I
can't easily get into that state in a test environment:

  $ kdb5_util use_mkey 1 2013-08-01
  kdb5_util: Invalid argument there must be one master key currently active

So, I'm curious how you got into that state.  Perhaps there is a bug
involved with that sequence of events.

Given that you are in that state, I would still expect kdb5_util
list_mkeys to be consistent with kadmin cpw, since they use the same
internal function to choose the active master key version.  In my tests,
the two are consistent with each other, so I'm not sure why they aren't
consistent for you.

There is a known bug that update_princ_encryption always chooses the
most recent master key, rather than the one which should be currently
active:

  http://krbdev.mit.edu/rt/Ticket/Display.html?id=6507

So it's not surprising that update_princ_encryption is inconsistent with
kadmin cpw.