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

[Benjamin Kaduk]

Hi Peter,

On Thu, 23 Jan 2014, Peter Grandi wrote:

> 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

I wrote the majority of both this document and the 'retiring des' document 
mentioned later.

> 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

The loss of the existing single-DES key is expected and desired.

> single-DES tokens and client to stop working as the key in the
> 'KeyFile' is no longer matched by one in the KDB:

It does not cause the existing single-DES tokens to stop working.
The existing tokens are derived from kerberos tickets issued against the 
old key, but once the service ticket is issued, the KDC is out of the 
picture.  So long as the key remains in the KeyFile on the AFS servers, 
the ticket (and thus token) can be verified.

> 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:

This is the correct way to avoid the loss of the old keys from the KDB, 
but it should not be necessary to retain the old keys in the KDB for the 
purposes of an rxkad-k5 migration.  Can you clarify a bit more why you 
believe it is necessary to preserve these keys in the KDB?

> 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.

The presence of the single-DES keys in rxkad.keytab is actually a problem.
The rxkad-k5 code was written so as to be as "minimally disruptive" as 
possible, meaning that for single-DES keys the old code paths will still 
be used.  In particular, that means that when receiving a token that's 
encrypted in a single-DES key, the AFS server will look in the KeyFile for 
that decryption key.  If the key is only in rxkad.keytab, it will fail.
This is particularly bad if the krb5 implementation on some (other) server 
will pick a key from the keytab in a fashion that does not take into 
account the strength of the various enctypes -- we have seen cases where a 
"printed token" used for server-to-server authentication ends up picking a 
single-DES key from rxkad.keytab (even when an AES enctype is available), 
and this causes server-to-server authentication to fail if the single-DES 
key is not also in the KeyFile.

> Looks to me There is a bug in the MIT Kerberos 'ktadd -norandkey'.

It does, thank you for the report.  I will look into it more closely.
Do I understand correctly that you see this behavior from ktadd -norandkey 
in both MIT krb5 1.8 and 1.10?

Thanks,

-Ben Kaduk