Subject: [eap] Re: deciding which NAI to send in an ID-RESPONSE

From: [email-masked] (Mark Watson)
Date: Fri, 13 Jun 2003 09:34:52 +0100

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C33186.A8B89A78
Content-Type: text/plain;
	charset="iso-8859-1"

> 
> > I am looking for a solution which places minimum new requirements on
> > elements in the WLAN network - that is the AP and any 
> RADIUS proxies used to
> > route authentication signalling to/from the WISPs that do the actual
> > authentication.
> 
> Are we talking about minimum requirements beyond what will be
> required for WFA certification of a public access AP?
> 

I am not familiar with the WFA certification requirements, but in terms of
the 3G interworking activity, the objective is to minimise the requirements
on the AP to those that are absolutely necessary (e.g. for security we
require WPA). Any additional requirements will reduce the set of WLAN
deployments that could interwork with 3G networks.

> > Further, only one SSID can be broadcast - which one ?
> 
> This is purely a limitation of the AP implementation.

Only in the sense that you could implement multiple logically distinct APs
in one physical AP. A single logical AP as described in 802.11 has only one
broadcast SSID, as I understand it.

> Assuming that
> support for multiple SSIDs were available, would you still need
> support within EAP?
>

Well, if all the available SSIDs are broadcast, this could work. But this is
not widely supported in WLANs today. Also, I am not sure that it's a
reasonable restriction to place on the WLAN owner - I gave the example of
the existing WLAN at Oslo airport - can we *require* that Oslo airport
modifies their WLAN to provide a separate SSID for each WISP they work with
? There will still be users who do not have an automatic authentication
capability (i.e. who rely on the 'landing page' & web-based
username/password) - how will they know which SSID to use ??

> > Where do I get info
> > about the other SSID's available
> 
> Two possibilities:
> 
> a. Send a Probe Request for the broadcast SSID.
> b. Send a Probe Request for a specific SSID.
> 

There are too many to use probes. To answer you question below, the user may
be able to authenticate through hundreds of domains. It would be too slow to
probe these all to see which is available.

> > (broadcast SSID) then access to any of the others will be 
> slow (have to
> > associate with the broadcast one first to get the info etc. etc.).
> 
> In IEEE 802.11, scanning (Beacons, Probe Request/Response) 
> occurs prior to
> authentication or association. Typical response times are on 
> the order of
> 1-2 ms. It's the EAP exchange that may require Association first (if
> pre-authentication isn't used).
> 

