KDC TGT enctype selection question

[Greg Hudson]

On 12/4/23 17:48, Ken Hornstein via krbdev wrote:> 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.

When this logic was written, we still expected rc4-hmac-exp (40-bit RC4) 
to be seen in the wild, and there was no session-enctypes string 
attribute.  So one might have had a reason to include rc4-hmac-exp in 
the local TGT's key data (hopefully not as the first key).  The 
downgrade attack would be to try printing a TGT encrypted in a random 
rc4-hmac-exp key and having it succeed with 2^-40 probability.  That 
might not be an especially practical attack, but it's not within 
comfortable tolerances.

The restriction is probably less necessary in a world with no super-weak 
enctypes, and with the string attribute as an alternative to including 
multiple enctypes in a local TGT key version.  But I don't see a 
compelling reason to relax it.

> So this begs some
> questions: to migrate to another TGT enctype on the KDC, what order do
> we need to upgrade things?

This particular restriction does not inhibit migrating to another TGT 
enctype, because when you migrate you create a new kvno set in the local 
krbtgt entry, keeping around the old kvno for some period of time.  So 
you might have:

   Key: vno 6, shiny-new-enctype
   Key: vno 6, just-ok-enctype
   Key: vno 5, just-ok-enctype
   Key: vno 5, showing-its-age-enctype

A TGT encrypted with just-ok-enctype and kvno 5 will still be accepted, 
because just-ok-enctype is still the first key of kvno 5.

We do have a long-standing[1] race with any krbtgt rotation, unrelated 
to the first-key restriction: when you add the new kvno to the primary 
KDC, it will immediately start vending TGTs encrypted in kvno 6, which 
can't be accepted by replica KDCs until the new entry has propagated.

[1] https://mv-ezproxy-com.ezproxyberklee.flo.org/rt/Ticket/Display.html?id=5338