Enctype Negotiation Problem - Kerberos

This is a discussion on Enctype Negotiation Problem - Kerberos ; 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: ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Enctype Negotiation Problem

  1. 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},
    rose@IASTATE.EDU 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 Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: Enctype Negotiation Problem

    John Hascall writes:
    > 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},
    > rose@IASTATE.EDU 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.


    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 Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  3. Re: Enctype Negotiation Problem



    On Wednesday, October 11, 2006 06:16:33 PM -0400 Marcus Watts
    wrote:


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


    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 Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  4. Re: Enctype Negotiation Problem


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


    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 Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  5. Re: Enctype Negotiation Problem



    On Wednesday, October 11, 2006 06:06:08 PM -0500 John Hascall
    wrote:

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

    >
    > 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 ]


    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 Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


+ Reply to Thread