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. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
