eap Mailing List: RE: comments on draft-adrangi-eap-network-discovery-02.txt

[Adrangi, Farid (farid.adrangi]

Thanks.  Please see my comments inline.
BR,
Farid

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba [at] internaut.com] 
> Sent: Tuesday, August 10, 2004 10:22 AM
> To: Adrangi, Farid
> Cc: eap [at] frascone.com; Pasi.Eronen [at] nokia.com
> Subject: RE: [eap] comments on 
> draft-adrangi-eap-network-discovery-02.txt
> 
> 
> Another comment.
> 
> In Section 3, the term "Wireless client" is used.  I'd 
> suggest that the
> term "EAP peer" be used instead.  Instead of AP, I'd use "EAP
> Authenticator" or NAS.
> 
> I'd recommend that step 1 (Association) be removed, since the 
> document is
> applicable to all access media, and inclusion of the 
> Association exchange
> appears to preclude EAP pre-authentication.
> 
Ok.  In that case, I guess we don't need the applicability section.

> In Section 3, the term "AN RADIUS server" is used.  From what 
> I can tell,
> this is actually a RADIUS proxy.

Yes, it acts as a RADIUS proxy.  It is my understanding that AAA servers
can also act as proxies when needed -- anyhow, I will change the name to
be more specific.

>  Also the abbreviation "AN" is not
> defined in the terminology section.  Perhaps the term "local 
> RADIUS proxy"
> might be more appropriate.

Ok.

>  The term "next RADIUS server" is used
> as well.  I think what is meant here is "home RADIUS server", no?
> 

Yes, home RADIUS server would be more appropriate.

> I'd prefer if the terms EAP-Request/Identity and EAP-Response/Identity
> were written out, rather than being abbreviated.
> 
Ok.
> In Section 3.1, 3.2 and 3.3, in the figures, the EAP 
> conversation is shown
> to occur only between the AP and the AN RADIUS server.  I'd 
> suggest that this
> be corrected to show the conversation going between the peer 
> and the home
> server.
> 

The figures are done from AAA routing perspective.  Don't you think the
conversation between the peer and RADIUS server is irrelevent here?

> In Section 3.3, a RADIUS proxy is shown responding to an
> EAP-Request/Identity.  An implication might be drawn that the RADIUS
> proxy is EAP-aware.

Yes.

>  What is happening is that the RADIUS 
> proxy does not
> have a route for the NAI Realm included in the User-Name 
> attribute.  In
> this situation, rather than silently discarding the Access-Request, it
> formulates an Access-Challenge with an EAP-Request/Identity 
> containing an
> identity  hint.  So the RADIUS proxy doesn't actually have to 
> interpret
> the contents of the EAP-Message attribute.
> 
That's correct.  I thought the paragraph after 3.3 diagram explained
this.  

> Also, I think there is an implication here that a State 
> attribute is being
> sent;  otherwise, how would the RADIUS proxy know if an 
> identity hint had
> previously been sent by it to the peer? 

Excellent point!  I thought about mentioning this in the draft, but I
thought it would be too much implementation-specific detials.  So, I
guess we need to bring it up.

> Note that this 
> implies that the
> RADIUS proxy would not know if the authenticator had sent an 
> identity hint
> originally,

That's right!

> so that it would still need to retry (3 EAP 
> Responses would be
> received in all).
> 

But, I don't know why the local AAA proxy should try the identity hint 3
times before it gives up.  If the local AAA proxy cannot still route the
AAA packet after sending the identity hints, then it should give up
rather than sending another identity hints (via EAP-Identity Request).

> Overall, my recommendation is that the requirements on EAP peers and
> servers deriving from Section 3.3 go into Section 1, phrased 
> purely in EAP
> terms (as suggested earlier).  In the Appendix, you can go 
> into the AAA
> implications -- however, please avoid the use of normative 
> language since
> this specification isn't about RADIUS or Diameter (if it 
> were, it would
> require review from the RADEXT or AAA WGs).
> 
Ok.