Network Working Group Y. Li Internet-Draft A. Lior Expires: April 22, 2007 BWS G. Zorn Cisco October 19, 2006 Remote Authentication Dial In User Service (RADIUS) Attribute Type Extension draft-lior-radius-attribute-type-extension-01.txt 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 April 22, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract In order for the Remote Authentication Dial In User Service protocol to continue to support new applications, the RADIUS attribute space must 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 Li, et al. Expires April 22, 2007 [Page 1] Internet-Draft RADIUS Attribute Type Extension October 2006 compatibility with Diameter. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. RADIUS Type Extension . . . . . . . . . . . . . . . . . . . . 4 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1 Normative References . . . . . . . . . . . . . . . . . . . 9 9.2 Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 11 Li, et al. Expires April 22, 2007 [Page 2] Internet-Draft RADIUS Attribute Type Extension October 2006 1. Introduction The Remote Authentication Dial In User Service (RADIUS) Protocol [RFC2865] defines two classes of attributes: attributes that belong to the standard RADIUS space; and vendor specific attributes (VSAs). VSAs are available to allow vendors (historically including Standards Development Organizations) to support their own extended attributes not suitable for general usage, whereas the attributes that belong to the standard RADIUS space are controlled by the IETF are intended to be suitable for general use. These attributes are defined in RFCs and are assigned type codes by Internet Assigned Number Authority (IANA)IANA [RFC3575]. Attributes that belong to the RADIUS space are allocated a type code that is a single octet and hence RADIUS is limited to 255 attribute types. Of these, 101 or so have already been assigned and 61 are reserved. Therefore, as of this writing there are less than 100 type 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 means of a new scheme for allocating 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 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. 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 Li, et al. Expires April 22, 2007 [Page 3] Internet-Draft RADIUS Attribute Type Extension October 2006 to maintain backwards compatibility. This means that RADIUS servers and 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 MUST to be compatible with both RADIUS [RFC2865] and RADIUS Accounting [RFC2866]. The scheme SHOULD ensure that the size of the type-space extension is large enough that it will not be exhausted in the foreseeable future or is itself easily extensible in the event of type code exhaustion. Furthermore, the scheme should align with the Diameter Network Access Server Application [RFC4005], thereby allowing the two IETF 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 have 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. A need to group RADIUS attributes together has become more prevalent in current work. Therefore, the proposed scheme NUST provide a mechanism to group attributes. In recent years, attribute sizes are threatening the limit of 253 octets. Fragmentation of RADIUS attributes has always been possible by extending the value into another attribute of the same type. However this approach does not always work, especially if the attribute type repeats in the RADIUS packet. The proposed scheme SHOULD address attribute fragmentation. 3. RADIUS Type Extension The solution described in this document uses the Vendor-Specific attribute [RFC2865]as a basis for the creation of the RADIUS Extended Attributes. 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. Vendor Specific attributes are encoded by using the Vendor-Specific (26) type code, followed by Length (1 octet), a 4 octet Vendor-Id identified using 3 octets (4 octets really) and a string which is Li, et al. Expires April 22, 2007 [Page 4] Internet-Draft RADIUS Attribute Type Extension October 2006 vendor-specific [RFC2865]. The string part is encoded as follows: o The first octet represents the RADIUS Extended Type o The next octet is the length of the Extended Attribute, which represents the length of the Extended Type field (1 octet), the length of the length itself (1 octet), the length of the Fragmentation and Tag field (1 octet) and the length of the Value field (1 or more octet(s) o The third octet is the Fragmentation/Tag field (1 octet) o The value is 1 or more octets 4. Formal Syntax The following represents the encoding scheme used for RADIUS Extended Attribute(s). It is based upon the Vendor Specific (26) encoding [RFC2865]. +---------------------------------------------------------------+ | 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 | Length | +---------------+---------------+---------------+---------------+ |F| TAG | Value +---------------+--------------- Type 26 for Vendor-Specific. Length >= 10 Vendor-Id The high-order octet is zero (0) and the low-order 3 octets are zeros (0)s representing an extended IETF RADIUS attribute. Extended-Type One (1) Octet. Up-to-date values of the RADIUS Extended-Type field are specified in the most recent "Assigned Numbers" IANA [RFC3575] . Li, et al. Expires April 22, 2007 [Page 5] Internet-Draft RADIUS Attribute Type Extension October 2006 Values XXXX-YYYY are reserved. Length >= 4 The length of the Extended-Type, Length, Fragmentation and Tag fields and the length of the Value field Fragmentation (F): When set(1) the attribute is fragmented. When clear (0), the attribute is not fragmented. When the value portion of an extended attribute exceeds 246 octets the value is fragmented over one or more extended attribute. In this case the Fragmentation Flag is set on the attribute(s) that contain the value fragments. Tag The Tag field is 7-bits and MUST always be present. It is used to group extended attributes. Attributes with the same non-zero value belong to the same group. A tag value of zero(0) indicates that the attribute is not grouped. A tag value of all-ones (0x7F) is reserved. Value One or more octets. 5. Examples Consider an attribute called Foo of type String. Foo is allocated an Extended-Type by IANA of 10. The following figure shows the encoding of Foo(0,10) = "Hello": +---------------------------------------------------------------+ | 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) | | | (6+8 = 14) | | +---------------+---------------+-------------------------------+ | Vendor-Id(0) | Extended-Type | Length | | | (10) | (3 + 5 = 8) | +---------------+---------------+---------------+---------------+ |F| TAG | Value | | | |0| (0) | (H) | (e) | (l) | +---------------+---------------+-------------------------------+ | (l) | (o) | +---------------+---------------+ Li, et al. Expires April 22, 2007 [Page 6] Internet-Draft RADIUS Attribute Type Extension October 2006 The next figure shows the encoding of Foo when the length of Foo is 251 octets. Foo(0,10) = "Hello W...end.". In this case the value is fragmented over two attributes. The first 246 octets are included in the first fragment and the remaining 5 octets appear in the second attributes which has the Fragmentation bit set to 1. +---------------------------------------------------------------+ | 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) | | |(6 + 249 = 255)| | +---------------+---------------+-------------------------------+ | Vendor-Id(0) | Extended-Type | Length | | | (10) |(3 + 246 = 249)| +---------------+---------------+---------------+---------------+ |F| TAG | Value | | | |0| (0) | (H) | (e) | (l) | +---------------+---------------+-------------------------------+ | (l) | (o) | | (W) | +---------------+---------------+---------------+---------------+ ................ +---------------+---------------+-------------------------------+ | Type (26) | Length | Vendor-Id (0) | | | (6+8 = 14) | | +---------------+---------------+-------------------------------+ | Vendor-Id(0) | Extended-Type | Length | | | (10) | (3 + 5 = 8) | +---------------+---------------+---------------+---------------+ |F| TAG | Value | | | |1| (0) | ( ) | (e) | (n) | +---------------+---------------+-------------------------------+ | (d) | (.) | +---------------+---------------+ Next consider the following structure: struct Integer a; String b; Integer c; endStruct Element 'a' is assigned an extended type of 20. Element 'b' is assigned an extended type of 25 and element 'c' is assigned an extended type of 27. The following figure illustrates the coding where a(0,20) = 0xDEADDEAD, b(0,25) = "He.....The end." and is of length 251 octets; and c(0,27) = 0x12345678. The attributes are Li, et al. Expires April 22, 2007 [Page 7] Internet-Draft RADIUS Attribute Type Extension October 2006 grouped together with TAG=42. +---------------------------------------------------------------+ | 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) | | |(6 + 7 = 13) | | +---------------+---------------+-------------------------------+ | Vendor-Id(0) | Extended-Type | Length | | | (20) |(3 + 4 = 7) | +-+-------------+---------------+---------------+---------------+ |F| TAG | Value | | | |0| (42) | (0xde) | (0xad) | (0xde) | +-+-------------+---------------+-------------------------------+ | (0xad) | Type(26) | Length | Vendor-Id(0) | | | | (6 + 249 = 255| | +---------------+---------------+---------------+---------------+ | Vendor-Id (0) | Extended-Type | | | (25) | +---------------+-+-------------+---------------+---------------+ | Length |F| TAG | Value | Value | | (3+246) = 249 |0| (42) | (H) | (e) | +---------------+-+-------------+---------------+---------------+ ........... +---------------+---------------+---------------+---------------+ | Value | Value | Value | Value | | (.) | (T) | (h) | (e) | +---------------+---------------+---------------+---------------+ | Type (26) | Length | Vendor-Id (0) | | | (6+8 = 14) | | +---------------+---------------+-------------------------------+ | Vendor-Id(0) | Extended-Type | Length | | | (25) | (3 + 5 = 8) | +---------------+---------------+---------------+---------------+ |F| TAG | Value | | | |1| (42) | ( ) | (e) | (n) | +---------------+---------------+---------------+---------------+ | (d) | (.) | Type (26) | Length | | | | | (6+7 = 13) | +---------------+---------------+---------------+---------------+ | Vendor-Id (0) | | | +---------------+---------------+-+-------------+---------------+ |Extended-Type | Length |F| TAG | Value | | (27) | (3+4 = 7) |0| (42) | (0x12) | +---------------+---------------+-+-------------+---------------+ Li, et al. Expires April 22, 2007 [Page 8] Internet-Draft RADIUS Attribute Type Extension October 2006 | Value | Value | Value | | (0x34) | (0x56) | (0x78) | +---------------+---------------+---------------+ 6. Security Considerations TBD 7. 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. The allocation rules for extended RADIUS attributes align with the rules for allocation of the standard RADIUS attributes. 8. 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? We have allocated 1 octets for Extended Type. Is that too little? Note, if we run out the IETF can take out another Vendor-Id. 9. References 9.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. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, Li, et al. Expires April 22, 2007 [Page 9] Internet-Draft RADIUS Attribute Type Extension October 2006 July 2003. 9.2 Informative References [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005. Authors' Addresses 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/ 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/ Glen Zorn Cisco Systems 2901 Third Avenue, Suite 600 SEA1/5/ Seattle, WA 98121 United States of America Phone: Email: gwz@cisco.com URI: http://www.cisco.com/ Li, et al. Expires April 22, 2007 [Page 10] Internet-Draft RADIUS Attribute Type Extension October 2006 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 (2006). 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. Li, et al. Expires April 22, 2007 [Page 11]