KDC TGT enctype selection question

[Greg Hudson]

On 12/6/23 14:07, Ken Hornstein via krbdev wrote:
> what is the reason the AES2 enctypes
> are later in the list of default enctypes than the SHA1 AES enctypes?

It helps mitigate the problem that don't make it perfectly easy to match 
the enctypes supported by a service to the enctypes present in the 
long-term keys for that service.  (Nico has advocated for making kadmin 
randkey use the kadmin client's supported_enctypes value instead of the 
KDC's, and I think that would be a good change, but it still wouldn't 
make us perfect.)

This problem gets less important over time (although to my knowledge 
Microsoft hasn't implemented aes-sha2), and would not outweigh a 
serious difference in security if there were one.  But since SHA-1's 
collision weaknesses don't impact HMACs, the advantage of aes-sha2 
enctypes is more about conformance than security.  (There are admittedly 
cases where the 96-bit size of aes-sha1 checksums can impact 
security--this came up in a recent set of PAC vulnerabilities, although 
it was overshadowed by larger vulnerabilities in RC4 enctypes. 
Basically, if you checksum over a checksum and your protocol has a 
checksum oracle, you become subject to the birthday bound of the inner 
checksum size.  So far I'm modeling this as an unusual confluence of 
protocol properties and not an aes-sha1 enctype weakness.)

Less importantly, the aes-sha1 enctypes are proposed standard and the 
aes-sha2 enctypes are informational.