INTERNET-DRAFT Murtaza S. Chiba Title:draft-chiba-radius-dynauthor-ext-00.txt Richard Foltak Expires February 2005 Cisco Systems, Inc. Avi Lior Bridgewater Systems September 2004 Command Additions for Dynamic Authorization Extensions to Remote Authentication Dial-In User Services (RADIUS) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This draft proposes to expand RFC3576 by adding commands that allow for, amongst other things, a query interface and ways to characterize the Change of Authorization messages. Chiba, et al. Expires February 2005 [Page 1] Internet Draft Command Additions to RFC3576 September 2004 1.0 Introduction The Dynamic Authorization extensions as described in RFC3576 allow for disconnecting, or dynamically changing the authorization of a session. Key aspects of the session are of interest to external servers, especially those that need to form policy decisions based on the current state information of a session(s). As an example, to allow a new prepaid service to be started for a session, the current prepaid state information can be requested using the simple query interface as laid out in this document. Other examples include, gathering the current resource usage, services being used, etc. Besides, it is useful to characterize the Change of Authorization to indicate, for example, the activation of a new service, or its deactivation. Note: The term service as used in this document refers to an application layer service, such as a music service, or a video-on-demand service, etc. 2.0 Message Exchange This draft proposes to use the CoA messages as described in RFC3576 with the addition of an Authorization-Command attribute to indicate the CoA character. +----------+ CoA-Request +----------+ | | <-------------------- | | | NAS | | RADIUS | | | CoA-Response | Server | | | ---------------------> | | +----------+ +----------+ The CoA packet contains the Authorization-Command attribute, in addition it contains both, session identification attributes and attributes required for the particular command. The CoA-ACK is sent when a sesion has been found and MAY contain attributes that make sense for a particular Authorization-Command. Chiba, et al. Expires February 2005 [Page 2] Internet Draft Command Additions to RFC3576 September 2004 A CoA-NAK is sent if the session described by the session identifying attributes does not exist (Error-Cause: 503 Session Context Not Found), in the case when no information/resources can be found to satisfy the Authorization-Command (Error-Cause: 506 Resources Unavailable), or when the NAS does not support the particular Authorization-Command (Error-Cause: 405 Unsupported Service). Response in the case of an ACK MAY contain attributes that make sense for the particular command, but is limited to attributes that are found in an Accounting-Request packet and in the case of errors, the NAK MUST contain an Error-Cause attribute and MAY contain Reply-Message (Attribute 18). Session Identification attributes along with the appropriate Authorization-Command related attributes MAY be reflected back in CoA-ACK messages. 3 Attributes Attributes carried in CoA ACK messages are limited to those found in a typical Accounting-Request and in addition MAY contain attributes reflected from the request itself. Attributes can be divided into two categories: 1. Identification attributes 2. Command Request/Response attributes Attributes used for identification are the set of attributes as listed in RFC3576 and include both, NAS and Session identification attributes. In addition, the following attributes are being proposed for inclusion. Chiba, et al. Expires February 2005 [Page 3] Internet Draft Command Additions to RFC3576 September 2004 3.1 Authorization-Command Description This attribute denotes the type of command. A summary of the Authorization-Command Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length >=3 Value The string field is one or more octets and this document defines the special value "Query-Only" to request information. 3.2 Command-Target Description This attribute helps to further isolate a target and is in addition to the identification attributes as described in RFC3576 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chiba, et al. Expires February 2005 [Page 4] Internet Draft Command Additions to RFC3576 September 2004 Type TBD Length >= 3 String The String field is one or more octets. It should contain a URI to further isolate a target. Since, Session-Identification attributes are limited to Sessions, there needs to be a way to further isolate multiple application services for a given session. For example the URIs for application services such as mp3 and video-on-demand would be: /session/service/mp3 and /session/service/video-on-demand It may also refer to a flow for an aggregating session: /session/flow/ 3.3 Query-Select Description This attribute identifies the requested information and further isolates the target of the query 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length >=3 Chiba, et al. Expires February 2005 [Page 5] Internet Draft Command Additions to RFC3576 September 2004 String The String field is one or more octets and contains the following format. from [where ] Where: select-id - a string containing an identifier that allows the requester to quickly identify the type of query without parsing the entire contents upon receipt of a response. attrs - identifies the attributes to be returned, can contain the value '*' to indicate all information or reference a group configured on the NAS. target - is the object, in a URI format, about which information is being sought and can have the value NULL if the identification attributes are sufficient e.g. for a session the URI is /session for a service on the session: /session/service object - further refines the target operand - is any of: eq - equal to ne - not equal to gt - greater than ge - greater than or equal to lt - less than le - less than or equal to value - is the specific object value Example: 1 SERVICE-GROUP from /session/service where service-name eq music 2 FLOW-GROUP from /session/flow where flow-id eq nnn Note: Combining multiple object, operand, value tuples into a single Boolean expression using conjuctive, or disjunctive Normal forms is beyond the scope of this document. The 'where' portion is optional and MAY be omitted. Chiba, et al. Expires February 2005 [Page 6] Internet Draft Command Additions to RFC3576 September 2004 4. Table of attributes This document describes the following new attributes Request ACK NAK # Attribute 0-1 0-1 0 TBD Authorization-Command 0-1 0-1 0 TBD Command-Target 0-1 0-1 0 TBD Query-Select In addition the Request and ACK message may contain the attributes from RFC2866 and identification attributes from RFC3576. The following table defines the meaning of the above table entries. 0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in packet. 0-1 Zero or one instance of this attribute MAY be present in packet. 1 Exactly one instance of this attribute MUST be present in packet. 5. Security Considerations All considerations as described in RFC3576 are applicable. 6. IANA Considerations This document uses the RADIUS [RFC2865] namespace, see . This document adds three new attributes TBD - Authorization-Command TBD - Command-Target TBD - Query-Select In addition this draft requests the addition of 'Accounting-Only' value to the Service-Type enumeration, the requirement for which is described in the section on "Diameter Compatibility" below. Chiba, et al. Expires February 2005 [Page 7] Internet Draft Command Additions to RFC3576 September 2004 7. Normative References [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3576] Chiba, M., et. al., "Dynamic Authorization Extensions to Remote Authentication Dial-in User Service (RADIUS)", RFC 3576, July 2003. 8. Informative references [AAATransport] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003. [Diameter] Calhoun, P., et al., "Diameter Base Protocol", Work in Progress. 9 Diameter Compatibility Since, there are no new packet codes being added there is no special consideration required, except when the Authorization-Command is set to Query-Only and the Service-Type set to Accounting-Only, then a NAS must send a CoA-NAK with the Error-Code set to "Request Initiated" and then follow-up with an Accounting-Request. A NAS not supporting this feature MUST send a CoA-NAK with the Error-Code attribute set to "Unsupported Service". For normal operation the Service-Type field should not be set to 'Authorize-Only', or 'Accounting-Only'. Chiba, et al. Expires February 2005 [Page 8] Internet Draft Command Additions to RFC3576 September 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. Chiba, et al. Expires February 2005 [Page 9] Internet Draft Command Additions to RFC3576 September 2004 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment The authors wish to thank the following people for their valued suggestions Richard Pruss Stefaan De Cnodder Bernard Aboba David Nelson Funding for the RFC Editor function is currently provided by the Internet Society. Authors' Addresses Murtaza Chiba Cisco Systems, Inc. 170 West Tasman Dr. San Jose CA, 95134 EMail: mchiba@cisco.com Phone: +1 800 553 6387 Richard Foltak Cisco Systems, Inc. 170 West Tasman Dr. San Jose CA, 95134 EMail: rfoltak@cisco.com Phone: +1 800 553 6387 Avi Lior Bridgewater Systems Corporation 303 Terry Fox Drive Suite 100 Ottawa, Ontario K2K 3J1 Canada Phone: (613) 591-6655 EMail: avi@bridgewatersystems.com Chiba, et al. Expires February 2005 [Page 10] Internet Draft Command Additions to RFC3576 September 2004 Expiration Date This memo is filed as and expires February 2005.