[38202] in Kerberos
Re: Preauth / AES / MIT Kerberos / TGT des3-cbc-sha1
daemon@ATHENA.MIT.EDU (John Tang Boyland)
Mon Feb 12 13:59:37 2018
From: John Tang Boyland <boyland@pabst.cs.uwm.edu>
To: Greg Hudson <ghudson@mit.edu>
In-reply-to: Your message of "Mon, 12 Feb 2018 11:53:02 -0500."
MIME-Version: 1.0
Content-ID: <20680.1518461824.1@pabst.cs.uwm.edu>
Date: Mon, 12 Feb 2018 12:57:04 -0600
Message-ID: <20681.1518461824@pabst.cs.uwm.edu>
Cc: kerberos@mit.edu
Reply-To: boyland@uwm.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Thanks very much!
Your information was very much on target.
(I was embarrassed to see that I had set
a 256 key and asked for a 128 key.)
There is the possible error in your reply that
even changing the 'test' principal to
have both aes128 and aes256 keys was not sufficient
to make Apple's kinit work. But that was before
adding the new keys for the krbtgt/<REALM>.
Adding new keys for krbtgt/<REALM> did the trick.
Everything works now:
$ /usr/bin/kinit -e aes128-cts-hmac-sha1-96 test@<REALM>
test@<REALM>'s password:
$ /usr/bin/klist -v
Credentials cache: API:503:2
Principal: test@<REALM>
Cache version: 0
Server: krbtgt/<REALM>@<REALM>
Client: test@<REALM>
Ticket etype: aes128-cts-hmac-sha1-96, kvno 2
Ticket length: 299
Auth time: Feb 12 12:50:15 2018
End time: Feb 12 22:50:12 2018
Ticket flags: enc-pa-rep, pre-authent, initial, forwardable
Addresses: addressless
Best regards,
John Boyland
] 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
