[5200] in Kerberos
Re: Kerberos 5 Beta 5 Interoperability with DCE # 2
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Fri May 19 14:41:51 1995
Date: Fri, 19 May 1995 14:16:07 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: Joe Kovara <joek@CyberSAFE.COM>
Cc: kerberos@MIT.EDU
In-Reply-To: Joe Kovara's message of Wed, 17 May 1995 21:53:07 -0700,
<Pine.SUN.3.91.950517214006.381A-100000@kerby.ocsg.com>
Date: Wed, 17 May 1995 21:53:07 -0700
From: Joe Kovara <joek@CyberSAFE.COM>
A serious problem is that there is no mechanism for negotiating the e-
type. Specifically, there is no way to find out what e/k-types the
other side of a connection supports, outside of the context of the
AS/TGS request, which is very limited. All anyone has to go on is
what they can infer from the e-types of messages they have in hand (or
have received), and the k-types from keys (either session keys or
stored keys), from which one can infer e-types. While this has not
been a problem with only one e/k-type, it can be a major problem with
multiple types--inferring e/k-types becomes very tricky, dangerous, or
impossible.
Yes. For better or for worse, the original protocol design for Kerberos
V5 envisioned that e-types and k-types were orthoganol (although
obviously only a very small intersection of e-types and k-types would be
allowed).
However, there wasn't enough thought put into the negotiation of what
the appropriate e-type would be --- in fact, the definition of the
e-type field was not fully defined in the protocol RFC. I have
developed a set of proposed errata which will hopefully clarify the
situation. They were written up early in the beta 5 design work, but
I've deliberately not sent them to Cliff yet because I want to gain some
implementation experience with adding a new e-type, such as triple DES,
before I make these new semantics "official". I'll include them below
for general comment.
The inclusion of the e-type in the key block in beta 5 appears to be
an attempt to remedy part of the problem by remembering an e-type used
by the other side. Apparently, the "hint" referred to in the code is
essentially a statement to the effect of "The last time I talked to
the other side, they used an e-type of X with this k-type, so I
suppose that's the e-type that they prefer (at least I know they
support this combination of e/k-types), and that I should use X when
talking to them." However, since you have the ticket, you have the
ticket's e-type, so why store it? I can think of two reasons: (1) so
you don't have to decode the ticket to sniff out the e-type; (2) it
has nothing to do with this, but...
Yes, both reasons where correct; the first is as an efficiency hack so
that we don't have to keep parsing out the ticket in order to figure out
the e-type. The second was that, before we made the auth context change
to the API, there was no way to pass the encryption type to
krb5_{rd,mk}_{safe,priv}. The original code assumed a one-to-one
mapping between the encryption type and the key type, which was a bad
assumption to make.
So, adding the e-type in the key block was a cheap way to preserve the
existing API while allowing the information to be properly passed to the
routines. Ultimately, though, we decided to bite the bullet and fix the
API, even though I knew that would inconvenience some people who had
starting code applications using our Beta 4 application. Storing the
e-type field there is still useful as an efficiency hack for reason
number 1, though.
-----------------------
Here's the draft errata that I had composed last November.
Assuming that we get multi-encryption support working without a glitch,
this is what I plan to propose as an errata to RFC-1510. Some of the
simplifying assumptions which are made in this errata should help
preserve people's sanity. (Sorry, Joe; if I known this was an area you
were investigating, I would have sent this to you, and perhaps saved a
bit of hair-pulling on your part.)
Any comments to this draft are appreciated.
Processing of the etype field, described in 3.1.3, and 5.4.1.
(Obsoletes errata #2.)
The etype field in the KDC-REQ message is a list of encryption types in
order of preference. [*] When processing a AS or TGS request, the KDC
will use the first encryption type which meets the following criteria:
* The encryption must be a strong encryption type.
* The KDC must support the encryption type
* The Kerberos database must indicate that the encryption type
is acceptable for the application server.
This encryption type will be used to generate the returned Kerberos
ticket, and the random session key in the ticket will be suitable for
use with this encryption type. In the case of a AS request, this
encryption type will also be used to encrypt the encrypted portion of
the KDC-REP message. In the case of a TGS request, the encrypted
portion of the KDC-REP message will be encrypted using the same
encryption type that was used to encrypt the authenticator.
[*] This is clear from the ASN.1 specification, but the definition of
the etype field which follows near the end of section 5.4.1 is
confusing, as it makes it appear that etype field is specifies a single
encryption type, not a list. I suspect, from the implementation
history, that the protocol originally specified that etype was an
INTEGER, and only later was expanded to be a LIST OF INTEGER. Also note
that the etype field is mandatory; the second paragraph of errata #2
makes it appears that it is optional, which it is not.
Clarification to section 3.2.2.
The authenticator is encrypted using the encryption type that was used
to encrypt the ticket.
Clarification to section 3.2.4
The KRB_AP_REQ message is encrypted using the encryption type that was
used to encrypt the authenticator (and the ticket) in the preceeding
KRB_AP_REQ message.
Clarification to section 3.5.1 and 3.6.1
The KRB_PRIV message and the KRB_CRED message are encrypted using the
using the encryption type that was used to encrypt the ticket and
authenticator used to establish the session key or subkey.
- Ted
