Network Working Group Alan DeKok INTERNET-DRAFT Network RADIUS Category: Proposed Standard Avi Lior Updates: 2865, 2866, 3575, 5176, 6158 <draft-ietf-radext-radius-extensions-10.txt> Expires: August 1, 2013 1 February 2013 Remote Authentication Dial In User Service (RADIUS) Protocol Extensions draft-ietf-radext-radius-extensions-10.txt Abstract The Remote Authentication Dial In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes which can carry more than 253 octets of data. This document defines changes to RADIUS which address all of the above problems. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 June 26, 2013. Copyright Notice DeKok, Alan Standards Track [Page 1]
INTERNET-DRAFT RADIUS Extensions 1 February 2013 Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info/) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. DeKok, Alan Standards Track [Page 2]
INTERNET-DRAFT RADIUS Extensions 1 February 2013 Table of Contents 1. Introduction ............................................. 5 1.1. Caveats and Limitations ............................. 6 1.1.1. Failure to Meet Certain Goals .................. 6 1.1.2. Implementation Recommendations ................. 6 1.2. Terminology ......................................... 7 1.3. Requirements Language ............................... 8 2. Extensions to RADIUS ..................................... 9 2.1. Extended Type ....................................... 10 2.2. Long Extended Type .................................. 11 2.3. TLV Data Type ....................................... 14 2.3.1. TLV Nesting .................................... 16 2.4. EVS Data Type ....................................... 16 2.5. Integer64 Data Type ................................. 18 2.6. Vendor-ID Field ..................................... 18 2.7. Attribute Naming and Type Identifiers ............... 19 2.7.1. Attribute and TLV Naming ....................... 19 2.7.2. Attribute Type Identifiers ..................... 19 2.7.3. TLV Identifiers ................................ 20 2.7.4. VSA Identifiers ................................ 20 2.8. Invalid Attributes .................................. 21 3. Attribute Definitions .................................... 22 3.1. Extended-Type-1 ..................................... 22 3.2. Extended-Type-2 ..................................... 23 3.3. Extended-Type-3 ..................................... 24 3.4. Extended-Type-4 ..................................... 25 3.5. Long-Extended-Type-1 ................................ 26 3.6. Long-Extended-Type-2 ................................ 27 4. Vendor Specific Attributes ............................... 28 4.1. Extended-Vendor-Specific-1 .......................... 29 4.2. Extended-Vendor-Specific-2 .......................... 30 4.3. Extended-Vendor-Specific-3 .......................... 31 4.4. Extended-Vendor-Specific-4 .......................... 32 4.5. Extended-Vendor-Specific-5 .......................... 33 4.6. Extended-Vendor-Specific-6 .......................... 35 5. Compatibility with traditional RADIUS .................... 36 5.1. Attribute Allocation ................................ 36 5.2. Proxy Servers ....................................... 37 6. Guidelines ............................................... 38 6.1. Updates to RFC 6158 ................................. 38 6.2. Guidelines for Simple Data Types .................... 38 6.3. Guidelines for Complex Data Types ................... 39 6.4. Design Guidelines For the New Types ................. 40 6.5. TLV Guidelines ...................................... 40 6.6. Allocation Request Guidelines ....................... 41 6.7. Allocation Requests Guidelines for TLVs ............. 42 6.8. Implementation Guidelines ........................... 43 DeKok, Alan Standards Track [Page 3]
INTERNET-DRAFT RADIUS Extensions 1 February 2013 6.9. Vendor Guidelines ................................... 43 7. Rationale for This Design ................................ 43 7.1. Attribute Audit ..................................... 43 8. Diameter Considerations .................................. 44 9. Examples ................................................. 45 9.1. Extended Type ....................................... 46 9.2. Long Extended Type .................................. 47 10. IANA Considerations ..................................... 50 10.1. Attribute Allocations .............................. 50 10.2. RADIUS Attribute Type Tree ......................... 50 10.3. Allocation Instructions ............................ 51 10.3.1. Requested Allocation from the Standard Space .. 52 10.3.2. Requested Allocation from the short extended sp 52 10.3.3. Requested Allocation from the long extended spa 52 10.3.4. Allocation Preferences ........................ 52 10.3.5. Extending the Type Space via TLV Data Type .... 53 10.3.6. Allocation within a TLV ....................... 53 10.3.7. Allocation of Other Data Types ................ 54 11. Security Considerations ................................. 54 12. References .............................................. 54 12.1. Normative references ............................... 54 12.2. Informative references ............................. 55 Appendix A - Extended Attribute Generator Program ............ 56 DeKok, Alan Standards Track [Page 4]
INTERNET-DRAFT RADIUS Extensions 1 February 2013 1. Introduction Under current allocation pressure, we expect that the RADIUS Attribute Type space will be exhausted by 2014 or 2015. We therefore need a way to extend the type space, so that new specifications may continue to be developed. Other issues have also been shown with RADIUS. The attribute grouping method defined in [RFC2868] has been shown to be impractical, and a more powerful mechanism is needed. Multiple attributes have been defined which transport more than the 253 octets of data originally envisioned with the protocol. Each of these attributes is handled as a "special case" inside of RADIUS implementations, instead of as a general method. We therefore also need a standardized method of transporting large quantities of data. Finally, some vendors are close to allocating all of the Attributes within their Vendor-Specific Attribute space. It would be useful to leverage changes to the base protocol for extending the Vendor- Specific Attribute space. We satisfy all of these requirements through the following changes given in this document: * defining an "Extended Type" format, which adds 8 bits of "Extended Type" to the RADIUS Attribute Type space, by using one octet of the "Value" field. This method gives us a general way of extending the Attribute Type Space. (Section 2.1) * allocating 4 attributes as using the format of "Extended Type". This allocation extends the RADIUS Attribute Type Space by approximately 1000 values. (Sections 3.1, 3.2, 3.3, and 3.4) * defining a "Long Extended Type" format, which inserts an additional octet between the "Extended Type" octet, and the "Value" field. This method gives us a general way of adding additional functionality to the protocol. (Section 2.2) * defining a method which uses the additional octet in the "Long Extended Type" to indicate data fragmentation across multiple Attributes. This method provides a standard way for an Attribute to carry more than 253 octets of data. (Section 2.2) * allocating 2 attributes as using the format "Long Extended Type". This allocation extends the RADIUS Attribute Type Space by an additional 500 values. (Sections 3.5 and 3.6) * defining a new "Type Length Value" (TLV) data type. The data type allows an attribute to carry TLVs as "sub-attributes", which can in turn encapsulate other TLVs as "sub-sub-attributes." This change creates a standard way to group a set of Attributes. (