Message-Id: <402AD717.76D32F8B@anl.gov>
Date: Wed, 11 Feb 2004 19:29:59 -0600
From: "Douglas E. Engert" <deengert@anl.gov>
MIME-Version: 1.0
To: rt-comment@krbdev.mit.edu
Cc: hartmans@mit.edu, krb5-prs@mit.edu
Subject: Re: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata
References: <rt-2110-9819.3.41057550142935@krbdev.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
RT-Send-Cc: 
Content-Length: 2790


Tom Yu via RT wrote:
> 
> >>>>> "DEEngert" == DEEngert@anl gov via RT <rt-comment@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.

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  <DEEngert@anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444