Re: Issue: Treatment of null Identity Response

[Jari Arkko <jari.arkko@piuha.net>]

Pasi,

> 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 like what you suggest above. But admittedly the specs
could be clearer about this. We also have RFC 3579, which
says

  ... the NAS MUST copy the
  contents of the Type-Data field of the EAP-Response/Identity received
  from the peer into the User-Name attribute...

Which we can perhaps interpret so that if the contents is missing then
we omit the attribute. But its not very clear. RFC 3579 also says

  ... If the NAS initially sends an EAP-Request for an
  authentication method, and the peer identity cannot be determined
  from the EAP-Response, then the User-Name attribute SHOULD be
  determined by another means.  As noted in [RFC2865] Section 5.6, it
  is recommended that Access-Requests use the value of the
  Calling-Station-Id as the value of the User-Name attribute.

which talks about a similar but not exactly the same case. And
recommends something different from what you were saying above.
Anyway, it seems like we have the options of (a) failing the connection,
(b) omitting User-Name, and (c) filling it with Called-Station-Id or some
predetermined value.

The other issue is what, if anything, we should clarify in the specs
about this.

--Jari


--
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/>