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

[Yoshihiro Ohba (yohba]

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