[5194] in Kerberos
Re: Kerberos 5 Beta 5 Interoperability with DCE # 2
daemon@ATHENA.MIT.EDU (Joe Kovara)
Thu May 18 02:27:25 1995
To: kerberos@MIT.EDU
Date: Wed, 17 May 1995 21:53:07 -0700
From: Joe Kovara <joek@CyberSAFE.COM>
On 10 May 1995, Doug Engert wrote:
[...]
> Well, I have been writing this note now for over two hours,
> and there is still another issue which will cloud this area. That
> is the addition of other keytypes. Now there is only the DES key,
> and all of the etype methods use DES. When the TGS_REQ etype sequence
> is generated, this list will have to be made up of etypes which
> work with the keytype as returned in the AS_REP.
[...]
> As you said further discussion is still needed....
Apologies. I've reread your original posting and looked at the code
(although I'm by no means intimate with beta 5). And, yes, I'd have
to agree that your fix is about all that can be done for the moment.
As to further discussion...
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.
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...
The inclusion of the e-type in the key block also solves a problem with
the e-type getting "lost" during processing, which I believe was an
artifact of the encoding/processing of the ASN encrypted data structure
You obviously need both a key and an e-type to encrypt/decrypt a message;
the ASN encoding splits this information (for obvious reasons), and the
original implementation tended to map structures more-or-less directly to
the ASN encoding. Since there was no structure where the key and e-type
were present simultaneously, they could--and did--become separated and one
of them sometimes got "lost" in the shuffle, and was then resurrected
(incorrectly) by inferring one from the other. (I'm not sure I agree that
putting the e-type in the key block--as opposed to an e-block-like
structure--to solve this problem was appropriate. Then again, our code is
very different.)
The last time I went through the exercise of trying to figure out what
to do about multiple e/k-types was quite painful. The RFC offers
little guidance in this area, and the earlier K5 implementations are
of...ahem...limited use. In an attempt to keep my own sanity, I built
a list of "things to remember", which others may find useful; even if
not, it might generate some much-needed discussion. These are from
old notes; apologies if any inaccuracies have crept in...
1. The client's requested e-type in the AS_REQ must consider both the
e-types the client supports, as well as the k-type
generated/available on the client. That is, if the string-to-key
function you just used generates a key that can only be used with
the DES e-types (or your key table contains only keys of a
particular type), don't put other e-types in the AS_REQ, even if
you have code that supports other types. So what is a client to
do if it would like to use an e-type, but doesn't know whether the
KDC supports it? Answer: try it and see what happens. Not
exactly elegant, and likely to generate lots of syslog messages,
but the only way I can think of. (The padata in the AS_REP looks
like it might be useful in this situation, but there doesn't
appear to be any mechanism defined to allow the KDC to return
something which says "I don't have an e/k-type of X/Y for you, but
I do have one of type P/Q, so try that.")
2. The AS_REP must be encrypted using one of the client's requested e-
types. If the KDC has no key available that may be used with one
of the requested e-types, the KDC will reject the request. In
other words, if the client says, "I want you [KDC] to use e-type X",
but the KDC does not have a key for the client usable with e-type X,
the KDC can't do much except reject the request. Note that this
leaves it up to the client to try e/k-types until it finds one the
KDC supports (back to the problem/solution above).
3. The KDC-generated TGS session key (in the AS_REP) must be usable
with one of the client's requested e-types in order for the client
to be able to use the TGS session key. Obviously the KDC must
also understand the TGS session k-type, and support an e-type for
which the k-type is usable. Maybe obvious, but there are some
subtle implications. E.g., just because the KDC supports a
combination of k-type X and e-type Y doesn't mean the client does-
-the client may support both of those e/k-types, but not in
combination with each other.
4. The e-type used for the e-part of the tgt need not be
understood/known by the client--only the TGS needs to understand
it (see below for more on this).
5. When making a TGS_REQ, the client may use any e-type for which the
TGS session key is usable in order to build/encrypt the AP_REQ-
authenticator (this is the AP_REQ in the padata field of the
TGS_REQ). This e-type need not bear any relationship to the
requested e-types (that is, those e-types which the KDC will use
to select the e-type to use to encrypt the TGS_REP).
So what if the k-type of the TGS session key allows it to be used
with e-types X, Y and Z (all of which the client supports and in
that order of preference), but the KDC supports only e-type Z?
How does the client know this? Answer: it doesn't. So what e-type
is the client suppose to use for encrypting the TGS_REQ? Answer:
infer it from the original AS_REP (using the e-type in the key
block, which came from the original AS_REP, which is why it has to
be remembered--such as in the cred cache, which appears to be one
reason why there is now a V3 cred cache format. Oh joy.)
6. When generating a TGS_REP, the (KDC-generated) session k-type
needs to be understood by both the client and the server. (This
is simply a restatement of the client/TGS exchange.) The e-type
used for encrypting the TGS_REP must match one of the e-types
requested in the TGS_REQ. The KDC's choice of e-type is thus
based on: (1) the client's requested e-types; (2) the k-type(s)
known to the KDC for the service; (3) the e-types supported by the
service. How does the KDC know the answer to the last two items?
Answer: for most implementations it doesn't; it can only infer the
answers from the keys (i.e., their types) stored in the principal
database.
So much for the client/KDC interaction. When it comes to the
client/server interaction, there are a few more things to keep in
mind...
a. Remember, the AS/TGS request e-types explicitly limits the e-type
used to encrypt the e-part of the AS/TGS reply. This is stated in
the RFC.
b. The AS/TGS request e-types implicitly limit the possible k-types
which the KDC may use when selecting the session k-type for the
ticket (client/server) session key. This is not stated in the
RFC, but it only makes sense--the session k-type must obviously be
usable with an e-type which both the client and server support.
c. The KDC is under no constraint to choose a particular e-type with
which to encrypt the e-part of the ticket, other than the KDC must
know that the server supports that e-type, and that the server
(and obviously the KDC) has a key available which can be used with
the e-type (for the KDC the keys are in the database, for the
server the keys are in the key table). Remember, we are talking
about the e-part of the ticket, not the e-part of the AS/TGS
reply. Again, the e-type used for the ticket applies only to the
server, not the client.
d. The client's selection of an e-type for construction of the AP_REQ
is practically limited to an e-type which may be used with the
session k-type. Since the KDC is implicitly bound to select the
session k-type based on the client's original request, the net
effect is that the KDC implicitly limits the e-type used by the
client for constructing the AP_REQ. This, in turn, implicitly
limits the client's selection of a sub-session k-type, so there's
no additional freedom offered by the sub-session key. I say
"implicitly" because the client could choose a different e/k type
(to construct the AP_REQ-authenticator), but this would require
that the client know a priori that the server supports that e-type
(the KDC may not have used that e-type because its selection
algorithm differs, or the KDC may not know the server supports a
particular e-type).
Remember that--in order to establish a common session key between
client and server--there is no requirement that the e-type used for
encrypting the service ticket need be understood by the client, since
only the server needs to decrypt the (service) ticket. (At which
point the server will have access to the session key, which may be for
a completely different e-type.) Thus, only the server really needs to
support that e-type. But...
Unfortunately, you're then left in a situation where the client and
server may support e-types which--while they may use the same k-type--
are not supported by both. Then what? You can always say that you
should never use an e-type other than one of the RFC-defined "must
support", but this is very restrictive, and severely limits the use of
alternative e/k types. Or the KDC is left to make the choice by
ensuring that the e-types are supported by both (which, in practice,
is again going to be either very restrictive or a management pain).
Even more unfortunate, this also means that a client and server can't
use an e-type which the KDC doesn't know about.
At the risk of stating the obvious, I suggest that a reasonable
operating rule is: The KDC is responsible for ensuring that the
session k-type is usable with at least one e-type supported by both
client and server, and that this be implicitly communicated to the
client by the e-type of the TGS_REP (NOT the e-type of the ticket).
This frees the KDC to choose any e-type supported by the server for
encrypting the ticket, without fear of breaking clients. If the
client knows a priori that the server supports an alternative e-type
for which the session k-type is usable, then the client may choose to
use that e-type (i.e., for building/encrypting the authenticator-
AP_REQ). This eliminates any inference by the server of the e-type
from the e-type used by the KDC to encrypt the ticket, and gives the
client some freedom in choosing the e-type, without fear of breaking
servers.
While you can always write applications to negotiate around these
problems, they are, by definition, going to be non-standard. My
lament is that much of the potential of alternative e/k types appears
to be just out of reach of the standard mechanisms.
Joe Kovara / Product Development Manager / CyberSAFE / joek@cybersafe.com
