RE: Issue: Treatment of null Identity Response

[<Pasi.Eronen@nokia.com>]

I don't think there's any contradiction here...

Both specs say that there are valid cases where no user name is
available or known. In EAP, the whole EAP-Response/Identity packet
cannot be omitted, so the client sends one with an empty data
field. In RADIUS, an unavailable/unknown username is indicated by
omitting the User-Name attribute from the Access-Request ("It MUST 
be sent in Access-Request packets _if_available_.").

So it seems the issue is only whether NAS implementations have really
remembered to handle this special case correctly. I'd guess there are
probably some implementations that send an empty User-Name attribute
instead (thus violating RFC2865), but this is just a hunch and not
based on actual experiences...

Best regards,
Pasi

> -----Original Message-----
> From: Bernard Aboba
> Sent: 12 December, 2005 22:24
> To: radiusext@ops.ietf.org
> Subject: Issue: Treatment of null Identity Response
> 
> RFC 3748 and RFC 2865 appear to disagree on the subject of whether 
> a response to an EAP-Request/Identity can be an 
> EAP-Response/Identity packet with no data.
> 
> RFC 3748 Section 5.1 says:
> 
>    Type
> 
>       1
> 
>    Type-Data
> 
>       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 prior
>       to the null is displayed.  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.
> 
> So according to RFC 3748, it is possible to have an Identity 
> Response field that is zero bytes in length, if the identity is 
> not known.
> 
> However, RFC 2865 Section 5.1 says:
> 
> 5.1.  User-Name
> 
>    Description
> 
>       This Attribute indicates the name of the user to be 
>       authenticated. It MUST be sent in Access-Request packets if 
>       available.
> 
>       It MAY be sent in an Access-Accept packet, in which case the
>       client SHOULD use the name returned in the Access-Accept packet 
>       in all Accounting-Request packets for this session.  If the 
>       Access-Accept includes Service-Type = Rlogin and the User-Name 
>       attribute, a NAS MAY use the returned User-Name when performing 
>       the Rlogin function.
> 
>    A summary of the User-Name Attribute format is shown below.  The
>    fields are transmitted from left to right.
> 
>     0                   1                   2
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>    |     Type      |    Length     |  String ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> 
>    Type
> 
>       1 for User-Name.
> 
>    Length
> 
>       >= 3
> 
>    String
> 
>       The String field is one or more octets.  The NAS may limit the
>       maximum length of the User-Name but the ability to 
>       handle at least 63 octets is recommended.
> 
>       The format of the username MAY be one of several forms:
>       text      Consisting only of UTF-8 encoded 10646 [7] characters.
>       network access identifier
> 
> Since the User-Name must be at least 3 bytes in length, a 
> zero-length String  field is not acceptable.
> 
> Question:  What does a RADIUS client do if it receives an 
> EAP-Identity/Response with no data?

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>