KDC TGT enctype selection question

Benjamin Kaduk kaduk at mit.edu
Mon Dec 4 17:07:25 EST 2023


On Mon, Dec 04, 2023 at 03:44:57PM -0600, Nico Williams wrote:
> On Mon, Dec 04, 2023 at 04:23:08PM -0500, Ken Hornstein wrote:
> > I understand the convention, but it doesn't really answer my question:
> > this is a very explicit coding choice and I can't really see WHY it
> > exists.  For one it could make it difficult to upgrade enctypes when
> > you had geographically-distributed KDCs that were managed by different
> > organizations.  Also, it doesn't really match the expected behavior
> > in terms of other Kerberos enctype negotations and I am trying to
> > understand why.  I am perfectly willing to believe there is something
> > I don't understand!
> 
> It's a very simple convention.  I would strongly advise running the same
> configuration on all the KDCs of any given realm.

I would go even further and say that it is a design assumption of MIT krb5
that all KDCs are just separate instances of the same logical instance and are
assumed to behave "identically" (i.e., with identical configuration).

As Nico says, this particular case seems like the KDC knowing that the enctype
list is sorted strongest-to-weakest, and also knowing that "the KDC" is the
only entity that can create this ciphertext, so enforcing that the strongest
key is being used and preventing by construction any brute-force or other
attacks on krbtgt keys of other enctypes.

-Ben


More information about the krbdev mailing list