On Thu, 26 Sep 2013 16:38:42 +0000 Arne Wiebalck <[email protected]> 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 [email protected] _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
