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

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Fri, 11 Feb 2005 14:53:32 -0800

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.

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

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.

~gwz
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Sat, 12 Feb 2005 08:46:00 -0800

Glen Zorn (gwz) <mailto:[email-masked]> supposedly scribbled:

> OK, now that we've established that the security properties of
WLANs
> are identical to those of cellular networks (I wish that Farooq
had
> pointed this out several years ago -- it would have saved a lot of
> time in 802.11i), I guess we can dispense with any further
discussion
> of such things.  Furthermore, no enterprise networks will be
listed
> in the hints, just SPs.  Suppose, then, that Bigco.com contracts
with
> Consort.com to provide remote access for Bigco's employees when
they
> are traveling.  Suppose also that Consort.com is a roaming partner
of
> Megatel.com, which operates hotspots in coffeehouses around the
> world.  A Bigco employee walks into a Megatel hotspot and tries to
> access the network.  

Should have mentioned, using her Bigco.com user ID.

>How does that work?  Does it work at all? 

BTW, this example is from Real Life -- the names have been changed
to protect the innocent -- and is the simplest example of enterprise
roaming/remote access I can think of.  There are _much_ more complex
examples, also from Real Life.        

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: "Bari, Farooq" <[email-masked]>
Date: Sat, 12 Feb 2005 18:27:50 -0800

Hi Joe,

Following is link to the stage 3 (i.e. detailed design document) TS
24.234 that has this draft listed as reference. The latest rev is 6.1.1
that is being worked on.
http://www.3gpp.org/ftp/Specs/html-info/24234.htm

If it makes everyone happy we can include a reference to this document
in the IETF draft.

BR,

Farooq

-----Original Message-----
From: Salowey, Joe [mailto:[email-masked]] 
Sent: Saturday, February 12, 2005 5:50 PM
To: Bari, Farooq; Zorn, Glen; Adrangi, Farid; [email-masked]
Cc: Lortz, Victor; [email-masked]; [email-masked]; Stephen
Hayes (TX/EUS)
Subject: RE: [eap] RE: Comments on
draft-adrangi-eap-network-discovery-07.txt

Hi Farooq,

Perhaps there is an informative 3GPP document that this draft can
reference.

Thanks,

Joe 

> -----Original Message-----
> From: Bari, Farooq [mailto:[email-masked]] 
> Sent: Saturday, February 12, 2005 4:22 PM
> To: Zorn, Glen; Adrangi, Farid; [email-masked]
> Cc: Lortz, Victor; [email-masked]; [email-masked]; 
> Stephen Hayes (TX/EUS); Salowey, Joe
> Subject: RE: [eap] RE: Comments on 
> draft-adrangi-eap-network-discovery-07.txt
> 
> Hi Glen,
> 
> I am not sure why you are opening this particular discussion 
> at the last minute, more than a year after we closed this 
> topic in the EAP WG group.
> FYI again, as it was stated several times, this draft is to 
> be used by 3GPP (http://www.3gpp.org/TB/Other/IETF.htm) for 
> their interworking with WLAN. The roaming scenarios are based 
> on 3GPP models and they work fine.
> Trying to answer your questions in this manner will take 
> forever and is not productive - their were several 
> opportunities for you in the last two years as you do 
> attend/follow the EAP WG and the draft went through not one 
> but two pseudo WG last calls.
> 
> And please do not twist other person's comments.
> 
> I hope this helps.
> 
> Farooq
> 
> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:[email-masked]]
> Sent: Saturday, February 12, 2005 12:24 PM
> To: 'Adrangi, Farid'; Bari, Farooq; [email-masked]
> Cc: 'Lortz, Victor'; [email-masked]; [email-masked]
> Subject: RE: [eap] RE: Comments on
> draft-adrangi-eap-network-discovery-07.txt
> 
> Adrangi, Farid <mailto:[email-masked]> supposedly
> scribbled:
> 
> > Hi Glen,
> > I don't think Farooq was implying that (security properties of
> WLANs
> > are identical to those of cellular networks).  Anyhow, in your 
> > example, either Megatel.com knows that it needs to route
> @bigco.com
> > to Consort.com (based on some local policy),
> 
> So the local proxy needs to have a list of all of 
> Consort.com's partners?  Otherwise, won't it send a set of 
> hints (which we've established wouldn't include Bigco.com, 
> and therefore seem pretty much useless in this case) back to 
> the client?
> 
> > or the user influences
> > the routing by NAI decoration. 
> 
> Does the latter option exist, unless the user happens to know 
> all the relationships involved?
> 
> > -Farid   
> > 
> > 
> > 
> >> -----Original Message-----
> >> From: Glen Zorn (gwz) [mailto:[email-masked]]
> >> Sent: Saturday, February 12, 2005 8:30 AM
> >> To: 'Bari, Farooq'; Adrangi, Farid; [email-masked]
> >> Cc: Lortz, Victor; [email-masked]; [email-masked]
> >> Subject: RE: [eap] RE: Comments on
> >> draft-adrangi-eap-network-discovery-07.txt
> >> 
> >> 
> >> are traveling.  Suppose also that Consort.com is a roaming
> partner of
> >> access the network.  How does that work?  Does it work at all?
> 
> Hope this helps,
> 
> ~gwz
> 
> Why is it that most of the world's problems can't be solved by simply

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Sun, 13 Feb 2005 12:52:15 -0800

