Tom Yu via RT wrote: > > >>>>> "DEEngert" == DEEngert@anl gov via RT 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. OK, I agree with that. > > >> 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. The difference is that the PA-PAC-REQUEST is really a flag, not a preauth. So maybe the KDC needs to recognize flag type entries (there may be others) and not make the assumption that this is a second AS-REQ. But this requires knowledge of all the possible pa-data types or at least the flag types. Is this an issue for Sam's draft-ietf-krb-wg-preauth-framework-00.txt? > > ---Tom -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444