Network Working Group A. Lior Internet-Draft Bridgewater Systems Expires: August 7, 2005 F. Adrangi Intel February 3, 2005 End-to-End Capabilities Support for Remote Authentication Dial In User Service (RADIUS) draft-lior-radext-end-to-end-caps-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 7, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes a new RADIUS attribute, End-to-End-Capability which can be used by a NAS to indicate its AAA capabilities to the home AAA server. Lior & Adrangi Expires August 7, 2005 [Page 1] Internet-Draft End-to-End Capabilities Support for RADIUS February 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. End-to-End-Capability Attribute . . . . . . . . . . . . . . 3 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Attribute Table . . . . . . . . . . . . . . . . . . . . . . 6 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Diameter Compatibility . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 8. Security considerations . . . . . . . . . . . . . . . . . . 7 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1 Bi-directional capability exchange . . . . . . . . . . . . 8 9.2 How to handle SDO capability extensions . . . . . . . . . 8 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1 Normative references . . . . . . . . . . . . . . . . . . 9 11.2 Informative references . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . 11 Lior & Adrangi Expires August 7, 2005 [Page 2] Internet-Draft End-to-End Capabilities Support for RADIUS February 2005 1. Introduction 1.1 Motivation There is a need for a home AAA server to discover capabilities of a NAS that has initiated a connection to it. The home AAA server may require that the NAS supports a particular AAA application. For example, if the user being authenticated and authorized is a prepaid user, then the home AAA needs to be assured that the NAS supports prepaid capabilities as defined in [I-D.lior-radius-prepaid-extensions]. Similarly, the home network may need to know whether or not the NAS supports RADIUS Dymanic Authorization Extensions as defined in [RFC3576]. Whether or not a NAS supports a particular capability could impact if the user is allowed on the network; or which attributes are delivered and perhaps the value of those attributes; and whether or not, and how the home network interacts with the NAS midsession. In some cases, the NAS itself may also need to communicate that it requires that the home AAA server deliver a particular capability. For example, the NAS may require that the home server deliver the Chargeable User Identity attribute as defined in [I-D.ietf-radext-chargeable-user-id]. This document defines an attribute appropriately called End-to-End-Capability attribute that allows the NAS to specify which capabilities it supports, and which capabilities that the NAS requires that the home AAA to deliver. The End-to-End-Capability attribute defined in this document is different then the capability exchange defined in Base Diameter [RFC3588]. The purpose of the Diameter based capability exchange is support routing of Diameter messages. Whereas, the functionality defined by this document is designed to ensure whether we can send an attribute or command or expect a behavior relating to this specific user's session. 1.2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. End-to-End-Capability Attribute The End-to-End-Capability attribute MUST be included in the Access-Request packet and indicates the capabilities that are supported by the NAS. The End-to-End-Capability attributes also Lior & Adrangi Expires August 7, 2005 [Page 3] Internet-Draft End-to-End Capabilities Support for RADIUS February 2005 allows the NAS to specify what capabities must be delivered to the NAS in an Access-Accept packet. A summary of the End-to-End-Capability attribute is given below. 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 for End-to-End-Capability. Length: >= 3 String: The string consists of a list of capabilities with each capability encoded as a bit-pair. Bit-pair '1' corresponds to Capability 1. Bit-pair '2' corresponds to Capability 2, etc. The bit-pair are used to indicated the following: 00: NOT-SUPPORTED Indicates that capability is not supported by the NAS. As per [RFC2865] the NAS MAY ignore any or all attributes associated with this capability. 10: SUPPORTED Implies that the capability is supported by the NAS. 11: REQUIRED Implies that the capbility is supported by the NAS and is required for the session. If the RADIUS server does not deliver the capability, the NAS SHOULD reject the session. The following end-to-end capabilities identities are assigned by this document. Additional capability Ids may be assigned later. See the IANA section. Lior & Adrangi Expires August 7, 2005 [Page 4] Internet-Draft End-to-End Capabilities Support for RADIUS February 2005 +--------+----------------------------------------------------------+ | Cap. | Capability | | Id | | +--------+----------------------------------------------------------+ | 0 | (RESERVED) MUST be set to '00' | | 1 | (NASREQ) Support for basic authentication and | | | authorization services as per [RFC2865]. The NAS MAY | | | indicate SUPPORTED only. | | 2 | (Accounting) Support for accounting as defined by | | | [RFC2866] and [RFC2869]. The NAS MAY indicate SUPPORTED | | | only. | | 3 | (TUNNELS) Supports RADIUS Attributes for Tunnel Protocol | | | Support as defined by [RFC2868]. The NAS MAY indicated | | | SUPPORTED and REQUIRED. | | 4 | (DM) Support Disconnect Message as defined by [RFC3576]. | | | The NAS MAY indicate SUPPORTED only. | | 5 | (COA) Support Change of Authorization as defined by | | | [RFC3576]. The NAS MAY indicate SUPPORTED only. | | 6 | (CUI) Support Chargeable User Identity as defined by | | | [I-D.ietf-radext-chargeable-user-id]. The NAS MAY | | | indicate SUPPORTED and REQUIRED. | | 7 | (L2 Filter) Support Layer-2 filtering as defined by | | | [I-D.congdon-radext-ieee802]. The NAS MAY indicate | | | SUPPORTED only. | | 8 | (L3 Filter) Support Layer-3 filtering as defined by | | | [I-D.congdon-radext-ieee802]. The NAS MAY indicate | | | SUPPORTED only. | | 9 | (L3 Redirect) Support Layer-3 redirects as defined by | | | [I-D.congdon-radext-ieee802]. The NAS MAY indicate | | | SUPPORTED only. | | 10 | (L4 Redirect) Support Layer-4 redirects as defined by | | | [I-D.congdon-radext-ieee802]. The NAS MAY indicate | | | SUPPORTED only. | | 11 | (PREPAID VOLUME) Support Volume-based prepaid as defined | | | by [I-D.lior-radius-prepaid-extensions]. The NAS MAY | | | indicate SUPPORTED only. | | 12 | (PREPAID TIME) Support Time-based prepaid as defined by | | | [I-D.lior-radius-prepaid-extensions]. The NAS MAY | | | indicate SUPPORTED only. | | 13 | (PREPAID POOL) Support prepaid pools as defined by | | | [I-D.lior-radius-prepaid-extensions]. The NAS MAY | | | indicate SUPPORTED only. | | 14 | (PREPAID RATING) Support rating groups pas defined by | | | [I-D.lior-radius-prepaid-extensions]. The NAS MAY | | | indicate SUPPORTED only. | | 15 | (PREPAID MULTI-SERVICE) Support for prepaid of | | | multi-services as defined by | | | [I-D.lior-radius-prepaid-extensions]. The NAS MAY | Lior & Adrangi Expires August 7, 2005 [Page 5] Internet-Draft End-to-End Capabilities Support for RADIUS February 2005 | | indicate SUPPORTED only. | +--------+----------------------------------------------------------+ 3. Operation This document assumes that the RADIUS protocol operates as specified in [RFC2865]. The End-to-End-Capability attribute provides capability supported by the NAS to the home network. AAA proxies MUST NOT modify the contents of this attribute. [RFC2865] includes the following statements about the behavior of a RADIUS server with respect to unsupported attributes: "A RADIUS server MAY ignore Attributes with an unknown Type." Therefore, a home AAA server that receives the End-to-End-Capability attribute which it does not understand, may ignore the attribute. If the NAS indicated that it REQUIRED the deliver of a particular capability, and the capability has not been provided in subsequent Access-Accept, the NAS MUST treat the Access-Accept as an Access-Reject. If the home AAA supports the End-to-End-Capability attribute and it includes a capability that is REQUIRED , then if the home AAA is unable to support the request, the home AAA SHOULD reply with an Access-Reject packet with Error-Cause(101) defined in [RFC3576] set to "Unsupported Capability"(TBD). 4. Attribute Table The following table provides a guide to which attribute(s) may be found in which kinds of packets, and in what quantity. Request Accept Reject Challenge Accounting # Attribute Request 0-1 0 0 0 0 TBD End-to-End-Capability 5. Example A RADIUS server may receive an End-to-End-Capability with the following value expressed in binary: '0010100010100000' The first bit-pair is set to zero as required by this document. The Lior & Adrangi Expires August 7, 2005 [Page 6] Internet-Draft End-to-End Capabilities Support for RADIUS February 2005 next bit-pair is set to '10' indicating that NASREQ capability is SUPPORTED. The next bit-pair is '10' indicating that the NAS supports Accounting. The next bit-pair is set to '00' indicating that the NAS does not support the TUNNELING capability. The next two bit-pair are set to '10' indicating that this NAS support both the Disconnect Message and Change of Authorization Messages as defined by [RFC3576]. Note the rest of the bits up to a the octet boundary are set to '0' indicating the no other capabilities are supported. 6. Diameter Compatibility This attribute functions in an equivalent manner in both RADIUS and Diameter. In Diameter, the base protocol layer may fill in the attribute values automatically based on its knowledge of applications running on top of it. 7. IANA Considerations This document uses the RADIUS [RFC2865] namespace, see "http://www.iana.org/assignments/radius-types". This document instructs IANA to assign a new RADIUS attribute number for the End-to-End-Capability attribute. End-to-End-Capability TBA Allocation of a new Error-Cause(101) value of "Unsupported Capability". Finally IANA should create a new name space, Capabilities Ids. The initial values in this name space include those listed in Section 2. New values in the 0-128 range can be allocated through IETF Consensus. Other values (upto 2023 i.e. 253 bytes times 8 bits) can be allocated on a First-Come First Served basis with Specification Required. 8. Security considerations The RADIUS proxies MUST NOT modify the End-to-End-Capability attribute. However, there is no way to detect or prevent this. If the NAS includes End-to-End-Capability attribute in an Access-Request packet, a man in the middle may remove attribute or change the value of the attribute. This could result in a denial of service by causing the NAS to reject the session. To prevent this attack, the NAS SHOULD include Message-Authenticator(80) in the Access-Request packets that contain a End-to-End-Capability Lior & Adrangi Expires August 7, 2005 [Page 7] Internet-Draft End-to-End Capabilities Support for RADIUS February 2005 attribute. 9. Open Issues 9.1 Bi-directional capability exchange Glen Zorn asked the question, why should the capability exchange should only come from the client? He is right! Using logoff as an example to illustrate why it makes sense. Supposing the NAS reports that it supports LOGOFF capability. It would be nice for the Server to be able to tell the NAS that it wants to receive the LOGOFF message as decribed in the logoof document. The server could do this during Access-Accept or even mid-session using CoA. By allowing the Server to send the capability attribute back in an Access-Accept the server can signal what it supports and what it REQUIRES. Comments? 9.2 How to handle SDO capability extensions How will capabilities be extended? When SDOs develop AAA application or deployments they often introduced their own capability attributes. While it would be nice to have everyone develop all their work in the IETF. This is not always practicle. We propose the following: Recommend to SDOs that if they want their own capability attribute that they should create their own VSA that matches the format of the End-to-End-Capability. The capability attribute would then be carried in the RADIUS packets as a VSA along side the RADIUS one. If they want to have an application that interoperates outside the scope of the SDOs, then they will have to allocate the capabilty attribute after they publish the RFC at the IETF. 10. Acknowledgements We would like to acknowledge the helpfull comments received from Bernard Aboba, David Nelson, Barney Wolf, Paul Congdon, and Jari Arkko. Lior & Adrangi Expires August 7, 2005 [Page 8] Internet-Draft End-to-End Capabilities Support for RADIUS February 2005 11. References 11.1 Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000. 11.2 Informative references [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [I-D.lior-radius-prepaid-extensions] Lior, A., "Prepaid Extensions to Remote Authentication Dial-In User Service (RADIUS)", Internet-Draft draft-lior-radius-prepaid-extensions-06, October 2004. [I-D.ietf-radext-chargeable-user-id] Adrangi, F., "Chargeable User Identity", Internet-Draft draft-ietf-radext-chargeable-user-id-01, December 2004. [I-D.congdon-radext-ieee802] Congdon, P., "RADIUS Extensions for IEEE 802", Internet-Draft draft-congdon-radext-ieee802-02, November 2004. Lior & Adrangi Expires August 7, 2005 [Page 9] Internet-Draft End-to-End Capabilities Support for RADIUS February 2005 Authors' Addresses Avi Lior Bridgewater Systems Corporation 303 Terry Fox Drive Ottawa, Ontario K2K 3J1 Canada Phone: +1 613-591-6655 Email: avi@bridgewatersystems.com Farid Adrangi Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97124 USA Phone: +1 503-712-1791 Email: farid.adrangi@intel.com Lior & Adrangi Expires August 7, 2005 [Page 10] Internet-Draft End-to-End Capabilities Support for RADIUS February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lior & Adrangi Expires August 7, 2005 [Page 11]