KDC TGT enctype selection question
Sam Hartman
hartmans at debian.org
Mon Dec 4 17:23:43 EST 2023
>>>>> "Ken" == Ken Hornstein via krbdev <krbdev at mit.edu> writes:
Ken> And the resulting TGT decryption fails because the first key is
Ken> the sha384 key _and_ the TGT key retrieved by find_server_key()
Ken> is the first one (because search_enctype is -1) which is the
Ken> sha384 key, and that doesn't match the enctype in the TGT
Ken> ticket (which is sha1).
Ken> The question I have is ... why does this explicit matching for
Ken> the first key in the highest kvno exist for non-crossrealm
Ken> TGTs? The comments say it is deliberate, but I will confess
Ken> that I am not sure why! It is fair to say that having your
Ken> KDCs support and/or issue different encryption types in tickets
Ken> is a misconfiguration, but I can't quite see why things are
Ken> explictly coded that way.
Because there was a bit of an overload between whether the presence of a
key in the database was intended to actually encourage use of that key
for a given service or whether it simply meant that a particular session
key was supported by that service.
Especially when some of the keys were weak but you wanted to retain
those keys on your tgt so you could get session keys of those weak
enctypes for some of your clients/services, we thought it was important
not to allow downgrade attacks to be mounted against the TGS service
itself.
And so, we assumed you ordered your TGS keys based on the order you
actually considered strongest.
--Sam
More information about the krbdev
mailing list