I was reviewing in great detail the 'rxkad-{k5,kdf}' upgrade instructions and in particular the rekeying HOWTO:
http://www.openafs.org/pages/security/how-to-rekey.txt here in the MIT Kerberos section: > The default encryption types given by the KDC are probably > fine, as long as single-DES is not one of them. If you want to > specify exactly which encryption types to use, give the -e > option to ktadd. To get the enctypes in the above example, for > example: > kadmin: ktadd -k /tmp/rxkad.keytab -e "aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal des3-hmac-sha1:normal arcfour-hmac-md5:normal" afs/cell > Entry for principal afs/cell with kvno 3, encryption type AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/tmp/rxkad.keytab. > Entry for principal afs/cell with kvno 3, encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/tmp/rxkad.keytab. > Entry for principal afs/cell with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/tmp/rxkad.keytab. > Entry for principal afs/cell with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/tmp/rxkad.keytab. The issue here is that at least in MIT kerberos 1.8 and 1.10 which I tested this on this results in the loss of the existing single-DES key from the KDB, which probably results in existing single-DES tokens and client to stop working as the key in the 'KeyFile' is no longer matched by one in the KDB: kadmin.local: addprinc -policy service -randkey -e "des-cbc-md5:normal" test Principal "t...@ty.sabi.co.uk" created. kadmin.local: getprinc test [ ... ] Number of keys: 1 Key: vno 1, des-cbc-md5, no salt [ ... ] kadmin.local: ktadd -k /tmp/test.kt -e "aes256-cts-hmac-sha1-96:normal" test Entry for principal test with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/test.kt. kadmin.local: getprinc test [ ... ] Number of keys: 1 Key: vno 2, aes256-cts-hmac-sha1-96, no salt [ ... ] To avoid this one has to use 'kadmin.local' to be able to use 'cpw -keepold' and 'ktadd -norandkey', as advised in the MIT kerberos "Retiring DES" HOWTO: http://web.mit.edu/kerberos/krb5-current/doc/admin/advanced/retiring-des.html This will result in the existing single-DES key to remain, and for the new keys to have a KVNO one higher than it. Then one must use 'ktadd -norandkey' to create the keytab. But this adds *all* keys to the keytab, including the single-DES key, and the single-DES key is added to the keytab with an incremented KVNO, *even if* the KVNO of the single-DES key's KVNO is not incremented in the KDB: kadmin.local: addprinc -policy service -randkey -e "des-cbc-md5:normal" test Principal "t...@ty.sabi.co.uk" created. kadmin.local: getprinc test [ ... ] Number of keys: 1 Key: vno 1, des-cbc-md5, no salt [ ... ] kadmin.local: cpw -randkey -keepold -e "aes256-cts-hmac-sha1-96:normal" test Key for "t...@ty.sabi.co.uk" randomized. kadmin.local: getprinc test [ ... ] Number of keys: 2 Key: vno 2, aes256-cts-hmac-sha1-96, no salt Key: vno 1, des-cbc-md5, no salt [ ... ] This is as desired, but then: kadmin.local: ktadd -k /tmp/test.kt -norandkey -e "aes256-cts-hmac-sha1-96:normal" test cannot specify keysaltlist when not changing key kadmin.local: ktadd -k /tmp/test.kt -norandkey test Entry for principal test with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/test.kt. Entry for principal test with kvno 2, encryption type des-cbc-md5 added to keytab WRFILE:/tmp/test.kt. kadmin.local: getprinc test [ ... ] Number of keys: 2 Key: vno 2, aes256-cts-hmac-sha1-96, no salt Key: vno 1, des-cbc-md5, no salt [ ... ] # klist -k /tmp/test.kt -e Keytab name: FILE:/tmp/test.kt KVNO Principal ---- -------------------------------------------------------------------------- 2 t...@ty.sabi.co.uk (aes256-cts-hmac-sha1-96) 2 t...@ty.sabi.co.uk (des-cbc-md5) That means that the keytab just created contains an entry for a non existent key. Easy to delete with 'ktutil', but can cause problems. Indeed there was a report in the #OpenAFS IRC channel about the presence of a DES key in the keytab causing failure: [06:20] chrisb | any comments on the upgrade procedure for server 1.6.2? i find it difficult [06:20] chrisb | bos: failed to restart servers (ticket contained unknown key version number) [06:32] chrisb | ok, working now. i had left des-enctypes in the .keytab I suspect that the presence of single-DES keys in 'rxkad.keytab' is not itself an issue, the issue is that it has an incremented KVNO that is higher than that of the key in the KDB is the problem. Looks to me There is a bug in the MIT Kerberos 'ktadd -norandkey'. _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info