[OpenAFS] Kerberos 5 encryption types and AFS

[Russ Allbery]

Jason Edgecombe <openafs@rampaginggeek.com> 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 (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>