eap Mailing List: RE: Comments on draft-adrangi-eap-network-discovery-07.txt

[Adrangi, Farid (farid.adrangi]

Hi Glen,
Please see my comments inline.
Farid

> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:gwz [at] cisco.com] 
> Sent: Friday, February 11, 2005 2:54 PM
> To: iesg [at] ietf.org
> Cc: Adrangi, Farid; Lortz, Victor; farooq.bari [at] attws.com; 
> Pasi.Eronen [at] nokia.com; eap [at] frascone.com
> Subject: Comments on draft-adrangi-eap-network-discovery-07.txt
> 
> 
> Section 2, paragraph 2 says "if the EAP server receives an
> EAP-Response/Identity with an unacceptable NAI Realm, EAP servers
> implementing this specification SHOULD reply with an
> EAP-Request/Identity containing an identity hint."  It's not clear
> how the EAP-Response/Identity message would reach an EAP server if
> it was unacceptable, nor how it would know what an acceptable hint
> would be.  The NAI is used to route AAA messages.  If the user knows
> the realm, and the realm is valid, and the EAP server receives from
> AAA an EAP message containing a known, valid user ID, how can that
> be unacceptable?  If it was somehow delivered to the wrong AAA home
> server, the only appropriate action for the AAA server to take is to
> deny access; if it was correctly delivered, however, the right
> course is to continue the authentication process.  This leads me to
> believe that there is a purpose other than the advertisement of
> available realms being served by this draft; if so, it might be a
> good idea if it were to be disclosed.
> 
I think Joe brought up the similar point.  So, please let's use the same
thread to avoid duplicate discussion.

> In the appendix, the authors take it upon themselves to use the term
> "EAP server" as a kind of placeholder that can represent virtually
> any entity in both the EAP and AAA chains.  However, an EAP server
> is a well-defined thing; in particular, it is not identical to an
> EAP authenticator (though they may be co-located), nor a RADIUS
> proxy, nor a RADIUS server (ditto).  

RFC 3784 has the following definition of an EAP server.

EAP server
      The entity that terminates the EAP authentication method with the
      peer.  In the case where no backend authentication server is used,
      the EAP server is part of the authenticator.  In the case where
      the authenticator operates in pass-through mode, the EAP server is
      located on the backend authentication server.

>This is a technical error, and
> betrays to my thinking a certain fuzziness (at least) of thought
> about the subject.  In fact, a real EAP server is unlikely to have
> any knowledge of NAIs or AAA routing, so that the hints described
> would almost certainly come from some AAA entity.  

I don't think we are saying that EAP server will do AAA routing.
However, we are saying the role of EAP server (could be part of
authenticator or AAA proxy) will be responsible for sending EAP-Identity
Request containing the hints.  In some cases, the AAA bearer is used to
deliver the EAP-Identity Request (e.g., when it is issued by the AAA
proxy).  Maybe "EAP server" is not the right term to use and hence the
source of the confusion.  But, I think we agree on how things would work
from technical / protocol perspective, do you have any suggestions for
using another term instead of "EAP server" for our purpose here?

> Hidden behind
> this fuzziness is a rather dangerous assumption, I think, that AAA
> should not only transport EAP messages, but interpret them and
> actually interfere with the operation of the EAP protocol.
> 
Fine, but that's outside the scope of this document.  As far as this
document concerns, AAA routing will be done based on the NAI placed in
UserName(1) attribute - please see RFC3579 on how NAI gets copied to
UserName(1).  Where AAA proxy in the Access Network is not able to route
the packet based the realm portion of the NAI, then it may send an
Access-Challenge with identity hints to the peer.

> If I understand the intent of this document, it seems that if this
> protocol operates successfully, the result will be that any person
> within range of say, an 802.11 hotspot, who just begins the EAP
> authentication process will end up with a list of all the roaming
> partners of the access network.  This would seem to be a rather
> serious security risk, but it is unmentioned in the Security
> Considerations section.
> 

In security section, we mention possible attack scenarios and some
methods to prevent them.  Did we miss any?  What is the attack scenario
that you have in mind?

> ~gwz
>