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

From: [email-masked] (Clint Chaplin)
Date: Thu, 12 Jun 2003 09:54:11 -0700

Wi-Fi or IEEE has >got< to move forward on Virtual APs, or these sorts of issues are going to keep coming up.

Several companies have investigated this issue, and there are several ways to solve it, some of which include a separate beacon for each SSID.  All solutions have problems with certain existing client implementations, and some of them are pushing the IEEE 802.11 standard in ways it wasn't designed to go.  (Bernard, I know I'm preaching to the choir with you; I've seen your Virtual AP presentation you gave at Wi-Fi last week).

If speed is essential, the Wi-Fi is the only approprate venue, but if changes need to be made to the standard, then IEEE needs to be present.

Clint (JOATMON) Chaplin

>>> "Mark Watson" <[email-masked]> 6/12/03 07:07:14 >>>
Hi Bernard,

Comments below...

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.

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: 12 June 2003 13:58
> To: Watson, Mark [MOP:EP10:EXCH]
> Cc: [email-masked]'; [email-masked] 
> Subject: RE: [eap] Re: deciding which NAI to send in an ID-RESPONSE
> 
> 
> > WISPs may not have their own SSIDs
> 
> Is this due to a limitation of current APs that could be removed?  For
> example, if some large number of virtual APs could be defined 
> (say, 255)
> per AP, so that each WISP could have their own SSIDs, would there be a
> need for additional information as well?  If so, how much 
> information are
> we talking about?  Remember that EAP-Request/Identity (or 
> Notification)
> doesn't support fragmentation, so it's limited by the MTU size.
> 

An example: I was in Oslo airport the other day. Oslo airport has a WLAN
with a single SSID (well, I could only see one). Oslo airport has agreements
with several WISPs. I can authenticate through any of those. SSID
limitations or otherwise, I don't think you can require the WLAN owner to
provision a separate SSID for each WISP with whom they have an agreement.

Further, only one SSID can be broadcast - which one ? Where do I get info
about the other SSID's available - if that's from the default WLAN
(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.).

The user may know too many domains throught which they can authenticate to
try a probe for each one (e.g. 3G case).

> > Notifications have the advantage that a mapping from RADIUS 
> Reply-Message to
> > EAP Notification is already defined.
> 
> Please check RFC 2869bis -- use of RADIUS Reply-Message is
> deprecated for use with EAP.  Use of Notification is preferred.
> However, in this case it seems like EAP-Request/Identity 
> might make more
> sense, given the purpose of the displayable message.
> 
> > So, the information can come from the
> > RADIUS server/proxy in the case of an error due to an 
> unrecognised Domain
> > Name in the NAI. This places less burden on the AP.
> 
> I don't understand why Notification is a burden on the AP -- it's just
> handled like any other EAP message.
> 

I was comparing with putting the info in the Request/Identity.

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

> > I think the idea of a defined 'name=value' format with IANA 
> registrations
> > for names is a good one. Does this align with general 
> practice ? I see we
> > have only one example so far.
> 
> RFC 2284 states that Notification is for delivery of a displayable
> messages, and that is what it is used for, as I understand 
> it.  Since a
> Notification Response is sent automatically, there is no way for the
> sender to know that the peer understood the message, or even that the
> message was displayed (the peer responds immediately, and doesn't wait
> until it has done the displaying to reply).
> 
> On the other hand, some APs do use the name=value format today within
> EAP-Request/Identity messages, for the purpose of identifying the
> AP. However, I don't think that EAP peer implementations do 
> anything with it.
> 
> The problem with going down the road of defining new 'name=value'
> parameters is that this could create interoperability 
> problems unless the
> parameters were only treated as hints -- if the wrong NAI is 
> sent, then
> the displayable message part of the EAP-Request/Identity is set to
> indicate that.

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.

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

________________________________________________________________________
This email has been scanned for computer viruses.

---

From: [email-masked] (Mark Watson)
Date: Thu, 12 Jun 2003 18:09:35 +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_01C33104.E4496E96
Content-Type: text/plain;
	charset="iso-8859-1"

Clint,

