KDC TGT enctype selection question

[Ken Hornstein]

I am trying to help a site I work with debug a nasty enctype problem they
ran into recently, and I ran into what I _think_ might be a related (but
not exactly the same) issue.

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

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:

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.

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

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

This occurs because of the following code in kdc_util.c:kdc_rd_ap_req():

    /*
     * 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;
    }

And the resulting TGT decryption fails because the first key is the
sha384 key _and_ the TGT key retrieved by find_server_key() is the first
one (because search_enctype is -1) which is the sha384 key, and that doesn't
match the enctype in the TGT ticket (which is sha1).

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.

--Ken