Network Working Group A. Lior Internet-Draft Y. Li Expires: May 25, 2004 BWS November 25, 2003 Remote Authentication Dial In User Service (RADIUS) Attribute Type Extension draft-lior-radius-attribute-type-extension-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 May 25, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract In order for Remote Authentication Dial In User Service (RADIUS) protocol to continue to support new applications it is required that the RADIUS attribute space be extended beyond the current limit of 255 possible attribute types. This document defines a mechanism to extend the base RADIUS attribute types while maintaining backwards compatibility as well as compatibility with Diameter. Lior & Li Expires May 25, 2004 [Page 1] Internet-Draft RADIUS Attribute Type Extension November 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. RADIUS Type Extension . . . . . . . . . . . . . . . . . . . . 6 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10 Normative References . . . . . . . . . . . . . . . . . . . . . 11 Informative References . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . 13 Lior & Li Expires May 25, 2004 [Page 2] Internet-Draft RADIUS Attribute Type Extension November 2003 1. Introduction The Remote Authentication Dial In User Service (RADIUS) Protocol RFC2865 [3] defines two classes of attributes. Attributes that belong to the RADIUS space; and vendor specific attributes (VSAs). VSAs are available to allow vendors (which includes other Standard Development Organizations) to support their own extended Attributes not suitable for general usage. Where as the attribute that belong to RADIUS space are controlled by the IETF and are to be used in application that are suitable for general use. These attributes are defined in RFCs and are assigned types codes by Internet Assigned Number Authority (IANA)IANA [5]. Attributes that belong to the RADIUS space are allocated a type code that is a single octet and hence RADIUS is limited to 255 attributes types. Of these 255 attributes types, 101 or so have been assigned. Types 192-223 are reserved for experimental use; Types 224-240 are reserved for implementation-specific use; and values 241-255 are reserved and should not be used. Therefore, as of this writing there are approximately 90 types codes that can be allocated to new attributes. RADIUS evolution must not be hindered by the inability to define new RADIUS attributes. This document defines a mechanism to extend the RADIUS Attribute space by defining a new scheme to allocate attribute type codes. 1.1 Terminology The term RADIUS Extended Attribute is the name given to the new RADIUS attribute types that are enabled by this document. The RADIUS Extended Type contains the new type code that is assigned to the RADIUS Extended Attributes. Other terms used in this document are explained below: To be completed... 1.2 Requirements Language In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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]. An implementation is not compliant if it fails to satisfy one or more Lior & Li Expires May 25, 2004 [Page 3] Internet-Draft RADIUS Attribute Type Extension November 2003 of the must or must not requirements for the protocols it implements. An implementation that satisfies all the must, must not, should and should not requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the must and must not requirements but not all the should or should not requirements for its protocols is said to be "conditionally compliant". Lior & Li Expires May 25, 2004 [Page 4] Internet-Draft RADIUS Attribute Type Extension November 2003 2. Requirements This informative section describes the requirements that drive the solution used to create the RADIUS Extended Attribute types. A fundamental requirement for extending the RADIUS attribute space is to maintain backwards compatibility. This means that RADIUS servers (proxies) must be able to continue to decode and encode messages even though they may not need to understand an attribute that has been extended. More specifically, the scheme needs to be compliant with ' RADIUS RFCs such as RFC2865 [3] and also RADIUS Accounting RFC2866 [4]. The scheme should ensure that the extension is large enough so that we do not run out of type codes. Furthermore, the scheme should align with the Diameter NAS Req Application NASREQ [6]. Thereby allowing for the two AAA standards to interoperate. Although according to the specification the allocation of RADIUS attribute type codes has been controlled by IANA, this has not been the case in reality. In the real world, certain vendors have grabbed attribute type codes that they shouldn't have. The result is that many RADIUS deployments had to work around these attribute collisions. Therefore, each time a new attribute type is introduced it raises the possibility that something will break. The proposed scheme must be impervious to this artifact. Lior & Li Expires May 25, 2004 [Page 5] Internet-Draft RADIUS Attribute Type Extension November 2003 3. RADIUS Type Extension The solution described in this document uses the Vendor Specific attributes RFC2865 [3] to create the RADIUS Extended Attributes. Vendor Specific attributes are encoded by using the Vendor-Specific (26) attribute followed by Length (1 octet), followed by a 4 octet Vendor-Id identified using 3 octets (4 octets really) followed by a string which is vendor specific RFC2865 [3]. We allocate RADIUS the Vendor-Id of zero (0). In essence we are assigning the IETF a Vendor-Id which is what other Standard Development Organization have done in registering their own Vendor-Id. RADIUS Extended Attributes are encoded using Vendor Specific attributes with Vendor-Id set to zero (0). The string part is encoded as one or more RADIUS Extended Attribute(s) as follows: o The first 4 octets represent the RADIUS Extended Type; o The next octet is the length of the Extended Type, which represents the length of the Extended Type, the length of the length itself and optionally the length of the value; and o The value is 0 or more octets. Each VSA MUST contain at least one Extended Attribute, and MAY contain more then one Extended Attribute providing the overall length does not exceed the maximum length of a RADIUS attribute. Lior & Li Expires May 25, 2004 [Page 6] Internet-Draft RADIUS Attribute Type Extension November 2003 4. Formal Syntax The following represents the encoding scheme used for RADIUS Extended Attribute(s). The basis of this encoding is the Vendor Specific (26) encoding. +---------------------------------------------------------------+ | 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 (26) | Length | Vendor-Id (0) | +---------------+---------------+-------------------------------+ | Vendor-Id(0) | Extended-Type | +---------------+---------------+---------------+---------------+ | Extended-Type | Length | Value | +---------------+---------------+---------------+---------------+ |.... +---- Type 26 for Vendor-Specific. Length >= 11 Vendor-Id The high-order octet is zero (0) and the low-order 3 octets are zeros (0)s representing the RADIUS VSA. Extended-Type Four (4) Octets. Up-to-date values of the RADIUS Extended-Type field are specified in the most recent "Assigned Numbers" IANA [5] . Values XXXX-YYYY are reserved. Length >= 5 Value Zero (0) or more octets as defined by the Extended-Type. The RADIUS VSA MAY contain more then one Extended Attribute. Providing the maximum length of the attributes does not exceed the maximum length of the a RADIUS attribute (255 octets). Lior & Li Expires May 25, 2004 [Page 7] Internet-Draft RADIUS Attribute Type Extension November 2003 5. Security Considerations TBD Lior & Li Expires May 25, 2004 [Page 8] Internet-Draft RADIUS Attribute Type Extension November 2003 6. IANA Considerations This solution requires that the IETF be allocated Vendor-Type of zero to the IETF. It also requires that IANA be set up to manage the RADIUS Extended Attributes. Lior & Li Expires May 25, 2004 [Page 9] Internet-Draft RADIUS Attribute Type Extension November 2003 7. Open Issues What is the numbering scheme for attributes that will be used by RFC writers going forward? For example today we write user-name(1). Going forward, will we write foo-bar(0,1)? What is the numbering plan for these attributes? What range should be reserved? Do we want to allow for attributes that are longer than 255 octets? There are examples of that already. Do we address this issue here or do we leave it for another specification? We have allocated 4 octets for Extended Type. Is that too much? Note having such a large address space will not conflict with Diameter. This is because in Diameter these RADIUS attributes would be encoded as VSAs with Vendor ID 0. Lior & Li Expires May 25, 2004 [Page 10] Internet-Draft RADIUS Attribute Type Extension November 2003 Normative References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [4] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [5] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003. Lior & Li Expires May 25, 2004 [Page 11] Internet-Draft RADIUS Attribute Type Extension November 2003 Informative References [6] Calhoun, P., "Diameter Network Access Server Application". Authors' Addresses Avi Lior Bridgewater Systems Corporation 303 Terry Fox Drive Suite 100 Ottawa, Ontario K2K 3J1 Canada Phone: (613) 591-6655 EMail: avi@bridgewatersystems.com URI: http://www.bridgewatersystems.com/ Yong Li Bridgewater Systems Corporation 303 Terry Fox Drive Suite 100 Ottawa, Ontario K2K 3J1 Canada Phone: (613) 591-6655 EMail: yongli@bridgewatersystems.com URI: http://www.bridgewatersystems.com/ Lior & Li Expires May 25, 2004 [Page 12] Internet-Draft RADIUS Attribute Type Extension November 2003 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 (2003). 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. 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 Lior & Li Expires May 25, 2004 [Page 13] Internet-Draft RADIUS Attribute Type Extension November 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lior & Li Expires May 25, 2004 [Page 14]