On 11/20/2013 5:29 PM, Peter Grandi wrote: >> I've got clients going back as far as Transarc 3.6 -- don't ask >> .... there are clients that cannot be changed/rebooted/updated >> due to "extreme sensitivity to change." > >> I had assumed that leaving the existing /usr/afs/etc/KeyFile >> alone and _not_ updating afs@REALM (with new encryption type for >> rekey effort) was the correct approach. > > It depends on what you want to achieve, in particular why you are > rekeying your AFS principals and in which conditions.
The underlying problem that Kim's cell has is that it is not permitted (or perhaps even physically possible) to upgrade the clients that issue the Kerberos afs service ticket request. In this scenario the clients cannot be updated to support rxkad-kdf. Nor can Kim assume that the clients understand how to use the afs/cellname@REALM syntax. Therefore he must continue to provide the afs@REALM service principal and the KDC must continue to offer afs service tickets that use a DES session key. Knowing that the KDC Kim's cell relies is Heimdal, the KDC software will most likely need to be upgraded to ensure that the issuance of DES session keys for "afs" service principals is possible when the KDC is not configured to issue tickets with DES as the service enctype. The other thing that Kim needs to test given the age of the clients is whether or not any of them suffer from an old bug that would result in an out of bounds array access if the service enctype has a value that is not recognized by the client. If so, it may not be possible to deploy AES256-SHA1 enctypes. > The upgrade notes discuss the difference between 'rxkad-k5' and > 'rxkad-kdf' upgrades, and that the latter is the only one that > permits getting rid of the single-DES enctypes for authentication. rxkad-k5 prevents the use of DES for service ticket encryption. rxkad-kdf provides a method of deriving a DES key from a non-DES key. In all cases, a 56-bit + parity key is used for the authentication challenge/response between an AFS RX connection initiator and the acceptor. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
