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

[Bernard Aboba (aboba]

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.

In Section 3, the term "AN RADIUS server" is used.  From what I can tell,
this is actually a RADIUS proxy.  Also the abbreviation "AN" is not
defined in the terminology section.  Perhaps the term "local RADIUS proxy"
might be more appropriate.  The term "next RADIUS server" is used
as well.  I think what is meant here is "home RADIUS server", no?

I'd prefer if the terms EAP-Request/Identity and EAP-Response/Identity
were written out, rather than being abbreviated.

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.

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.  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.

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?  Note that this implies that the
RADIUS proxy would not know if the authenticator had sent an identity hint
originally, so that it would still need to retry (3 EAP Responses would be
received in all).

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).