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

[Glen Zorn (gwz) (gwz]

Adrangi, Farid <mailto:farid.adrangi [at] intel.com> supposedly
scribbled:

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

I don't really understand your point.  I agree (and said) that they
may be co-located; that doesn't make them the same thing.  My
dictionary defines "entity" as "Something that exists as a
particular and discrete unit."  

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

Which entity is going to _provide_ the hints?  That is, which one
has knowledge of roaming partners, next hop routing for AAA packets,
etc.?  Since what you are actually doing is telling the user how to
source-route AAA packets, wouldn't that be the AAA server?
     
> 
>> 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).  

Not exactly -- it will be done based upon what AAA tells the client
to put in the NAI.

> 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

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel