RE: backwards compatible introduction of NEW attribute such as CUI

["Nelson, David" <dnelson@enterasys.com>]

Avi Lior writes...

> 3576 supports missing attribute indication.

Let's talk about RFC3576.

Section 1.1 Applicability says, in part:

   This protocol is being recommended for publication as an
   Informational RFC rather than as a standards-track RFC because of
   problems that cannot be fixed without creating incompatibilities with
   deployed implementations.  This includes security vulnerabilities, as
   well as semantic ambiguities resulting from the design of the
   Change-of-Authorization (CoA) commands.  While fixes are recommended,
   they cannot be made mandatory since this would be incompatible with
   existing implementations.

RFC3576 is an Informational document that was created without any IETF
Working Group review (it came into existence between the RADIUS and
RADEXT working group timeframes).

Given the RADEXT WG charter requirement to maintain backwards
compatibility, and assuming that document conflicts would be resolved in
favor of the Standards Track document over the Informational document,
we may need to look at the applicability and backwards compatibility
properties of attributes and commands from RFC3576 somewhat more
carefully, in proposing them as solutions to current RADEXT issues.

RFC3576 does not indicate that the Error-Cause attribute may be used in
any commands other than CoA-Request, CoA-ACK and CoA-NAK.  Nor does it
explicitly prohibit their use in other commands, such as Access-Request,
Access-Challenge, Access-Accept or Access-Reject.  It remains silent on
that matter, but given that RFC3576 avoids any attempt to update or
modify RFC2865, that seems appropriate.   In the absence of any RFC that
includes the Error-Cause attribute in an "attribute usage table" that
includes the traditional RADIUS Access-* commands, such usage is
speculative, and non-standardized.

That doesn't mean we can't re-use the Error-Cause attribute here, but it
does, IMHO, mean that the CUI document would need to explicitly call out
the allowed inclusion of the Error-Cause attribute in RADIUS
Access-Request, Access-Challenge, Access-Accept or Access-Reject
commands, in an appropriate "attribute usage table".

I guess I should submit this as a RADEXT Issue against the CUI draft.
I'll make a note to do that...

As to whether the inclusion of Error-Cause or some other form of missing
attribute indication in RADIUS Access-Reject messages should be used as
the basis of specifying a general RADIUS capabilities negotiation
protocol, IMHO, that's a whole other matter.



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