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

From: [email-masked] (Bernard Aboba)
Date: Thu, 22 May 2003 05:58:28 -0700 (PDT)

In practice, many APs send an Identity Request with hints encoded in it.
These hints include the Identity of the NAS, as well as other information,
along with a Displayable message.

I'll look around for the specification for this and get an issue submitted
so that we can discuss it in more detail.  However, this is not specified
in any IEEE specification, including IEEE 802.1X or IEEE 802.11i.

On Thu, 22 May 2003, Jari Arkko wrote:

>
> Just for my education: assuming a client has multiple NAIs
> and credentials, how does it decide which one to send? I
> remember some talk about SSIDs as well as the contents
> of the EAP ID request. But what exactly is currently done
> by implementations, and has IEEE specified something about
> this?
>
> --Jari
>
>

---

From: [email-masked] (Jari Arkko)
Date: Thu, 22 May 2003 16:28:04 +0300

> in any IEEE specification, including IEEE 802.1X or IEEE 802.11i.

Interesting.

So, what is the practise on the client side then? Do the implementations
bring up a window to display the Displayable Message to the user,
and then the user decides? Or is there some magic involved where
the client decides that the hint is of a specific format and decides
all by itself without asking the user?

--Jari

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 22 May 2003 06:13:33 -0700 (PDT)

> all by itself without asking the user?

I think that either is permissible. The Displayable Message part of the
Identity Request is displayed to the user, and the rest of the message is
meant to be machine readable, and so could be used to make an automatic
decision.

---

From: [email-masked] (Jari Arkko)
Date: Thu, 22 May 2003 16:55:30 +0300

> meant to be machine readable, and so could be used to make an automatic

I'm not sure I understand where the "rest of the message" is.
Rfc2284bis-03:

    Type-Data

       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.

So, the Type-Data field use completely used for the Displayable
Message part. What other fields do we have for the other things?

--Jari

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 28 May 2003 09:57:29 -0700 (PDT)

> Message part. What other fields do we have for the other things?

In order to answer your question about "what is actually done in practice"
I did a capture of an EAP session on our 802.11 network.  Here is what is
sent in the EAP-Request/Identity:

0000:  00 6E 65 74 77 6F 72 6B 69 64 3D 4D 53 46 54 57  .networkid=MSFTW
0010:  4C 41 4E 2C 6E 61 73 69 64 3D 63 75 73 72 65 64  LAN,nasid=cusred
0020:  30 34 30 63 33 34 30 39 2C 70 6F 72 74 69 64 3D  040c3409,portid=
0030:  30                                               0

So the first octet is a NULL, followed by a comma delimited list of
parameters. The networkid parameter provides the SSID, the nasid
parameter provides the identity of the NAS (cusred040c3409), and the
portid parameter provides the port identifier (zero here).

My understanding is that the material prior to the null (not present here)
was to be presented to the user and the information after that (the comma
delimited parameter list) is for machine consumption.

---

From: [email-masked] (Jari Arkko)
Date: Wed, 28 May 2003 22:07:16 +0300

> delimited parameter list) is for machine consumption.

Very nice example, thanks. So, how do we treat this matter then?
It seems that current practise does not match what 2284bis says
(unless the last part of the text applies only to responses):

       This field MAY contain a displayable message in the Request,
       containing UTF-8 encoded ISO 10646 characters [RFC2279]. (... stuff
       about responses ... ) 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.

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

--Jari