| Comments on draft-adrangi-eap-network-discovery-07.txt | <– Date –> <– Thread –> |
|
From: Glen Zorn (gwz) (gwz |
|
| Date: Fri, 11 Feb 2005 17:54:04 -0500 (EST) | |
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. 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). 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. 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. 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. ~gwz
-
Comments on draft-adrangi-eap-network-discovery-07.txt Glen Zorn (gwz), February 11 2005
-
RE: Comments on draft-adrangi-eap-network-discovery-07.txt Adrangi, Farid, February 11 2005
-
RE: Comments on draft-adrangi-eap-network-discovery-07.txt Glen Zorn (gwz), February 11 2005
- RE: RE: Comments on draft-adrangi-eap-network-discovery-07.txt Glen Zorn (gwz), February 11 2005
-
RE: Comments on draft-adrangi-eap-network-discovery-07.txt Glen Zorn (gwz), February 11 2005
- RE: RE: Comments on draft-adrangi-eap-network-discovery-07.txt Adrangi, Farid, February 11 2005
-
RE: Comments on draft-adrangi-eap-network-discovery-07.txt Adrangi, Farid, February 11 2005
Results generated by Tiger Technologies using MHonArc.