eap Mailing List: RE: Issue 193: Peer SM review

[Bernard Aboba (aboba]

Thanks.  In reviewing the state machines again, I think I agree with you.
They function even if the 802.1X state machine does not differentiate
between an EAP Request and an EAP Response.

On Sat, 15 Nov 2003, CONGDON,PAUL (HP-Roseville,ex1) wrote:

>
> I agree completely with Yoshihiro.   The lower layer (e.g. 802.1X) does not
> want to know what EAP method is running.  Ideally, the lower layers might
> even want to support another authentication protocol other than EAP (though
> this is not an explicit design objective of 802.1aa now called 802.1X-D7.1).
> Tying the interface between the layers with method specific details is not a
> good idea.
>
>
> Paul
>
> > -----Original Message-----
> > From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com]
> > On Behalf Of Yoshihiro Ohba
> > Sent: Thursday, November 13, 2003 11:49 AM
> > To: Bernard Aboba
> > Cc: eap [at] frascone.com
> > Subject: Re: [eap] Issue 193: Peer SM review
> >
> >
> > I have one comment in line.
> >
> > On Sun, Nov 09, 2003 at 07:10:34PM -0800, Bernard Aboba wrote:
> > > Issue 193: Peer SM review
> > > Submitter name: Bernard Aboba
> > > Submitter email address: aboba [at] internaut.com
> > > Date first submitted: Nov 8, 2003
> > > Reference:
> > > Document: SM-01
> > > Comment type: T
> > > Priority: S
> > > Section: 2, 4
> > > Rationale/Explanation of issue:
> > >
> > > pp. 5, first paragraph
> > >
> > > "pass EAP messages to a Backend Server where the real
> > Authentication
> > > Method resides"
> > >
> > > As is made clear later, the pass-through authenticator does *not*
> > > forward all EAP messages to the backend authentication server, only
> > > EAP-Responses. Rephrase to:
> > >
> > > "pass EAP-Response messages to a Backend Server where the
> > > Authentication Method resides"
> > >
> > > Third paragraph:
> > >
> > > The implication is the EAP method demultiplexing depends on
> > the lower
> > > layer. This is not the case because all EAP implementations on all
> > > media must support  demultiplexing (whether they support an
> > > authenticator or peer listener is another issue).
> > >
> > > Suggest replacing the paragraph with:
> > >
> > > "As noted in RFC 2284bis, Section 2.3, the EAP layer demultiplexes
> > > incoming EAP packets. Packets with Code=2 (Response) are
> > delivered to
> > > the Authenticator state  machine, while packets with Code=1
> > (Request),
> > > 3
> > > (Success) or 4 (Failure) are  delivered to the Peer state machine."
> > >
> > > Page 9, Figure 3.
> > >
> > > The notation used later (Figure 6) is more clear than the
> > use of the
> > > "|" operator as in Figure 3. I'd recommend adopting the Figure 6
> > > notation everywhere.
> > >
> > > It would appear to me that methodState is a variable that
> > needs to be
> > > exported from the peer to the lower layer. This is so that
> > lower layer
> > > state  machines such as 802.1X can know whether their own state
> > > machines should be  affected or not.
> >
> > I don't think exposing methodState to the lower layer is a
> > good idea. Since the state machine draft is an informational
> > document, an implementation can be based on yet another state
> > machine that realizes the same on-the-wire behavior but uses
> > a different set of states.  If a lower layer requires such
> > internal state exposition, I believe there is something wrong
> > with the lower layer design...
> >
> > Yoshihiro Ohba
> >
> >
> >
> > >
> > > The INITIALIZE state does not initialize all variables.
> > > Non-initialized variables
> > > include:
> > >
> > > eapKeyData = NONE
> > > eapKeyAvailable = FALSE
> > > eapSuccess = FALSE
> > > eapFail = FALSE
> > > methodState = NONE
> > > selectedMethod = NONE
> > > decision = FAIL
> > >
> > > The initialization values seem important since transitions can be
> > > based on them before they are initialized. Re-initializing
> > variables
> > > in the INITIALIZE  state is a bit different from giving the
> > variables
> > > initial values before they are ever used.
> > >
> > > Not sure what "decision = FAIL | COND_SUCC" means in the INITIALIZE
> > > state. I assume this means that this variable can be
> > assigned one of
> > > two values, at the  implementation's descretion. I think we
> > want this
> > > variable initialized to FAIL.
> > >
> > > There is a transition from the IDLE state to the SUCCESS
> > and FAILURE
> > > states. This occurs without appearing to require receipt of
> > a packet.
> > > I think that this can't  be the case;  something has to be
> > received at
> > > some point for the peer to leave idleWhile  OR it is a
> > situation where
> > > the peer is testing whether the authenticator is
> > EAP-capable (e.g. a
> > > wired LAN application).
> > >
> > > The transition to FAILURE state occurs when an alternative
> > indication
> > > of Rejection occurs (e.g. Disassociate); when the idleWhile
> > timer runs
> > > out and the decision is not an unconditional success; when an
> > > alternative indication of success is available but the decision is
> > > FAIL.
> > >
> > > There is also a transition from the IDLE state to the
> > SUCCESS state.
> > > This can occur when the idleWhile timer runs out and the
> > decision is
> > > an unconditional success; or when an alternative indication
> > of success
> > > is available and the decision is not FAILURE.
> > >
> > > It seems that the INITIALIZE state will need to have the correct
> > > default values or these transitions may not occur correctly.
> > > _______________________________________________
> > > 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
> >
>