Re: KDC TGT enctype selection question

>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.

I'm trying to understand the downgrade attack here, because it seems
like it wouldn't be possible without issuing a whole pile of TGTs.  Which
is possible, I suppose, but normally you wouldn't be able to coax a KDC
into issuing a TGT service ticket for a weak enctype.  Also, I think
that the same issue applies to every Kerberized service?  But I can
understand why the TGS would be treated special.

The reason I would like to understand this COMPLETELY is: the realms I
deal with have KDCs that are (a) geographically disparate, (b) managed
by different organizations, (c) usually have different maintenance
schedules, (d) SOMETIMES have different configurations (like above), and
(e) we actually care about enctype migration.  In trying to replicate
another enctype problem, I ran into this problem.  So this begs some
questions: to migrate to another TGT enctype on the KDC, what order do
we need to upgrade things?  If one of the concerns is different KDC
configurations, fair enough, but understanding what is expected to work
and what isn't is extremely critical.

To answer Ben's question:

>Getting back to your initial question, though ... as I see it, Nico, Sam, and
>I have been saying basically the same thing in different words and I think it
>does answer your question.  Do you still think you have an unanswered
>question?  (If so, what is it?)

Alright, I guess my next question is: does this limitation in not accepting
the "wrong" enctype for TGS requests still make sense in 2023?

There isn't the same disparity between enctypes like there was during
the single-DES transition, and I'm concerned about the corner case
mentioned above.  I could also see issues where you have realms that share
TGS keys but have KDCs running different Kerberos implementations, like
a Windows domain controller and MIT Kerberos (I personally find this
situation completely scary and would never do it, but I know it is
done).

--Ken
_______________________________________________
krbdev mailing list             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev