-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Lothar Reith
Sent: Tuesday, December 07, 2004 4:19 AM
To: 'Nelson, David'; 'radiusext@ops.ietf.org'
Cc: 'David Kessens'; 'Bert Wijnen'; 'Bernard Aboba'
Subject: backwards compatible introduction of NEW attribute such as CUI (was: re: Minutes of the RADEXT WG Meeting at IETF-61David,
in your minutes you wrote (excerpt):
===================================================================================
Farid Adrangi: Chargeable User identity
(draft-adrangi-radius-chargeable-user-identity-02.txt)
------------------------------------------------------Farid went through current issues. Issues 13, 14 and 15 are addressed in the most recent draft. There are two open issues: (a) backward
compatibility and (b) the lack of general capability negotiation mechanism in RADIUS. We could send a "hint" attribute in the Access- Request message as indication of CUI feature support.
======================================================================================
As pointed out earlier, using an approach of "always send a hint" attribute in all Access-Request messages may be prohibitively expensive, in particular when this approach is used as precedence for advertising support of a new attribute in ALL access-request messages sent, even for the case when only once in a billion times this information is actually used.
The backwards compatibility issue with CUI - your issue a)above - is just one example of the general problem which you referred to as issue b): lack of general capability negotiation mechanism in RADIUS.
I would like to propose a solution for a) and for a subset of b), and therefore I would like to formulate issue c) below which I consider to be the most critical subset of your issue b:
issue c) lack of a backwards compatible server-initiated method which allows a server to verify (challenge) if a NAS supports a new RADIUS attribute referred to as "NEW", which is considered by the server to be a mandatory attribute, i.e. the Server requires assurance that the NAS will not ignore the NEW attribute when present in an Access-Accept.
An example of "NEW" is "CUI". A good example of issue c) is the CUI backwards compatibility issue described above in issue a). It is essential to the operation of CUI, that the server can trust the NAS will support CUI functionality and include a received CUI in the accounting messages - otherwise the home network operator would loose money.
My proposal to overcome issue c) is as follows (revised from an earlier proposal I made in the context of CUI):
Before including a new mandatory attribute "NEW" into an access-accept message a server may want to challenge the NAS in order to verify if the NAS supports that particular new attribute "NEW". This "Challenge" can be done implicitly (reject with a hint) or explicitly (challenge with a hint).
Implicit challenge:
1) on receipt of an access-request which does not include a Null-NEW attribute, but where the server would only send an access-accept if assured that the NAS supports NEW, the Server may respond with an Access-Reject message which includes the Null-NEW attribute as elaboration on the cause of the failure, implicitly signalling: I may have accepted if a Null-NEW attribute had been present in the access-request. On receipt of an access-reject with a Null-NEW attribute, the NAS should resend the access-accept but this time include the Null-NEW attribute, in order to confirm support of the NEW attribute.I believe this behaviour should be in line with Bernard's below earlier comment.
Bernard wrote in response to one of my earlier proposals which suggested re-interpreting an Access-Reject as an Access-Accept:
"Changing the semantics of the Access-Reject is somewhat tricky since the goal of that message is to deny service. As a result, RFC 2865 discourages inclusion of service-definition attributes within an Access-Reject, and subsequent RFCs have only included attributes that provide elaboration on the failure or its causes: EAP-Message, Reply-Message, etc." and "Interpreting an Access-Reject as an Access-Accept is explicitly forbidden by RFC 2865. We don't want to go down that road."
Alternatively perhaps an explicit challenge may be used as follows:
2) on receipt of an access-request message which does not include a Null-NEW attribute, but where the server would only send an access-accept if assured that the NAS supports NEW, the Server may respond with an Access-Challenge message which includes the Null-NEW attribute. A NAS which supports an attribute NEW MUST on receipt of a Null-NEW attribute in an access-challenge message include a Null-NEW attribute in the subsequent ACCESS-Request message in order to confirm support of NEW attribute to the challenging Server.I would like to note that it is up to the server if he requires an explicit assurance. If the server knows via some other way that the NAS supports the attribute NEW - then he does not need to challenge the NAS to provide confirmation of attribute support. Also, if the NAS is prepared to take a risk...
As always, comments welcome...
Lothar