Received: from cathode-dark-space.mit.edu (daemon@CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) by krbdev.mit.edu (8.9.3p2) with ESMTP id TAA20627; Wed, 11 Feb 2004 19:02:52 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9) id i1C02qop003854; Wed, 11 Feb 2004 19:02:52 -0500 (EST) To: rt@krbdev.mit.edu Subject: Re: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata References: From: Tom Yu Date: Wed, 11 Feb 2004 19:02:52 -0500 In-Reply-To: (rt-comment@krbdev.mit.edu's message of "Wed, 11 Feb 2004 18:30:36 -0500 (EST)") Message-Id: Lines: 51 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii RT-Send-Cc: X-RT-Original-Encoding: us-ascii Content-Length: 2117 >>>>> "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. >> 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