Enctype Negotiation Problem

[Marcus Watts]

John Hascall <john at iastate.edu> writes:
> Given the KDB entry:
> 
>    kadmin: getprinc host/cerberus.ait.iastate.edu
>    Principal: host/cerberus.ait.iastate.edu at IASTATE.EDU
>       ...
>    Number of keys: 1
>    Key: vno 6, DES cbc mode with CRC-32, no salt
> 
> and the request:
> 
>    Oct 11 11:24:26 kerberos-1.iastate.edu krb5kdc[21825](info): \
>       TGS_REQ (3 etypes {3 2 1}) 12.216.5.82:
>       ISSUE: authtime 1160583856, etypes {rep=2 tkt=1 ses=2},
>       rose at IASTATE.EDU for host/cerberus.ait.iastate.edu at IASTATE.EDU
> 
> I don't understand why enctype 2 (des-cbc-md4)
> is being selected as the session key's enctype
> when there is only an enctype 1 (des-cbc-crc) key available.
> 
> I *thought* the way it worked was the KDC walked down the
> list of requested enctypes ({3, 2, 1} in this case) and
> found the first one that was both:
>   a) allowed by krb5.conf[libdefaults]permitted_enctypes,
>           and
>   b) there was a key for in the DB.
> 
> [FWIW, we have no permitted_enctypes in our krb5.conf]
> 
> We just upgraded our KDC and the user says this worked(got a useful enctype),
> before (under a 1.2.6 KDC), but it does not now (under our new 1.4.3 KDC).
> 
> Thanks for any help you can give!
> 
> John
> PS, FWIW, the client in this case is running Heimdal (0.4.?)
>     but other Heimdal clients (0.6.3) are working fine.

In the MIT kerberos source, there's a pair of routines select_session_keytype
and dbentry_supports_enctype that are probably making this decision for you.
Here's the comment in dbentry_supports_enctype:
    /*
     * If it's DES_CBC_MD5, there's a bit in the attribute mask which
     * checks to see if we support it.  For now, treat it as always
     * clear.
     *
     * In theory everything's supposed to support DES_CBC_MD5, but
     * that's not the reality....
     */
Unfortunately, that's followed immediately by
	if (enctype == ENCTYPE_DES_CBC_MD5) return 0;
which should have the effect "never use des-cbc-md5".
Presumably the "bit in the attribute mask" never got implemented.
The bit itself appears to be defined -- looks like it's called
KRB5_KDB_SUPPORT_DESMD5 (0x4000) or "support_desmd5".

This should only be an issue for des; for des3, aes, etc., whether a
service supports a given enctype is defined entirely by whether the
service has a key for that type.  The reason for this confusion with
des is that des-cbc-crc, des-cbc-md4, and des-cbc-md5 are treated in some
sense as "interchangeable"; one key can be used for all 3
cryptosystems.  I believe the intent is not to duplicate this behavioral
confusion in present or future cryptosystems.

					-Marcus