Jason Edgecombe <[EMAIL PROTECTED]> writes: > We run an AFS cell with a kerberos 5 kdc and still have krb5/kas > authentication in parallel. I'm looking to upgrade the kerberos server > to version 1.6. This works well in my test setup. My question is "how > does adding supporting encryption types interact with AFS and windows?"
> Here is part of the kdc.conf > supported_enctypes = des-cbc-crc:normal des-cbc-crc:v4 des-cbc-crc:afs3 > Does adding more encryption types hose AFS or windows? I'd like to start > enabling stronger crypto types so that we have the option of using them > in the future. > What do I need to lookout for with this? Adding more supported enctypes does not, in and of itself, break anything. It's only when you change keys and principals pick up new enctypes that anything might break. Adding enctypes to user principals also doesn't break anything *except* in the case where you're obtaining TGTs via programs linked against one Kerberos library and then using a different program to obtain service tickets. In that case, if the encryption type of the TGT is one that the program getting service tickets doesn't understand, it may not be able to obtain a service ticket. In practice, 3DES has no problems here, but AES keys can confuse really old clients. When we added more enctypes to our realm, we listed 3DES before AES in the supported_enctypes configuration before changing the TGT key so that ticket contents would be encrypted with 3DES by default. This avoided some compatibility issues, and new clients could still negotiate AES if they knew how to handle it. Note that Java prior to 1.6 with the extended encryption libraries (I forget what they're called) can't deal with AES keys in its internal Kerberos implementation. Neither AFS nor Windows will care about any of this. What they care about is if you change the keys of their service principals. The AFS service principal must have only a des-cbc-crc enctype, so after you add more supported enctypes, you have to use additional caution and always specify the enctype whenever you change that key. Similarly, your cross-realm keys to a Windows AD realm must use DES or RC4; AES isn't supported unless you're running the latest bleeding edge Windows code, which you probably aren't. 3DES will probably never be supported. But you can enable other enctypes as long as you don't use those enctypes for your cross-realm keys. > BTW, we're still running krb524d because our aklog still needs it. You'll want to upgrade that aklog at some point. :) > What do I need to do on the clients to enable use of the stronger crypto > types? Make sure that you don't restrict the enctypes in the client krb5.conf and then all Kerberos programs will negotiate enctypes on the fly and in general just do the right thing. You can control which enctypes will be used for a service by controlling what enctypes the service principal has. If you have services that are going to be accessed by old versions of Java, for instance, you may want to take a conservative approach to what enctypes you add for those principals. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
