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 "[email protected]" 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 "[email protected]" 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 [email protected] (aes256-cts-hmac-sha1-96)
2 [email protected] (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
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
