[7472] in Kerberos
Re: beta 6 -- enctype vs keytype
daemon@ATHENA.MIT.EDU (Joe Kovara)
Wed Jun 12 21:49:06 1996
To: kerberos@MIT.EDU
Date: Wed, 12 Jun 1996 03:31:24 GMT
From: joek@CyberSafe.com (Joe Kovara)
Having received several requests for information on the original proposal, I'm
re-posting it for those interested. There were no follow-ups to the original
posting, or subsequent discussion in the kerberos news group that I am aware
of...
------------------------------------------------------------------------------
Newsgroups: comp.protocols.kerberos
Subject: Proposed change: etype and keytype in V5 Kerberos
Date: 27 Jun 1995 16:55:43 -0400
Organization: comp.protocols.kerberos<->kerberos@mit.edu gateway
Lines: 82
Sender: daemon@cam.ov.com
Message-ID: <199506272049.AA08612@cayman-islands.isi.edu>
Reply-To: bcn@ISI.EDU, kerberos@mit.edu
NNTP-Posting-Host: pad-thai.cam.ov.com
This message is a proposal for a change in the way that a Kerberos
client determines the encryption type to be used for an authenticator
when communicating with a particular service provider.
RFC1510 did not specify how this was to be done, providing simply that
messages will be tagged with the encryption type used to generate
them, and that encryption keys would be typed.
The name space for encryption types and encryption key types were
separate spaces since some key types could be used by different
defined encryption types. In particular, the DES key type was
suitable for DES-CBC-CRC, DES-CBC-MD4, and DES-CBC-MD5.
Unfortunately, since there is no field in the response from the KDC
indicating which encryption type should be used for the authenticator,
the client was forced to choose one that was suitable for the key type
of the session key.
The Kerberos 5 Beta 5 release was the first release to support the
required DES-CBC-MD5 method, and to facilitate the transition, the
client makes the decision of the encryption method to use for the
authenticator based on the encryption type of the ticket, assuming
that since the ticket is encrypted using a particular method, the
remote server must support that method. Unfortunately, this method
for selecting the etype has the side effect of requiring that the
ticket be encrypted using a method that the client supports, whereas
this was never a requirement for the Kerberos protocol itself.
An example where it would be desirable to use different methods is the
case where the KDC and the application server use a stronger method
(e.g. triple DES) to protect the ticket than the client is capable of
supporting (the ticket granting service would be a good example of
this). In this case one would like to use the stronger method for the
TGT, even though the authenticator would be protected using a method
supported by the client.
A better solution would be for the client to let the KDC choose the
encryption method for the authenticator based on the list of methods
already sent to the KDC by the client, and the KDC's knowledge (from
its database) of the methods supported by the application server. The
KDC would communicate this choice of methods to the client through the
keytype field of the session key. Unfortunately, we had not defined
keytypes to map one to one onto encryption methods.
Fortunately, only a single keytype is presently defined, that for DES (1),
which supports several encryption methods. We will define new keytypes
that correspond to each of the encryption methods, des-cbc-md4(2)
des-cbc-md5(3). The new keytypes will only support the corresponding
encryption method. The old keytype of 1 will continue to support etype 1,
and the behavior of the clients would be changed so that it assumes etype x
when keytype x is received.
The RFC states that etypes 2 and 3 use keytype 1. Thus, this change would
result in a change in the spec so that etype 2 accepts only keytype 2, and
etype 3 accepts keytype 3. We would also change the spec to call the field
associated with an encryption key an etype, instead of a keytype, removing
references to keytypes from the RFC. This will not result in changes to the
encoding of messages or tickets, since the fields are encoded the same.
For existing clients prior to beta 5, etype 1 is the only etype supported,
and the KDC will use etype 1 and keytype 1 for the response, and all will
be fine.
Unfortunately, this change will break the existing beta 5 clients when
using des-cbc-md5 with a new KDC, since they will receive a response with
an etype for the ticket of 3, and an etype of 3, and will complain that
keytype 3 is not appropriate for keytype 3 (wanting a keytype of 1).
During the transition phase, this problem can be addressed by having the
KDC always use keytype and etype 1 until such time as the beta 5 clients
are phased out. Fortunately, beta 5 has not been out so long that there
should be many such clients. Beta 4 and earlier clients will behave
correctly with new KDCs. It is our belief that all the current commercial
clients will also behave correctly with this change.
We would like comments on this proposal. In particular, if anyone has
an implementation other than the MIT beta 5 release that will not
behave correctly with this new behavior let us know. Also, if anyone
objects to this change let us know. We would like to release patches
to the MIT beta 5 release that will provide this new behavior as
quickly as possible so that the transition period within which etype
and keytype 1 are still the preferred choices can be as short as possible.
Clifford Neuman
Regards,
Joe Kovara / CyberSafe Corp. / joek@cybersafe.com
