Network Working Group A. Lior Internet-Draft Bridgewater Systems Expires: January 18, 2006 F. Adrangi Intel July 17, 2005 End-to-End Capabilities Support for Remote Authentication Dial In User Service (RADIUS) draft-lior-radext-end-to-end-caps-01 Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 January 18, 2006. 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 RADIUS capabilities to the RADIUS server and also allows the RADIUS server to request certain capabilities from the NAS. Lior & Adrangi Expires January 18, 2006 [Page 1] Internet-Draft E2E Capabilities Support for RADIUS July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. End-to-End-Capability Attribute . . . . . . . . . . . . . . 4 3. Attribute Table . . . . . . . . . . . . . . . . . . . . . . 7 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 7. Security considerations . . . . . . . . . . . . . . . . . . 8 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1 Bi-directional capability exchange . . . . . . . . . . . . 8 8.2 How to handle SDO capability extensions . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1 Normative references . . . . . . . . . . . . . . . . . . 9 10.2 Informative references . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . 12 Lior & Adrangi Expires January 18, 2006 [Page 2] Internet-Draft E2E Capabilities Support for RADIUS July 2005 1. Introduction 1.1 Motivation There is a need for a RADIUS server to discover capabilities of a NAS that has initiated a connection to it. The RADIUS server may require that the NAS supports a particular RADIUS application. For example, if the user being authenticated and authorized is a prepaid user, then the RADIUS needs to be assured that the NAS supports prepaid capabilities as defined in [I-D.lior-radius-prepaid- extensions]. Similarly, the 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 network interacts with the NAS midsession. In some cases, the NAS itself may also need to communicate that it requires that the RADIUS server deliver a particular capability. For example, the NAS may require that the server deliver the Chargeable User Identity attribute as defined in [I-D.ietf-radext- chargeable-user-id]. Similarly, the RADIUS server may require that the NAS enable certain feature that the RADIUS server requires for the session. For example, the network may require that the NAS deliver location information as defined by [I-D.ietf-geopriv-radius-lo] before it can authenticate the session. This document defines an attribute appropriately called End-to-End- Capability attribute that allows: o The NAS to specify which capabilities it supports. o The NAS to specify which capabilities that are required to be delivered by the RADIUS server. o The RADIUS server to express the capabilities desired from the NAS. o The RADIUS server to express the capabilities that the RADIUS server requires from the NAS. 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. Lior & Adrangi Expires January 18, 2006 [Page 3] Internet-Draft E2E Capabilities Support for RADIUS July 2005 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 MAY be included in the Access- Request, Access-Challenge, Access-Accept and Change of Authorization packets. A NAS that supports RADIUS features beyond those defined in [RFC2865] SHOULD include the End-to-End-Capability attribute to advertize the capabilities that it supports. A NAS that requires certain capabilities from the RADIUS server SHOULD include the End-to-End-Capability attribute indicating which capabilities MUST be delivered by the RADIUS server. If the requested capabilities are not delivered, the NAS MAY reject the subsequent replies from the RADIUS server. The specific behavior will depend on the associated capability and will be defined in the associated RFCs. A RADIUS server MAY include an End-To-End-Capability attribute in an Access-Accept, Challenge message or COA packets to indicate which capabilites it desires from the NAS. If the NAS recognizes the End- to-End-Capability attribute, then the NAS MAY honor the RADIUS server's request. Using the End-to-End-Capability attribute, the RADIUS server MAY specifiy which capabilities that it requires from the NAS. A NAS that recognizes the End-to-End-Capability attribute and that supports the requested feature SHOULD deliver the requested capabilites to the RADIUS server. If the capabilities are not delivered to the RADIUS server, the RADIUS server MAY reject the session. If the session has already been established the RADIUS server may send a Disconnect Message to terminate the session. The exact behavior of the RADIUS server is dependant on the actual capability being requested. 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... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lior & Adrangi Expires January 18, 2006 [Page 4] Internet-Draft E2E Capabilities Support for RADIUS July 2005 Type: TBD for End-to-End-Capability. Length: >= 3 String: The string consists of a sequence 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 sequence is octet aligned. The sequence will grow as capabilities are added. A NAS or a RADIUS server MAY only report the first N octets of the sequence. In this case the reciever SHALL interpret that the capabilities represented by the missing octets are not supported by the sender. The bit-pair are used to indicated the following: 00: NOT-SUPPORTED Indicates that capability is not supported or not desired. 10: SUPPORTED Implies that the capability is supported or desired. 11: REQUIRED Implies that the capbility is supported and is required for the session. When sent by the NAS to the RADIUS server, if the RADIUS server does not deliver the capability, the NAS MAY reject the session. When sent by the RADIUS server to the NAS, the RADIUS server MAY reject the session if the capabilities are not delivered for 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 January 18, 2006 [Page 5] Internet-Draft E2E Capabilities Support for RADIUS July 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. | Lior & Adrangi Expires January 18, 2006 [Page 6] Internet-Draft E2E Capabilities Support for RADIUS July 2005 | 15 | (PREPAID MULTI-SERVICE) Support for prepaid of | | | multi-services as defined by | | | [I-D.lior-radius-prepaid-extensions]. The NAS MAY | | | indicate SUPPORTED only. | | 16 | (CIVIC_LOCATION) Support for civic location as defined | | | by [I-D.ietf-geopriv-radius-lo]. The NAS MAY indicate | | | SUPPORTED only. | | 17 | (GEO_LOCATION) Support for geospatial location as | | | defined by [I-D.ietf-geopriv-radius-lo]. The NAS MAY | | | indicate SUPPORTED only. | +--------+----------------------------------------------------------+ 3. 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 COA # Attribute Request 0-1 0-1 0 0-1 0 0-1 TBD End-to-End-Capability 4. 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 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. Capabilities in Octets that follow this are not supported. 5. 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 Lior & Adrangi Expires January 18, 2006 [Page 7] Internet-Draft E2E Capabilities Support for RADIUS July 2005 running on top of it. 6. 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. 7. 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. This attack could also cause the RADIUS server to deliver infomration that is not rquired by the NAS but could be useful to that attacker. To prevent this attack, the NAS SHOULD include Message-Authenticator(80) in the Access-Request packets that contain a End-to-End-Capability attribute. 8. Open Issues 8.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 Lior & Adrangi Expires January 18, 2006 [Page 8] Internet-Draft E2E Capabilities Support for RADIUS July 2005 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. The [I-D.ietf-geopriv-radius-lo] also includes requirment for bi- directional exchange. ADDED IN VERSION 01 Comments? 8.2 How to handle SDO capability extensions How will capabilities be extended? When SDOs develop RADIUS 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. 9. Acknowledgements We would like to acknowledge the helpfull comments received from Bernard Aboba, David Nelson, Barney Wolf, Paul Congdon, and Jari Arkko. 10. References 10.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. Lior & Adrangi Expires January 18, 2006 [Page 9] Internet-Draft E2E Capabilities Support for RADIUS July 2005 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000. 10.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)", draft-lior-radius-prepaid-extensions-08 (work in progress), July 2005. [I-D.ietf-radext-chargeable-user-id] Adrangi, F., "Chargeable User Identity", draft-ietf-radext-chargeable-user-id-05 (work in progress), May 2005. [I-D.ietf-geopriv-radius-lo] Tschofenig, H., "Carrying Location Objects in RADIUS", draft-ietf-geopriv-radius-lo-04 (work in progress), July 2005. [I-D.congdon-radext-ieee802] Congdon, P., "RADIUS Extensions for IEEE 802", draft-congdon-radext-ieee802-03 (work in progress), February 2005. Lior & Adrangi Expires January 18, 2006 [Page 10] Internet-Draft E2E Capabilities Support for RADIUS July 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 January 18, 2006 [Page 11] Internet-Draft E2E Capabilities Support for RADIUS July 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 January 18, 2006 [Page 12]