Re: KDC TGT enctype selection question

>>>>> "Ken" == Ken Hornstein via krbdev <[email protected]> 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
_______________________________________________
krbdev mailing list             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev