Subject: RE: [eap] comments on draft-adrangi-eap-network-discovery-02.txt

From: "Adrangi, Farid" <[email-masked]>
Date: Tue, 10 Aug 2004 12:13:32 -0700

Thanks.  Please see my comments inline.
BR,
Farid

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Tuesday, August 10, 2004 10:22 AM
> To: Adrangi, Farid
> Cc: [email-masked]; [email-masked]
> 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.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 10 Aug 2004 14:35:52 -0700 (PDT)

> conversation between the peer and RADIUS server is irrelevent here?

Yes.  That's why I'm not clear what the arrows are trying to say:

     |                   <-- EAP conversation -->                   |

The EAP converation is not the issue, and in any case, EAP is spoken
between the peer and the home RADIUS server so the arrows are in the wrong
place.

> That's correct.  I thought the paragraph after 3.3 diagram explained

You might say specifically that the RADIUS proxy acts only on the
User-Name attribute and does not have to parse the EAP-Message attribute.
That way it's clear that no change to RADIUS proxy behavior is intended.

> thought it would be too much implementation-specific details.  So, I

It's not a big deal if Section 3 goes in an Appendix.  Just don't use
normative language.

> > RADIUS proxy would not know if the authenticator had sent an

Yes, because there would be no State attribute to tell it that the NAS
already sent a hint.

> times before it gives up.

The AAA proxy would only try once, but the NAS would have tried once
before that, and it wouldn't know.  So you'd have two EAP-Identity
exchanges, both with hints.  After that the AAA proxy gives up, and
presumably sends an EAP-Notification or EAP-Failure.