KDC TGT enctype selection question

[Ken Hornstein]

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

Fair enough; thank you for explaining some of the backstory.

>> 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:
>[...]

I'm not worried about THIS scenario, it's more about other corner cases I
described earlier (disparate KDCs managed by different groups).  I guess
the thing that struck me the most was that I was under the impression that
like any other Kerberized service, the TGS would accept a service ticket
for any enctype that it knows about.  It does not; fair enough.  I am
also trying to understand any potential pitfalls for enctype migration
because we have some environments that are ... "challenging" might be
the best word.

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

I already knew about that, and I'm not worried so much about that; it's
a self-correcting issue.

As long as we are on the subject, what is the reason the AES2 enctypes
are later in the list of default enctypes than the SHA1 AES enctypes?
That has the practical effect of causing the AES2 enctypes to not be
used that often unless you really try extra hard to configure that
enctype exclusively.  I am sure there is a reason; I am just trying to
think ahead because of the general overall push to slowly migrate away
from anything that uses SHA1.

--Ken