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

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

Could the same approach apply also to EAP Notifications ?

A usecase for this (both in Identity & Notifications) is when the user has
accounts with many WISPs and the particular WLAN supports users of one or
more of them. The user needs to know the WISPs that are supported so that a
choice of appropriate NAI can be made (potentially automatically). There are
not necessarily separate SSIDs for each WISP.

The list of supported WISPs could instead be made available 'out of band'
(i.e. stickers in the window of a coffee shop), but this precludes automatic
selection.

Notifications have the advantage that a mapping from RADIUS Reply-Message to
EAP Notification is already defined. 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.

Additionally, in current 3GPP WLAN interworking work, a user can
authenticate through any 3G Operator recognised by the WLAN, even though the
user may have no account with that 3G Operator. This is achieved via the
roaming agreements between 3G Operators. In this case the selection usually
needs to be made automatically, based on information about roaming
agreements configured in the user's terminal.

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.

Regards...Mark

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: 29 May 2003 20:08
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: Re: [eap] Re: deciding which NAI to send in an ID-RESPONSE
> 
> 
> Bernard Aboba wrote:
> >>We could (1) ignore such practise and pretend it doesn't 
> exist or (2)
> >>change the definition to say that there may be a null, after which
> >>the Displayable Message ends a Non-Displayble message begins ;-)
> > 
> > 
> > Well, there apparently are some people who care about this 
> and want to use
> > it for something. Perhaps if they spoke up we could 
> determine what to do.
> > 
> > Off the top of my head, I would think that an Appendix 
> describing what is
> > currently done might be appropriate. It also might make 
> sense to have an
> > IANA registry for the parameters so that interoperability 
> is possible.
> > On the other hand, I could also see handling this issue in 
> a separate
> > draft if it is determined that the effort to specify this 
> is significant
> > (and RFC 2284bis might be delayed).
> 
> Yes. If we want to find something in between, one approach would be
> to define that there may be a null character which terminates the
> Displayable Message, and that the contents beyond that are 
> implementation
> specific. This would at least warn people not to go beyond the null,
> and leave the possibility for later to document the contents of
> that field.
> 
> --Jari
> 
> 
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
> 

------_=_NextPart_001_01C330D4.57802322
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>Could the same approach apply also to EAP =
Notifications ?</FONT>
</P>

<P><FONT SIZE=3D2>A usecase for this (both in Identity &amp; =
Notifications) is when the user has accounts with many WISPs and the =
particular WLAN supports users of one or more of them. The user needs =
to know the WISPs that are supported so that a choice of appropriate =
NAI can be made (potentially automatically). There are not necessarily =
separate SSIDs for each WISP.</FONT></P>

<P><FONT SIZE=3D2>The list of supported WISPs could instead be made =
available 'out of band' (i.e. stickers in the window of a coffee shop), =
but this precludes automatic selection.</FONT></P>

<P><FONT SIZE=3D2>Notifications have the advantage that a mapping from =
RADIUS Reply-Message to EAP Notification is already defined. 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.</FONT></P>

<P><FONT SIZE=3D2>Additionally, in current 3GPP WLAN interworking work, =
a user can authenticate through any 3G Operator recognised by the WLAN, =
even though the user may have no account with that 3G Operator. This is =
achieved via the roaming agreements between 3G Operators. In this case =
the selection usually needs to be made automatically, based on =
information about roaming agreements configured in the user's =
terminal.</FONT></P>

<P><FONT SIZE=3D2>I think the idea of a defined 'name=3Dvalue' 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.</FONT></P>

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

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Jari Arkko [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</F=
ONT>
<BR><FONT SIZE=3D2>&gt; Sent: 29 May 2003 20:08</FONT>
<BR><FONT SIZE=3D2>&gt; To: Bernard Aboba</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; Bernard Aboba wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;We could (1) ignore such practise and =
pretend it doesn't </FONT>
<BR><FONT SIZE=3D2>&gt; exist or (2)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;change the definition to say that there =
may be a null, after which</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;the Displayable Message ends a =
Non-Displayble message begins ;-)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Well, there apparently are some people who =
care about this </FONT>
<BR><FONT SIZE=3D2>&gt; and want to use</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; it for something. Perhaps if they spoke up =
we could </FONT>
<BR><FONT SIZE=3D2>&gt; determine what to do.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Off the top of my head, I would think that =
an Appendix </FONT>
<BR><FONT SIZE=3D2>&gt; describing what is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; currently done might be appropriate. It =
also might make </FONT>
<BR><FONT SIZE=3D2>&gt; sense to have an</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; IANA registry for the parameters so that =
interoperability </FONT>
<BR><FONT SIZE=3D2>&gt; is possible.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; On the other hand, I could also see =
handling this issue in </FONT>
<BR><FONT SIZE=3D2>&gt; a separate</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; draft if it is determined that the effort =
to specify this </FONT>
<BR><FONT SIZE=3D2>&gt; is significant</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (and RFC 2284bis might be delayed).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Yes. If we want to find something in between, =
one approach would be</FONT>
<BR><FONT SIZE=3D2>&gt; to define that there may be a null character =
which terminates the</FONT>
<BR><FONT SIZE=3D2>&gt; Displayable Message, and that the contents =
beyond that are </FONT>
<BR><FONT SIZE=3D2>&gt; implementation</FONT>
<BR><FONT SIZE=3D2>&gt; specific. This would at least warn people not =
to go beyond the null,</FONT>
<BR><FONT SIZE=3D2>&gt; and leave the possibility for later to document =
the contents of</FONT>
<BR><FONT SIZE=3D2>&gt; that field.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; --Jari</FONT>
<BR><FONT SIZE=3D2>&gt; </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_01C330D4.57802322--

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 12 Jun 2003 05:58:18 -0700 (PDT)

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

> 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

I don't understand why Notification is a burden on the AP -- it's just
handled like any other EAP message.

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