Preauth / AES / MIT Kerberos / TGT des3-cbc-sha1

[Greg Hudson]

On 02/12/2018 10:37 AM, John Tang Boyland wrote:
> What's going on?  Does MIT kerberos not actually support AES256?

Check the keys for the krbtgt/<REALM> principal entry.  The ticket will
always be encrypted in the first of those keys.  I suspect that key is des3.

To explain your three different results:

1. When you use kinit normally, the KDC chooses aes256-cts to encrypt
the reply (you can't see this), des3 to encrypt the ticket, and probably
des3 for the session key.

2. When you use "kinit -e aes128-cts", the KDC can't find a match
between the request enctypes and the client principal keys, since the
client principal has only an aes256-cts key.  The KDC should respond
with a "KDC has no support for encryption type" error, but instead it
says something nonsensical: "you have to do preauth, but I don't have
any preauth mechs which will work".  I will file a ticket for this KDC
behavior.  The Apple kinit has a special error message for this
response, which could probably be improved (but not by a lot; it's hard
to say something useful to a user in this case).

3. When you restrict the request enctypes to aes256-cts aes128-cts
through configuration, the KDC can't select a session key enctype
agreeable to both the request and the server (it assumes that the
server, in this case krbtgt/<REALM>, can only support ticket session
keys matching the enctypes it has keys for).  So it responds with a "KDC
has no support for encryption type" error.