| Re: [Issue 248] Comments on EAP state machine v4 | <– Date –> <– Thread –> |
|
From: Yoshihiro Ohba (yohba |
|
| 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
- Re: [Issue 248] Comments on EAP state machine v4, (continued)
- Re: [Issue 248] Comments on EAP state machine v4 Nick Petroni, June 25 2004
- Re: [Issue 248] Comments on EAP state machine v4 Florent Bersani, June 26 2004
- Re: [Issue 248] Comments on EAP state machine v4 Nick Petroni, June 26 2004
- Re: [Issue 248] Comments on EAP state machine v4 Florent Bersani, June 29 2004
- Re: [Issue 248] Comments on EAP state machine v4 Yoshihiro Ohba, June 26 2004
- Re: [Issue 248] Comments on EAP state machine v4 John Vollbrecht, June 28 2004
- Re: [Issue 248] Comments on EAP state machine v4 Florent Bersani, June 29 2004
- dos vulnerabilities of NAKs and Failures (Was: Re: [eap] [Issue 248] Comments on EAP state machine v4) Jari Arkko, June 29 2004
- Re: [Issue 248] Comments on EAP state machine v4 Nick Petroni, June 25 2004
Results generated by Tiger Technologies using MHonArc.