Subject: [eap] Re: [Issue 19] User-Name in EAP/RADIUS

From: [email-masked] (Bernard Aboba)
Date: Sun, 14 Apr 2002 11:15:43 -0700 (PDT)

I've assigned this issue #19. EAP issues are tracked at:

http://www.drizzle.com/~aboba/EAP/eapissues.html

> from RFC 2869:
> > In order to permit non-EAP aware RADIUS proxies to forward the
> > Access-Request packet, if the NAS sends the EAP-Request/Identity, the
> > NAS MUST copy the contents of the EAP-Response/Identity into the
> > User-Name attribute and MUST include the EAP-Response/Identity in the
> > User-Name attribute in every subsequent Access-Request.
> 
> 
> 1) Is the EAP-Response/Identity (as concerns 2869), which is required to
> be placed into the User-Name attribute, the entire EAP-Response/Identity
> packet including Code, Identifier, Length, Type, and Type-Data or is it
> simply the Type-Data?  (If the latter is true, 2869 might more carefully
> have been written: "...the NAS MUST copy the contents of Type-Data from
> the EAP-Response/Identity packet into the User-Name attribute...")

It is simply the Type-Data. Your recommended change will be incorporated
in RFC2869bis-02. 

> 2) RFC 2865 defines the User-Name attribute to be the triple: 
> >  User-Name (0x01), Length (>3), and String... 
> RFC 2284 makes no demands upon the contents of Type-Data contained in an
> EAP-Response/Identity.  RFC 2284 would seem to allow any data, including
> embedded 0x00's (and, in fact, this might be thought useful by some EAP
> authentication schemes).  Does EAP interoperation with RADIUS, as
> defined in 2869, presuppose that the contents of Type-Data within an
> EAP-Response/Identity packet be somewhat well-behaved (i.e. - a
> reasonable string)?
> 

In RFC 2284bis-04, the following text describes the contents of the
Type-Data field of the Identity type:

"This field MAY contain a displayable message in the Request, 
containing UTF-8 encoded 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."

Note that some similar text about UTF-8 has been put into the description
of the Notification type.
 
Any problems with this?