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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20050701/233f3007/attachment.bin