Enctype Negotiation Problem

Given the KDB entry:

kadmin: getprinc host/cerberus.ait.iastate.edu
Principal: host/cerberus.ait.iastate.edu@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},
[email]rose@IASTATE.EDU[/email] for host/cerberus.ait.iastate.edu@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.
---------------------- relevant sections of krb5.conf ----------------------
[libdefaults]
ticket_lifetime = 600
default_realm = IASTATE.EDU
default_etypes = des-cbc-crc
default_tkt_enctypes = des-cbc-crc
default_tgs_enctypes = des-cbc-crc
krb4_srvtab = /etc/srvtab
krb4_config = /etc/krb.conf
krb4_realms = /etc/krb.realms
[realms]
IASTATE.EDU = {
kdc = kerberos-1.iastate.edu
kdc = kerberos-2.iastate.edu
admin_server = kerberos-1.iastate.edu:749
default_domain = iastate.edu
supported_enctypes = des-cbc-crc:normal des-cbc-crc:v4
[domain_realm]
.ait.iastate.edu = IASTATE.EDU
.iastate.edu = IASTATE.EDU
________________________________________________
Kerberos mailing list [email]Kerberos@mit.edu[/email]
[url]https://mailman.mit.edu/mailman/listinfo/kerberos[/url]

John Hascall <john@iastate.edu> writes:[color=blue]
> Given the KDB entry:
>
> kadmin: getprinc host/cerberus.ait.iastate.edu
> Principal: host/cerberus.ait.iastate.edu@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},
> [email]rose@IASTATE.EDU[/email] for host/cerberus.ait.iastate.edu@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.[/color]

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
________________________________________________
Kerberos mailing list [email]Kerberos@mit.edu[/email]
[url]https://mailman.mit.edu/mailman/listinfo/kerberos[/url]

On Wednesday, October 11, 2006 06:16:33 PM -0400 Marcus Watts
<mdw@umich.edu> wrote:

[color=blue]
> 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".[/color]

Except the issue here is he's getting a DES_CBC_MD4 session key when he
wants DES_CBC_CRC. The "why" is likely in the code you're quoting -
DES_CBC_MD4 is a "better" enctype, and both sides appear to support it
(since the single-des types are interchangeable).

I'd be curious to know how the resulting ticket is not "useful"; that is,
what application is being used and what error results when attempting to
use that ticket.

-- Jeff
________________________________________________
Kerberos mailing list [email]Kerberos@mit.edu[/email]
[url]https://mailman.mit.edu/mailman/listinfo/kerberos[/url]

[color=blue]
> Except the issue here is he's getting a DES_CBC_MD4 session key when he
> wants DES_CBC_CRC. The "why" is likely in the code you're quoting -
> DES_CBC_MD4 is a "better" enctype, and both sides appear to support it
> (since the single-des types are interchangeable).[/color]
[color=blue]
> I'd be curious to know how the resulting ticket is not "useful"; that is,
> what application is being used and what error results when attempting to
> use that ticket.[/color]

Here is the error reported by the user:

$ telnet -fax cerberus.ait.iastate.edu
Encryption is verbose
Trying 129.186.145.115...
Connected to cerberus.ait.iastate.edu.
Escape character is '^]'.
[ Trying mutual KERBEROS5 (host/cerberus.ait.iastate.edu@IASTATE.EDU)... ]
[ Kerberos V5 refuses authentication because telnetd:
krb5_rd_req failed: Encryption type not permitted ]
[ Trying KERBEROS5 (host/cerberus.ait.iastate.edu@IASTATE.EDU)... ]
[ Kerberos V5 refuses authentication because telnetd:
krb5_rd_req failed: Encryption type not permitted ]


John
________________________________________________
Kerberos mailing list [email]Kerberos@mit.edu[/email]
[url]https://mailman.mit.edu/mailman/listinfo/kerberos[/url]

On Wednesday, October 11, 2006 06:06:08 PM -0500 John Hascall
<john@iastate.edu> wrote:
[color=blue]
>[color=green]
>> Except the issue here is he's getting a DES_CBC_MD4 session key when he
>> wants DES_CBC_CRC. The "why" is likely in the code you're quoting -
>> DES_CBC_MD4 is a "better" enctype, and both sides appear to support it
>> (since the single-des types are interchangeable).[/color]
>[color=green]
>> I'd be curious to know how the resulting ticket is not "useful"; that
>> is, what application is being used and what error results when
>> attempting to use that ticket.[/color]
>
> Here is the error reported by the user:
>
> $ telnet -fax cerberus.ait.iastate.edu
> Encryption is verbose
> Trying 129.186.145.115...
> Connected to cerberus.ait.iastate.edu.
> Escape character is '^]'.
> [ Trying mutual KERBEROS5 (host/cerberus.ait.iastate.edu@IASTATE.EDU)... ]
> [ Kerberos V5 refuses authentication because telnetd:
> krb5_rd_req failed: Encryption type not permitted ]
> [ Trying KERBEROS5 (host/cerberus.ait.iastate.edu@IASTATE.EDU)... ]
> [ Kerberos V5 refuses authentication because telnetd:
> krb5_rd_req failed: Encryption type not permitted ][/color]

Is the telnetd also heimdal? That sounds like either the machine running
telnetd is configured to require des-cbc-crc, or its keytab contains only a
des-cbc-crc key. You can fix the latter problem by using ktutil to copy
the keytab to a v4 srvtab and back.

-- Jeff
________________________________________________
Kerberos mailing list [email]Kerberos@mit.edu[/email]
[url]https://mailman.mit.edu/mailman/listinfo/kerberos[/url]