scribbled:

> Hi Glen,
> Please see my comments inline.
> Farid
> 
>> Sent: Saturday, February 12, 2005 4:54 PM
'Stephen
>> Hayes (TX/EUS)'; 'Salowey, Joe'
>> Bari, Farooq <mailto:[email-masked]> supposedly
scribbled:
>> 
>>> Hi Glen,
>>> 
>>> I am not sure why you are opening this particular discussion at
the
>>> last minute, more than a year after we closed this topic in the
EAP
>>> WG group.
>> 
>> It appears that this is not an EAP WG work item.  It only came to
my
>> attention that the IETF Last Call was ending Friday on Thursday,
and
>> I was actually not planning to comment; however, I was strongly
>> encouraged to do so by several others.  In any case, I believe
that
>> in this body topics are open for discussion until the last Last
Call
>> ends. 
>> 
> 
> Yes. This is an individual submission.  I believe we had 3 pseudo
> last calls (initiated by Bernard) before the draft was sent to
IESG,
> and also the WG had this draft reviewed by IEEE/WIEN and received
an
> official feedback/approval from the chair of IEEE/WIEN -- the
report
> was posted on the list by Bernard and Jari.    
> 
> We (authors) do encourage you to review the draft.  But, I don't
> think we want to repeat or rehash the discussion that we have had
in
> last two years.  A few things could help:  (1) You might want to
> review the archives (in last two years) on this thread and I am
sure
> you will find answers to most of your questions.  (2) You might
want
> to review the problem statement for network selection (written by
> Bernard and Jari). (3) You might want to review Release-6
3GPP/WLAN
> (stage 2 and 3      
> documents) which will provide an overview how this concept is
used.
> Your colleague, Mark Grayson, could also be a good source of the
> information, as he was involved in the design of network selection
in
> 3GPP.  

OK, so I'm not just trying to give you a hard time.  I also believe
myself to be neither a super-genius who can spot problems where
others cannot, nor delusional enough to imagine problems where there
are none (though Farooq may disagree with that ;-).  I have read all
the references (both normative and informative) cited in the draft,
several of them many times & co-authored one of them.  I was
co-chair of the WG that developed the original NAI spec.
Nevertheless, I still don't understand exactly how this thing would
work in practice & I still have serious (to me, anyway) questions
about both the security of the proposal and about its compatibility
with existing IETF models of roaming.  I believe that others could
reasonably pose similar questions.  Yet, RFCs are (I think) supposed
to be more or less standalone documents: if a person reads the RFC
and the normative texts referenced therein, that person (assuming
average intelligence & appropriate training) should understand
clearly the RFC in question.  Perhaps I'm just an idiot, but if not,
then telling me to read 2 years of email archives and hundreds of
pages of documentation from an external SDO in order to understand
an RFC is just unacceptable, IMHO.

<extensive explanation/justification of why everything is fine
elided>

Hope this helps,

~gwz

---

From: "Bari, Farooq" <[email-masked]>
Date: Mon, 14 Feb 2005 12:35:52 -0800

Hi Eugene,

Your comment about applicability is quite valid and was also requested by Joe - we do plan to update the draft for it.

BR,

Farooq

