[OpenAFS] Help rekeying cell when both service principals (afs@REALM and afs/cell@REALM) exist

[Kim Kimball]

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
>
>