KDC TGT enctype selection question

[Nico Williams]

On Mon, Dec 04, 2023 at 03:46:44PM -0500, Ken Hornstein via krbdev wrote:
> Let us say you have two KDCs in your realm, KDC A and B.  KDC B has
> the following lines in it's kdc.conf:
> 
> [libdefaults]
>         default_tgs_enctypes = aes256-cts-hmac-sha1-96
>         default_tkt_enctypes = aes256-cts-hmac-sha1-96
>         permitted_enctypes = aes256-cts-hmac-sha1-96

The only one of these that affects the KDC's behavior is
permitted_enctypes.

The other two are client-side settings only.

> KDC A does not have these lines in it's kdc.conf file.  The two realms
> are otherwise identical.  The enctypes for the TGT for this realm are:

The configuration has to be the same though, because otherwise as you've
discovered the TGTs vended by A will not be accepted by B.

> Key: vno 1, aes256-cts-hmac-sha384-192
> Key: vno 1, aes256-cts-hmac-sha1-96
> 
> First, you will say that these configuration settings are NOT RECOMMENDED.
> I agree!  I was not aware that was a common practice at this site.
> 
> If you kinit and contact KDC A, you get the following etypes for your
> TGT:
> 
>         Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha384-192
> 
> Which is not unexpected as most clients prefer sha1-96 right now.

The KDC picked the strongest key for the ticket enc-part that it had
available, which was aes256-cts-hmac-sha384-192 because
permitted_enctypes wasn't set and because the default value of
permitted_enctypes includes that particular enctype.

The KDC picked aes256-cts-hmac-sha1-96 for the session key because that
was the strongest enctype in the client's request's body's etype field.

> But if you kinit and contact KDC B, you get the following etypes for
> your TGT:
> 
>         Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

Similarly as above, except that B's permitted_enctypes was more
constrained.

> Which I suppose is also not unexpected because of the permitted_enctypes
> line in KDC B's kdc.conf file.  This TGT works fine _if_ you contact KDC B.
> But _if_ you take this TGT and contact KDC A and try to get a service
> ticket it will fail with "Bad encryption type".

I'd expect this sort of failure given the configurations you've
described.  Don't do this.

>     /*
>      * When we issue tickets we use the first key in the principals' highest
>      * kvno keyset.  For non-cross-realm krbtgt principals we want to only
>      * allow the use of the first key of the principal's keyset that matches
>      * the given kvno.
>      */
>     if (krb5_is_tgs_principal(apreq->ticket->server) &&
>         !is_cross_tgs_principal(apreq->ticket->server)) {
>         search_enctype = -1;
>         match_enctype = 0;
>     }
> 
> [...]
> 
> The question I have is ... why does this explicit matching for the first
> key in the highest kvno exist for non-crossrealm TGTs?  The comments say
> it is deliberate, but I will confess that I am not sure why!  It is fair
> to say that having your KDCs support and/or issue different encryption
> types in tickets is a misconfiguration, but I can't quite see why
> things are explictly coded that way.

The general convention is that a principal's long term keys are ordered
from strongest to weakest, thus picking the first key that is approved
by local policy (permitted_enctypes) is generally what you want.  This
is just a convention.

I suspect that for root TGS principals (krbtgt/REALM at REALM where the two
REALMs are the same) the convention MIT wants is that the first key _is_
the key to use always, and woe unto you then if that key's enctype is
not in the permitted_enctypes.

I'm not sure how B ends up accepting the TGTs that it vends though, in
this case, given that it shouldn't be accepting the second key to
decrypt the TGT's enc-part.

Nico
--