Subject: [eap] Issue 142: Contents of the EAP-Request/Identity

From: [email-masked] (Mark Watson)
Date: Thu, 12 Jun 2003 13:51:03 +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_01C330E1.484C7B14
Content-Type: text/plain;
	charset="iso-2022-jp"

<this is related to my earlier message, but at that time I hadn't spotted
this thread>

It is certainly possible that for a single WLAN ESS (i.e. one SSID), there
are several possible WISPs or other organisations that can provide
authentication. The user identifies the domain they wish to use for
authentication in the domain portion of the NAI and the AP (or RADIUS proxy)
routes the Auth request (EAP Response/Identity) to the correct place.

You cannot expect information about the possible domains supported by a
given WLAN to be obvious from the SSID.

Nor can you expect a trial and error approach on the part of the user (i.e.
trying different NAI domains until one works), since there may be many
possible NAI domains that the user could authenticate with.

So, I think there is still a requirement to provide information about the
supported authentication domains within the context of a single
autenticator/ESS/802.1X system (or whatever the correct term is). The
selection decision based on this information is taken subsequent to a
decision on which AP/SSID/802.1X authenticator to use, which as noted below
can be based on the Beacon frames, or PANA etc.

...Mark

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: 10 June 2003 17:20
> To: CONGDON,PAUL (HP-Roseville,ex1)
> Cc: 'Bernard Aboba'; [email-masked]
> Subject: Re: [eap] Issue 142: Contents of the EAP-Request/Identity
> 
> 
> I agree with Paul on not including the information (AUP, networkid,
> nasid, portid) in EAP message.  Such information should be provided
> before a peer chooses an appropriate authenticaticator with which it
> starts EAP conversation.  In this sense, including the information in
> 802.1X frame might also be too late.  On the other hand, AUP should be
> provided in a stateless fashon, because a user on a peer 
> device tends to
> take more time to read the AUP and make a decision to whether it
> should start EAP conversation with the EAP authenticator that
> originated the AUP.
> 
> Thus, I think the appropriate place is containing it in Beacon frame
> in the case of 802.11 and in PANA authentication agent discovery
> exchange in the case of PANA.  Of course the size of AUP text should
> be as small as possible so that it does not consume the bandwidth.
>  
> Yoshihiro Ohba
> 
> On Wed, Jun 11, 2003 at 10:46:38AM -0400, CONGDON,PAUL 
> (HP-Roseville,ex1) wrote:
> > 
> > Seems like this should really be considered at the link layer?   New
> > EAPOL-Start or EAPOL-Hello messages could contain the discovery
> > information...
> > 
> > > -----Original Message-----
> > > From: Bernard Aboba [mailto:[email-masked]] 
> > > Sent: Tuesday, June 10, 2003 11:16 PM
> > > To: [email-masked]
> > > Subject: [eap] Issue 142: Contents of the EAP-Request/Identity
> > > 
> > > 
> > > Submitter name: Tim Moore
> > > Submitter email address: [email-masked]
> > > Date first submitted: June 9, 2003
> > > Reference:
> > > Document: EAP-03
> > > Comment type: T
> > > Priority: S
> > > Section: 5.1
> > > Rationale/Explanation of issue:
> > > 
> > > Change:
> > > 
> > > " This field MAY contain a displayable message in the 
> > > Request, containing UTF-8 encoded ISO 10646 characters 
> > > [RFC2279]. The Response uses this field to return the 
> > > Identity. If the Identity is unknown, this field should be 
> > > zero bytes in length. The field MUST NOT be null terminated. 
> > > The length of this field is derived from the Length field of 
> > > the Request/Response packet and hence a null is not required."
> > > 
> > > To:
> > > 
> > > " This field MAY contain a displayable message in the 
> > > Request, containing UTF-8 encoded ISO 10646 characters 
> > > [RFC2279]. Where the Request contains a null, only the 
> > > portion of the field preceeding the null is displayed, with 
> > > the rest used as a hint to the peer as to the identity to be 
> > > provided in the Response, as described in Appendix A.2. If 
> > > the Identity is unknown, the Identity Response field should 
> > > be zero bytes in length. The Identity Response field MUST NOT 
> > > be null terminated. In all cases, the length of the Type-Data 
> > > field is derived from the Length field of the 
> > > Request/Response packet."
> > > 
> > > Add to Appendix A:
> > > 
> > > "A.2 Contents of the Request/Identity Type-Data field
> > > 
> > > So as to provide the peer with a hint as to the appropriate 
> > > identity to place in the Type-Data field of the 
> > > EAP-Response/Identity, the authenticator may wish to identity 
> > > itself EAP-Request/Identity, in addition to providing a 
> > > displayable message to the peer, such as an Appropriate Use 
> > > Policy (AUP).
> > > 
> > > The following format is proposed for the null-terminated 
> > > displayable string and the comma-separated portion of the 
> > > EAP-Request/Identity message
> > > string:
> > > 
> > > <display-string>\0networkid=<network-name>,nasid=<nas-name>,po
> > > rtid=<port-id>
> > > 
> > > Where:
> > > 
> > > network-name: Name of the network to which the 
> authenticator connects.
> > >               This is typically the SSID for IEEE 802.11.
> > > 
> > > nas-name: Name or address of the NAS.
> > > 
> > > 
> > > port-id: port that the EAP session is on.
> > > 
> > > The EAP peer should display display-string before the 
> null termination
> > > (\0) to enable administrators to display network 
> > > identification messages or appropriate use policies (AUPs)."
> > > 
> > > _______________________________________________
> > > eap mailing list
> > > [email-masked]
> > > http://mail.frascone.com/mailman/listinfo/eap
> > > 
> > _______________________________________________
> > eap mailing list
> > [email-masked]
> > http://mail.frascone.com/mailman/listinfo/eap
> > 
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
> 

