[5124] in Kerberos
Re: Kerberos 5 Beta 5 Interoperability with DCE # 2
daemon@ATHENA.MIT.EDU (Joe Kovara)
Wed May 10 01:06:52 1995
To: kerberos@MIT.EDU
Date: Tue, 9 May 1995 21:27:11 -0700
From: Joe Kovara <joek@CyberSAFE.COM>
On 8 May 1995, Doug Engert wrote:
[...]
> Since the etype in this routine was taken from the krbtgt and as
> the comments in the krb5.h for the krb5_keyblock indicate, it is
> only a HINT. It appears that the ETYPE_DES_CBC_CRC was used by
> the dce_login, while the ETYPE_DES_CBC_MD5 was used by the
> rlogin.
>
> A better test might be:
> if(krb5_csarraylocal_dec_rep->enc_part.etypeY->system->proto_keytype
> != key->keytype)
> Test if the key can be used for this encryption method.
[...]
While the above will work, I believe the fix violates the spirit (if not
the letter?) of the RFC; the original code is, I believe, simply
deficient.
The e-type in the request is more than a "hint". The KDC should use the
first supported e-type; it is assumed that the client put the e-types in
order of preference for a reason. At any rate, the KDC _must_ use one of
the requested e-types, or it should reject the request with an
"unsupported e-type" error--it should not simply pick something it happens
to like.
By the same token, the client should reject the reply if it does not match
_one_ of the requested e-types. (The function described above only
accepts a single e-type. Oh well.) This may be different than the e-type
of the TGT, since, of course, the server in question may not support all
of the client's e-types (or for a couple other reasons).
While simply saying that any e-type will do (as long as the key will
work), I think that a response that uses an e-type other than one of the
ones requested indicates a broken KDC, and the client should reject the
reply. This is in the same spirit as the rest of the checks made by the
client of KDC replies: even though a reply may decrypt properly and is
within the clock skew, the client still checks--and will reject--a KDC
reply for any number of reasons; many of those checks are "if it ain't
exactly what I requested, reject it with a 'KDC reply modified' error".
Yes, one could make the argument that, since the client has already
decrypted the original KDC reply, that the KDC knows that the client
supports that e-type, and that the client doesn't have to explicitly
request the e-type present in the TGT. But this raises several other
questions/ambiguities (which is one thing we don't need more of :); but
any discussion of them would would probably induce disorientation and
nausea, if not bore you to death.
Then again, the RFC can be a bit fuzzy when it comes to the treatment of
multiple e-types and key types, so some additional discussion and comment
is probably in order...
Joe Kovara / Product Development Manager / CyberSAFE / joek@cybersafe.com
