Ticket enctype question - Kerberos

This is a discussion on Ticket enctype question - Kerberos ; Hello all, We're in the process of enabling additional enctypes in a K5 realm that previously only had DES keys. Our kdc.conf file now reads (in part): master_key_type = des-cbc-crc supported_enctypes = des-cbc-crc:normal des3-cbc-sha1:normal aes256-cts:normal I've rekeyed the krbtgt key ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Ticket enctype question

  1. Ticket enctype question

    Hello all,

    We're in the process of enabling additional enctypes in a K5 realm that
    previously only had DES keys. Our kdc.conf file now reads (in part):

    master_key_type = des-cbc-crc
    supported_enctypes = des-cbc-crc:normal des3-cbc-sha1:normal aes256-cts:normal

    I've rekeyed the krbtgt key of our realm (with -keepold) to add the new
    enctypes, and my user principal has had its password changed to acquire
    new enctypes:

    Principal: krbtgt/stanford.edu@stanford.edu
    Expiration date: [never]
    Last password change: Thu Aug 31 06:05:13 PDT 2006
    Password expiration date: [none]
    Maximum ticket life: 1 day 01:00:00
    Maximum renewable life: 7 days 00:00:00
    Last modified: Thu Aug 31 06:05:13 PDT 2006 (rra/admin@stanford.edu)
    Last successful authentication: [never]
    Last failed authentication: [never]
    Failed password attempts: 0
    Number of keys: 4
    Key: vno 2, DES cbc mode with CRC-32, no salt
    Key: vno 2, Triple DES cbc mode with HMAC/sha1, no salt
    Key: vno 2, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
    Key: vno 1, DES cbc mode with CRC-32, no salt
    Attributes:
    Policy: [none]

    Principal: rra@stanford.edu
    Expiration date: [never]
    Last password change: Tue Mar 28 11:05:10 PST 2006
    Password expiration date: [none]
    Maximum ticket life: 1 day 01:00:00
    Maximum renewable life: 7 days 00:00:00
    Last modified: Thu Aug 10 16:27:53 PDT 2006 (rra/admin@stanford.edu)
    Last successful authentication: [never]
    Last failed authentication: [never]
    Failed password attempts: 0
    Number of keys: 3
    Key: vno 10, DES cbc mode with CRC-32, no salt
    Key: vno 10, Triple DES cbc mode with HMAC/sha1, no salt
    Key: vno 10, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
    Attributes: REQUIRES_PRE_AUTH
    Policy: standard

    However, when I run klist -5e after running kinit, I see:

    Ticket cache: FILE:/tmp/krb5cc_1000_TsmYeM
    Default principal: rra@stanford.edu

    Valid starting Expires Service principal
    08/31/06 09:14:36 09/01/06 10:14:33 krbtgt/stanford.edu@stanford.edu
    Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, DES cbc mode with CRC-32

    Why is the tkt encrypted with des-cbc-crc? Is there some other key that
    also needs to be rekeyed, or some configuration error somewhere?

    The client is not setting any enctype restrictions; the complete
    [libdefaults] section on the client is:

    default_realm = stanford.edu
    krb4_config = /etc/krb.conf
    krb4_realms = /etc/krb.realms

    The relevant KDC log messages are:

    Aug 31 09:14:20 kerberos3 krb5kdc[27556]: AS_REQ (7 etypes {18 17 16 23 1 3 2}) 171.64.19.147: NEEDED_PREAUTH: rra@stanford.edu for krbtgt/stanford.edu@stanford.edu, Additional pre-authentication required
    Aug 31 09:14:24 kerberos3 krb5kdc[27556]: AS_REQ (7 etypes {18 17 16 23 1 3 2}) 171.64.19.147: ISSUE: authtime 1157040864, etypes {rep=18 tkt=1 ses=18}, rra@stanford.edu for krbtgt/stanford.edu@stanford.edu

    That tkt=1 is the problem.

    The master key (K/M@stanford.edu) is des-cbc-crc, of course, but my
    understanding was that that was not supposed to affect the bits on the
    wire. Is my understanding incorrect?

    --
    Russ Allbery (rra@stanford.edu)

  2. Re: Ticket enctype question

    >We're in the process of enabling additional enctypes in a K5 realm that
    >previously only had DES keys. Our kdc.conf file now reads (in part):
    >
    >master_key_type = des-cbc-crc
    >supported_enctypes = des-cbc-crc:normal des3-cbc-sha1:normal aes256-cts:normal


    There's a implied preference order to the keys listed in
    supported_enctypes. If you want AES to be used for tickets (when
    possible, of course), you should list that first.

    (For session keys, the list send by the client is used as the preference
    order).

    --Ken
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  3. Re: Ticket enctype question

    Ken Hornstein writes:

    >> We're in the process of enabling additional enctypes in a K5 realm that
    >> previously only had DES keys. Our kdc.conf file now reads (in part):
    >>
    >> master_key_type = des-cbc-crc
    >> supported_enctypes = des-cbc-crc:normal des3-cbc-sha1:normal aes256-cts:normal


    > There's a implied preference order to the keys listed in
    > supported_enctypes. If you want AES to be used for tickets (when
    > possible, of course), you should list that first.


    > (For session keys, the list send by the client is used as the preference
    > order).


    Thanks to both you and Jeff Altman (who sent me the same detail privately)
    for the diagnosis. I had tried changing the kdc.conf and restarting the
    KDC, but the preference order is apparently encoded in the database at the
    time the key is changed. I'll change the key again after changing
    kdc.conf to fix the preference order.

    --
    Russ Allbery (rra@stanford.edu)

  4. Re: Ticket enctype question

    * Ken Hornstein [20060831 10:40]:
    > >We're in the process of enabling additional enctypes in a K5 realm that
    > >previously only had DES keys. Our kdc.conf file now reads (in part):
    > >
    > >master_key_type = des-cbc-crc
    > >supported_enctypes = des-cbc-crc:normal des3-cbc-sha1:normal aes256-cts:normal

    >
    > There's a implied preference order to the keys listed in
    > supported_enctypes. If you want AES to be used for tickets (when
    > possible, of course), you should list that first.
    >
    > (For session keys, the list send by the client is used as the preference
    > order).


    An interesting interoperability wrinkle arises if you have any Windows
    2K/XP machines with native kerberos libraries (not KfW) pointed at
    your MIT KDC for authentication. In my experiments a few months ago,
    such machines *fail* to get tickets if the first enctype listed in the
    KDC's 'supported_enctypes' is not 'des-cbc-crc:normal'.

    In other words, when I tried reversing the order of 'supported_enctypes'
    like this:

    supported_enctypes = aes256-cts:normal des3-cbc-sha1:normal \
    des-cbc-crc:normal

    I found that native windows clients could no longer authenticate to the
    KDC. Perhaps Vista will support enctypes other than single DES...

    Has anyone else seen this?

    Ben
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  5. Re: Ticket enctype question

    >An interesting interoperability wrinkle arises if you have any Windows
    >2K/XP machines with native kerberos libraries (not KfW) pointed at
    >your MIT KDC for authentication. In my experiments a few months ago,
    >such machines *fail* to get tickets if the first enctype listed in the
    >KDC's 'supported_enctypes' is not 'des-cbc-crc:normal'.
    >
    >In other words, when I tried reversing the order of 'supported_enctypes'
    >like this:
    >
    > supported_enctypes = aes256-cts:normal des3-cbc-sha1:normal \
    > des-cbc-crc:normal


    Hrm. I've definately made it work without des-cbc-crc in the front.

    >I found that native windows clients could no longer authenticate to the
    >KDC. Perhaps Vista will support enctypes other than single DES...


    Didn't try arcfour, did you?

    --Ken
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  6. Re: Ticket enctype question

    * Ken Hornstein [20060831 11:30]:
    > >In other words, when I tried reversing the order of 'supported_enctypes'
    > >like this:
    > >
    > > supported_enctypes = aes256-cts:normal des3-cbc-sha1:normal \
    > > des-cbc-crc:normal

    >
    > Hrm. I've definately made it work without des-cbc-crc in the front.


    It's good to hear that you've had it work. I'll have to experiment some
    more.

    > >I found that native windows clients could no longer authenticate to the
    > >KDC. Perhaps Vista will support enctypes other than single DES...

    >
    > Didn't try arcfour, did you?


    No, I definitely didn't.

    Ben


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (GNU/Linux)

    iD8DBQFE9ywokRipTWr1IBkRAqzdAKCdFzFcOqN3MNEsc0XWAZ UTREh+FgCdFAte
    KuoXKCqiNw+J+KiR3buICOA=
    =V6si
    -----END PGP SIGNATURE-----


  7. Re: Ticket enctype question

    >>>>> "Ben" == Ben Poliakoff writes:

    Ben> An interesting interoperability wrinkle arises if you have
    Ben> any Windows 2K/XP machines with native kerberos libraries
    Ben> (not KfW) pointed at your MIT KDC for authentication. In my
    Ben> experiments a few months ago, such machines *fail* to get
    Ben> tickets if the first enctype listed in the KDC's
    Ben> 'supported_enctypes' is not 'des-cbc-crc:normal'.

    That has not been MIT's experience doing interoperability testing with
    Microsoft.

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  8. Re: Ticket enctype question

    I have seen this behaviour changing between MS hotfixes for 2003.

    Markus

    "Sam Hartman" wrote in message
    news:tslu03svilc.fsf@cz.mit.edu...
    >>>>>> "Ben" == Ben Poliakoff writes:

    >
    > Ben> An interesting interoperability wrinkle arises if you have
    > Ben> any Windows 2K/XP machines with native kerberos libraries
    > Ben> (not KfW) pointed at your MIT KDC for authentication. In my
    > Ben> experiments a few months ago, such machines *fail* to get
    > Ben> tickets if the first enctype listed in the KDC's
    > Ben> 'supported_enctypes' is not 'des-cbc-crc:normal'.
    >
    > That has not been MIT's experience doing interoperability testing with
    > Microsoft.
    >
    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >




+ Reply to Thread