[1392] in Kerberos-V5-bugs
Re: Kerberos 5 Beta 5 Interoperability with DCE # 2
daemon@ATHENA.MIT.EDU (Doug Engert)
Wed May 10 12:22:53 1995
Date: Wed, 10 May 95 11:22:38 CDT
From: "Doug Engert" <DEEngert@anl.gov>
To: <KERBEROS@MIT.EDU>
Cc: <JOEK@CYBERSAFE.COM>, <KRB5-BUGS@MIT.EDU>
Joe,
Thanks for the response to my bug report. I have made a number
of comments, and in doing so, I have a better understanding
of how the keytype and etypes have to work together.
On May 9 Joe responded to my note with:
>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_csarray[local_dec_rep->enc_part.etype]->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.
I agree, the original code may be deficient, and the fix is not perfect.
The above fix got it to work, and hopefully in the following
discussion, I can map out a better fix.
>
>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.
The "hint" I talked about was not the AS_REQ etype sequence. I
believe the DCE KDC is using the etype sequence, which is a
sequence in preference order. It is selecting one of these,
and I believe it is the first one.
The "hint" I referred to is in the krb5_keyblock.etype (krb5.h)
which says: /* hint of what encryption type to use */.
This appears to come from the as_reply->ticket->enc_part.etype
which is the encryption method used with the AS_REP and should be one
of the types requested in the AS_REQ etype sequence.
When the client issues a TGS_REQ it also can fill in the etype sequence
with a list, which should be chosen based on the keytype returned
in the AS_REP. The krb5_send_tgs() routine has an etypes parameter
which appears to be designed for this purpose. But if it is NULL
a default list is used instead. The only place krb5_send_tgs()
appears to be called from is gc_via_tkt.c, and it sets etypes to NULL.
A fix could be to have it pass the single etype
which was saved in the "hint", and tell the KDC which method to use.
(Thats what K5.4.3 did.) A better fix would be to have it fill in
the TGS_REQ etype sequence with a list of etypes which can
be used with the returned key.
>
>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).
I believe the KDC (both the MIT 5.5 and the DCE server) are selecting
one of the etypes from the sequence. That is not the problem.
K5.5 made the assumption that the client in the AS_REQ
and the client in the TGS_REQ will use the same etype sequence. i.e. the
etype used in the AS_REP is saved in the "hint" and it will be the
same method used when the TGS_REP is processed, even though the
TGS_REQ specified a different etype sequence.
The REAL problem is that the K5.5 code is testing the TGS_REP
using the "hint" etype rather then testing if the etype used
was one of the ones it sent in the TGS_REQ.
In my testing, the AS_REQ is generated by the dce_login program,
and the TGS_REQ is done by the K5.5 rlogin. I believe they are
sending two different sequences.
With K5.4.3 I did not have this problem. The etype for the TGS_REQ was
obtained in gc_frm_kdc.c:
#define TGT_ETYPE \
krb5_keytype_array[tgt.keyblock.keytype]->system->proto_enctype;
>
>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.
>
I hope that the comments I have made above makes it clear, that I am
NOT saying to disregard the *_REQ etype sequence, but rather the
checks used in K5.5 are wrong and this caused the problem.
>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
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.
The krb5_get_default_in_tkt_etypes() may need to be changed
to add the keytype as a parameter.
The fix I produced is usable, but I would hope the next beta version
would provide a better one. I am reluctant to make major changes in
an area of the code which may change in the next release.
As you said further discussion is still needed....
Douglas E. Engert
Systems Programming
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(708) 252-5444
Internet: DEEngert@anl.gov