------_=_NextPart_001_01C330E1.484C7B14
Content-Type: text/html;
	charset="iso-2022-jp"
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-2022-jp">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [eap] Issue 142: Contents of the =
EAP-Request/Identity</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&lt;this is related to my earlier message, but at =
that time I hadn't spotted this thread&gt;</FONT>
</P>

<P><FONT SIZE=3D2>It is certainly possible that for a single WLAN ESS =
(i.e. one SSID), there are several possible WISPs or other =
organisations that can provide authentication. The user identifies the =
domain they wish to use for authentication in the domain portion of the =
NAI and the AP (or RADIUS proxy) routes the Auth request (EAP =
Response/Identity) to the correct place.</FONT></P>

<P><FONT SIZE=3D2>You cannot expect information about the possible =
domains supported by a given WLAN to be obvious from the SSID.</FONT>
</P>

<P><FONT SIZE=3D2>Nor can you expect a trial and error approach on the =
part of the user (i.e. trying different NAI domains until one works), =
since there may be many possible NAI domains that the user could =
authenticate with.</FONT></P>

<P><FONT SIZE=3D2>So, I think there is still a requirement to provide =
information about the supported authentication domains within the =
context of a single autenticator/ESS/802.1X system (or whatever the =
correct term is). The selection decision based on this information is =
taken subsequent to a decision on which AP/SSID/802.1X authenticator to =
use, which as noted below can be based on the Beacon frames, or PANA =
etc.</FONT></P>

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

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Yoshihiro Ohba [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>=
]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: 10 June 2003 17:20</FONT>
<BR><FONT SIZE=3D2>&gt; To: CONGDON,PAUL (HP-Roseville,ex1)</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'Bernard Aboba'; [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [eap] Issue 142: Contents of the =
EAP-Request/Identity</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I agree with Paul on not including the =
information (AUP, networkid,</FONT>
<BR><FONT SIZE=3D2>&gt; nasid, portid) in EAP message.&nbsp; Such =
information should be provided</FONT>
<BR><FONT SIZE=3D2>&gt; before a peer chooses an appropriate =
authenticaticator with which it</FONT>
<BR><FONT SIZE=3D2>&gt; starts EAP conversation.&nbsp; In this sense, =
including the information in</FONT>
<BR><FONT SIZE=3D2>&gt; 802.1X frame might also be too late.&nbsp; On =
the other hand, AUP should be</FONT>
<BR><FONT SIZE=3D2>&gt; provided in a stateless fashon, because a user =
on a peer </FONT>
<BR><FONT SIZE=3D2>&gt; device tends to</FONT>
<BR><FONT SIZE=3D2>&gt; take more time to read the AUP and make a =
decision to whether it</FONT>
<BR><FONT SIZE=3D2>&gt; should start EAP conversation with the EAP =
authenticator that</FONT>
<BR><FONT SIZE=3D2>&gt; originated the AUP.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thus, I think the appropriate place is =
containing it in Beacon frame</FONT>
<BR><FONT SIZE=3D2>&gt; in the case of 802.11 and in PANA =
authentication agent discovery</FONT>
<BR><FONT SIZE=3D2>&gt; exchange in the case of PANA.&nbsp; Of course =
the size of AUP text should</FONT>
<BR><FONT SIZE=3D2>&gt; be as small as possible so that it does not =
consume the bandwidth.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; Yoshihiro Ohba</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On Wed, Jun 11, 2003 at 10:46:38AM -0400, =
CONGDON,PAUL </FONT>
<BR><FONT SIZE=3D2>&gt; (HP-Roseville,ex1) wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Seems like this should really be =
considered at the link layer?&nbsp;&nbsp; New</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; EAPOL-Start or EAPOL-Hello messages could =
contain the discovery</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; information...</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; From: Bernard Aboba [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>] =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sent: Tuesday, June 10, 2003 11:16 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Subject: [eap] Issue 142: Contents of =
the EAP-Request/Identity</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Submitter name: Tim Moore</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Submitter email address: =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Date first submitted: June 9, =
2003</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Reference:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Document: EAP-03</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Comment type: T</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Priority: S</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Section: 5.1</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Rationale/Explanation of =
issue:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Change:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &quot; This field MAY contain a =
displayable message in the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Request, containing UTF-8 encoded ISO =
10646 characters </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; [RFC2279]. The Response uses this =
field to return the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Identity. If the Identity is unknown, =
this field should be </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; zero bytes in length. The field MUST =
NOT be null terminated. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; The length of this field is derived =
from the Length field of </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the Request/Response packet and hence =
a null is not required.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; To:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &quot; This field MAY contain a =
displayable message in the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Request, containing UTF-8 encoded ISO =
10646 characters </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; [RFC2279]. Where the Request contains =
a null, only the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; portion of the field preceeding the =
null is displayed, with </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the rest used as a hint to the peer =
as to the identity to be </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; provided in the Response, as =
described in Appendix A.2. If </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the Identity is unknown, the Identity =
Response field should </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; be zero bytes in length. The Identity =
Response field MUST NOT </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; be null terminated. In all cases, the =
length of the Type-Data </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; field is derived from the Length =
field of the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Request/Response packet.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Add to Appendix A:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &quot;A.2 Contents of the =
Request/Identity Type-Data field</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; So as to provide the peer with a hint =
as to the appropriate </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; identity to place in the Type-Data =
field of the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; EAP-Response/Identity, the =
authenticator may wish to identity </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; itself EAP-Request/Identity, in =
addition to providing a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; displayable message to the peer, such =
as an Appropriate Use </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Policy (AUP).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; The following format is proposed for =
the null-terminated </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; displayable string and the =
comma-separated portion of the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; EAP-Request/Identity message</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; string:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; =
&lt;display-string&gt;\0networkid=3D&lt;network-name&gt;,nasid=3D&lt;nas=
-name&gt;,po</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; rtid=3D&lt;port-id&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Where:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; network-name: Name of the network to =
which the </FONT>
<BR><FONT SIZE=3D2>&gt; authenticator connects.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; This is typically the SSID for IEEE 802.11.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; nas-name: Name or address of the =
NAS.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; port-id: port that the EAP session is =
on.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; The EAP peer should display =
display-string before the </FONT>
<BR><FONT SIZE=3D2>&gt; null termination</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; (\0) to enable administrators to =
display network </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; identification messages or =
appropriate use policies (AUPs).&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; eap mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &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; &gt; &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></FON=
T>
<BR><FONT SIZE=3D2>&gt; &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_01C330E1.484C7B14--