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

From: [email-masked] (Mark Watson)
Date: Thu, 12 Jun 2003 15:07:14 +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_01C330EB.ED07A0B6
Content-Type: text/plain;
	charset="iso-8859-1"

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
> 

------_=_NextPart_001_01C330EB.ED07A0B6
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>Hi Bernard,</FONT>
</P>

<P><FONT SIZE=3D2>Comments below...</FONT>
</P>

<P><FONT SIZE=3D2>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.</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: 12 June 2003 13:58</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; WISPs may not have their own SSIDs</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Is this due to a limitation of current APs that =
could be removed?&nbsp; For</FONT>
<BR><FONT SIZE=3D2>&gt; example, if some large number of virtual APs =
could be defined </FONT>
<BR><FONT SIZE=3D2>&gt; (say, 255)</FONT>
<BR><FONT SIZE=3D2>&gt; per AP, so that each WISP could have their own =
SSIDs, would there be a</FONT>
<BR><FONT SIZE=3D2>&gt; need for additional information as well?&nbsp; =
If so, how much </FONT>
<BR><FONT SIZE=3D2>&gt; information are</FONT>
<BR><FONT SIZE=3D2>&gt; we talking about?&nbsp; Remember that =
EAP-Request/Identity (or </FONT>
<BR><FONT SIZE=3D2>&gt; Notification)</FONT>
<BR><FONT SIZE=3D2>&gt; doesn't support fragmentation, so it's limited =
by the MTU size.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>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.).</FONT></P>

<P><FONT SIZE=3D2>The user may know too many domains throught which =
they can authenticate to try a probe for each one (e.g. 3G =
case).</FONT>
</P>

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

<P><FONT SIZE=3D2>I was comparing with putting the info in the =
Request/Identity.</FONT>
</P>

<P><FONT SIZE=3D2>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.</FONT></P>

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

<P><FONT SIZE=3D2>Sure, I would expect this information to be a 'hint' =
about the NAI domains that *are* supported. You can ignore it if you =
like &amp; try a different domain, but then you'll get an error =
response.</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_01C330EB.ED07A0B6--

---

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

> route authentication signalling to/from the WISPs that do the actual

Are we talking about minimum requirements beyond what will be
required for WFA certification of a public access AP?

> Further, only one SSID can be broadcast - which one ?

This is purely a limitation of the AP implementation.  Assuming that
support for multiple SSIDs were available, would you still need
support within EAP?

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

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

> try a probe for each one (e.g. 3G case).

How many domains are we talking about? A dozen? A hundred? A thousand?

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

> this proxy does not otherwise need to understand EAP.

Yes, it could be generated by the proxy.

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