Updating encryption types

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Updating encryption types

Phil Dibowitz
So reading through:

  http://web.mit.edu/kerberos/www/krb5-1.4/krb5-1.4.1/doc/krb5-install/Upgrading-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.

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


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

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Updating encryption types

Jeffrey Hutzelman


On Friday, July 01, 2005 02:14:02 AM -0700 Phil Dibowitz <[hidden email]>
wrote:

> So reading through:
>
>
> http://web.mit.edu/kerberos/www/krb5-1.4/krb5-1.4.1/doc/krb5-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) <[hidden email]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Updating encryption types

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

<SNIP>

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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Updating encryption types

Will Fiveash
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.
>
> <SNIP>
>
> 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: [hidden email]

Valid starting                Expires                Service principal
07/04/05 15:12:13  07/04/05 23:12:13  krbtgt/[hidden email]
        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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Updating encryption types

Kenneth G Raeburn
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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Updating encryption types

Phil Dibowitz
In reply to this post by Will Fiveash
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=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: [hidden email]
>
> Valid starting                Expires                Service principal
> 07/04/05 15:12:13  07/04/05 23:12:13  krbtgt/[hidden email]
>         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
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: [hidden email]

Valid starting     Expires            Service principal
07/05/05 13:36:31  07/05/05 23:36:31  krbtgt/[hidden email]
        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},
[hidden email] for krbtgt/[hidden email]

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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Updating encryption types

Phil Dibowitz
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: [hidden email]
>
> Valid starting     Expires            Service principal
> 07/05/05 13:36:31  07/05/05 23:36:31  krbtgt/[hidden email]
>         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},
> [hidden email] for krbtgt/[hidden email]
>
> Neither the session key, nor my principal key seem to have been using the new
> 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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Updating encryption types

Jeffrey Altman-3
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: [hidden email]
>>
>>Valid starting     Expires            Service principal
>>07/05/05 13:36:31  07/05/05 23:36:31  krbtgt/[hidden email]
>>        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},
>>[hidden email] for krbtgt/[hidden email]
>>
>>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/[hidden email] ?



--
-----------------
This e-mail account is not read on a regular basis.
Please send private responses to jaltman at mit dot edu
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Updating encryption types

Kevin Coffman
In reply to this post by Phil Dibowitz
> 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: [hidden email]
> >=20
> > Valid starting     Expires            Service principal
> > 07/05/05 13:36:31  07/05/05 23:36:31  krbtgt/[hidden email]
> >         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},
> > [hidden email] for krbtgt/[hidden email]
> >=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/[hidden email] principal still
only has a des key.  'cpw -randkey -keepold' on that principal to
generate other keys.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Updating encryption types

Tom Yu
In reply to this post by Phil Dibowitz
>>>>> "phil" == Phil Dibowitz <[hidden email]> writes:

phil> [phil@frantic unstale]$ klist -e
phil> Ticket cache: FILE:/tmp/krb5cc_36070
phil> Default principal: [hidden email]

phil> Valid starting     Expires            Service principal
phil> 07/05/05 13:36:31  07/05/05 23:36:31  krbtgt/[hidden email]
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> [hidden email] for krbtgt/[hidden email]

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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Updating encryption types

Phil Dibowitz
In reply to this post by Kevin Coffman
On Wed, Jul 06, 2005 at 07:21:17PM -0400, Kevin Coffman wrote:
> My guess is that your krbtgt/[hidden email] 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 [hidden email] and
krbtgt/[hidden email] ? They both exist, but krbtgt/ISD.USC.EDU seems
to be the ACTUAL ticket granting principal, while [hidden email] 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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Updating encryption types

Tom Yu
>>>>> "phil" == Phil Dibowitz <[hidden email]> 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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Updating encryption types

Phil Dibowitz
On Thu, Jul 07, 2005 at 07:52:52PM -0400, Tom Yu wrote:

> >>>>> "phil" == Phil Dibowitz <[hidden email]> 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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Updating encryption types

Phil Dibowitz
In reply to this post by Phil Dibowitz
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/[hidden email] 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 [hidden email] and
> krbtgt/[hidden email] ? They both exist, but krbtgt/ISD.USC.EDU seems
> to be the ACTUAL ticket granting principal, while [hidden email] has the
> DISALLOW_ALL_TIX attribute.
OK, so going back, I find that

krbtgt/[hidden email] is for crossrealm trust.
[hidden email] was our original tgt.

However, now all tickets seem to be coming from
krbtgt/[hidden email]. Now the person who setup
krbtgt/[hidden email] 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: [hidden email]

Valid starting     Expires            Service principal
07/07/05 14:34:25  07/08/05 00:34:23  krbtgt/[hidden email]
[phil@frantic phil]$


But I would think it SHOULD look like this:

[phil@frantic phil]$ klist
Ticket cache: FILE:/tmp/krb5cc_36070
Default principal: [hidden email]

Valid starting     Expires            Service principal
07/07/05 14:34:25  07/08/05 00:34:23  [hidden email]
[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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Updating encryption types

Phil Dibowitz
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/[hidden email] 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 [hidden email] and
> > krbtgt/[hidden email] ? They both exist, but krbtgt/ISD.USC.EDU seems
> > to be the ACTUAL ticket granting principal, while [hidden email] has the
> > DISALLOW_ALL_TIX attribute.
>
> OK, so going back, I find that
>
> krbtgt/[hidden email] is for crossrealm trust.
> [hidden email] was our original tgt.
Oh, I typoed. Which made me realize there's another issue. The cross-realm
princ is:

krbtgt/[hidden email]

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

[hidden email]

and the mystery ticket is doing everything:

krbtgt/[hidden email]

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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Updating encryption types

Russ Allbery
In reply to this post by Phil Dibowitz
Phil Dibowitz <[hidden email]> writes:

> OK, so going back, I find that

> krbtgt/[hidden email] is for crossrealm trust.
> [hidden email] was our original tgt.

> However, now all tickets seem to be coming from
> krbtgt/[hidden email]. Now the person who setup
> krbtgt/[hidden email] 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 ([hidden email])             <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Updating encryption types

Jeffrey Hutzelman
In reply to this post by Phil Dibowitz


On Thursday, July 07, 2005 05:46:18 PM -0700 Phil Dibowitz <[hidden email]>
wrote:

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

This principal is meaningless, and is used for nothing.

> and the mystery ticket is doing everything:
>
> krbtgt/[hidden email]

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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Updating encryption types

Phil Dibowitz
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 <[hidden email]>
> wrote:
>
> >and the right tgt (based on Kerberos by Brian Tung), doesn't seem to be
> >doing anything:
> >
> >[hidden email]
>
> This principal is meaningless, and is used for nothing.
>
> >and the mystery ticket is doing everything:
> >
> >krbtgt/[hidden email]
>
> 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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Updating encryption types

Jeffrey Hutzelman


On Thursday, July 07, 2005 06:18:16 PM -0700 Phil Dibowitz <[hidden email]>
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
>> <[hidden email]>  wrote:
>>
>> > and the right tgt (based on Kerberos by Brian Tung), doesn't seem to be
>> > doing anything:
>> >
>> > [hidden email]
>>
>> This principal is meaningless, and is used for nothing.
>>
>> > and the mystery ticket is doing everything:
>> >
>> > krbtgt/[hidden email]
>>
>> 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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos