[OpenAFS] 'afs/' principal rekeying instructions may be incomplete

[Peter Grandi]

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 "test@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 "test@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 "test@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 test@TY.SABI.CO.UK (aes256-cts-hmac-sha1-96) 
     2 test@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'.