Updating encryption types - Kerberos

This is a discussion on Updating encryption types - Kerberos ; So reading through: http://web.mit.edu/kerberos/www/krb5...ryption%20Keys (the upgrading encryption types page)... regarding this sentence "Because of the way the MIT Kerberos database is structured, the KDC will assume that a service supports only those encryption types for which keys are found in ...

+ Reply to Thread
Results 1 to 19 of 19

Thread: Updating encryption types

  1. Updating encryption types

    So reading through:

    http://web.mit.edu/kerberos/www/krb5...ryption%20Keys

    (the upgrading encryption types page)... regarding this sentence "Because of
    the way the MIT Kerberos database is structured, the KDC will assume that a
    service supports only those encryption types for which keys are found in the
    database."

    That makes me think that even if kdc.conf has:

    default_tgs_enctypes = arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc

    and krb5.conf has:

    default_tkt_enctypes = arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc
    default_tgs_enctypes = arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc

    Any principals created before the switchover will obviously be stored in the
    old encryption type - but during authentication, what encryption type will be
    used between the client and the KDC?

    I'm a bit confused as to what all will use the new encryption types and what
    will use the old encryption types.

    Thanks.
    --
    Phil Dibowitz
    Systems Architect and Administrator
    Enterprise Infrastructure / ISD / USC
    UCC 180 - 213-821-5427


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

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

    iD8DBQFCxQlZ7lkZ1Iyv898RAkEDAJ9FN49wq8D1A2ZT1+7hzE FptOcA7wCgwRCJ
    wclaUGqhnfRi91uCqo9Zqrc=
    =wjjK
    -----END PGP SIGNATURE-----


  2. Re: Updating encryption types



    On Friday, July 01, 2005 02:14:02 AM -0700 Phil Dibowitz
    wrote:

    > So reading through:
    >
    >
    > http://web.mit.edu/kerberos/www/krb5...5-install/Upgr
    > ading-to-Triple-DES-and-RC4-Encryption-Keys.html#Upgrading%20to%20Triple-
    > DES%20and%20RC4%20Encryption%20Keys
    >
    > (the upgrading encryption types page)... regarding this sentence "Because
    > of the way the MIT Kerberos database is structured, the KDC will assume
    > that a service supports only those encryption types for which keys are
    > found in the database."
    >
    > That makes me think that even if kdc.conf has:
    >
    > default_tgs_enctypes = arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc
    >
    > and krb5.conf has:
    >
    > default_tkt_enctypes = arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc
    > default_tgs_enctypes = arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc
    >
    > Any principals created before the switchover will obviously be stored in
    > the old encryption type - but during authentication, what encryption type
    > will be used between the client and the KDC?
    >
    > I'm a bit confused as to what all will use the new encryption types and
    > what will use the old encryption types.



    When responding to an initial ticket request, the KDC chooses three keys:

    (1) The key in which the KDC's reply to the client will be encrypted.
    This key will be of one of the enctypes the KDC supports.
    This key will be of one of the enctypes the client says it supports.
    And, this key will be one of the client's long-term keys from the
    KDB, which means it will naturally be of one of the enctypes for
    which the KDB contains a key for this client.

    (2) The key in which the private parts of the new ticket will be encrypted.
    This key will be one of the enctypes the KDC supports.
    This key will be one of the service's long-term keys from the KDB,
    which means it will naturally be one of the enctypes for which the KDB
    contains a key for the requested service (usually krbtgt/REALM@REALM).
    The client has no ability to affect the enctype of this key (except
    that some versions of some KDC implementations contain a bug in which
    the KDC considers only keys supported by the client).

    (3) The session key contained in the new ticket.
    This key will be one of the enctypes the KDC supports.
    This key will be one of the enctypes the client says it supports;
    however, it need not be one for which the client has a long-term key.
    This key will be one of the enctypes known by the KDC to be supported
    by the server. There is nothing in the Kerberos protocol which
    requires that this be the enctype of one of the service's long-term
    keys; however, the MIT implementation uses that list to decide what
    enctypes it thinks the server supports.


    When responding to an additional ticket request, the KDC chooses keys for
    the same three roles. However, the key used in role (1) is normally the
    session key from the client's TGT, and thus its enctype was chosen at the
    time the TGT was issued (alternately, it may be a sub-session key chosen by
    the client, which may be any enctype supported by both the client and KDC.
    Of course, the only enctypes the client knows are supported by the KDC are
    those used in its TGT). The keys used in roles (2) and (3) are chosen in
    the same way as for initial tickets.


    So, communicaton during an initial ticket exchange can be protected only by
    one of the client's long-term keys in the KDB. That means that no matter
    what enctype settings are used on either client or KDC, you can't get it to
    use an enctype for which the user doesn't have a key. To do that, the user
    will have to change his password so the admin server can generate a key for
    him for the new enctype.


    Note that there are very few good reasons to configure clients for a
    specific set of enctypes. In fact, under normal circumstances the only
    place you should have to configure enctypes is on the admin server, which
    needs to know which enctypes to generate keys for in the KDB. As long as
    the KDB entry for each _service_ contains only keys of enctypes actually
    supported by that service, everything should work fine.

    The one major exception is if you have a client workstation on which a
    single credential cache will be shared by multiple Kerberos implementations
    which do not all support the same set of enctypes. In that case, you may
    want or need to restrict the set of enctypes used on that client to those
    which are supported by all implementations.

    -- Jeffrey T. Hutzelman (N3NHS)
    Sr. Research Systems Programmer
    School of Computer Science - Research Computing Facility
    Carnegie Mellon University - Pittsburgh, PA

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


  3. Re: Updating encryption types

    On Fri, Jul 01, 2005 at 06:03:52AM -0400, Jeffrey Hutzelman wrote:
    > When responding to an initial ticket request, the KDC chooses three keys:
    >
    > (1) The key in which the KDC's reply to the client will be encrypted.
    > This key will be of one of the enctypes the KDC supports.
    > This key will be of one of the enctypes the client says it supports.
    > And, this key will be one of the client's long-term keys from the
    > KDB, which means it will naturally be of one of the enctypes for
    > which the KDB contains a key for this client.




    After reading this and Will Fiveash's slides, I think I have a better
    understanding.... but let me make a few simplified restatements to make sure
    I'm correct:

    1. Changing the enctypes (the previous admin had it hard coded) will cause
    session keys to use the new enctypes, but other keys will not immediately see
    effect.

    2. As users change their password, the kadmind will generate their secret keys
    in all supported formats, and provided a client supports that encryption type,
    the higher encryption types will be used.

    So far, so good?

    Which leaves me with a question:

    Is there a way to tell what encryption type is being used for the session
    key? I'm assuming the "3 etypes {511 511 1}" means there are three encryption
    types defined (which seems right)... but then there's "etypes {rep=1 tkt=1
    ses=1}" which I interpret to say the session key is type "1" (DES?).

    Thanks.

    --
    Phil Dibowitz
    Systems Architect and Administrator
    Enterprise Infrastructure / ISD / USC
    UCC 180 - 213-821-5427


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

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

    iD8DBQFCxbs37lkZ1Iyv898RAl74AJ9BLLdXuPR45jgayblr60 nLSbPGEACfeZNO
    sOcgTW1Sz88Fq3vv7XwpGVU=
    =Wbhe
    -----END PGP SIGNATURE-----


  4. Re: Updating encryption types

    On Fri, Jul 01, 2005 at 02:52:55PM -0700, Phil Dibowitz wrote:
    > On Fri, Jul 01, 2005 at 06:03:52AM -0400, Jeffrey Hutzelman wrote:
    > > When responding to an initial ticket request, the KDC chooses three keys:
    > >
    > > (1) The key in which the KDC's reply to the client will be encrypted.
    > > This key will be of one of the enctypes the KDC supports.
    > > This key will be of one of the enctypes the client says it supports.
    > > And, this key will be one of the client's long-term keys from the
    > > KDB, which means it will naturally be of one of the enctypes for
    > > which the KDB contains a key for this client.

    >
    >
    >
    > After reading this and Will Fiveash's slides, I think I have a better
    > understanding.... but let me make a few simplified restatements to make sure
    > I'm correct:
    >
    > 1. Changing the enctypes (the previous admin had it hard coded) will cause
    > session keys to use the new enctypes, but other keys will not immediately see
    > effect.


    If you mean creating a new set of enctype keys for service princs will
    have an immediate effect on the enctype of sessions keys issued after
    the new keys are created then yes (make sure the service systems
    krb5.keytab is updated also). I am not sure what you mean by "other
    keys".

    > 2. As users change their password, the kadmind will generate their secret keys
    > in all supported formats, and provided a client supports that encryption type,
    > the higher encryption types will be used.


    I think that is true. You should verify this if you have a system with
    limited enctype support using a KDC that supports a larger set.

    > So far, so good?
    >
    > Which leaves me with a question:
    >
    > Is there a way to tell what encryption type is being used for the session
    > key? I'm assuming the "3 etypes {511 511 1}" means there are three encryption
    > types defined (which seems right)... but then there's "etypes {rep=1 tkt=1
    > ses=1}" which I interpret to say the session key is type "1" (DES?).


    klist -e should show something like:
    $ klist -e
    Ticket cache: FILE:/tmp/krb5cc_10224
    Default principal: jimmy@SUN.COM

    Valid starting Expires Service principal
    07/04/05 15:12:13 07/04/05 23:12:13 krbtgt/SUN.COM@SUN.COM
    renew until 07/11/05 15:12:13, Etype(skey, tkt): AES-128 CTS mode with 96-bit SHA-1 HMAC, AES-128 CTS mode with 96-bit SHA-1 HMAC

    If the enctypes are not being mapped to the more readable form it may be
    that the enctype is not known on the system that is trying to
    interperate the low level enctype IDs. Anyway, I know RFC 1510 has some
    of the older enctype IDs:

    ---------------+-----------+----------+----------------+---------------
    Encryption type|etype value|block size|minimum pad size|confounder size
    ---------------+-----------+----------+----------------+---------------
    NULL 0 1 0 0
    des-cbc-crc 1 8 4 8
    des-cbc-md4 2 8 0 8
    des-cbc-md5 3 8 0 8

    and draft-raeburn-krb-rijndael-krb-05.txt has:

    +--------------------------------------------------------------------+
    | encryption types |
    +--------------------------------------------------------------------+
    | type name etype value key size |
    +--------------------------------------------------------------------+
    | aes128-cts-hmac-sha1-96 17 128 |
    | aes256-cts-hmac-sha1-96 18 256 |
    +--------------------------------------------------------------------+
    --
    Will Fiveash
    Sun Microsystems Inc.
    Austin, TX, USA (TZ=CST6CDT)
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  5. Re: Updating encryption types

    On Jul 4, 2005, at 16:29, Will Fiveash wrote:
    > On Fri, Jul 01, 2005 at 02:52:55PM -0700, Phil Dibowitz wrote:
    >> Is there a way to tell what encryption type is being used for the
    >> session
    >> key? I'm assuming the "3 etypes {511 511 1}" means there are three
    >> encryption
    >> types defined (which seems right)... but then there's "etypes {rep=1
    >> tkt=1
    >> ses=1}" which I interpret to say the session key is type "1" (DES?).


    The "3 etypes" bit should be for the encryption types the client
    indicates to the KDC that it supports (or that it wants used), in the
    request message. (Though I don't know what 511 would be; in the MIT
    code, 0x1ff is ENCTYPE_UNKNOWN, but we shouldn't be transmitting that
    in any requests. Are you actually seeing the above with an MIT
    client?)


    > Anyway, I know RFC 1510 has some
    > of the older enctype IDs:


    > and draft-raeburn-krb-rijndael-krb-05.txt has:


    http://www.iana.org/assignments/kerberos-parameters has these now, btw,
    except for changing 0 from "NULL" to "reserved". (Though the
    references are outdated and should point to RFCs; I've just asked IANA
    to fix that.)

    Ken

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


  6. Re: Updating encryption types

    On Mon, Jul 04, 2005 at 03:29:11PM -0500, Will Fiveash wrote:
    > > 1. Changing the enctypes (the previous admin had it hard coded) will cause
    > > session keys to use the new enctypes, but other keys will not immediately see
    > > effect.

    >
    > If you mean creating a new set of enctype keys for service princs will
    > have an immediate effect on the enctype of sessions keys issued after
    > the new keys are created then yes (make sure the service systems
    > krb5.keytab is updated also). I am not sure what you mean by "other
    > keys".


    What i meant was "changing enctypes in kdc.conf and krb5.conf and doing
    nothing else should at best up the encryption of the session keys. Nothing
    else will change until password are changed."

    > > Is there a way to tell what encryption type is being used for the session
    > > key? I'm assuming the "3 etypes {511 511 1}" means there are three encryption
    > > types defined (which seems right)... but then there's "etypes {rep=1tkt=1
    > > ses=1}" which I interpret to say the session key is type "1" (DES?).

    >
    > klist -e should show something like:
    > $ klist -e
    > Ticket cache: FILE:/tmp/krb5cc_10224
    > Default principal: jimmy@SUN.COM
    >
    > Valid starting Expires Service principal
    > 07/04/05 15:12:13 07/04/05 23:12:13 krbtgt/SUN.COM@SUN.COM
    > renew until 07/11/05 15:12:13, Etype(skey, tkt): AES-128 CTS modewith 96-bit SHA-1 HMAC, AES-128 CTS mode with 96-bit SHA-1 HMAC


    Ah, very cool. So in my test environment I have a KDC with a bunch of DES
    encrypted principals. I changed the "enctypes" on both krb5.conf and kdc.conf
    from des to rc4, des3, and des, and changed the password on my principal.I
    now see:

    Number of keys: 3
    Key: vno 10, ArcFour with HMAC/md5, no salt
    Key: vno 10, Triple DES cbc mode with HMAC/sha1, no salt
    Key: vno 10, DES cbc mode with CRC-32, no salt
    Attributes:

    from kadmin, great (though is that "no salt" supposed to be there?)!

    However, klist -e shows:

    [phil@frantic unstale]$ klist -e
    Ticket cache: FILE:/tmp/krb5cc_36070
    Default principal: phil@ISD.USC.EDU

    Valid starting Expires Service principal
    07/05/05 13:36:31 07/05/05 23:36:31 krbtgt/ISD.USC.EDU@ISD.USC.EDU
    Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with CRC-32
    [phil@frantic unstale]$

    and the logs show:

    Jul 05 13:36:31 frantic.usc.edu krb5kdc[26284](info): AS_REQ (3 etypes {23 16
    1}) 128.125.10.120: ISSUE: authtime 1120595791, etypes {rep=23 tkt=1 ses=1},
    phil@ISD.USC.EDU for krbtgt/ISD.USC.EDU@ISD.USC.EDU

    Neither the session key, nor my principal key seem to have been using the new
    encryption... it's not clear to me why...

    --
    Phil Dibowitz
    Systems Architect and Administrator
    Enterprise Infrastructure / ISD / USC
    UCC 180 - 213-821-5427


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

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

    iD8DBQFCyvI17lkZ1Iyv898RAi1bAJ9CtR3xGmUMm9xIQ2BKKK OANfK9mACeNVRt
    NODoCiQmda6utI3T6Ug4+ks=
    =mVqA
    -----END PGP SIGNATURE-----


  7. Re: Updating encryption types

    On Tue, Jul 05, 2005 at 01:48:54PM -0700, Phil Dibowitz wrote:
    > from kadmin, great (though is that "no salt" supposed to be there?)!
    >
    > However, klist -e shows:
    >
    > [phil@frantic unstale]$ klist -e
    > Ticket cache: FILE:/tmp/krb5cc_36070
    > Default principal: phil@ISD.USC.EDU
    >
    > Valid starting Expires Service principal
    > 07/05/05 13:36:31 07/05/05 23:36:31 krbtgt/ISD.USC.EDU@ISD.USC.EDU
    > Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with CRC-32
    > [phil@frantic unstale]$
    >
    > and the logs show:
    >
    > Jul 05 13:36:31 frantic.usc.edu krb5kdc[26284](info): AS_REQ (3 etypes {23 16
    > 1}) 128.125.10.120: ISSUE: authtime 1120595791, etypes {rep=23 tkt=1 ses=1},
    > phil@ISD.USC.EDU for krbtgt/ISD.USC.EDU@ISD.USC.EDU
    >
    > Neither the session key, nor my principal key seem to have been using thenew
    > encryption... it's not clear to me why...



    Anyone?


    --
    Phil Dibowitz
    Systems Architect and Administrator
    Enterprise Infrastructure / ISD / USC
    UCC 180 - 213-821-5427


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

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

    iD8DBQFCzF3o7lkZ1Iyv898RApbuAJ9MCeA4YA/E7OlDhLM06GADPF82nACcCBes
    EKFcyOKc6LywjoDS9kjvK0Y=
    =RTiL
    -----END PGP SIGNATURE-----


  8. Re: Updating encryption types

    > On Tue, Jul 05, 2005 at 01:48:54PM -0700, Phil Dibowitz wrote:
    > > from kadmin, great (though is that "no salt" supposed to be there?)!
    > >=20
    > > However, klist -e shows:
    > >=20
    > > [phil@frantic unstale]$ klist -e
    > > Ticket cache: FILE:/tmp/krb5cc_36070
    > > Default principal: phil@ISD.USC.EDU
    > >=20
    > > Valid starting Expires Service principal
    > > 07/05/05 13:36:31 07/05/05 23:36:31 krbtgt/ISD.USC.EDU@ISD.USC.EDU
    > > Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with CR=

    > C-32=20
    > > [phil@frantic unstale]$=20
    > >=20
    > > and the logs show:
    > >=20
    > > Jul 05 13:36:31 frantic.usc.edu krb5kdc[26284](info): AS_REQ (3 etypes {2=

    > 3 16
    > > 1}) 128.125.10.120: ISSUE: authtime 1120595791, etypes {rep=3D23 tkt=3D1 =

    > ses=3D1},
    > > phil@ISD.USC.EDU for krbtgt/ISD.USC.EDU@ISD.USC.EDU
    > >=20
    > > Neither the session key, nor my principal key seem to have been using the=

    > new
    > > encryption... it's not clear to me why...

    >
    >
    > Anyone?


    My guess is that your krbtgt/ISD.ISC.EDU@ISD.USC.EDU principal still
    only has a des key. 'cpw -randkey -keepold' on that principal to
    generate other keys.

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


  9. Re: Updating encryption types

    Phil Dibowitz wrote:

    > On Tue, Jul 05, 2005 at 01:48:54PM -0700, Phil Dibowitz wrote:
    >
    >>from kadmin, great (though is that "no salt" supposed to be there?)!
    >>
    >>However, klist -e shows:
    >>
    >>[phil@frantic unstale]$ klist -e
    >>Ticket cache: FILE:/tmp/krb5cc_36070
    >>Default principal: phil@ISD.USC.EDU
    >>
    >>Valid starting Expires Service principal
    >>07/05/05 13:36:31 07/05/05 23:36:31 krbtgt/ISD.USC.EDU@ISD.USC.EDU
    >> Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with CRC-32
    >>[phil@frantic unstale]$
    >>
    >>and the logs show:
    >>
    >>Jul 05 13:36:31 frantic.usc.edu krb5kdc[26284](info): AS_REQ (3 etypes {23 16
    >>1}) 128.125.10.120: ISSUE: authtime 1120595791, etypes {rep=23 tkt=1 ses=1},
    >>phil@ISD.USC.EDU for krbtgt/ISD.USC.EDU@ISD.USC.EDU
    >>
    >>Neither the session key, nor my principal key seem to have been using the new
    >>encryption... it's not clear to me why...

    >
    >
    >
    > Anyone?


    What enctypes are configured for the service principal
    krbtgt/ISD.USC.EDU@ISD.USC.EDU ?



    --
    -----------------
    This e-mail account is not read on a regular basis.
    Please send private responses to jaltman at mit dot edu

  10. Re: Updating encryption types

    >>>>> "phil" == Phil Dibowitz writes:

    phil> [phil@frantic unstale]$ klist -e
    phil> Ticket cache: FILE:/tmp/krb5cc_36070
    phil> Default principal: phil@ISD.USC.EDU

    phil> Valid starting Expires Service principal
    phil> 07/05/05 13:36:31 07/05/05 23:36:31 krbtgt/ISD.USC.EDU@ISD.USC.EDU
    phil> Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with CRC-32

    This indicates that your KDC is issuing a TGT which has its
    ticket-encrypting key of type des-cbc-crc, which implies that the TGT
    principal has at best a single-DES enctype.

    phil> and the logs show:

    phil> Jul 05 13:36:31 frantic.usc.edu krb5kdc[26284](info): AS_REQ (3 etypes {23 16
    phil> 1}) 128.125.10.120: ISSUE: authtime 1120595791, etypes {rep=23 tkt=1 ses=1},
    phil> phil@ISD.USC.EDU for krbtgt/ISD.USC.EDU@ISD.USC.EDU

    phil> Neither the session key, nor my principal key seem to have been using the new
    phil> encryption... it's not clear to me why...

    It does list "rep=23", which means that the *reply* is encrypted in
    arcfour. The client shouldn't care about what the ticket-encrypting
    enctype is, though some really old implementations erroneously do
    care. The session key choice is limited by the capabilities of the
    TGT principal.

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


  11. Re: Updating encryption types

    On Wed, Jul 06, 2005 at 07:21:17PM -0400, Kevin Coffman wrote:
    > My guess is that your krbtgt/ISD.ISC.EDU@ISD.USC.EDU principal still
    > only has a des key. 'cpw -randkey -keepold' on that principal to
    > generate other keys.


    Nice. That works. I didn't realize that had to be updated. Which leaves me
    with a few more questions:

    1. What's the difference between the principals krbtgt@ISD.USC.EDU and
    krbtgt/ISD.USC.EDU@ISD.USC.EDU ? They both exist, but krbtgt/ISD.USC.EDU seems
    to be the ACTUAL ticket granting principal, while krbtgt@ISD.USC.EDU has the
    DISALLOW_ALL_TIX attribute.

    2. As expected doing the cpw on the krbtgt/ISD.USC.EDU ticket provides us
    with:

    Key: vno 2, ArcFour with HMAC/md5, no salt
    Key: vno 2, Triple DES cbc mode with HMAC/sha1, no salt
    Key: vno 2, DES cbc mode with CRC-32, no salt
    Key: vno 1, DES cbc mode with CRC-32, no salt

    and since the kvno is updated, that means I will need to regenerage/ktadd the
    new version of the key stashfile on all KDC's used to start the KDC, right?

    3. Anything else I need to be wary of changing this principal and/or the
    "other" krbtgt principal?

    Thanks.
    --
    Phil Dibowitz
    Systems Architect and Administrator
    Enterprise Infrastructure / ISD / USC
    UCC 180 - 213-821-5427


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

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

    iD8DBQFCzZ0z7lkZ1Iyv898RAmUGAKCbXNM2IeLZxNXia+AGvz jg+BLPMgCfU/Cb
    T9BIwsPenDztZUurIpwSeVM=
    =NP4c
    -----END PGP SIGNATURE-----


  12. Re: Updating encryption types

    >>>>> "phil" == Phil Dibowitz writes:

    phil> 2. As expected doing the cpw on the krbtgt/ISD.USC.EDU ticket provides us
    phil> with:

    phil> Key: vno 2, ArcFour with HMAC/md5, no salt
    phil> Key: vno 2, Triple DES cbc mode with HMAC/sha1, no salt
    phil> Key: vno 2, DES cbc mode with CRC-32, no salt
    phil> Key: vno 1, DES cbc mode with CRC-32, no salt

    phil> and since the kvno is updated, that means I will need to
    phil> regenerage/ktadd the new version of the key stashfile on all
    phil> KDC's used to start the KDC, right?

    No, you will simply need to kprop the updated database. The krbtgt
    key is not stored in any keytab. The stashfile stores the master key,
    not the krbtgt key.

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


  13. Re: Updating encryption types

    On Thu, Jul 07, 2005 at 07:52:52PM -0400, Tom Yu wrote:
    > >>>>> "phil" == Phil Dibowitz writes:

    >
    > phil> 2. As expected doing the cpw on the krbtgt/ISD.USC.EDU ticket provides us
    > phil> with:
    >
    > phil> Key: vno 2, ArcFour with HMAC/md5, no salt
    > phil> Key: vno 2, Triple DES cbc mode with HMAC/sha1, no salt
    > phil> Key: vno 2, DES cbc mode with CRC-32, no salt
    > phil> Key: vno 1, DES cbc mode with CRC-32, no salt
    >
    > phil> and since the kvno is updated, that means I will need to
    > phil> regenerage/ktadd the new version of the key stashfile on all
    > phil> KDC's used to start the KDC, right?
    >
    > No, you will simply need to kprop the updated database. The krbtgt
    > key is not stored in any keytab. The stashfile stores the master key,
    > not the krbtgt key.


    That's what I thought, thanks.

    I've grabbed my kerb book and my notes and I have a few unrelated questions
    that I will ask in another email.

    --
    Phil Dibowitz
    Systems Architect and Administrator
    Enterprise Infrastructure / ISD / USC
    UCC 180 - 213-821-5427


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

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

    iD8DBQFCzcb/7lkZ1Iyv898RArE0AJ9mgvhibysHCm8sQFtwK7/2ZQ+BNQCgjL/g
    GZmFrdpm1NaboJ2IhXkhYMw=
    =8AME
    -----END PGP SIGNATURE-----


  14. Re: Updating encryption types

    On Thu, Jul 07, 2005 at 02:22:59PM -0700, Phil Dibowitz wrote:
    > On Wed, Jul 06, 2005 at 07:21:17PM -0400, Kevin Coffman wrote:
    > > My guess is that your krbtgt/ISD.ISC.EDU@ISD.USC.EDU principal still
    > > only has a des key. 'cpw -randkey -keepold' on that principal to
    > > generate other keys.

    >
    > Nice. That works. I didn't realize that had to be updated. Which leaves me
    > with a few more questions:
    >
    > 1. What's the difference between the principals krbtgt@ISD.USC.EDU and
    > krbtgt/ISD.USC.EDU@ISD.USC.EDU ? They both exist, but krbtgt/ISD.USC.EDU seems
    > to be the ACTUAL ticket granting principal, while krbtgt@ISD.USC.EDU has the
    > DISALLOW_ALL_TIX attribute.


    OK, so going back, I find that

    krbtgt/ISD.USC.EDU@ISD.USC.EDU is for crossrealm trust.
    krbtgt@ISD.USC.EDU was our original tgt.

    However, now all tickets seem to be coming from
    krbtgt/ISD.USC.EDU@ISD.USC.EDU. Now the person who setup
    krbtgt/ISD.USC.EDU@ISD.USC.EDU and the cross-realm trust was 2 admins ago -
    did they make a mistake, or is this a bug in kerb, or is this expected
    behavior?

    In other words, my klist looks like this:

    [phil@frantic phil]$ klist
    Ticket cache: FILE:/tmp/krb5cc_36070
    Default principal: phil@ISD.USC.EDU

    Valid starting Expires Service principal
    07/07/05 14:34:25 07/08/05 00:34:23 krbtgt/ISD.USC.EDU@ISD.USC.EDU
    [phil@frantic phil]$


    But I would think it SHOULD look like this:

    [phil@frantic phil]$ klist
    Ticket cache: FILE:/tmp/krb5cc_36070
    Default principal: phil@ISD.USC.EDU

    Valid starting Expires Service principal
    07/07/05 14:34:25 07/08/05 00:34:23 krbtgt@ISD.USC.EDU
    [phil@frantic phil]$

    I get the eerie feeling that this is due to a misconfiguration of our
    cross-realm trust...

    Hmmm.

    --
    Phil Dibowitz
    Systems Architect and Administrator
    Enterprise Infrastructure / ISD / USC
    UCC 180 - 213-821-5427


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

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

    iD8DBQFCzckP7lkZ1Iyv898RAvGJAJ9hA5ybqyXFQFmkj5rq+s c6ZNr3oQCeM7dg
    D9f4PgXBE7hOIQ0yaPc2Fos=
    =o8lb
    -----END PGP SIGNATURE-----


  15. Re: Updating encryption types

    Phil Dibowitz writes:

    > OK, so going back, I find that


    > krbtgt/ISD.USC.EDU@ISD.USC.EDU is for crossrealm trust.
    > krbtgt@ISD.USC.EDU was our original tgt.


    > However, now all tickets seem to be coming from
    > krbtgt/ISD.USC.EDU@ISD.USC.EDU. Now the person who setup
    > krbtgt/ISD.USC.EDU@ISD.USC.EDU and the cross-realm trust was 2 admins
    > ago - did they make a mistake, or is this a bug in kerb, or is this
    > expected behavior?


    I would expect your krbtgt ticket to include your realm. Ours always has,
    and we haven't set up cross-realm trust.

    --
    Russ Allbery (rra@stanford.edu)

  16. Re: Updating encryption types

    On Thu, Jul 07, 2005 at 05:30:07PM -0700, Phil Dibowitz wrote:
    > On Thu, Jul 07, 2005 at 02:22:59PM -0700, Phil Dibowitz wrote:
    > > On Wed, Jul 06, 2005 at 07:21:17PM -0400, Kevin Coffman wrote:
    > > > My guess is that your krbtgt/ISD.ISC.EDU@ISD.USC.EDU principal still
    > > > only has a des key. 'cpw -randkey -keepold' on that principal to
    > > > generate other keys.

    > >
    > > Nice. That works. I didn't realize that had to be updated. Which leavesme
    > > with a few more questions:
    > >
    > > 1. What's the difference between the principals krbtgt@ISD.USC.EDU and
    > > krbtgt/ISD.USC.EDU@ISD.USC.EDU ? They both exist, but krbtgt/ISD.USC.EDU seems
    > > to be the ACTUAL ticket granting principal, while krbtgt@ISD.USC.EDU has the
    > > DISALLOW_ALL_TIX attribute.

    >
    > OK, so going back, I find that
    >
    > krbtgt/ISD.USC.EDU@ISD.USC.EDU is for crossrealm trust.
    > krbtgt@ISD.USC.EDU was our original tgt.


    Oh, I typoed. Which made me realize there's another issue. The cross-realm
    princ is:

    krbtgt/ICS.USC.EDU@ISD.USC.EDU

    and the right tgt (based on Kerberos by Brian Tung), doesn't seem to be doing
    anything:

    krbtgt@ISD.USC.EDU

    and the mystery ticket is doing everything:

    krbtgt/ISD.USC.EDU@ISD.USC.EDU

    Now I'm quite confused. Any thoughts would be appreciated.

    --
    Phil Dibowitz
    Systems Architect and Administrator
    Enterprise Infrastructure / ISD / USC
    UCC 180 - 213-821-5427


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

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

    iD8DBQFCzczX7lkZ1Iyv898RAnJPAJ9osM0nSF2YbJdveVfZAM KRrWegHACeNugW
    M2SzymvURjxAUp4R8Psy5/o=
    =sqzh
    -----END PGP SIGNATURE-----


  17. Re: Updating encryption types



    On Thursday, July 07, 2005 05:46:18 PM -0700 Phil Dibowitz
    wrote:

    > and the right tgt (based on Kerberos by Brian Tung), doesn't seem to be
    > doing anything:
    >
    > krbtgt@ISD.USC.EDU


    This principal is meaningless, and is used for nothing.

    > and the mystery ticket is doing everything:
    >
    > krbtgt/ISD.USC.EDU@ISD.USC.EDU


    This principal is the local-realm ticket-granting service.

    In other words, it's working exactly like it's supposed to. It's anyone's
    guess where the meaningless principal came from.
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  18. Re: Updating encryption types

    On Thu, Jul 07, 2005 at 09:03:36PM -0400, Jeffrey Hutzelman wrote:
    >
    >
    > On Thursday, July 07, 2005 05:46:18 PM -0700 Phil Dibowitz
    > wrote:
    >
    > >and the right tgt (based on Kerberos by Brian Tung), doesn't seem to be
    > >doing anything:
    > >
    > >krbtgt@ISD.USC.EDU

    >
    > This principal is meaningless, and is used for nothing.
    >
    > >and the mystery ticket is doing everything:
    > >
    > >krbtgt/ISD.USC.EDU@ISD.USC.EDU

    >
    > This principal is the local-realm ticket-granting service.
    >
    > In other words, it's working exactly like it's supposed to. It's anyone's
    > guess where the meaningless principal came from.


    So krbtgt@REALM is not what MIT krb uses as the TGT, it uses
    krbtgt/REALM@REALM - just a discrepency between the MIT implimentation and the
    Kerb book I have?

    OK, I'm happy with that.

    Deleting the meaningless ticket in test seems to be harmless. Sweet. OK,
    awesome, thanks.

    --
    Phil Dibowitz
    Systems Architect and Administrator
    Enterprise Infrastructure / ISD / USC
    UCC 180 - 213-821-5427


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

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

    iD8DBQFCzdRY7lkZ1Iyv898RAl5eAJ9XC0ujKNZF3TE79tK7of XksUvftACgkGI0
    FRTGeV1pzKU5UlS1305yyq0=
    =qaUW
    -----END PGP SIGNATURE-----


  19. Re: Updating encryption types



    On Thursday, July 07, 2005 06:18:16 PM -0700 Phil Dibowitz
    wrote:

    > On Thu, Jul 07, 2005 at 09:03:36PM -0400, Jeffrey Hutzelman wrote:
    >>
    >>
    >> On Thursday, July 07, 2005 05:46:18 PM -0700 Phil Dibowitz
    >> wrote:
    >>
    >> > and the right tgt (based on Kerberos by Brian Tung), doesn't seem to be
    >> > doing anything:
    >> >
    >> > krbtgt@ISD.USC.EDU

    >>
    >> This principal is meaningless, and is used for nothing.
    >>
    >> > and the mystery ticket is doing everything:
    >> >
    >> > krbtgt/ISD.USC.EDU@ISD.USC.EDU

    >>
    >> This principal is the local-realm ticket-granting service.
    >>
    >> In other words, it's working exactly like it's supposed to. It's
    >> anyone's guess where the meaningless principal came from.

    >
    > So krbtgt@REALM is not what MIT krb uses as the TGT, it uses
    > krbtgt/REALM@REALM - just a discrepency between the MIT implimentation
    > and the Kerb book I have?


    It's not what _anything_ uses, and so far as I can remember never has been.
    If the book says that, then either it's a typo or Brian was asleep when he
    wrote that part. :-)

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


+ Reply to Thread