> From: Eugene Chang [mailto:[email-masked]]
> Sent: Monday, February 14, 2005 11:19 AM
> To: Bari, Farooq; Eugene Chang; [email-masked]; Adrangi, Farid; [email-masked]
> Subject: RE: [eap] RE: Comments on draft-adrangi-eap-network-discovery-07.txt
> 
> Farooq,
> Thanks for your reply.
> 
> 1- It would be very helpful if the scope being addressed be stated. It seems
> very natural to read an RFC as an absolute statement to a problem unless the
> limits are explicit.
> 
> 2- What is ironic to me is that in a subscribers "home region" where the
> home network has the most influence, the proposed solutions works well. This
> is the very scenario that the proposed solution may not be needed. When the
> subscriber is traveling far from home, the very situation the proposed
> solution is most valuable; it is likely that the proposed solution will not
> be helpful.
> 
> I have watched the discussion for a long time. With all the issues I have
> seen mentioned (again) in the last three days, I am surprised that, the
> draft has not changes to explicitly narrowed the focus to define some of the
> issues out-of-bounds or to have changed to broadened the solution's
> effectiveness to address more of the issues.
> 
> Gene
> 
> 
> ---------------------------------
> Eugene Y. Chang
> Funk Software
> voice   1-617-497-6339 x244
> fax     1-617-547-1031
> mobile  1-781-799-0233
> AIM     gene02421
> Skype   gene02421
> email   [email-masked]
> email   [email-masked]
> ---------------------------------
> 
> 
> > Sent: Monday, February 14, 2005 11:51 AM
> > To: Eugene Chang; [email-masked]; Adrangi, Farid; [email-masked]
> > Subject: RE: [eap] RE: Comments on draft-adrangi-eap-network-discovery-
> > 07.txt
> >
> > Hi Eugene,
> >
> > All I can say is that you are not catching up on your weekend emails but
> > on last two years worth of discussions in EAP WG :)) on the draft. It is
> > difficult  for me to understand why IESG has these rules that practically
> > reset everything that has happened with the draft since it got introduced
> > long time back and require authors to satisfy everyone again from the very
> > beginning on  fundamental questions that were dealt with longtime back and
> > are hard to explain/resolve/convey over emails...................
> >
> > A very brief response (which I am sure can not staisfy you and obviously
> > can not because discussion on this topic is something that has always
> > taken a long time to converge) is, the draft does not mandate anything on
> > the part of the service provider. It is about ABNF. The information on
> > roaming partners is just a hint for the client device about hotspot
> > operators own roaming partners, and no where does it say it has to be an
> > exhaustive list of all of its roaming partners roaming partners partner
> > etc..IT is not tryin g to solve world hunger problem.  The service
> > provider, can also choose not to advertise any of its partners, a couple
> > of them or all of them if there are a handful. This draft is NOT trying to
> > address your  thousands of roaming coprorate partners scenarios but is to
> > be used by 3GPP SPs. Again this roaming partner information is just a hint
> > and I am not sure why people expect this draft to solve everyone's roaming
> > issues and problems with all the scalability to handle n possible
> > mediating partners etc. ...... to be honest I am not sure if some one can
> > design such a solution that satisfies everyone's roaming dreams.
> >
> >
> > BR,
> >
> > Farooq
> >
> > > From: Eugene Chang [mailto:[email-masked]]
> > > Sent: Monday, February 14, 2005 7:46 AM
> > > To: [email-masked]; Bari, Farooq; 'Adrangi, Farid'; [email-masked]
> > > Subject: RE: [eap] RE: Comments on draft-adrangi-eap-network-discovery-
> > 07.txt
> > >
> > > Farid,
> > > I am sorry to be catching up with the weekend mail.
> > > Glen points out an example that is often overlooked. There are many
> > cases
> > > where the "home AAA" is the enterprise and not a public provider. This
> > > provides a significant increase in the number of home AAA. Further, the
> > > enterprises that fall into this category provide a large number of
> > roaming
> > > users so we should not be minimizing this scenario.
> > >
> > > I really would like to see an explanation of how this the network
> > discovery
> > > scheme works in a global context. I can understand how it works with a
> > small
> > > set of bilateral arrangements but I thing the scheme does not scale.
> > >
> > > Gene
> > >
> > >
> > > ---------------------------------
> > > Eugene Y. Chang
> > > Funk Software
> > > voice   1-617-497-6339 x244
> > > fax     1-617-547-1031
> > > mobile  1-781-799-0233
> > > AIM     gene02421
> > > Skype   gene02421
> > > email   [email-masked]
> > > email   [email-masked]
> > > ---------------------------------
> > >
> > >
> > > Sent: Saturday, February 12, 2005 11:46 AM
> > > To: [email-masked]; 'Bari, Farooq'; 'Adrangi, Farid'; [email-masked]