Virtual APs, implying a separate beacon for each SSID is certainly a
solution to this problem, but I am looking for a solution which does not
impact the AP. This problem will exist for WLANs that are being deployed now
- even if a virtual AP solution was fully agreed and standardised now, then
we couldn't wait for it to be implemented.

...Mark

> From: Clint Chaplin [mailto:[email-masked]]
> Sent: 12 June 2003 17:54
> To: [email-masked]; Watson, Mark [MOP:EP10:EXCH]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Wi-Fi or IEEE has >got< to move forward on Virtual APs, or 
> these sorts of issues are going to keep coming up.
> 
> Several companies have investigated this issue, and there are 
> several ways to solve it, some of which include a separate 
> beacon for each SSID.  All solutions have problems with 
> certain existing client implementations, and some of them are 
> pushing the IEEE 802.11 standard in ways it wasn't designed 
> to go.  (Bernard, I know I'm preaching to the choir with you; 
> I've seen your Virtual AP presentation you gave at Wi-Fi last week).
> 
> If speed is essential, the Wi-Fi is the only approprate 
> venue, but if changes need to be made to the standard, then 
> IEEE needs to be present.
> 
> Clint (JOATMON) Chaplin
> 

------_=_NextPart_001_01C33104.E4496E96
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>Clint,</FONT>
</P>

<P><FONT SIZE=3D2>Virtual APs, implying a separate beacon for each SSID =
is certainly a solution to this problem, but I am looking for a =
solution which does not impact the AP. This problem will exist for =
WLANs that are being deployed now - even if a virtual AP solution was =
fully agreed and standardised now, then we couldn't wait for it to be =
implemented.</FONT></P>

<P><FONT SIZE=3D2>...Mark</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Clint Chaplin [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>=
]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: 12 June 2003 17:54</FONT>
<BR><FONT SIZE=3D2>&gt; To: [email-masked]; Watson, Mark =
[MOP:EP10:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [email-masked]; [email-masked]; =
[email-masked];</FONT>
<BR><FONT SIZE=3D2>&gt; [email-masked]; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [eap] Re: deciding which NAI to =
send in an ID-RESPONSE</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Wi-Fi or IEEE has &gt;got&lt; to move forward =
on Virtual APs, or </FONT>
<BR><FONT SIZE=3D2>&gt; these sorts of issues are going to keep coming =
up.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Several companies have investigated this issue, =
and there are </FONT>
<BR><FONT SIZE=3D2>&gt; several ways to solve it, some of which include =
a separate </FONT>
<BR><FONT SIZE=3D2>&gt; beacon for each SSID.&nbsp; All solutions have =
problems with </FONT>
<BR><FONT SIZE=3D2>&gt; certain existing client implementations, and =
some of them are </FONT>
<BR><FONT SIZE=3D2>&gt; pushing the IEEE 802.11 standard in ways it =
wasn't designed </FONT>
<BR><FONT SIZE=3D2>&gt; to go.&nbsp; (Bernard, I know I'm preaching to =
the choir with you; </FONT>
<BR><FONT SIZE=3D2>&gt; I've seen your Virtual AP presentation you gave =
at Wi-Fi last week).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If speed is essential, the Wi-Fi is the only =
approprate </FONT>
<BR><FONT SIZE=3D2>&gt; venue, but if changes need to be made to the =
standard, then </FONT>
<BR><FONT SIZE=3D2>&gt; IEEE needs to be present.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Clint (JOATMON) Chaplin</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&gt; &quot;Mark Watson&quot; =
&lt;[email-masked]&gt; 6/12/03 07:07:14 &gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Hi Bernard,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Comments below...</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I am looking for a solution which places =
minimum new requirements on</FONT>
<BR><FONT SIZE=3D2>&gt; elements in the WLAN network - that is the AP =
and any RADIUS </FONT>
<BR><FONT SIZE=3D2>&gt; proxies used to</FONT>
<BR><FONT SIZE=3D2>&gt; route authentication signalling to/from the =
WISPs that do the actual</FONT>
<BR><FONT SIZE=3D2>&gt; authentication.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Bernard Aboba [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>] =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: 12 June 2003 13:58</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: Watson, Mark [MOP:EP10:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: [email-masked]'; =
[email-masked] </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: RE: [eap] Re: deciding which NAI =
to send in an ID-RESPONSE</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; WISPs may not have their own =
SSIDs</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Is this due to a limitation of current APs =
that could be </FONT>
<BR><FONT SIZE=3D2>&gt; removed?&nbsp; For</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; example, if some large number of virtual =
APs could be defined </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (say, 255)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; per AP, so that each WISP could have their =
own SSIDs, would </FONT>
<BR><FONT SIZE=3D2>&gt; there be a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; need for additional information as =
well?&nbsp; If so, how much </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; information are</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; we talking about?&nbsp; Remember that =
EAP-Request/Identity (or </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Notification)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; doesn't support fragmentation, so it's =
limited by the MTU size.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; An example: I was in Oslo airport the other =
day. Oslo airport </FONT>
<BR><FONT SIZE=3D2>&gt; has a WLAN</FONT>
<BR><FONT SIZE=3D2>&gt; with a single SSID (well, I could only see =
one). Oslo airport </FONT>
<BR><FONT SIZE=3D2>&gt; has agreements</FONT>
<BR><FONT SIZE=3D2>&gt; with several WISPs. I can authenticate through =
any of those. SSID</FONT>
<BR><FONT SIZE=3D2>&gt; limitations or otherwise, I don't think you can =
require the </FONT>
<BR><FONT SIZE=3D2>&gt; WLAN owner to</FONT>
<BR><FONT SIZE=3D2>&gt; provision a separate SSID for each WISP with =
whom they have </FONT>
<BR><FONT SIZE=3D2>&gt; an agreement.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Further, only one SSID can be broadcast - which =
one ? Where </FONT>
<BR><FONT SIZE=3D2>&gt; do I get info</FONT>
<BR><FONT SIZE=3D2>&gt; about the other SSID's available - if that's =
from the default WLAN</FONT>
<BR><FONT SIZE=3D2>&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; associate with the broadcast one first to get =
the info etc. etc.).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&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; try a probe for each one (e.g. 3G case).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Notifications have the advantage that =
a mapping from RADIUS </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Reply-Message to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; EAP Notification is already =
defined.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Please check RFC 2869bis -- use of RADIUS =
Reply-Message is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; deprecated for use with EAP.&nbsp; Use of =
Notification is preferred.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; However, in this case it seems like =
EAP-Request/Identity </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; might make more</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; sense, given the purpose of the =
displayable message.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; So, the information can come from =
the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; RADIUS server/proxy in the case of an =
error due to an </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; unrecognised Domain</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Name in the NAI. This places less =
burden on the AP.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I don't understand why Notification is a =
burden on the AP </FONT>
<BR><FONT SIZE=3D2>&gt; -- it's just</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; handled like any other EAP message.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I was comparing with putting the info in the =
Request/Identity.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&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; burden on the AP, because the Request/Identity =
is generated by the AP.</FONT>
<BR><FONT SIZE=3D2>&gt; Perhaps, though, a subsqeuent Request/Identity =
after an </FONT>
<BR><FONT SIZE=3D2>&gt; unrecognised NAI</FONT>
<BR><FONT SIZE=3D2>&gt; domain error could be generated by the RADIUS =
proxy detecting </FONT>
<BR><FONT SIZE=3D2>&gt; this ? But</FONT>
<BR><FONT SIZE=3D2>&gt; this proxy does not otherwise need to =
understand EAP.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I think the idea of a defined =
'name=3Dvalue' format with IANA </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; registrations</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; for names is a good one. Does this =
align with general </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; practice ? I see we</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; have only one example so far.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; RFC 2284 states that Notification is for =
delivery of a displayable</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; messages, and that is what it is used for, =
as I understand </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; it.&nbsp; Since a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Notification Response is sent =
automatically, there is no way for the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; sender to know that the peer understood =
the message, or </FONT>
<BR><FONT SIZE=3D2>&gt; even that the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; message was displayed (the peer responds =
immediately, and </FONT>
<BR><FONT SIZE=3D2>&gt; doesn't wait</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; until it has done the displaying to =
reply).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; On the other hand, some APs do use the =
name=3Dvalue format </FONT>
<BR><FONT SIZE=3D2>&gt; today within</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; EAP-Request/Identity messages, for the =
purpose of identifying the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; AP. However, I don't think that EAP peer =
implementations do </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; anything with it.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The problem with going down the road of =
defining new 'name=3Dvalue'</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; parameters is that this could create =
interoperability </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; problems unless the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; parameters were only treated as hints -- =
if the wrong NAI is </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; sent, then</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the displayable message part of the =
EAP-Request/Identity is set to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; indicate that.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&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; that *are* supported. You can ignore it if you =
like &amp; try a different</FONT>
<BR><FONT SIZE=3D2>&gt; domain, but then you'll get an error =
response.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; eap mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [email-masked] </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; <A =
HREF=3D"http://mail.frascone.com/mailman/listinfo/eap" =
TARGET=3D"_blank">http://mail.frascone.com/mailman/listinfo/eap</A> =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
______________________________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; __________</FONT>
<BR><FONT SIZE=3D2>&gt; This email has been scanned for computer =
viruses.</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_01C33104.E4496E96--

---

From: [email-masked] (Clint Chaplin)
Date: Thu, 12 Jun 2003 10:14:36 -0700

Well, I need to point out one assumption that is incorrect: several manufacturers are already shipping APs  (standalone and wireless switch) that implement Virtual APs in one form or another.

Clint (JOATMON) Chaplin

>>> "Mark Watson" <[email-masked]> 6/12/03 10:09:35 >>>
Clint,

...Mark

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 12 Jun 2003 10:06:27 -0700 (PDT)

Thanks, Clint.

My question is this: Assuming this happens (and I agree there is lots of
need for it), do we need something else in EAP too? If so, what?
It would be nice to avoid a zillion bells and whistles if possible.

---

From: [email-masked] (Mark Watson)
Date: Fri, 13 Jun 2003 15:38:40 +0100

------_=_NextPart_001_01C331B9.28F9FDEE
Content-Type: text/plain;
	charset="iso-8859-1"

No, I would expect only a handful (<10, probably <5) to be available in any
one location. These are the domains with which the WLAN operator has a
direct agreement.

...Mark

> Sent: 13 June 2003 14:52
> Cc: [email-masked]
> > 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.
> 
> Are hundreds of domains likely to be active in ths same 
> location?  Would
> they all need to be encoded within the EAP-Request/Identity?

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

<P><FONT SIZE=3D2>No, I would expect only a handful (&lt;10, probably =
&lt;5) to be available in any one location. These are the domains with =
which the WLAN operator has a direct agreement.</FONT></P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Bernard Aboba [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FON=
T>
<BR><FONT SIZE=3D2>&gt; Sent: 13 June 2003 14:52</FONT>
<BR><FONT SIZE=3D2>&gt; To: Watson, Mark [MOP:EP10:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [eap] Re: deciding which NAI to =
send in an ID-RESPONSE</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; There are too many to use probes. To =
answer you question </FONT>
<BR><FONT SIZE=3D2>&gt; below, the user may</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; be able to authenticate through hundreds =
of domains. It </FONT>
<BR><FONT SIZE=3D2>&gt; would be too slow to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; probe these all to see which is =
available.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Are hundreds of domains likely to be active in =
ths same </FONT>
<BR><FONT SIZE=3D2>&gt; location?&nbsp; Would</FONT>
<BR><FONT SIZE=3D2>&gt; they all need to be encoded within the =
EAP-Request/Identity?</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_01C331B9.28F9FDEE--

---

From: [email-masked] (Mark Watson)
Date: Mon, 16 Jun 2003 14:46:45 +0100

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

Yes, space might be a problem. But we're not expecting there to be all that
many domains available in a single WLAN - there is a limit to the number of
relationships that a WLAN owner will be bothered to make/maintain & a law of
diminishing returns (in terms of the number of additional potential users
each new relationship will bring in).

And then, should the Request/Identity advertise just the domains available
from this particular SSID, or should it include domains available from other
SSIDs in the same area (and those corresponding SSIDs, of course). If the
former, then if you do run out of space you have a solution in terms of
multiple SSIDs (remembering that this space problem is unlikely to bite for
some time, so equipment capability issues are not so pressing).

Alternatively, the user does know all the possible domains they could
authenticate with - it's just there might be too many to try them one by
one. It may be sufficient to provide, say, a 4-octet hash of each FQDN
available if we're short of space. Collissions result in users very
occasionally attempting to authenticate with a domain which is not
available. We should think about this when we have a better idea how many
FQDNs we could fit in the message.

...Mark

> From: Bernard Aboba [mailto:[email-masked]]
> Sent: 16 June 2003 13:41
> > Yes, but there is no way today for the station to learn the 
> relationship
> > between SSID it can see and the NAI domains that will be 
> accepted. So, any
> > solution to this will involve the client.
> 
> OK. Since there is no relationship between SSIDs and domains, 
> it may not
> be obvious what domain is appropriate given the SSID. For 
> example, is it
> obvious that SSID MSFTWLAN is expecting an NAI of 
> [email-masked],
> and that an NAI of [email-masked] won't be accepted? Not 
> unless there
> is preconfiguration or user intervention.  If this could be handled
> automatically it would be better.
> 
> Note however that since we're talking about FQDNs, there may 
> not be room
> for a lot of them in the EAP-Request/Identity.
> 

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

<P><FONT SIZE=3D2>Yes, space might be a problem. But we're not =
expecting there to be all that many domains available in a single WLAN =
- there is a limit to the number of relationships that a WLAN owner =
will be bothered to make/maintain &amp; a law of diminishing returns =
(in terms of the number of additional potential users each new =
relationship will bring in).</FONT></P>

<P><FONT SIZE=3D2>And then, should the Request/Identity advertise just =
the domains available from this particular SSID, or should it include =
domains available from other SSIDs in the same area (and those =
corresponding SSIDs, of course). If the former, then if you do run out =
of space you have a solution in terms of multiple SSIDs (remembering =
that this space problem is unlikely to bite for some time, so equipment =
capability issues are not so pressing).</FONT></P>

<P><FONT SIZE=3D2>Alternatively, the user does know all the possible =
domains they could authenticate with - it's just there might be too =
many to try them one by one. It may be sufficient to provide, say, a =
4-octet hash of each FQDN available if we're short of space. =
Collissions result in users very occasionally attempting to =
authenticate with a domain which is not available. We should think =
about this when we have a better idea how many FQDNs we could fit in =
the message.</FONT></P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Bernard Aboba [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: 16 June 2003 13:41</FONT>
<BR><FONT SIZE=3D2>&gt; To: Watson, Mark [MOP:EP10:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [email-masked]'; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [eap] Re: deciding which NAI to =
send in an ID-RESPONSE</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Yes, but there is no way today for the =
station to learn the </FONT>
<BR><FONT SIZE=3D2>&gt; relationship</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; between SSID it can see and the NAI =
domains that will be </FONT>
<BR><FONT SIZE=3D2>&gt; accepted. So, any</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; solution to this will involve the =
client.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; OK. Since there is no relationship between =
SSIDs and domains, </FONT>
<BR><FONT SIZE=3D2>&gt; it may not</FONT>
<BR><FONT SIZE=3D2>&gt; be obvious what domain is appropriate given the =
SSID. For </FONT>
<BR><FONT SIZE=3D2>&gt; example, is it</FONT>
<BR><FONT SIZE=3D2>&gt; obvious that SSID MSFTWLAN is expecting an NAI =
of </FONT>
<BR><FONT SIZE=3D2>&gt; [email-masked],</FONT>
<BR><FONT SIZE=3D2>&gt; and that an NAI of [email-masked] won't be =
accepted? Not </FONT>
<BR><FONT SIZE=3D2>&gt; unless there</FONT>
<BR><FONT SIZE=3D2>&gt; is preconfiguration or user intervention.&nbsp; =
If this could be handled</FONT>
<BR><FONT SIZE=3D2>&gt; automatically it would be better.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Note however that since we're talking about =
FQDNs, there may </FONT>
<BR><FONT SIZE=3D2>&gt; not be room</FONT>
<BR><FONT SIZE=3D2>&gt; for a lot of them in the =
EAP-Request/Identity.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3340D.B99F87C8--