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

[Kim Kimball]

There is no kaserver in play, just for completeness.

Until all AFS clients are upgraded from (as old as) Transarc 3.6.5x to 
1.6.5 I will assume that the afs@REALM principal is required.

Currently planned:
The afs@REALM principal will be configured with the requisite single-DES 
encryption types.
The afs/cell@REALM will be configured with AES128 (and des-cbc-crc if 
testing shows that it is required) as will /usr/afs/etc/rxkad.keytab

I don't have direct access to the ancient Transarc clients for testing.  
Always a wrinkle.  I've built some tools for the older platforms but 
tools for _all_ the ancient *NIX clients are probably not reliably 
included in that, nor do I expect I will have a build environment on the 
oldest ... so I may not be able to update all client software to 1.6.5 
unless I can (miraculously) get OS updates into the mix.

We may just decide to trust anyone on the campus network and shut down 
access to AFS servers from non campus networks, but I'd rather get at 
least the rxkad.keytab in place -- servers are all 1.6.5 so at least 
that much should work if we/I don't do something vile to 
/usr/afs/etc/KeyFile ...  and if I've read the documentation correctly 
there is at least some significant advantage to getting rid of 
single-DES private server keys ...

Last year I established a working single-node AFS cell in AWS and can 
likely use that procedure to do it again (time has moved on as has AWS 
but I ain't skeered) so if push comes to shove and someone needs to 
provide external access to campus-only AFS data/servers there will be at 
least that option ... an external cell.

AFS is still, IMO, the best way to share data reliably and consistently 
across all platforms relevant to this campus, and in any case just 
shutting down the servers would require witness protection for the 
perpetrator ...





On 11/21/2013 9:39 AM, Jeffrey Hutzelman wrote:
> 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.
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>