Subject: RE: [eap] Issue 286: Security

From: "Adrangi, Farid" <[email-masked]>
Date: Sun, 13 Feb 2005 22:25:56 -0800

Bernard, all
Please see my comments in line.
Farid

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 

> On Behalf Of Bernard Aboba
> Sent: Sunday, February 13, 2005 7:13 PM
> To: Bari, Farooq
> Cc: [email-masked]
> 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
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Adrangi, Farid" <[email-masked]>
Date: Wed, 16 Feb 2005 15:45:34 -0800

Hi Sam,
The proposed text was intended to clarify the immediate applicability of
the proposed solution only.  The included 3GPP specification references
(stage 2 and 3) explain exactly how the proposed solution is used for
3GPP/WLAN network selection.  The introduction section also provides
some usage models and rationale for EAP-based network advertisement, and
appendix provides detailed examples with network topology and railroad
diagrams.  But, I guess you still are not clear about the concept.  Hmmm
-- I guess we need to work on it more!  It would be nice if you file an
issue explaining what additional details you are expecting to see in the
document.  
-Farid

> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Wednesday, February 16, 2005 1:50 PM
> To: Adrangi, Farid
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: [eap] Issue 286: Security
> 
> 
> Your proposed text probably will not work for me.  It is focusing too
> much on who will use the technology, not on why or what they get out
> of the technology.
> 
> I should be able to read the document and come away knowing whether
> the technology is appropriate for an environment I'm considering
> designing and probably know what environments it would be good for.
> 
> I'm not sure your text does that.
> 
>

---

From: "Bari, Farooq" <[email-masked]>
Date: Wed, 16 Feb 2005 20:57:30 -0800

Hi Sam,

Section 1 of the draft has some of the information that you are probably
looking for and the proposed text that Farid sent out is not meant to
replace that information but to add to it. There also used to be much
more information on the roaming scenarios etc.in the draft in its
earlier versions which explained the usage etc. However as the draft
went through revisions the guidance we got from EAP WG was to focus on
the main objective of the draft and not focus too much on
informational/problem statement type of dicussion in the draft. The
reference document [netsel-problem] is a draft that got trigerred by
discussions on our draft and much of the of the information on the
larger problem space now resides in that draft. We have included this
draft as the reference.

BR,

Farooq

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Adrangi, Farid
> Sent: Wednesday, February 16, 2005 3:46 PM
> To: Sam Hartman
[email-masked]