Subject: [eap] RE: Comments on draft-adrangi-eap-network-discovery-07.txt

From: "Adrangi, Farid" <[email-masked]>
Date: Fri, 11 Feb 2005 15:55:50 -0800

Hi Glen,
Please see my comments inline.
Farid

> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:[email-masked]] 
> Sent: Friday, February 11, 2005 2:54 PM
> To: [email-masked]
> Cc: Adrangi, Farid; Lortz, Victor; [email-masked]; 
> [email-masked]; [email-masked]
> 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
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Fri, 11 Feb 2005 16:20:12 -0800

Adrangi, Farid <mailto:[email-masked]> supposedly
scribbled:

>> 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
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. 
> 
EAP
>> authenticator (though they may be co-located), nor a RADIUS
proxy,
>> nor a RADIUS server (ditto).
> 
>       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."  

> 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?
     
> document concerns, AAA routing will be done based on the NAI
placed
> in  
> 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.   
> 
> 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
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Fri, 11 Feb 2005 18:25:19 -0800

Glen Zorn (gwz) <> supposedly scribbled:

...

>> scenario that you have in mind?

Sorry, I missed this one.  It seems that it enables attacks against
the greater network; it's not an attack against your protocol, per
se, but it seems that your protocol is giving away (by design) a lot
of information about network topology and even contracts to anybody
who happens along.  That's almost never a good idea.  It would be
far less revealing if the EAP peer were to send a list of realms it
was willing to use.

Hope this helps,

~gwz