eap Mailing List: Re: Re: Issue 251

[Yoshihiro Ohba (yohba]

Hi Jim,

On Tue, Jul 27, 2004 at 06:16:56PM -0400, Jim Burns wrote:
> Hi folks,
> I was just reading up on 'Success/Fail' packets in rfc3748 
> and found two things:
> 
> 1.  I do not believe that the .1XRev machine's behavior in 
> the FORCE_AUTH and FORCE_UNAUTH will cause any 
> interoperability issues.  RFC
> 3748 is clear what to do:  "By default, an EAP peer MUST 
> silently discard a "canned" Success packet (a Success packet 
> sent immediately upon connection). "  [second paragraph, page 
> 23, rfc3748].  This is good since I believe it is too late to make
> changes on 802.1XRev.
> 
> 2.  I do have a question...later on in the same section in 
> RFC 3748 there is this text:
> "However, an authenticator MAY omit having the peer 
> authenticate to it in situations where limited access is 
> offered (e.g., guest access). In this case, the authenticator 
> MUST send a Success packet. "  [ second paragraph, page 24, 
> rfc3748]  Now...I probably missed something...but this seems 
> to contradict the sentence I indicated in #1 above.  It seems 
> to say that the authenticator *can* omit the authentication 
> to allow guest access and it must send a success 
> packet...which according to #1 
> would appear as a 'canned success' and be discarded by the peer.   If 
> this were true then you could say that FORCE_AUTH and 
> FORCE_UNAUTH states (in the 1XRev) implement this behavior 
> locally in the NAS.

I think the text points to a case where the authenticator can sends
Success message in response to Identity Response from the peer.  So
it would not appear as a canned success.

Yoshihiro Ohba


> 
> I am concerned about this contradiction though.  Did I miss 
> something in the doc?  
> Thanks,
> Jim B.
> 
> 
> 
> Nick Petroni wrote:
> 
> >Paul,
> >
> >Thanks for jumping in. The way I understand these messages is, I think, as
> >you have described. Basically, if 802.1X is off, but the Peer comes in and
> >sends an EAPoL Start, then the authenticator will immediately respond with
> >an EAP Success or an EAP Fail without doing a run of the Identity method
> >or an actual authentication method. Is this correct? If so, I *think* this
> >would violate RFC3748 per Bernard's and Jari's comments. Any thoughts,
> >corrections, or clarifications to my assessment?
> >
> >Thanks,
> >nick
> >
> >Nick L. Petroni, Jr.
> >Graduate Student, Computer Science
> >Maryland Information Systems Security Lab
> >University of Maryland
> >http://www.cs.umd.edu/~npetroni
> >
> >On Tue, 27 Jul 2004, Congdon, Paul T (ProCurve) wrote:
> >
> > 
> >
> >>The 'canned' messages are only send when the 802.1X port is
> >>administratively forced authorized or unauthorized.   This is basically
> >>when management turns off 802.1X and forces the port open or closed.
> >>These message are also discussed in the text.
> >>
> >>Paul
> >>
> >>   
> >>
> >>>-----Original Message-----
> >>>From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com]
> >>>On Behalf Of Nick Petroni
> >>>Sent: Tuesday, July 27, 2004 8:13 AM
> >>>To: Bernard Aboba
> >>>Cc: eap [at] frascone.com
> >>>Subject: Re: [eap] Re: Issue 251
> >>>
> >>>     
> >>>
> >>>>802.1X "canned" messages are encapsulated EAP packets.  So
> >>>>       
> >>>>
> >>>an 802.1X
> >>>     
> >>>
> >>>>packet containing an EAP Success is expressly forbidden under RFC
> >>>>3748, even though I think it is still mentioned in IEEE
> >>>>       
> >>>>
> >>>802.1X-2004.
> >>>     
> >>>
> >>>>Similarly, our discussion of whether "canned" EAP Failure
> >>>>       
> >>>>
> >>>is illegal
> >>>     
> >>>
> >>>>also applies to "canned" 802.1X packets.
> >>>>       
> >>>>
> >>>Ok, this was the source of my confusion. I guess I assumed
> >>>that since they were in another standard they were going to
> >>>be allowed for backwards compatibility or some other legacy
> >>>argument. They are, indeed, still in the latest version,
> >>>which was another source of my confusion. They are in the
> >>>802.1X SM diagrams, not just the text.
> >>>
> >>>Thanks,
> >>>nick
> >>>
> >>>     
> >>>
> >>>_______________________________________________
> >>>eap mailing list
> >>>eap [at] frascone.com
> >>>http://mail.frascone.com/mailman/listinfo/eap
> >>>
> >>>     
> >>>
> >>_______________________________________________
> >>eap mailing list
> >>eap [at] frascone.com
> >>http://mail.frascone.com/mailman/listinfo/eap
> >>
> >>   
> >>
> >
> >
> >_______________________________________________
> >eap mailing list
> >eap [at] frascone.com
> >http://mail.frascone.com/mailman/listinfo/eap
> >
> > 
> >
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap