eap Mailing List: RE: Issue 286: Security

[Adrangi, Farid (farid.adrangi]

Bernard, all
Please see my comments in line.
Farid

> -----Original Message-----
> From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] 

> On Behalf Of Bernard Aboba
> Sent: Sunday, February 13, 2005 7:13 PM
> To: Bari, Farooq
> Cc: eap [at] frascone.com
> Subject: RE: [eap] Issue 286: Security
> 
> 
> > I do not claim myself to be a security expert. The 
> fundamental question
> > that I ask, is if it is fair thing to ask a service provider not to
> > announce its presence when by the very nature of its 
> business it needs
> > to announce its presence to the maximum number of current 
> and potential
> > future customers?
> 
> It seems fair to enable the maximum degree of connectivity -- 
> but this is
> not the same as requiring that a AAA proxy announce its routing table
> beyond the boundaries of the routing system.  Based on some of the
> exchanges, my understanding is that there is some implicit "filtering"
> that is to occur in the route announcements so that not all routes are
> actually announced to the client.  But it is not clear to me from the
> discussion exactly how this filter is defined, and what the 
> impact is on
> global reachability.
> 

Three are a few things to note:

(1) AAA proxy announcement does NOT happen always.  If the AAA proxy
knows how to route @Bigco.com, then it will go ahead and do it - i.e.,
no network announcement!  For example, AAA proxy may have a direct
business relationship with Bigco.com.  

(2) "filtering" could be done based on the realm part of the user's NAI.
When the local AAA proxy (that does not have a direct roaming
relationship with bigco.com) receives a AAA packet for a user of
bigco.com, it is possible for the AAA proxy to know which of its roaming
partners can route the packet to bigco.com, and hence it announces only
those roaming partners.

(3) Glen also suggested that "filtering" can be done by having the user
to announce the roaming partners of its home operator.   But, I see some
problems with this method:

(a) Would operators be happy with this method? That is, having the
client reveal all their roaming partners to any access network?

(b) This method does not seem to work well when "manual selection" is
used.  The "manual selection" refers to a usage model where a list of
networks appears on the screen, and the user selects one (based on some
prior knowledge).

(c) Let's say the user announces a, b, c networks, and it turns out the
AAA proxy also supports a, b, c networks and therefore it announces a,
b, c.  So, in this case, it does not make any difference!


> > 1) What is the issue with advertising presence of a service 
> provider to
> > all users before authentication has been done?
> 
> The exchanges have brought up at least three issues:
> 
> a)  Security.  In the Request/Response model the peer announces its
> networks, then the AAA proxy replies with a subset of that set that it
> supports.  In such an exchange a rogue proxy can learn the networks
> supported by the client, but it is harder for a rogue client 
> to learn all
> the networks supported by a AAA proxy.  Are the threats in one model
> inherently more serious than the other model?

I guess the question is that what harms a rogue client can do once it
learns the roaming partners of an access network?  Did we miss any
attack scenarios in the security section?

> 
> b) Scalability.  As the number of supported networks grows, a
> Request/Response model appears to scale better than a raw
> announcement model.  In particular, a peer may only be 
> expected to support
> a relatively small number of networks, while a AAA proxy may support a
> great many.  Therefore a Request/Response exchange can scale to a much
> greater degree than a pure announcement model can, without having to
> exceed the MTU size.
> 
 
A Request/Response model can be added as an option to the draft -- and
it would be upto the operators if they want to implement it in their
clients.  

BTW, I thought the WG decided to position this draft as a short-term
solution (to mainly address 3GPP needs) while waiting for IEEE 11u (or
whatever) for more secure, scalable, and efficient (layer-2 based)
solution?  

> c) Reachability.  Given that a pure announcement model does 
> not scale, the
> question is what filters need to be applied in order to allow the
> announcement to fit within an MTU.  The document appears to 
> assume that a
> "carrier" filter is being applied which prevents home AAA servers from
> being advertised.  

How did you infer that?  If the AAA proxy can route the packet directly
to the home network, there won't be any announcement.  That is, the
proposed solution will NOT be exercised.

>Glen has questioned whether this implicit 
> roaming model
> is articulated in the document, and whether that model is 
> consistent with
> RFC 2194 and RFC 2477.
> 

Or, we can reverse the question:  Why isn't the proposed solution
consistent with the RFCs?

> > 2) Do not we do it today via SSID or PLMN ID etc? Do not the hotpsot
> > operator try to announce themselve by trying to have a 
> specific SSID for
> > their customers and broadcasting it (it has its issues but they are
> > relevant to this discussion). The hotspot operators can 
> even announce
> > their roaming partners today by using multiple SSIDs.
> 
> Today there are a number of models in use for SSID 
> discovery/announcement.
> For example, some vendors support both announced and "hidden" SSIDs.
> Announced SSIDs are sent in Beacons, along with capabilities. 
>  "Hidden"
> networks can only be discovered via a Probe Request/Response. 
>  So I think
> the answer today is that *both* the broadcast and request/response
> exchanges are supported.
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>