[5216] in Kerberos
Re: Kerberos 5 Beta 5 Interoperability with DCE # 2
daemon@ATHENA.MIT.EDU (Joe Kovara)
Mon May 22 17:12:48 1995
To: kerberos@MIT.EDU
Date: Mon, 22 May 1995 13:17:13 -0700
From: Joe Kovara <joek@CyberSAFE.COM>
On 19 May 1995, Theodore Ts'o wrote:
> 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.
[...]
Thanks for the update on this work. (No apologies necessary; I needed the
mental exercise anyway :) I hope others have a few ideas in this area...
It appears that your key simplifying assumption is that e-types will--for
all intents and purposes--be the same (for a given sequence of
request/reply, including any tickets in those replies, as well as
authenticators). E.g., the e-type used to encrypt the KDC reply
(KDC->client) defines the e-type used to encrypt the ticket (KDC->server).
I don't think this degree of simplification/restriction is necessary. I
interpret the RFC as allowing the inference of the k-type from the e-type
"...though more than one [encryption] algorithm may use the same type of
key (the mapping is many [e-type] to one [k-type])." (sec 6.2)
Moreover, such an assumption seems overly restrictive, as it essentially
means that even if the KDC and a server can use a stronger e-type than the
client, they both end up degenerating to a client-requested e-type. It is
fine if an implementation makes simplifying assumptions, but... This could
be a problem if implementations start inferring/requiring certain behavior
based on those assumptions. Specifically, I think it is incorrect for a
client to base any action based on (the e-type of) any part of a message
not specifically intended for the client--it is none of the client's
business. E.g., the client shouldn't attempt to use the e-type from the
(KDC-REP) ticket in *any* way; this includes checking the e-type for
validity.
