Sorry for the delayed response. It looks like Jeffrey's and Andrew's
responses should have addressed the major issues.
It would also be a little easier for me if the attribution of who wrote
the quoted text was retained.
On Thu, 23 Jan 2014, Peter Grandi wrote:
** Crucial details for completion
- The DES key can be removed from the afs service principal only if all
clients have been upgraded:
I don't believe this is exactly right, with the note that to me "afs
service principal" means "the keys in the KDB". Once a service ticket has
been issued by the KDC (encrypted in the long-term key of the afs service
principal, which is shared between the AFS servers and the KDC), the KDC
is not involved anymore (barring the rare case of initial tickts directly
for the afs service principal which Jeffrey mentioned in passing; this
would involve the -I and -S arguments to k5start). The normal workflow
does not involve material encrypted in the afs service principal's
long-term key coming back to the KDC. Even if you are concerned that
initial tickets for the afs service principal are in use, you only need to
wait for the maximum renewable lifetime to pass after creating the new
keys before removing the old ones; the status of client software is not
relevant at all.
- The client caches, as long as they include the rxkad patches (1.4.15,
1.6.5, or equivalent with backports) don’t need restarting, because
what matters is the tokens, which are not part of their state:
The client caches don't even need the rxkad patches. An aklog binary (or
whatever binaries are used to obtain tokens) from 1.4.15 with the rest of
the cache manager from 1.4.14 (or older) is sufficient to gain the
benefits of rxkad-kdf.
-Ben
