Comments on draft-adrangi-eap-network-discovery-07.txt
From: Glen Zorn (gwz) (gwzcisco.com)
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

Results generated by Tiger Technologies using MHonArc.