No, given that trial-and-error probes are too slow, then if you use multiple
SSIDs, with only one broadcast, then you will need to associate to the
broadcast one to get the information about what SSIDs are available (various
ways to do this once you've associated). Then you'd have to re-associate
with your chosen SSID.

So, I think that separate SSIDs for each network is unreasonable unless they
are all broadcast, requiring Virtual AP support, which is not ubiquitous in
todays WLANs.

> > The user may know too many domains throught which they can 
> authenticate to
> > try a probe for each one (e.g. 3G case).
> 
> How many domains are we talking about? A dozen? A hundred? A thousand?
> 
> > Putting the info in the Request/Identity, if I understand 
> correctly, is a
> > burden on the AP, because the Request/Identity is generated 
> by the AP.
> 
> Since the contents of the Request/Identity message doesn't 
> change, the AP
> can just store the contents of the Type-Data field, so we're 
> just talking
> about a little memory, no computational load.
> 

Yep, but it's a new function which would have to be implemented on APs. A
WLAN owner would need to upgrade all their APs or buy new ones before they
could support this mechanism.

> > Perhaps, though, a subsqeuent Request/Identity after an 
> unrecognised NAI
> > domain error could be generated by the RADIUS proxy 
> detecting this ? But
> > this proxy does not otherwise need to understand EAP.
> 
> Yes, it could be generated by the proxy.

This would be easier for the WLAN network owner - probably only a small
number of RADIUS proxies.

> 
> > Sure, I would expect this information to be a 'hint' about 
> the NAI domains
> > that *are* supported. You can ignore it if you like & try a 
> different
> > domain, but then you'll get an error response.
> 
> OK. Out of curiosity, how many domains (e.g. values of 
> network-id) are we
> talking about?

Hundreds, could be more than a thousand, I am not sure - one for each 3G
operator in the world.

As a 3G subscriber I can authenticate through any 3G operator which has a
roaming agreement with my home operator.

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

------_=_NextPart_001_01C33186.A8B89A78
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [eap] Re: deciding which NAI to send in an =
ID-RESPONSE</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I am looking for a solution which places =
minimum new requirements on</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; elements in the WLAN network - that is the =
AP and any </FONT>
<BR><FONT SIZE=3D2>&gt; RADIUS proxies used to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; route authentication signalling to/from =
the WISPs that do the actual</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; authentication.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Are we talking about minimum requirements =
beyond what will be</FONT>
<BR><FONT SIZE=3D2>&gt; required for WFA certification of a public =
access AP?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>I am not familiar with the WFA certification =
requirements, but in terms of the 3G interworking activity, the =
objective is to minimise the requirements on the AP to those that are =
absolutely necessary (e.g. for security we require WPA). Any additional =
requirements will reduce the set of WLAN deployments that could =
interwork with 3G networks.</FONT></P>

<P><FONT SIZE=3D2>&gt; &gt; Further, only one SSID can be broadcast - =
which one ?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This is purely a limitation of the AP =
implementation.</FONT>
</P>

<P><FONT SIZE=3D2>Only in the sense that you could implement multiple =
logically distinct APs in one physical AP. A single logical AP as =
described in 802.11 has only one broadcast SSID, as I understand =
it.</FONT></P>

<P><FONT SIZE=3D2>&gt; Assuming that</FONT>
<BR><FONT SIZE=3D2>&gt; support for multiple SSIDs were available, =
would you still need</FONT>
<BR><FONT SIZE=3D2>&gt; support within EAP?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

<P><FONT SIZE=3D2>Well, if all the available SSIDs are broadcast, this =
could work. But this is not widely supported in WLANs today. Also, I am =
not sure that it's a reasonable restriction to place on the WLAN owner =
- I gave the example of the existing WLAN at Oslo airport - can we =
*require* that Oslo airport modifies their WLAN to provide a separate =
SSID for each WISP they work with ? There will still be users who do =
not have an automatic authentication capability (i.e. who rely on the =
'landing page' &amp; web-based username/password) - how will they know =
which SSID to use ??</FONT></P>

<P><FONT SIZE=3D2>&gt; &gt; Where do I get info</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; about the other SSID's available</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Two possibilities:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; a. Send a Probe Request for the broadcast =
SSID.</FONT>
<BR><FONT SIZE=3D2>&gt; b. Send a Probe Request for a specific =
SSID.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>There are too many to use probes. To answer you =
question below, the user may be able to authenticate through hundreds =
of domains. It would be too slow to probe these all to see which is =
available.</FONT></P>

<P><FONT SIZE=3D2>&gt; &gt; (broadcast SSID) then access to any of the =
others will be </FONT>
<BR><FONT SIZE=3D2>&gt; slow (have to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; associate with the broadcast one first to =
get the info etc. etc.).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In IEEE 802.11, scanning (Beacons, Probe =
Request/Response) </FONT>
<BR><FONT SIZE=3D2>&gt; occurs prior to</FONT>
<BR><FONT SIZE=3D2>&gt; authentication or association. Typical response =
times are on </FONT>
<BR><FONT SIZE=3D2>&gt; the order of</FONT>
<BR><FONT SIZE=3D2>&gt; 1-2 ms. It's the EAP exchange that may require =
Association first (if</FONT>
<BR><FONT SIZE=3D2>&gt; pre-authentication isn't used).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>No, given that trial-and-error probes are too slow, =
then if you use multiple SSIDs, with only one broadcast, then you will =
need to associate to the broadcast one to get the information about =
what SSIDs are available (various ways to do this once you've =
associated). Then you'd have to re-associate with your chosen =
SSID.</FONT></P>

<P><FONT SIZE=3D2>So, I think that separate SSIDs for each network is =
unreasonable unless they are all broadcast, requiring Virtual AP =
support, which is not ubiquitous in todays WLANs.</FONT></P>

<P><FONT SIZE=3D2>&gt; &gt; The user may know too many domains throught =
which they can </FONT>
<BR><FONT SIZE=3D2>&gt; authenticate to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; try a probe for each one (e.g. 3G =
case).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; How many domains are we talking about? A dozen? =
A hundred? A thousand?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Putting the info in the Request/Identity, =
if I understand </FONT>
<BR><FONT SIZE=3D2>&gt; correctly, is a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; burden on the AP, because the =
Request/Identity is generated </FONT>
<BR><FONT SIZE=3D2>&gt; by the AP.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Since the contents of the Request/Identity =
message doesn't </FONT>
<BR><FONT SIZE=3D2>&gt; change, the AP</FONT>
<BR><FONT SIZE=3D2>&gt; can just store the contents of the Type-Data =
field, so we're </FONT>
<BR><FONT SIZE=3D2>&gt; just talking</FONT>
<BR><FONT SIZE=3D2>&gt; about a little memory, no computational =
load.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>Yep, but it's a new function which would have to be =
implemented on APs. A WLAN owner would need to upgrade all their APs or =
buy new ones before they could support this mechanism.</FONT></P>

<P><FONT SIZE=3D2>&gt; &gt; Perhaps, though, a subsqeuent =
Request/Identity after an </FONT>
<BR><FONT SIZE=3D2>&gt; unrecognised NAI</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; domain error could be generated by the =
RADIUS proxy </FONT>
<BR><FONT SIZE=3D2>&gt; detecting this ? But</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; this proxy does not otherwise need to =
understand EAP.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Yes, it could be generated by the proxy.</FONT>
</P>

<P><FONT SIZE=3D2>This would be easier for the WLAN network owner - =
probably only a small number of RADIUS proxies.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sure, I would expect this information to =
be a 'hint' about </FONT>
<BR><FONT SIZE=3D2>&gt; the NAI domains</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that *are* supported. You can ignore it if =
you like &amp; try a </FONT>
<BR><FONT SIZE=3D2>&gt; different</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; domain, but then you'll get an error =
response.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; OK. Out of curiosity, how many domains (e.g. =
values of </FONT>
<BR><FONT SIZE=3D2>&gt; network-id) are we</FONT>
<BR><FONT SIZE=3D2>&gt; talking about?</FONT>
</P>

<P><FONT SIZE=3D2>Hundreds, could be more than a thousand, I am not =
sure - one for each 3G operator in the world.</FONT>
</P>

<P><FONT SIZE=3D2>As a 3G subscriber I can authenticate through any 3G =
operator which has a roaming agreement with my home operator.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; eap mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://mail.frascone.com/mailman/listinfo/eap" =
TARGET=3D"_blank">http://mail.frascone.com/mailman/listinfo/eap</A></FON=
T>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C33186.A8B89A78--

---

From: [email-masked] (Bernard Aboba)
Date: Fri, 13 Jun 2003 06:52:27 -0700 (PDT)

> probe these all to see which is available.

Are hundreds of domains likely to be active in ths same location?  Would
they all need to be encoded within the EAP-Request/Identity?

---

From: [email-masked] (Bernard Aboba)
Date: Fri, 13 Jun 2003 08:06:35 -0700 (PDT)

> broadcast SSID, as I understand it.

Actually, IEEE 802.11-1999 doesn't define a "logical AP" nor does it
restrict the number of SSIDs it may use.  That's part of the problem --
the specification may be interpretted as supporting "Virtual APs" in
multiple ways.  Thus the interest in defining a single interoperable way
of handling this.

> Well, if all the available SSIDs are broadcast, this could work.
>
> I am not sure that it's a
> modifies their WLAN to provide a separate SSID for each WISP?

Probably not.  However, there are a number of potential solutions to the
problem, and the question is "how do we evaluate them?" I'm not sure that
the principle of "no changes to the AP" holds universally -- there
are other situations where "no changes to the peer" are desirable.  For
example, in enterprise deployments, updating 50K+ clients is a *very*
expensive operation, whereas an AP firmware upgrade is much less costly.

> username/password) - how will they know which SSID to use ??

Today that problem already exists because multiple APs can be advertising
different SSIDs.  Some Airports are already quite crowded, with networks
from the airlines, WISPs, and even sometimes the airport itself (e.g.
baggage handling system).  Typically this is handled either via user
intervention or by preferences on the peer.

> are all broadcast

I agree.

> could support this mechanism.

As we discussed, only the first EAP-Request/Identity need be sent by the
AP. Subsequent ones can be sent by the RADIUS server/proxy.

Typically a software upgrade is not insurmountable, but a "forklift
upgrade" is another story.