krb5-kdc: Cannot change passwords if password history is used

[Tom Yu]

Christopher Odenbach <odenbach at uni-paderborn.de> writes:

> we recently updated our master KDC from Debian Lenny to Debian
> Squeeze. This included a kerberos upgrade from 1.6 to 1.8. After the
> update several users were not able anymore to change their passwords,
> no matter if kpasswd or kadmin.local was used:
>
> change_password: Message size is incompatible with encryption type
> while changing password for "tex1 at UNI-PADERBORN.DE".

That does indeed suggest that the history key being chosen to decrypt
the history doesn't match the history key that was used to encrypt the
history.

> (gdb) p input->ciphertext.length
> $1 = 24
> (gdb) p header_len
> $2 = 8
> (gdb) p trailer_len
> $3 = 20
> (gdb) p input->enctype
> $4 = 511

The number 511 is ENCTYPE_UNKNOWN, which is unconditionally set by
krb5_dbekd_def_decrypt_key_data, so it doesn't necessarily tell us
anything useful.  The lengths imply that the ciphertext was encrypted
using a single-DES enctype.

> (gdb) p ktp->etype
> $5 = 16
>
> So the history key type is Triple-DES. When we setup a new test realm
> we found a DES key was used instead, just like the master key.

When you set up a new test realm, what krb5 release were you using on
the KDC?  What krb5.conf and kdc.conf enctype/keytype parameters in
both the test realm and the production realm?

> kadmin.local:  getprinc kadmin/history
> Principal: kadmin/history at UNI-PADERBORN.DE
> Expiration date: [never]
> Last password change: Tue Dec 10 15:51:20 CET 2002
> Password expiration date: [none]
> Maximum ticket life: 0 days 00:01:04
> Maximum renewable life: 0 days 00:00:00
> Last modified: Tue Dec 10 15:51:20 CET 2002 (kdb5_util at UNI-PADERBON.DE)
> Last successful authentication: [never]
> Last failed authentication: [never]
> Failed password attempts: 0
> Number of keys: 2
> Key: vno 2, Triple DES cbc mode with HMAC/sha1, no salt
> Key: vno 2, DES cbc mode with CRC-32, no salt
> MKey: vno 1
> Attributes:
> Policy: [none]
>
> I have no idea why our realm database has these two enctypes for the
> kadmin/history principal, but it has. The 1.8 code seems to have a
> serious problem with that as it causes KRB5_BAD_MSIZE to be thrown.

The 1.8 code that decrypts the key history for a client principal
unconditionally chooses the first key in the list, so ordering is
important.  Does getprinc kadmin/history on the original 1.6 database
show a different ordering of keys?  What sorts of tools did you use to
do the upgrade?

> How can we deal with this mess? Is it possible to remove the Triple
> DES key from the kadmin/history principal? Or should the code be
> changed to deal correctly with this issue?

I think we can make changes to the code to resolve this issue, but we
need to gether more information.  It's not clear whether removing the
triple-DES key will resolve the issue, because any principals who have
changed their passwords and had their old keys encrypted using the
triple-DES history key will then have problems.

Thanks for reporting this problem.  It is rather perplexing, and we
would appreciate any additional information you can provide.