[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposed Resolution to RFC 3576bis Issue 163: VSA with Disconnect-Request
The text of Issue 163 is enclosed below.
The permitted attributes in a Disconnect-Request parallels the attributes
permitted in a RADIUS Access-Reject to some extent. The Disconnect-Request
only includes session identification attributes since the goal is not to
change the authorizations, but to terminate the user. Therefore the only
attributes needed are those that are used for user-identification.
RFC 2865 only enables Reply-Message and Proxy-State attributes in an
Access-Reject; Vendor-Specific attributes are prohibited. RFC 2869 enables
inclusion of Password-Retry, EAP-Message and Message-Authenticator
attributes. RFC 3579 enables inclusion of an Error-Cause attribute within
an Access-Reject. RFC 2868 and 3162 do not enable use of the attributes
defined there within an Access-Reject.
So my take is that the omission of vendor-specific attributes from a RFC
3576 Disconnect-Request is intentional.
Of course, this begs the question of why a Service-Type value of "Authorize
Only" is being used with a Disconnect-Request in the first place. RFC 3576
is in error in stating that this is useful for Diameter interoperability;
in fact, Diameter disconnect requests are handled via request/response, not
via generation of another Access-Request.
The proposed resolution is to change the last two paragraphs of Section 3 to
" Where a Service-Type Attribute with value "Authorize Only" is
included within a CoA-Request, attributes representing an
authorization change MUST NOT be included; only NAS or session
identification attributes are permitted, as well as Service-Type,
Nonce and State attributes. If other attributes are included in such
a CoA-Request, implementations MUST send a CoA-NAK; an Error-Cause
Attribute with value "Unsupported Attribute" MAY be included.
A Disconnect-Request MUST contain only NAS and session identification
attributes (see Section 3), as well as Service-Type, Nonce and State
attributes. If other attributes are included in a Disconnect-
Request, implementations MUST send a Disconnect-NAK; an Error-Cause
Attribute with value "Unsupported Attribute" MAY be included."
Issue 163: Vendor-Specific Attribute with "Authorize-Only" Service-Type
Submitter names: Steven Xu
Submitter email address: email@example.com
Date first submitted: January 20, 2006
Comment type: 'T'echnical |
Rationale/Explanation of issue:
I am looking for a clarification on "Vendor-Specific" attribute in
Disconnect-Request when it is used for "Authorize Only".
In RFC3576 section 3.2, there is no Note for "Vendor-Specific" in Disconnect
Request. (There is Note 3 for the COA). So when the Service-Type is
"Authorize Only" in Disconnect-Request, can it have the Vendor-Specific
attribute? The Note 3 says NO, but it is not added for DM.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.