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

[CONGDON,PAUL (HP-Roseville,ex1) (paul.congdon]

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
>