Thanks, Jeff. That helps confirm what I suspected I was facing.
Heimdal has some interesting quirks that I'll document along with the
procedure that now works reliably. Thankfully I've had a test
environment to work with -- the first effort at rekeying the production
environment failed in an interesting way, and only for the 1.6.5 aklog
... but it was of course a Heimdal "quirk" that got in the way.
Kim
On 11/20/2013 4:05 PM, Jeffrey Altman wrote:
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
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
