Re: [Issue 248] Comments on EAP state machine v4
From: Yoshihiro Ohba (yohbatari.toshiba.com)
Date: Sat, 26 Jun 2004 10:06:46 -0400 (EDT)
Hi Florent and Nick,

Let me comment on one specific issue.

On Sat, Jun 26, 2004 at 11:09:03AM +0200, Florent Bersani wrote:

(snip)

> 
> Second problem, if the authenticator adopts this IMO bad behavior, I 
> still have a concern with aaaResp being set to TRUE
> Indeed, the authenticator is interfaced with the AAA layer (what you 
> call lower layer in your mail), e.g. RADIUS or DIAMETER
> 
> This how IINM things work:
> 1) when the authenticator sets aaaEapResp to TRUE, the AAA layer (e.g. 
> RADIUS) takes aaaEapRespData and encapsulate it in the relevant AVP 
> (EAP-Message) *without any other processing by the AAA layer* and the 
> AAA layer of the authenticator sends it to the AAA layer of the AS server
> 2) the authenticator waits in the AAA_IDLE state after having sent this 
> response of the peer to the AS
> 3) and then it can get a request that the AS sent to it through their 
> AAA link and....
> 
> So, to me, when you set aaaEapResp to TRUE on the authenticator, you 
> indicate to the AAA layer (e.g. RADIUS) that you have an EAP Response 
> received from the peer that you want to transfer to the AS. And this is 
> not the case in the scenario I describe. Hence, to me, if the 
> implementation is very dumb and logical, when aaaEapResp is set to TRUE, 
> the AAA layer should take whatever is located at aaaEAPRespData and 
> encapsulate in the AAA AVP (e.g. EAP message) and send it to the AS. Did 
> I clarify what I meant? Is this completely nonsense?

Yes, the AAA layer should take whatever is located at aaaEapRespData
and encapsulate in the AAA message that defines some AVP or attribute
to carry EAP PDU.  But if aaaEapRespData is NONE, it locates
*nothing*.  It agree that the EAP state machine document is unclear on
what is the AAA layer's expected behavior when aaaEapRespData is NONE.
I believe that the expected behavor is creating an AVP or attribute to
carry EAP PDU but with empty data.  I think adding some clarification
on this in the EAP state machine draft (perhaps in Implementation
Considerations section) could be useful for implementors.

> 
> Proposed solution to problem 2: either adopt problem 1 proposed 
> resolution (which would remove the transition of figure 7 from 
> INITIALIZE_PASSTHROUGH to AAA_IDLE with currentId==NONE, BTW could you 
> tell me why or how this transition appeared?) or make the AAA layer 
> behavior explicit (e.g. it is able to understand that aaaEapResp==NONE 
> and if so signals "sth"  via the AAA layer to the AS... and this "sth" 
> should/could be defined)
> 
> >The way it works (in very shorthand, please don't make me be more
> >precise) is:
> >
> >
> >Time    EAP Layer                            Lower Layer
> >====    =========                            ===========
> >|     Transition to AAA_IDLE
> >|     Set aaaEapResp = TRUE
> >|                                        Sees aaaEapResp == TRUE
> >|                                        Sees aaaEapRespData == NONE
> > 
> >
> I disagree with this, the AAA layer does not have to understand that 
> EapRespData == NONE, to me the AAA layer is only responsible for 
> encapsulation of the data it is handed over. To me the behavior you 
> describe is layer violation of what the AAA layer does

I think the AAA layer should at least check whether EapRespData is
NONE or not (see my comment above).

> 
> >|                                        Build the first EAP Request
> >|                                        set aaaEapReq
> >|     Sees aaaEapReq
> >|     sends the request
> >|     waits for a response
> >|     set aaaEapResp = TRUE
> >|                                        Sees aaaEapResp == TRUE
> >|                                        sees aaaEapRespData is filled
> >|                                        Parses aaaEapRespData
> > 
> >
> It is not the AAA layer of the authenticator that parses EapRespData 
> (some checks have however been done by the authenticator in its EAP 
> layer, namely in RECEIVED2)

Right.  The AAA layer does not have to parse EapRespData.

Yoshihiro Ohba



> 
> >|                                        decides whether to send another
> >|                                          request, sets aaaEapReq or
> >|                                          aaaEapNoReq
> >|
> >V
> >
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap

Results generated by Tiger Technologies using MHonArc.