eap Mailing List: RE: Re: Issue 251

[John Vollbrecht (jrv]

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