Subject: RE: [eap] Issue 286: Security

From: "Bari, Farooq" <[email-masked]>
Date: Sun, 13 Feb 2005 17:46:50 -0800

Hi Bernard,

Pls see my comments below.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Bernard Aboba
> Sent: Sunday, February 13, 2005 12:09 PM
> To: [email-masked]
> Subject: [eap] Issue 286: Security
> 
> It seems that the crux of the issue here is the appropriateness of the
> network disclosure mechanisms.
> 
> For example, as I understand it in 802.11u, there is a proposal
whereby
> the STA would disclose the networks with which it has a relationship
in
> the Probe Request, and the AP would respond with the subset of that
list
> that it supports in the Probe Response.
> 
> The discovery mechanism in this draft is somewhat different:  the AAA
> proxy discloses its roaming relationships to the peer without the peer
> first indicating what networks it supports.
> 
> The questions this issue raises are:
> 
> 1. Is the disclosure negotiation described in this document
appropriate?
>    What are the security implications?
> 
> 2. Does the document need to be modified so as to have the peer
indicate
>    the networks it supports?

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
furutre customers? Also

1) What is the issue with advertising presence of a service provider to
all users before authentication has been done?  What new security issue
has been created? Service providers use printed materials, radio/tv
advertisements etc. to announce their presence as well. Are these all
security risks and they have security implications? Should they take off
all the billboards, newspaper advertisements etc. as well?  Again I say,
no new security issue is created as this knowledge already exsists in
public domain.

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.

BR,

Farooq
> _______________________________________________
> 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: Bernard Aboba <[email-masked]>
Date: Sun, 13 Feb 2005 19:12:53 -0800 (PST)

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

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

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.

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

> 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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 14 Feb 2005 12:44:20 +0200

> their roaming partners today by using multiple SSIDs.

The use of virtual SSIDs is probably similar to what is
being proposed here, in that the presence of a network
is published and that there are fundamental limits to
how many such networks will in practise be published.
That is, both would probably be used in a commercial
setting to highlight the existence of a few large commercial
entities, rather than a hundred thousand served corporate
networks.

I think Bernard mentioned that hidden SSIDs are possible.
The same is possible in the advertisement scheme as well,
by not advertising all partners... not sure if the draft
mentions this case though.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Feb 2005 18:40:04 +0200

Here's an attempt to write some text that would
address this issue. I agree that the draft should
define its area of applicability better, and
should talk about the security considerations of
revealing network identities.

Text: Add the following new text to the end
of the abstract:

   The mechanism defined in this document is
   primarily intended for advertising connectivity
   to a limited number of entities that find such
   advertisements of their presence useful.

Add the following new text before the
last paragraph in Section 1.

   This mechanism is not generally applicable to
   all access networks or all home or mediating networks.
   Basic roaming and AAA routing mechanisms are normally
   sufficient, and the identification hints are typically
   useful only when there's too much ambiquity, or when
   the scale of the roaming associations precludes
   full automatic connectivity from all access networks
   to all home networks. In such situations, a limited
   number of identity hints can be provided. Even
   in this case, it is required that the networks that
   are listed in these hints consent to such
   advertisements.

And add this to the Security Considerations section:

   Any information revealed either from the network
   or client sides before authentication has occurred
   can be seen as a security risk. For instance, revealing
   the existence of network that uses a poor authentication
   method can make it easier for attackers to discover
   that such network can be accessed. As a result,
   the consent of the network being described in the
   hints is required before such hints can be sent.

Comments? Would this work for people?

--Jari

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Tue, 15 Feb 2005 13:31:24 -0800

Jari Arkko <> supposedly scribbled:

> Here's an attempt to write some text that would address this
issue. I
> agree that the draft should define its area of applicability
better,
> and should talk about the security considerations of revealing
> network identities. 

This would work for me: I would _really_ like to end all this rather
coy dancing around the subject.  So, I would like the authors to
explain clearly, concisely and precisely (_in the document_, not in
the EAP list archives or some 3GPP document-in-progress, unless
those are referenced _in the document_) what the purpose of this
thing is, who is going to use it and why. Farooq has reminded us
several times that this is 3GPP; OK, then put that in title:
"Identity Selection in 3GPP Networks" or something.  As I mentioned
in an earlier message, I don't think that any of the hints are
actually necessary for roaming to function, especially those in
secondary identity requests.  I suspect (but don't _know_, since the
authors aren't telling) that this is actually to implement some kind
of AAA source-routing, possibly to support some legacy model of
circuit-switched accounting.  OK, fine.  Explain that, clearly mark
it as a 3GPP thing, make it Informational and let's be done with it.

> 
> Text: Add the following new text to the end of the abstract:
> 

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: Jari Arkko <[email-masked]>
Date: Wed, 16 Feb 2005 15:19:18 +0200

Hi Glen,

> thing is, who is going to use it and why. 

Ok, great!

> Farooq has reminded us several times that this is 3GPP; OK, then put that in title:
> circuit-switched accounting.  

I believe 3GPP intends to use some form of source routing,
even though that would not necessarily be the only way to
use this functionality. I personally hesitate a bit to make
the title 3GPP specific. (Maybe its just a preference of
writing "situation X" instead of "organization Y".) There
seems to be a very specific scenario where the hints are
useful; what comes afterwards is either a decision to go
somewhere else, use another identifer, or source routing.

> OK, fine.  Explain that, clearly mark

It is already Informational (and individual submission).

--Jari