Enctype Negotiation Problem

John Hascall john at iastate.edu
Wed Oct 11 17:49:29 EDT 2006

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})
      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,
  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!

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 ----------------------
        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
        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
        .ait.iastate.edu = IASTATE.EDU
        .iastate.edu = IASTATE.EDU

More information about the Kerberos mailing list