Re: -01 version of Chargeable User Identity

["Alan DeKok" <aland@ox.org>]

Bernard Aboba <aboba@internaut.com> wrote:
> [ rejecting requests with unrecognized attributes ]
>
> There are two questions:  whether this is behavior that is commonly
> implemented, and whether this is behavior that the IETF wishes to condone.
> I agree that it seems like a bad idea, but of course that doesn't mean
> that it isn't commonly implemented anyway.  I'd like to hear more from
> RADIUS server implementers on what their implementations do.

  FreeRADIUS ignores all attributes it doesn't understand.  That is,
it's policy is:

  - Try to authorize/authenticate the request by looking for, and using,
    known attributes in the Access-Request
  - If no known attributes are found, send Access-Reject
  - If the authentication using known attributes succeeds, send Access-Accept.
  - If not, send Access-Reject

  Any "extra" attributes in the Access-Request not used as part of the
above process are ignored.  It doesn't matter if they're
Vendor-Specific or not, they're all treated identically.

> The latter is more problematic, because the RADIUS server could send an
> Access-Accept with no CUI attribute, and then wonder why the NAS never
> sent an Accounting packet indicating that service started.  Or is the
> intent for a non-supporting RADIUS server to send an Access-Reject?  If
> so, then we need to verify that existing RADIUS servers that don't support
> CUI actually behave this way.

  FreeRADIUS doesn't, but it can be configured to do so.

  i.e. "If attribute X is not in the Access-Request, send Access-Reject".

  This ability is dependent only on the administrators ability to know
the attribute number, and potentially the vendor ID of the attribute.
It doesn't require knowledge of the attribute format or values.

  Alan DeKok.

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