eap Mailing List: Re: Re: Issue 251

[Jim Burns (jeb]

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 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
>
>