eap Mailing List: Re: Proposed resolution of issue 251

[John Vollbrecht (jrv]

Hi Yoshi - see comments in line
--On Tuesday, August 10, 2004 4:28 PM -0400 Yoshihiro Ohba 
<yohba [at] tari.toshiba.com> wrote:

> Hi John,
>
> Please see my comments in line.
>
> On Tue, Aug 10, 2004 at 11:37:45AM -0400, John Vollbrecht wrote:
> > A couple questions --
> >
> > --On Tuesday, August 10, 2004 12:48 PM +0300 Pasi.Eronen [at] nokia.com
> > wrote:
> >
> > > Hi,
> > >
> > > To summarize the discussion about issue #251 at San Diego,
> > > the conclusion seemed to be that
> > >
> > > - The "canned" success/failure prohibited by RFC3748
> > >  means success/failure sent immediately after a
> > >  connection is established.
> > >
> > -- so not a success failure sent because of administrative changes
> >
> > > - The 1X-REV behavior of sending success/failure on
> > >  administrative change is not totally in line with this.
> > >
> > -- it does seem different.  so not specifically prohibited.
> >
> > > - However, you could argue that those canned messages are not
> > >  really part of an EAP conversation, but just use EAPOL frame
> > >  type.
> > >
> > ok - this seems reasonable
> >
> > > - Perhaps using something else would have been prettier, but
> > >  the current behavior doesn't seem to be that harmful either
> > >  (e.g. if you disable the port, the client is not going to get
> > >  access anyway), and it's too late to change it.
> > >
> > this doesn't seem to deal with the case where a port is taken down and
> > up,  sending a Success, and it may be in the middle of a conversation.
>
> I don't understand the case where an authenticator sends a Success in
> the middle of a conversation in this case.  When a port on an IEEE
> 802.1X authenticator is taken down and up, isn't the IEEE 802.1X
> authenticator state machine initialized with restarting the EAP state
> machine?

In the case where a port may be administratively set to "Force Auth" (sec 
8.2.4.11 of 802-1X-Rev-d11)  a port will send a canned Success message.

The scenario I imagine is that two ports are doing EAP, and the 
authenticator is taken down and its portControl variable is set to 
ForceAuthorized.  It then sends a Success.

If the Station state machine is is a state where it will accept a Success, 
it may not notice that the authenticator has gone down and back up.  It 
will accept the Success and connect to the net.  Thus the Peer could come 
up to a authenticator which to which it has not authenticated.

This is clearly an unlikely situation.   It is unlikely to happen at all. 
If it does happen it is unlikely that the AP it connects to will not be the 
one that just went down and came up.

In my mind it is something to note but not requiring change.  I just want 
to be sure everyone agrees.

John

> Yoshihiro Ohba
>
>
> >
> > > - EAP peer state machine discards canned success/failure
> > >  (because "reqId == lastId" can't be true, since lastId
> > >  is NONE). Thus, no changes required there.
> > true - but this is not the administrative success/failure
> > >
> > > - EAP authenticator state machine does not explicitly mention
> > >  that canned success/failure is prohibited. If desired, we
> > >  could add something like "Policy.getDecision MUST comply with
> > >  RFC3748 restrictions about canned Success and Failure messages."
> > >  in author's 48 hours.
> > I think this is a good idea
> >
> > >
> > > - Sending success/failure after an identity request/response
> > >  pair is allowed by RFC3748 (and is explicitly mentioned
> > >  in an example). The peer can, of course, have a policy
> > >  requiring authentication of the server.
> > >
> > > I didn't notice this at San Diego, but additionally it
> > > seems that:
> > >
> > > - The current version of EAP peer state machine does not accept
> > >  a Success message after identity request (because decision is FAIL;
> > >  this still worked in version -01 where decision could be also
> > >  COND_SUCC).
> > >
> > > - We could add text saying that "The peer state machine assumes
> > >  that the peer's policy requires that an authentication method
> > >  is always run. That is, an EAP Success message immediately
> > >  following an EAP Identity or Notification exchange is ignored."
> > >
> > > - Or, we could add a constant AllowImmediateSuccess, and
> > >  change "decision = FAIL" to "if (AllowImmediateSuccess)
> > >  decision = COND_SUCC; else decision = FAIL;" in the
> > >  INITIALIZE state.
> > >
> > > Comments? What should we do about the last item?
> > > (Personally, I'd prefer the first alternative, as we
> > > could add that at author's 48 hours.)
> > >
> > I also prefer the first alternative, but I think input from the list
> > would  be useful
> >
> > - John
> >
> > > Best regards,
> > > Pasi
> > >
> > _______________________________________________
> > 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