[OpenAFS] Re: Creating service principal and keytab from active directory for afs/cell

[Andrew Deason]

On Thu, 26 Sep 2013 16:38:42 +0000
Arne Wiebalck <Arne.Wiebalck@cern.ch> wrote:

> To answer Andrew's questions: the test realm is a clone of our
> production one, so it can issue service tickets for
> afs/testcell@testrealm.  With the corresponding changes to krb5.conf,
> CellservDB and the like aklog will get you a session key/service
> ticket pair for the test realm's "AFS service" (there are no AFS
> servers the client could talk to, but that does not stop the client
> from getting a token). For that sess/tkt pair I was surprised to see
> DES/ArcFour with old AFS client versions and AES/AES for new client
> versions. Does that make sense?

It makes sense to me now what your setup is, but you're not supposed to
be able to do that; the client should not be able to change the enctype
of the encrypted service ticket. You should either get DES/AES and
AES/AES, or DES/ArcFour and ArcFour/ArcFour or something. If you can
cause the service ticket enctype to change, it is a potential security
problem, since an attacker can get the kdc to issue a service ticket
with a weaker enctype, and try to brute force it offline. For arcfour,
maybe that's not as much of a concern since it's at least stronger than
des, but if a client can force des then that very much is a problem.

This is not specific to AFS. If you can run e.g. 'kvno -e des-cbc-crc',
'kvno -e rc4-hmac', and 'kvno -e aes256-cts' for any service principal
and get a different service ticket enctype each time, then that's a
problem. (The session key enctype will be different, but the service
ticket enctype should be the same.) If you do see results like that,
check your AD configuration or complain to Microsoft.

> The reason I am doing all this is because our batch system uses some
> home made tools to decrypt the token which is used to verify a user's
> identity, and I managed to port that tool to decrypt AES, but not
> ArcFour. The tool basically uses the functions the AFS server code
> uses I didn't get round to look into that much more, but when I saw
> this thread I thought it maybe worthwhile to jump in and ask if I am
> trying to achieve something that is not achievable. 

Well, ideally you'd be able to handle any enctype supported by the
underlying krb5 library (or openssl or whatever, but I'd think you'd
want to do this with a krb5 library). If you follow the code used by afs
servers, then you'll be able to do that. Hard-coding a specific
encryption algorithm is probably just going to make more work for you in
the future.

-- 
Andrew Deason
adeason@sinenomine.net