Subject: [eap] Adding supplementary data to Identity-Response?

From: "Lortz, Victor" <[email-masked]>
Date: Mon, 11 Aug 2003 08:06:41 -0700

Section 5.1 of 2284bis describes the EAP Identity messages (Request and Response).  The latest draft says that the text of the Request message prior to a NULL character is intended to be displayed to the user.  Any information after the NULL character is extra data whose format is still TBD.  Some existing networks use  the following syntax:

<display-string>\0networkid=<network-name>,nasid=<nas-name>,portid=<port-id>

What do people think about extending this idea to include extra data in Identity-Response messages as well?  One possible use would be to allow the peer to indicate its preferred authentication method.  Another use would be to communicate characteristics of the network services desired by the peer.  For example, the peer may require a certain bit rate or a certain quality of service (or the ability to request quality of  service).   

One could think of this additional data (in both the Identity Request and Response) as supplementary information (i.e., hints) that can be used to determine whether it will be worthwhile to continue attempting the connection.  Piggy-backing this data on the Identity messages has the important advantages of reducing round trips and of making this data available as soon as possible in the authentication process.    

Additional considerations:  

If the Identity-Response contains extra data after a NULL, the processing of the Identity Type-Data field  might need to be changed in some implementations.  For example, when the NAI is copied from the Type-Data field into the RADIUS Username attribute, the implementation must avoid copying the data after the NULL.   Furthermore, implementations of EAP servers would  need to be modified to enable processing of this new data.   

Regards,
Vic

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 13 Aug 2003 17:18:43 +0300

> <display-string>\0networkid=<network-name>,nasid=<nas-name>,portid=<port-id>

Yes.

> One could think of this additional data (in both the Identity Request and Response) as supplementary information (i.e., hints) that can be used to determine whether it will be worthwhile to continu…

Here are some thoughts:

As you point out, the proposal has potential backwards compatibility
considerations. For instance, I might have to upgrade the firmware
of my old NAS if a new client with support for this came around, otherwise
authentication would fail. On those grounds, I'm a bit skeptical of this
particular solution.

There's a related issue of transferring configuration and other information
through EAP. We might find ways to do what you request without breaking
old implementations. But then we have to figure out what information is
really needed, and what protocol is the right place in the stack to transfer
this information. For instance, there has been a discussion of whether
"network selection" should be done at EAP, link layer, or somewhere else.

Looking at your example uses of this information, there may be some
specific uses that require their specific solutions if they are to be
done right. For instance, passing the "preferred method" information
to the authenticator. While its true that such information could reduce
the number of roundtrips, if we are going to touch the ack-nak behaviour
of EAP I'd rather make the negotiation secure at the same time.

--Jari