RE: DISCUSS and COMMENT: draft-ietf-radext-fixes

["David B. Nelson" <d.b.nelson@comcast.net>]

Alan DeKok writes...

>   [RFC 2865] Section 1.1 already states:
> 
>    A NAS that does not implement a given service MUST NOT 
>    implement the RADIUS attributes for that service.  For example,
>    a NAS that is unable to offer ARAP service MUST NOT implement the
>    RADIUS attributes for ARAP.  A NAS MUST treat a RADIUS access-
>    accept authorizing an unavailable service as an access-reject
>    instead.
> 
>   The WG has discussed this, and related issues a fair bit.  The 
>   problem is that RADIUS doesn't have capability negotiations or
>   signaling.

Capability signaling is an issue that has been addressed in an ad-hoc
fashion for a couple of recent extensions (e.g. GEOPRIV).  We've discussed
it in more general terms, but never had consensus to take action.

> This makes it very difficult for servers to know client 
> capabilities.  There is no real good solution.  The text was place
> there to warn people of possible issues, and to suggest the safest
> behavior.

I've always though that it would be a good practice for a RADIUS client
implementation to have a configuration parameter to control this behavior,
allowing the system administrator to opt for maximum plug-'n'-play behavior
(ignore unknown attributes) or to opt for maximum security (deny service
when presented with unknown, non-VSA attributes in an Access-Accept).  I
don't think there is one policy that will work appropriately in all
deployment scenarios.

>   Administrators are generally aware of the need to fight with
> implementations to get client and server to agree on a set of attributes
> that they both accept.

That's what happens in the absence of capability signaling or a global
strict/lax policy configuration feature.

>   Note also that the recommendation is a SHOULD, not a MUST.

Should the keyword be RECOMMENDED instead?




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