Network Working Group Alan DeKok INTERNET-DRAFT Network RADIUS Category: Proposed Standard Avi Lior Updates: 2865, 2866, 5176 BWS <draft-dekok-radext-radius-extensions-00.txt> Expires: March 1, 2011 1 September 2010 Remote Authentication Dial In User Service (RADIUS) Protocol Extensions draft-dekok-radext-radius-extensions-00.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 March 1, 2011. Copyright Notice DeKok, Alan Informational [Page 1]
INTERNET-DRAFT RADIUS Extensions 1 September 2010 Copyright (c) 2010 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 Informational [Page 2]
INTERNET-DRAFT RADIUS Extensions 1 September 2010 Table of Contents 1. Introduction ............................................. 4 1.1. Terminology ......................................... 5 1.2. Requirements Language ............................... 5 2. Extensions to RADIUS ..................................... 6 2.1. Extended Type ....................................... 6 2.2. Extended Type with Flags ............................ 7 2.3. TLV Data Type ....................................... 8 2.3.1. TLV Nesting .................................... 10 2.4. Naming and References ............................... 10 2.4.1. Attribute and TLV Naming ....................... 10 2.4.2. Attribute References ........................... 11 2.4.3. TLV References ................................. 11 3. Attribute Definitions .................................... 11 3.1. Attributes of Extended Type ......................... 12 3.2. Attributes of Extended Type With Flags .............. 12 4. Vendor Specific Attributes ............................... 12 4.1. Extended Type VSAs .................................. 13 4.2. Extended Type with Flag VSAs ........................ 14 5. Compatibility with traditional RADIUS .................... 14 5.1. Attribute Allocation ................................ 15 5.2. Proxy Servers ....................................... 15 6. Design Guidelines ........................................ 16 7. Examples ................................................. 16 7.1. Extended Type ....................................... 17 7.2. Extended Type with Flags ............................ 17 7.3. Extended Type with Flags, and "More" ................ 17 7.4. Extended Type with Flags, and a TLV ................. 18 7.5. Extended Type with Flags, and two TLVs .............. 18 7.6. Nested TLVs ......................................... 19 8. IANA Considerations ...................................... 19 8.1. Attribute Allocations ............................... 19 8.2. RADIUS Attribute Type Tree .......................... 20 8.3. Assignment Policy ................................... 20 8.4. Extending the Attribute Type Tree ................... 21 9. Security Considerations .................................. 21 10. References .............................................. 22 10.1. Normative references ............................... 22 10.2. Informative references ............................. 22 DeKok, Alan Informational [Page 3]
INTERNET-DRAFT RADIUS Extensions 1 September 2010 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. In addition, the attribute grouping method defined in [RFC2868] has limitations, and a more complex mechanism is needed. Finally, multiple attributes have been defined which transport more than 253 octets of data. Each of these attributes is handled as a "special case" inside of RADIUS implementations. We need a standardized method of transporting large quantities of data. We implement those requirements through the following design: * defining an "Extended Type" format, which adds 8 bits of "Extended Type" to the RADIUS Attribute Type space, but inserting one octet between the "Length" and "Value" fields of RADIUS Attributes. * allocating 4 attributes using the format of "Extended Type". This extends the RADIUS Attribute Type Space by approximately 1000 numbers. * defining an "Extended Type with Flags" format, which inserts an additional "Flags" octet between the "Extended Type" octet, and the "Value" field. * Defining a way use the "Flags" field to indicate data fragmentation across multiple Attributes * allocating 2 attributes using the format of "Extended Type with Flags". This extends the RADIUS Attribute Type Space by an additional 500 or so numbers. * Defining a new "Type Length Value" (TLV) data type. This data type allows an attribute to encapsulate "sub-attributes", which can in turn encapsulate "sub-sub-attributes" * permitting the new formats to carry the data type TLV. This extends the RADIUS Attribute Type space by over 200 numbers for each attribute which is defined to be of data type TLV * permitting As with any protocol change, the changes defined here are the result of a series of compromises. We have tried to find a balance between flexibility, and space in the RADIUS packet. DeKok, Alan Informational [Page 4]
INTERNET-DRAFT RADIUS Extensions 1 September 2010 1.1. Terminology This document uses the following terms: silently discard This means the implementation discards the packet without further processing. The implementation MAY provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter. 1.2. Requirements Language In this document, several words are used to signify the requirements of the specification. 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]. An implementation is not compliant if it fails to satisfy one or more 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". DeKok, Alan Informational [Page 5]
INTERNET-DRAFT RADIUS Extensions 1 September 2010 2. Extensions to RADIUS This section defines two new attribute formats; "Extended Type"; and "Extended Type with Flags". The formats are defined below. 2.1. Extended Type This section defines a new attribute format, called "Extended Type". It extends the Attribute Type space from 8 bits to more than 8 bits. A summary of the Attribute format is shown below. The fields are transmitted from left to right. 0 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 | Length | Extended-Type | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type This field is identical to the Type field of the Attribute format defined in [RFC2865] Section 5. Length This field is identical to the Length field of the Attribute format defined in [RFC2865] Section 5. Permitted values are between 4 and 255. Extended-Type The Extended-Type field is one octet. Unlike [RFC2865] Section 5, no values are defined for experimental, or implementation-specific use. Values 241-255 are reserved and should not be used. Value This field is similar to the Value field of the Attribute format defined in [RFC2865] Section 5. The format of the data SHOULD be a valid RADIUS data type. The addition of the Extended-Type field decreases the maximum length for attributes of type "text" or "string", to 252 octets. Otherwise, this field can be thought of as the Value field of the Attribute format defined in [RFC2865] Section 5, but moved by one octet. Experience has shown that the "experimental" and "implementation specific" attributes defined in [RFC2865] Section 5 have had little DeKok, Alan Informational [Page 6]
INTERNET-DRAFT RADIUS Extensions 1 September 2010 practical value. We therefore do not continue that practice here. 2.2. Extended Type with Flags This section defines a new attribute format, called "Extended Type with Flags". It leverages the "Extended Type" format in order to permit the transport of attributes encapsulating more than 253 octets of data. A summary of the Attribute format is shown below. The fields are transmitted from left to right. 0 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 | Length | Extended-Type |M| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type This field is identical to the Type field of the Attribute format defined in [RFC2865] Section 5. Length This field is identical to the Length field of the Attribute format defined in [RFC2865] Section 5. Permitted values are between 5 and 255. Extended-Type This field is identical to the Extended-Type field defined above in Section X.Y. M (More) The More Flag is one (1) bit in length, and indicates whether or not the current attribute contains "more" than 251 octets of data. The More flag MUST be clear (0) if the Length field has value less than 255. The More flag MAY be set (1) if the Length field has value of 255. If the More flag is set (1), it indicates that the Value field has been fragmented across multiple RADIUS attributes. In that case, each fragmenty will contain 251 octets of data; there MUST be an attribute following this one; that attribute MUST have both the same Type and Extended Type. That is, multiple fragments of the same value MUST be in order and MUST be consecutive attributes in DeKok, Alan Informational [Page 7]
INTERNET-DRAFT RADIUS Extensions 1 September 2010 the packet, and the last attribute in a packet MUST NOT have the More flag set (1). Flags This field is 7 bits long, and is reserved for future use. Implementations MUST set it to zero (0) when encoding an attribute for sending in a packet. The contents SHOULD be ignored on reception. Value This field is similar to the Value field of the Attribute format defined in [RFC2865] Section 5. It may contain a complete piece of data (when the Length field has value less than 255), or it may contain a fragment of data (when the More field is set). Any interpretation of the resulting data MUST occur after the fragments have been reassembled. The length of the data MUST be taken as the sum of the lengths of the fragments (i.e. Value fields) from which it is constructed. The format of the data SHOULD be a valid RADIUS data type. This definition increases the RADIUS Attribute Type space as above, but also provides for transport of Attributes which could contain more than 253 octets of data. 2.3. TLV Data Type We define a new data type in RADIUS, called "tlv". The "tlv" data type is an encapsulation layer which which permits the "Value" field of an Attribute to contain new sub-Attributes. These sub-Attributes can in turn contain "Value"s of data type TLV. This capability both extends the attribute space, and permits "nested" attributes to be used. This nesting can be used to encapsulate or group data into one or more logical containers. The "tlv" data type re-uses the RADIUS attribute format, as given below: 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV-Type | TLV-Length | TLV-Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV-Type DeKok, Alan Informational [Page 8]
INTERNET-DRAFT RADIUS Extensions 1 September 2010 The Type field is one octet. Up-to-date values of this field are specified by IANA. Values of zero (0) MUST NOT be used. Values 254-255 are "Reserved" for use by future extensions to RADIUS. TLV-Length The TLV-Length field is one octet, and indicates the length of this TLV including the TLV-Type, TLV-Length and TLV-Value fields. It MUST have a value between 3 and 255. If a server receives a TLV in a "request" packet from a client, but with an invalid TLV- Length, the server SHOULD respond with a "nak" packet. If a client receives a TLV in a "response" packet from a server, but with an invalid TLV-Length, the packet MUST either be treated as "nak" or else silently discarded. The above reference to a "request" packet means an Access-Request [RFC2865], Accounting-Request [RFC2866], CoA-Request [RFC5176], Disconnect-Request [RFC5176], or other any new packet codes sent from a client to server, as defined by later specifications. The reference to a "response" packet means the response packet corresponding to a request; Access-Accept, Access-Challenge, Access-Reject for Access-Request; Accounting-Response for Accounting-Request; CoA-ACK or CoA-NAK for CoA-Request; Disconnect-ACK or Disconnect-NAK for Disconnect-Request; or any other new packet codes sent from a server to client, as defined by later specifications. The reference to a "nak" packet means the "negative acknowledgement" response packet corresponding to a request; Access-Reject for Access-Request; CoA-NAK for CoA- Request; Disconnect-NAK for Disconnect-Request; or any other new "negative acknowledgement" packet codes sent from a server to client, as defined by later specifications. TLV-Value The Value field is one or more octets and contains information specific to the Attribute. The format and length of the TLV-Value field is determined by the TLV-Type and TLV-Length fields. The TLV-Value field will normally contain a RADIUS data type such as "text", "string", "integer", "address", "time", "IPv6 Address", etc. The TLV-Value field MAY also contain one or more attributes of data type "tlv", which allows for simple grouping, and multiple layers of nesting. The TLV-Value field is limited to containing 253 or fewer octets of data. Specifications which require a TLV to contain more than 253 octets of data are incompatible with RADIUS, and need to be redesigned. Specifications which require the transport of empty DeKok, Alan Informational [Page 9]
INTERNET-DRAFT RADIUS Extensions 1 September 2010 Values (i.e. Length = 2) are incomaptible with RADIUS, and need to be redesigned. The TLV-Value field SHOULD NOT contain data using the format of the Extended Attributes. The base Extended Attributes format allows for sufficient flexibility that nesting them offers little value. This definition is compatible with the suggested format of the "String" field of the Vendor-Specific attribute, as defined in [RFC2865] Section 5.26, though that specification does not discuss nesting. Vendors MAY use attributes of type "tlv" in any Vendor Specific Attribute. 2.3.1. TLV Nesting TLVs may contain other TLVs. When this occurs, the "container" TLV MUST be completely filled by one or more of the "contained" TLVs. That is, the "container" TLV-Length field MUST be exactly two (2) more than the sum of the "contained" TLV-Length fields. If the "contained" TLVs over-fill the "container" TLV, the packet MUST be considered to be malformed, and handled as described above. The depth of TLV nesting is limited only by the restrictions on the TLV-Length field. The limit of 253 octets of data results in a limit of 126 levels of nesting. However, nesting depths of more than 4 are NOT RECOMMENDED. 2.4. Naming and References Attributes have traditionally been referred to by name and number. For example, the User-Name attribute has been allocated number one (1). This naming scheme needs to be extended in order to be able to refer to attributes of Extended Type, and to TLVs. It will also be used by IANA for tracking and allocating RADIUS Attribute Types. These names and references are intended to be used only in specifications, and may not be useful when referring to the contents of a RADIUS packet. 2.4.1. Attribute and TLV Naming RADIUS specifications traditionally use names consisting of one or more words, separated by hyphens, e.g. "User-Name". However, these names are not allocated from a registry, and there is no restriction other than convention on their global uniqueness. DeKok, Alan Informational [Page 10]
INTERNET-DRAFT RADIUS Extensions 1 September 2010 We therefore RECOMMEND that specifications give names to Extended Types TLVs which attempt to be globally unique across all RADIUS Attributes. We recognise that this suggestion may be difficult to do in practice. 2.4.2. Attribute References The "Extended-Type" field defines 256 possible types, with values 1 through 240 available for allocation. This field is defined within a RADIUS Attribute "Type" space, and is best referred to in that context. We propose a naming scheme which uses a "dotted number" notation similar to that used for SNMP variables. For example, an attribute of format "Extended Type", allocated within the Type space of 241, and having an Extended-Type of one (1), should be referred to as "241.1". Similarly, an attribute of format "Extended Type with flags", allocated within the Type space of 246, having Extended-Type of ten (10), should be referred to as "246.10". 2.4.3. TLV References We can extend the Attribute reference scheme defined above for TLVs. This is done by leveraging the "dotted number" notation. As above, we define an additional TLV type space, within the "Extended Type" space, by appending another "dotted number" in order to refer to the TLV. This method can be replied in sequence for nested TLVs. For example, let us say that "245.1" refers to RADIUS attribute 245, containing an "Extended Type" of one (1), which is of type "tlv". That attribute will contain 256 possible TLVs, one for each value of the TLV-Type field. The first TLV-Type value of one (1) can then be referenced by appending a ".1" to the number of the encapsulating attribute ("241.1"), to yeild "245.1.1". Similarly, the sequence "245.2.3.4" refers to RADIUS attribute 245, containing an "Extended Type" of two (2) which is of type "tlv", which in turn contains a TLV with TLV-Type number three (3), which in turn contains another TLV, wth TLV-Type number four (4). 3. Attribute Definitions We now use the newly defined Attribute formats to define new attributes. In order to save space, we do not follow the traditional RADIUS specification method of showing the attribute format and giving detailed definitions for every field. Instead, we refer to the formats defined above, and give only the minimum information which defines the new attribute. DeKok, Alan Informational [Page 11]
INTERNET-DRAFT RADIUS Extensions 1 September 2010 3.1. Attributes of Extended Type We define four (4) attributes of "Extended Type", which are allocated from the "Reserved" attribute types: Type Name ---- ---- 241 Extended-Type-1 242 Extended-Type-2 243 Extended-Type-3 244 Extended-Type-4 The Type and Name fields are given above may also be used by implementations which have not been updated to support the new type. Such implementations SHOULD treat these attributes as being of type "string". We define four attributes of this type in order to extend the RADIUS Attribute Type Space by adding the capability for over 1000 new attributes. 3.2. Attributes of Extended Type With Flags We define four (4) attributes of "Extended Type", which are allocated from the "Reserved" attribute types: Type Name ---- ---- 245 Extended-Type-Flagged-1 246 Extended-Type-Flagged-2 The Type and Name fields are given above may also be used by implementations which have not been updated to support the new type. Such implementations SHOULD treat these attributes as being of type "string". We define two attributes of this type in order to further extend the RADIUS Attribute Type space by adding the capability for over 500 new attributes. 4. Vendor Specific Attributes We define six new attributes which can carry Vendor Specific information. The following table provides a guide as to the value of Type and Extended-Type fields for the VSAs, along with their names. Type Name ------ ---- DeKok, Alan Informational [Page 12]
INTERNET-DRAFT RADIUS Extensions 1 September 2010 241.26 Extended-Vendor-Specific-1 242.26 Extended-Vendor-Specific-2 243.26 Extended-Vendor-Specific-3 244.26 Extended-Vendor-Specific-4 245.26 Extended-Vendor-Specific-5 246.26 Extended-Vendor-Specific-6 When the recommended format is used, these definitions provide for over 1500 additional VSAs per vendor. These provisions should be sufficient for the forseeable future. 4.1. Extended Type VSAs The VSA format for attributes using the "Extended Type" is shown below. The fields are transmitted from left to right. 0 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 | Length | Extended-Type | Vendor-Id ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Vendor-Id | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Type, Length, and Extended-Type fields have the same definitions as above in Section X.Y. The Vendor-Id field is defined identically to the Vendor-Id field of [RFC2865] Section 5.26. The Length field MUST have a value between 8 and 255. The Value field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets. For maximum interoparability, vendors SHOULD use the format given below. Other Value formats are NOT RECOMMENDED. 0 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 | Length | Extended-Type | Vendor-Id ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Vendor-Id | Vendor-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the "Vendor-Type" field defines 255 possible VSAs, each being able to carry up to 247 octets of data. The attributes using this DeKok, Alan Informational [Page 13]
INTERNET-DRAFT RADIUS Extensions 1 September 2010 format SHOULD use a well-known RADIUS data type, and SHOULD NOT use the TLV data type. 4.2. Extended Type with Flag VSAs The VSA format for attributes using the "Extended Type" is shown below. The fields are transmitted from left to right. 0 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 | Length | Extended-Type |M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Type, Length, Extended-Type, M (More), and Reserved fields have the same definitions as above in Section X.Y. The Vendor-Id field is defined identically to the Vendor-Id field of [RFC2865] Section 5.26. The Length field MUST have a value between 9 and 255. The Value field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets. For maximum interoparability, vendors SHOULD use the format given below. Other Value formats are NOT RECOMMENDED. 0 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 | Length | Extended-Type |M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the "Vendor-Type" field defines 255 possible VSAs, each being able to carry more than 247 octets of data. The Value field MAY be of data type TLV. 5. Compatibility with traditional RADIUS There are a number of potential compatibility issues with traditional RADIUS. This section describes them. DeKok, Alan Informational [Page 14]
INTERNET-DRAFT RADIUS Extensions 1 September 2010 5.1. Attribute Allocation Some vendors have "self allocated" attributes from the "Reserved" space, for use as "ad hoc" Vendor Specific Attributes. This is not good practice, as noted in [GUIDELINES]. These vendor definitions conflict with all of the attributes in the RADIUS Attribute Type space. The result is that it may be difficult for implementations to support both those Vendor Attributes, and the new Extended Attribute formats. We RECOMMEND that RADIUS server implementations have a per-client configurable flag which indicates which type of attributes are being sent from the client. If the flag is set one way, the conflicting attributes can be interpreted as being "self allocated" by the vendor. If the flag is set the other way, the attributes MUST be interpreted as being of the Extended Attributes format. The default SHOULD be to interpret the attributes as being of the Extended Attributes format We do NOT RECOMMEND that servers implement "ad hoc" methods to determine how to interpret the attributes. These "ad hoc" methods will usually be fragile and prone to error. We RECOMMEND that RADIUS server implementations re-use the above flag to determine which type of attributes to send in a reply message. If the request is expected to contain the "self allocated" attributes, the reply SHOULD NOT contain Extended Attributes. If the request is expected to contain Extended Attributes, the reply MUST NOT contain "self allocated" attributes. RADIUS clients will have fewer issues than servers. Clients MUST NOT send "self allocated" attributes in a request. For replies, clients SHOULD interpret any conflicting attributes as being of the Extended Attributes format. 5.2. Proxy Servers We expect that RADIUS Proxy servers will need to forward the Extended Attributes, even if they do not support the new format. We remind implementors of the following text in [RFC2865] Section 2.3: The forwarding server MUST NOT change the order of any attributes of the same type, including Proxy-State. This requirement solves some of the issues related to proxying of the new format, but not all. The reason is that proxy servers are permitted to examine the contents of the packets that they forward. Many proxy implementations not only examine the attributes, but they DeKok, Alan Informational [Page 15]
INTERNET-DRAFT RADIUS Extensions 1 September 2010 refuse to forward attributes which they do not understand. This practice is NOT RECOMMENDED. Proxy servers SHOULD forward all attributes, even ones which they do not understand, or which are not in a local dictionary. The only exception to this recommendation is when local site policy dictates that filtering of attributes has to occur. For example, a filter at a visited network may require removal of certain authorization rules which apply to the home network, but not to the visited network. Practice has shown [EDUROAM] that many proxies do not follow recommended practices for unknown Attributes. Some proxies filter out unknown attributes or attributes which have unexpected lengths (17/70, 24%), some truncate the attributes to the "expected" length (8/70, 11%), some discard the request entirely (1/70, or 1%), with the rest (44/70, 63%) following the "best practice" of passing the attributes verbatim. It will be difficult to widely use the Extended Attributes format until the non-conformant proxies are fixed. We therefore RECOMMEND that all proxies which do not support the Extended Attributes (241 through 246) define them as being of type "string", and delete any "self allocated" definitions for those attributes. This change should enable wider usage of the Extended Attributes format. 6. Design Guidelines We recommend the following guidelines when designing attributes using the new format: * We still recommend caution when allocating attributes. The new space is much larger than the old one, but is not infinite. * when multiple attributes should be allocated as a logical group, using TLVs is RECOMMENDED. * more than 4-5 layers of TLVs is NOT RECOMMENDED. * TLVs which will never need more than 247 octets of data MAY be allocated from 241.*, 242.*, 243.*, or 244.*. TBD: add more text here. 7. Examples A few examples are presented to illustrate the encoding of the new attribute formats. These examples are not intended to be exhaustive, DeKok, Alan Informational [Page 16]
INTERNET-DRAFT RADIUS Extensions 1 September 2010 many others are possible. For simplicity, we do not show complete packets, only attributes. The examples are given first as hexadecimal dumps of the attributes in network byte order, with the attribute numbers underlined for clarity. These are followed by a set of rows which decode the hex dump, and show the number of octets in a field, the name of the field, and finally the value of the field. 7.1. Extended Type We show the encoding of an attribute using the format "Extended Attribute", numbered 241.1, encoding 4 octets of data. f1 07 01 aa bb cc dd -- -- 1 Type = 241 1 Length = 7 1 Extended-Type = 1 4 Value = 0xaabbccdd 7.2. Extended Type with Flags We show the encoding of an attribute using the format "Extended Attribute with Flags", numbered 245.1, encoding 4 octets of data. f5 08 01 00 aa bb cc dd -- -- 1 Type = 245 1 Length = 8 1 Extended-Type = 1 1 M (More) = 0 (unset) Flags = 0b0000000 4 Value = 0xaabbccdd 7.3. Extended Type with Flags, and "More" We show the encoding of an attribute using the format "Extended Attribute with Flags", numbered 245.2, encoding 256 octets of data. In this example, the data is split into two fragments. The first fragment contains 251 octets of data, and the second fragment contains 5 octets of data. f5 ff 02 80 aa ... -- -- f5 09 02 00 aa aa aa aa aa -- -- 1 Type = 245 1 Length = 255 1 Extended-Type = 2 DeKok, Alan Informational [Page 17]
INTERNET-DRAFT RADIUS Extensions 1 September 2010 1 M (More) = 1 (set) Flags = 0b0000000 251 Value = 0xaaaa... 1 Type = 245 1 Length = 8 1 M (More) = 1 (set) Flags = 0b0000000 1 Extended-Type = 2 5 Value = 0xaaaaaaaaaa 7.4. Extended Type with Flags, and a TLV We show the encoding of an attribute using the format "Extended Attribute with Flags", numbered 245.2, encoding a TLV of TLV-Type one (1), which in turn encapsulates 4 octets of data. That is, the attribute is numbered "245.3.1". f5 0a 03 00 01 06 aa bb cc dd -- -- -- 1 Type = 245 1 Length = 10 1 Extended-Type = 3 1 M (More) = 0 (unset) Flags = 0b0000000 1 TLV-Type = 1 1 TLV-Length = 6 4 Value = 0xaabbccdd 7.5. Extended Type with Flags, and two TLVs We show the encoding of an attribute using the format "Extended Attribute with Flags", numbered 245.2, encoding a TLV of TLV-Type one (1), which in turn encapsulates 4 octets of data. A second TLV of TLV-Type two (2) with 4 octets of data is also encapsulated in the parent attribute. f5 10 03 00 01 06 aa bb cc dd 02 06 66 77 88 99 -- -- -- -- 1 Type = 245 1 Length = 16 1 Extended-Type = 3 1 M (More) = 0 (unset) Flags = 0b0000000 1 TLV-Type = 1 1 TLV-Length = 6 4 Value = 0xaabbccdd 1 TLV-Type = 2 DeKok, Alan Informational [Page 18]
INTERNET-DRAFT RADIUS Extensions 1 September 2010 1 TLV-Length = 6 4 Value = 0x66778899 7.6. Nested TLVs We show the encoding of an Extended Attribute with Flags, numbered 245.4, encoding a TLV of TLV-Type two (2), which in turn encapsulates a TLV of TLV-type three (3), which encapsulates 4 octets of data. That is, the attribute is numbered as "245.4.2.3". f5 0c 04 00 02 08 03 06 aa bb cc dd -- -- -- -- 1 Type = 245 1 Length = 12 1 Extended-Type = 4 1 M (More) = 0 (unset) Flags = 0b0000000 1 TLV-Type = 2 1 TLV-Length = 8 1 nested TLV-Type = 3 1 nested TLV-Length = 6 4 Value = 0xaabbccdd 8. IANA Considerations This document has multiple impacts on IANA, in the "RADIUS Attribute Types" registry. Attribute types which were previously reserved are now allocated, and the registry is extended from a simple 8-bit array to a tree-like structure, up to a maximum depth of 125. Once this specification is published, IANA is requested to prefer allocations from the extended type space, rather than from the original type space. This is, allocations from the RADIUS Attribute Type space in the range 1 to 255 SHOULD NOT be performed. Allocations SHOULD instead be taken from the extended type space, starting with lower numbered attributes. 8.1. Attribute Allocations IANA is requested to move the following numbers from "Reserved", to allocated, with the following names: * 241 Extended-Type-1 * 242 Extended-Type-2 * 243 Extended-Type-3 * 244 Extended-Type-4 * 245 Extended-Type-Flagged-1 * 246 Extended-Type-Flagged-2 These attributes serve as an encapsulation layer for the new RADIUS DeKok, Alan Informational [Page 19]
INTERNET-DRAFT RADIUS Extensions 1 September 2010 Attribute Type tree. 8.2. RADIUS Attribute Type Tree Each attribute allocated above extends the "RADIUS Attribute Types" to an N-ary tree, via a "dotted number" notation. Each number in the tree is an 8-bit value (1 to 255). The value zero (0) MUST NOT be used. Currently, only one level of the tree is defined: * 241.{1-25} Unassigned * 241.26 Extended-Vendor-Specific-1 * 241.{27-240} Unassigned * 241.{241-255} Reserved * 242.{1-25} Unassigned * 242.26 Extended-Vendor-Specific-2 * 242.{27-240} Unassigned * 242.{241-255} Reserved * 243.{1-25} Unassigned * 243.26 Extended-Vendor-Specific-3 * 243.{27-240} Unassigned * 243.{241-255} Reserved * 244.{1-25} Unassigned * 244.26 Extended-Vendor-Specific-4 * 244.{27-240} Unassigned * 244.{241-255} Reserved * 245.{1-25} Unassigned * 245.26 Extended-Vendor-Specific-5 * 245.{27-240} Unassigned * 245.{241-255} Reserved * 246.{1-25} Unassigned * 245.26 Extended-Vendor-Specific-6 * 246.{27-240} Unassigned * 246.{241-255} Reserved The values marked "Unassigned" above are available for assignment by IANA in future RADIUS specifications. The values marked "Reserved" are reserved for future use. 8.3. Assignment Policy In general, attributes MUST be assigned starting with the lowest unassigned number. e.g. 241.1, then 241.2, etc. Attributes of type "tlv" MUST NOT be assigned from the type spaces 241.*, 242.*, 243.*, or 244.*. Attributes which are expected to transport more than 252 octets of data MUST be assigned from the 245.* or 246.* space, again using the lowest unassined number. Specifications defining a TLV attribute or attribute which can carry more than 252 octets of data MUST request assignment from the appropriate Attribute Type Space. All other attributes (non-TLV types, and types which are known to DeKok, Alan Informational [Page 20]
INTERNET-DRAFT RADIUS Extensions 1 September 2010 require 252 octets or less of data) MUST be assigned from the lowest unassigned number. 8.4. Extending the Attribute Type Tree New specifications may request that the tree be extended to an additional level or levels. The attribute MUST be of type "tlv". For example, a specification may request that an "Example-TLV" attribute be assigned, of data type "tlv". If it is assigned the number 245.1, then it will define an extension to the registry as follows: * 245.1 Example-TLV * 245.1.{1-253} Unassigned * 245.1.{254-255} Reserved Note that this example does not define an "Example-TLV" attribute. The number zero (0) MUST NOT be used. The last two numbers (254 and 255) MUST be reserved for future use. All other numbers are available for assignment by IANA. The Attribute Type Tree can be extended multiple levels in one specification. For example, the "Example-TLV" above could contain another attribute, "Example-Nested-TLV", of type "tlv". It would define an additional extension to the registry as follows: * 245.1.1 Example-Nested-TLV * 245.1.1.{1-253} Unassigned * 245.1.1.{254-255} Reserved This process may be continued to additional levels of nesting. Again, this example does not define an "Example-Nested-TLV" attribute. 9. Security Considerations This document defines new formats for data carried inside of RADIUS, but otherwise makes no changes to the security of the RADIUS protocol. Attacks on cryptographic hashes are well known, and are getting better with time, as discussed in[RFC4270]. RADIUS uses the MD5 hash [RFC1321] for packet authentication and attribute obfuscation. There are ongoing efforts in the IETF to analyze and address these issues for the RADIUS protocol. As with any protocol change, code changes are required in order to DeKok, Alan Informational [Page 21]
INTERNET-DRAFT RADIUS Extensions 1 September 2010 implement the new features. These code changes have the potential to introduce new vulnerabilities in the software. Since the RADIUS server performs network authentication, it is an inviting target for attackers. We RECOMMEND that end user access (network or otherwise) to RADIUS servers be kept to a minimum. 10. References 10.1. Normative references [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, April, 1992 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", 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. 10.2. Informative references [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2868] Zorn, G., et al, " RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. [RFC4270] Hoffman, P, and Schneier, B, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005. [RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008. [GUIDELINES] DeKok, A., and Weber, G., "RADIUS Design Guidelines", draft- ietf-radext-design-16.txt, work in progress. [EDUROAM] Internal Eduroam testing page, data retrieved 04 August 2010. Acknowledgments This document is the result of long discussions in the IETF RADEXT working group. The authors would like to thank all of the participants who contributed various ideas over the years. Their feedback has been invaluable, and has helped to make this specification better. DeKok, Alan Informational [Page 22]
INTERNET-DRAFT RADIUS Extensions 1 September 2010 Author's Address Alan DeKok Network RADIUS SARL 15 av du Granier 38240 Meylan France Email: aland@networkradius.com URI: http://networkradius.com Avi Lior Bridgewater Systems Corporation 303 Terry Fox Drive Suite 100 Ottawa, Ontario K2K 3J1 Canada Phone: +1 (613) 591-6655 Email: avi@bridgewatersystems.com URI: http://www.bridgewatersystems.com/ DeKok, Alan Informational [Page 23]