Changing password for a principal reverts master key used

[David Shrimpton]

I have run into a problem with MIT kerberos 1.11.2 where changing the password for
a principal causes the master key in use for that principal
to revert to an earlier master key.


eg


1. kdb5_util list_mkeys

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

2. kdb5_util update_princ_encryption -v foobar
Re-encrypt all keys not using master key vno 2?
(type 'yes' to confirm)? yes
Principals whose keys are being re-encrypted to master key vno 2 if necessary:
updating: foobar at KRB5.UQ.EDU.AU
skipping: foobar at KRB5.UQ.EDU.AU
2 principals processed: 1 updated, 1 already current

3. getprinc foobar

MKey: vno 2

4. cpw -pw XXXX foobar
Password for "foobar at YYYY" changed.

5. getprinc foobar

MKey: vno 1



foobar is the first principal to be changed to MKey: vno 2 in the database.
(Apart from K/M which was changed to MKey: vno 2 by the 'kdb5_util add_mkey -s'
used to add the new key.  MKey: vno 2 was also marked as active by add_mkey
though possibly this should not have happened either.)

The reversion of MKey  occurs regardless of whether principal has a policy.
It happens with several principals tested so presumeably over time the
whole database would revert to MKey: vno 1.


I am wondering if anyone else has observed this problem and whether 
this is a bug in MIT kerberos  1.11.2 .


-- 
David Shrimpton