[24208] in Kerberos
Re: Updating encryption types
daemon@ATHENA.MIT.EDU (Will Fiveash)
Mon Jul 4 16:30:11 2005
Date: Mon, 4 Jul 2005 15:29:11 -0500
From: Will Fiveash <William.Fiveash@sun.com>
To: kerberos@mit.edu
Message-ID: <20050704202911.GA14872@sun.com>
Mail-Followup-To: kerberos@mit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050701215255.GD13640@usc.edu>
Errors-To: kerberos-bounces@mit.edu
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: 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
