[OpenAFS] Help rekeying cell when both service principals (afs@REALM
and afs/cell@REALM) exist
Wed, 20 Nov 2013 21:07:34 -0700
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.
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
> 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