Subject: RE: [eap] Issue 286: Security

From: "Adrangi, Farid" <[email-masked]>
Date: Tue, 15 Feb 2005 13:51:30 -0800

I agree with you Glen.  Eugene also requested some clarification on
applicability/scalability of the solution.  Will the following text work
for you?  And Eugene?

"
The immediate application of the proposed mechanism is in 3GPP systems
inteworking with WLANs [XX][yy]. The roaming partner information
provided via this mechanism is limited by the link layer MTU size. For
example, assuming an average of 20 octets per roaming partner / home
network information and the link layer MTU size of 1096, the approximate
number of roaming partners that can be advertised would be 50.  The
scalability limitation imposed by the link layer MTU size should be
taken into consideration when deploying this solution.

[xx] TS.23.234 3GPP System to Wireless Local Area Network (WLAN)
interworking. Stage 2. (www.3gpp.org) 
[yy] TS.24.234 3GPP System to Wireless Local Area Network (WLAN)
interworking. Stage 3. (www.3gpp.org)
"

BR,
Farid

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Glen Zorn (gwz)
> Sent: Tuesday, February 15, 2005 1:31 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [eap] Issue 286: Security
> 
> 
> 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:
> > 
> >    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
> > _______________________________________________
> > eap mailing list
> > [email-masked]
> > http://mail.frascone.com/mailman/listinfo/eap
> 
> 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
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Feb 2005 07:33:21 +0200

Sam,

I agree that the text should focus on what the
situation is rather than who uses this stuff.
I sent an alternative text proposal to the EAP
list a while ago (but it did not go to the IESG
list). Here's a new revision of that proposal.
Would this work for you better?

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

Replace paragraphs 3-5 in Section 1 with the
following:

   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 to try
   all client identity and access network combinations
   efficiently, or when the scale of the roaming associations
   precludes full automatic connectivity from all access
   networks to all home networks. This can happen, for
   instance, when access networks have contracts with
   multiple roaming consortiums but do not have a full
   list of home networks reachable through them.

   In the situations mentioned above, a limited
   number of identity hints can be provided by the
   mechanism described in this document. Even
   in this case, for security reasons it is required
   that the networks that are listed in these hints
   consent to such advertisements.

   Exactly how the identity hint information is used by
   the peer depends largely on the peer's local policy
   and configuration, and is outside the scope of this
   document. However, the peer would typically either
   decide to use another identity it has, decide to
   switch to another access network, or attempt to
   reformat its NAI [rfc2486bis] to assist in proper
   routing.

   This document is also related to the general network
   discovery and selection problem. See [netsel-problem]
   for more detailed discussion about this problem space.