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

From: [email-masked] (Mark Watson)
Date: Fri, 13 Jun 2003 17:19:49 +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_01C331C7.9CBADEF2
Content-Type: text/plain;
	charset="iso-8859-1"

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

I'm not an expert in 802.11, but I was led to believe that an AP as defined
in 802.11-1999 can only broadcast a single SSID at one time (a quick reading
of the MLME-START.request and MLME-RESET.request management primitives seems
to suggest this, but as I say, I'm no expert here).

I thought that it could support many SSIDs, which can be probed, but not
many simultaneous beacons.

Of course, you can always put several APs in one physical box.

But we seem to be agreeing that there is not a fully-defined way to do this
right now, even though there may be a number of existing implementations
that appear to work.

> > Well, if all the available SSIDs are broadcast, this could work.
> >
> > 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?
> 
> 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.
> 

Perhaps different solutions will be appropriate in diffent situations.

But I don't think the problem we are discussing admits a solution which does
not impact the client. The problem is for the client to discover the
available domains with which to authenticate - how can this be done without
impacting the client ? 

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

Ok, so you're saying there might be a 'default' SSID that needs to be
advertised to 'legacy' users (who use web-based authentication) and through
which all WISPs are available. Then separate SSIDs for each WISP for 802.1X
authentication ??

> > So, I think that separate SSIDs for each network is 
> unreasonable unless they
> > are all broadcast
> 
> I agree.
> 
> > 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.
> 
> 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.
> 

I meant support of multiple broadcast SSIDs on a single AP was a new
function - at least we seem to agree that it is not currently supported in a
well-defined known-to-be-interoperable way.

> Typically a software upgrade is not insurmountable, but a "forklift
> upgrade" is another story.
> 
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
> 

------_=_NextPart_001_01C331C7.9CBADEF2
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>
<BR>

<P><FONT SIZE=3D2>&gt; Actually, IEEE 802.11-1999 doesn't define a =
&quot;logical AP&quot; nor does it</FONT>
<BR><FONT SIZE=3D2>&gt; restrict the number of SSIDs it may use.&nbsp; =
That's part of the </FONT>
<BR><FONT SIZE=3D2>&gt; problem --</FONT>
<BR><FONT SIZE=3D2>&gt; the specification may be interpretted as =
supporting &quot;Virtual APs&quot; in</FONT>
<BR><FONT SIZE=3D2>&gt; multiple ways.&nbsp; Thus the interest in =
defining a single </FONT>
<BR><FONT SIZE=3D2>&gt; interoperable way</FONT>
<BR><FONT SIZE=3D2>&gt; of handling this.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>I'm not an expert in 802.11, but I was led to believe =
that an AP as defined in 802.11-1999 can only broadcast a single SSID =
at one time (a quick reading of the MLME-START.request and =
MLME-RESET.request management primitives seems to suggest this, but as =
I say, I'm no expert here).</FONT></P>

<P><FONT SIZE=3D2>I thought that it could support many SSIDs, which can =
be probed, but not many simultaneous beacons.</FONT>
</P>

<P><FONT SIZE=3D2>Of course, you can always put several APs in one =
physical box.</FONT>
</P>

<P><FONT SIZE=3D2>But we seem to be agreeing that there is not a =
fully-defined way to do this right now, even though there may be a =
number of existing implementations that appear to work.</FONT></P>

<P><FONT SIZE=3D2>&gt; &gt; Well, if all the available SSIDs are =
broadcast, this could work.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I am not sure that it's a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; reasonable restriction to place on the =
WLAN owner - I gave </FONT>
<BR><FONT SIZE=3D2>&gt; the example of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the existing WLAN at Oslo airport - can we =
*require* that </FONT>
<BR><FONT SIZE=3D2>&gt; Oslo airport</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; modifies their WLAN to provide a separate =
SSID for each WISP?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Probably not.&nbsp; However, there are a number =
of potential </FONT>
<BR><FONT SIZE=3D2>&gt; solutions to the</FONT>
<BR><FONT SIZE=3D2>&gt; problem, and the question is &quot;how do we =
evaluate them?&quot; I'm </FONT>
<BR><FONT SIZE=3D2>&gt; not sure that</FONT>
<BR><FONT SIZE=3D2>&gt; the principle of &quot;no changes to the =
AP&quot; holds universally -- there</FONT>
<BR><FONT SIZE=3D2>&gt; are other situations where &quot;no changes to =
the peer&quot; are </FONT>
<BR><FONT SIZE=3D2>&gt; desirable.&nbsp; For</FONT>
<BR><FONT SIZE=3D2>&gt; example, in enterprise deployments, updating =
50K+ clients is a *very*</FONT>
<BR><FONT SIZE=3D2>&gt; expensive operation, whereas an AP firmware =
upgrade is much </FONT>
<BR><FONT SIZE=3D2>&gt; less costly.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>Perhaps different solutions will be appropriate in =
diffent situations.</FONT>
</P>

<P><FONT SIZE=3D2>But I don't think the problem we are discussing =
admits a solution which does not impact the client. The problem is for =
the client to discover the available domains with which to authenticate =
- how can this be done without impacting the client ? </FONT></P>

<P><FONT SIZE=3D2>&gt; &gt; ? There will still be users who do not have =
an automatic </FONT>
<BR><FONT SIZE=3D2>&gt; authentication</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; capability (i.e. who rely on the 'landing =
page' &amp; web-based</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; username/password) - how will they know =
which SSID to use ??</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Today that problem already exists because =
multiple APs can be </FONT>
<BR><FONT SIZE=3D2>&gt; advertising</FONT>
<BR><FONT SIZE=3D2>&gt; different SSIDs.&nbsp; Some Airports are =
already quite crowded, </FONT>
<BR><FONT SIZE=3D2>&gt; with networks</FONT>
<BR><FONT SIZE=3D2>&gt; from the airlines, WISPs, and even sometimes =
the airport itself (e.g.</FONT>
<BR><FONT SIZE=3D2>&gt; baggage handling system).&nbsp; Typically this =
is handled either via user</FONT>
<BR><FONT SIZE=3D2>&gt; intervention or by preferences on the =
peer.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>Ok, so you're saying there might be a 'default' SSID =
that needs to be advertised to 'legacy' users (who use web-based =
authentication) and through which all WISPs are available. Then =
separate SSIDs for each WISP for 802.1X authentication ??</FONT></P>

<P><FONT SIZE=3D2>&gt; &gt; So, I think that separate SSIDs for each =
network is </FONT>
<BR><FONT SIZE=3D2>&gt; unreasonable unless they</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; are all broadcast</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I agree.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Yep, but it's a new function which would =
have to be </FONT>
<BR><FONT SIZE=3D2>&gt; implemented on APs. A</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; WLAN owner would need to upgrade all their =
APs or buy new </FONT>
<BR><FONT SIZE=3D2>&gt; ones before they</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; could support this mechanism.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; As we discussed, only the first =
EAP-Request/Identity need be </FONT>
<BR><FONT SIZE=3D2>&gt; sent by the</FONT>
<BR><FONT SIZE=3D2>&gt; AP. Subsequent ones can be sent by the RADIUS =
server/proxy.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>I meant support of multiple broadcast SSIDs on a =
single AP was a new function - at least we seem to agree that it is not =
currently supported in a well-defined known-to-be-interoperable =
way.</FONT></P>

<P><FONT SIZE=3D2>&gt; Typically a software upgrade is not =
insurmountable, but a &quot;forklift</FONT>
<BR><FONT SIZE=3D2>&gt; upgrade&quot; is another story.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><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_01C331C7.9CBADEF2--

---

From: [email-masked] (Bernard Aboba)
Date: Fri, 13 Jun 2003 10:02:29 -0700 (PDT)

> right now, even though there may be a number of existing implementations

Actually, there are several ways it can be done, and a number of existing
AP approaches, several of which do *not* work reliably with existing
stations. The approach that does work with all existing stations is
not implementable by all existing APs.

For example, putting multiple SSID Information Elements in a Beacon or
Probe Response is not prohibited by IEEE 802.11-1999 -- but most stations
will not interpret this correctly.

Similarly, if different capability sets and SSIDs are sent in a Beacon
originating from the same BSSID, some drivers will interpret this as a
configuration change on the AP -- and overwrite the existing
configuration. As a result, instead of seeing multiple virtual APs, the
station will only see a single virtual AP with the capabilities rapidly
"flipping" between the different configurations.

> available domains with which to authenticate - how can this be done without

Existing stations have to be able to deal with multiple physical APs, so
they will also deal with multiple virtual APs that advertise with
different BSSIDs -- since the two cases cannot be distinguished by the
station.

> which all WISPs are available. Then separate SSIDs for each WISP for 802.1X

A Virtual AP is like a physical AP in that you can choose the SSID and
capabilities independently from other APs.  It's possible to
have one Virtual AP advertising "SSIDA" with one set of capabilities, and
another advertising "SSIDB" with a different set.

It's also possible to have several Virtual APs advertising the same SSID,
but with different capabilities. For example, many WISPs now support
Web portal, but want to also support WPA.  With Virtual APs, the WISP
could create one Virtual AP advertising a Web Portal (open auth) and
another Virtual AP advertising WPA -- and they both can have the same
SSID. Clients can then choose based on their preferences and
capabilities.

> well-defined known-to-be-interoperable way.

Actually, virtual APs using separate BSSIDs *do* interoperate with
existing clients -- and the way to do this is well defined, because it's
indistinguishable from how different physical APs work today. However,
some chipsets cannot support this, just as some drivers cannot not support
alternative approaches.

So I do agree with your conclusion that even if virtual AP capability were
standardized, that it would be a while before it could be used, and so
some interim measure is probably required.

The question is whether the problem can be addressed by defining
parameters to be advertised in the EAP-Request/Identity.  This seems like
the most reasonable EAP-based approach to me, since while one can expect
an EAP-Request/Identity to influence the EAP-Response/Identity, since it's
the same method, expecting a Notification-Request to influence an
EAP-Response/Identity in an automated way would appear to violate the EAP
multiplexing model.