eap Mailing List: RE: Re: Issue 251

[Congdon, Paul T (ProCurve) (paul.congdon]

I don't believe a change of the magnitude that you are talking about is
possible for 802.1X at this time.  It is basically frozen and in the
final re-circulation ballot. 

> -----Original Message-----
> From: jrv [at] j.imap.itd.umich.edu 
> [mailto:jrv [at] j.imap.itd.umich.edu] On Behalf Of John Vollbrecht
> Sent: Wednesday, August 04, 2004 8:37 AM
> To: Nick Petroni; Congdon, Paul T (ProCurve)
> Cc: Bernard Aboba; eap [at] frascone.com
> Subject: RE: [eap] Re: Issue 251
> 
> 
> 
> --On Tuesday, July 27, 2004 2:38 PM -0400 Nick Petroni 
> <npetroni [at] cs.umd.edu> 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
> >
> I think if the authenticator can send Success messages when 
> turning off 802.1x and then setting and administrative 
> "enable", and the client is in the middle of an EAP method 
> when this happens, then there is a potential problem.  The 
> client may connect based on the success, when it would not 
> without the success.   I am wondering if there is any way 
> that EAP can or 
> should aid in the situation where 802.1X is turned off.  I 
> think the intent is to eliminate timeout if possible, but I 
> an not sure it is possible.
> 
> Sending a Fail seems not so bad, since we want the connection 
> to fail, but there is no guarantee that the Failure will 
> cause the connection to break since the client may be in the 
> middle of an EAP method that does not accept Fail.
> 
> I am not sure what the right answer here is, but it does seem 
> to be a problem.
> 
> One possibility, not good from an 802.1x point of view, might 
> be to have an administrative change send an EAPoL logoff.  At 
> a quick view this seems to be a way to keep the change out of 
> the EAP method.  This presumably would need a (small) change 
> to 802.1X which may not be feasible.  Any thoughts about this?
> 
> > 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
> 
> 
> 
> 
>