[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue: Treatment of null Identity Response



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.

What we are seeing in implementations in the field is a mix of a) and c), with the behavior in case c) ranging all over the map. In particular, some implementations are treating a null EAP-Response/Identity as a privacy NAI (no userid or realm).



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