Re: Re: Issue 251
From: Yoshihiro Ohba (yohbatari.toshiba.com)
Date: Wed, 28 Jul 2004 11:05:03 -0400 (EDT)
On Wed, Jul 28, 2004 at 11:00:30AM -0400, Nick Petroni wrote:
> Yoshihiro,
> 
> > 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.
> 
> Even if this were not canned, it seems to still violate the rule that a
> higher-layer authentication method must be run. Furthermore, Identity is
> always optional so what works with Identity should work without (IMHO).
> Perhaps I am missing some subtleties.

You are right.  I should have said "Success message in response to
Identity Response in a tunneling method".

Yoshihiro Ohba


> 
> Best,
> nick
> 
> >
> > 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
> >
> 

Results generated by Tiger Technologies using MHonArc.