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
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
