Proposed Resolution to RFC 3576bis Issue 163: VSA with Disconnect-Request

["Bernard Aboba" <bernard_aboba@hotmail.com>]

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 
the following:

"   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: steven.xu@motorola.com
Date first submitted: January 20, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00034.html
Document: FIXES-01
Comment type: 'T'echnical |
Priority: S
Section: Various
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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>