[krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata

[Tom Yu via RT]

>>>>> "DEEngert" == DEEngert at anl gov via RT <rt-comment at krbdev.mit.edu> writes:

DEEngert> Tom Yu via RT wrote:

>> I think the code is functioning as I expect it to, in this case.

DEEngert> No.

Let me rephrase: I think the code is functioning the way it was
intended to function when it was written.  Whether that behavior is
correct in this case is debatable.

>> After all, you require preauth, and you didn't provide any preauth
>> that it understood.  Or are you saying that it should ask for
>> additional preauth rather than returning "preauth failed"?

DEEngert> Yes, on the first AS-REQ the client does not know what
DEEngert> preauth if any is required. So it justs sends the
DEEngert> PA-PAC-REQUEST. It has to do this on the first request, as
DEEngert> preauth may not be needed.

DEEngert> If preauth is not required the KDC ignores the
DEEngert> PA-PAC-REQUEST and it works.

DEEngert> If preauth is required, a krb-error SHOULD be sent saying
DEEngert> which preauths can be used.

DEEngert> I thing the KDC code sees some preauth data,
DEEngert> (PA-PAC-REQEUST) but not any it can use, and assumes that
DEEngert> this must be a second AS-REQ request and it assumes it has
DEEngert> already sent the client a krb-error with the list of
DEEngert> preauths.

This would appear to be the intent.  The problem is, if the KDC sees
any AS-REQ containing padata, the most safe assumption to make is that
it is a "second" AS-REQ, i.e., one replying to a KRB-ERROR asking for
additional preauth.

Consider what happens when a client sends an AS-REQ containing padata
that the KDC do not understand.  KDC sends KRB-ERROR with list of
supported padata.  Client is broken in a way that causes it to send
a mostly identical AS-REQ, lacking the padata that the KDC require.
KDC again sends KRB-ERROR with list of supported padata.  Looping
ensues.  The main problem being that KRB-ERROR requesting additional
preauth isn't a hard failure, and the other errors are.

I'm not sure of the best way to get around this problem, without
somehow requiring the KDC to keep some state which it currently does
not.

---Tom