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

[Jeffrey Hutzelman]

On Wed, 2013-11-20 at 18:05 -0500, Jeffrey Altman wrote:

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

Yes, we established all of that.  What we've not established is whether
it is even possible to use non-DES service keys.  IBM AFS 3.6 clients
did not include a krb5-based aklog, so for clients of that vintage,
there is a distinct possibility that AFS service tickets are being
obtained via krb4 or kaserver.  If that is the case, non-DES service
keys _will not work_, as those protocols support only DES.

It is theoretically possible for a kaserver to issue tokens which are
really krb5 or rxkad-2b format, and which thus could use a non-DES
service key.  It is probably even possible to patch Heimdal's kaserver
to do this.  However, as far as I know, no such kaserver implementation
has ever existed.


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

Uh, I'm not aware of any such bug.  Can you provide a reference?
There _is_ a bug which could result in an out-of-bounds array access if
the returned token is too large, which could happen for some enctypes.
However, this is relatively unlikely if your client principal names
aren't too big.  We designed rxkad-2b such that everything would fit
within the smaller limit even with maximal-size client principal names,
but that was using DES, and the block size for the AES enctypes is
larger.


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

Correct.