diff options
Diffstat (limited to 'doc/rfc/rfc6929.txt')
| -rw-r--r-- | doc/rfc/rfc6929.txt | 3811 |
1 files changed, 3811 insertions, 0 deletions
diff --git a/doc/rfc/rfc6929.txt b/doc/rfc/rfc6929.txt new file mode 100644 index 0000000..e9e8968 --- /dev/null +++ b/doc/rfc/rfc6929.txt @@ -0,0 +1,3811 @@ + + + + + + +Internet Engineering Task Force (IETF) A. DeKok +Request for Comments: 6929 Network RADIUS +Updates: 2865, 3575, 6158 A. Lior +Category: Standards Track April 2013 +ISSN: 2070-1721 + + Remote Authentication Dial-In User Service (RADIUS) + Protocol Extensions + +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 that can carry more than 253 octets of data. This + document defines changes to RADIUS that address all of the above + problems. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6929. + +Copyright Notice + + 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 & Lior Standards Track [Page 1] + +RFC 6929 RADIUS Extensions April 2013 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Caveats and Limitations ....................................5 + 1.1.1. Failure to Meet Certain Goals .......................5 + 1.1.2. Implementation Recommendations ......................5 + 1.2. Terminology ................................................6 + 1.3. Requirements Language ......................................7 + 2. Extensions to RADIUS ............................................7 + 2.1. Extended Type ..............................................8 + 2.2. Long Extended Type .........................................9 + 2.3. TLV Data Type .............................................12 + 2.3.1. TLV Nesting ........................................14 + 2.4. EVS Data Type .............................................14 + 2.5. Integer64 Data Type .......................................16 + 2.6. Vendor-Id Field ...........................................16 + 2.7. Attribute Naming and Type Identifiers .....................17 + 2.7.1. Attribute and TLV Naming ...........................17 + 2.7.2. Attribute Type Identifiers .........................18 + 2.7.3. TLV Identifiers ....................................18 + 2.7.4. VSA Identifiers ....................................18 + 2.8. Invalid Attributes ........................................19 + 3. Attribute Definitions ..........................................21 + 3.1. Extended-Type-1 ...........................................21 + 3.2. Extended-Type-2 ...........................................22 + 3.3. Extended-Type-3 ...........................................23 + 3.4. Extended-Type-4 ...........................................24 + 3.5. Long-Extended-Type-1 ......................................25 + 3.6. Long-Extended-Type-2 ......................................26 + 4. Vendor-Specific Attributes .....................................27 + 4.1. Extended-Vendor-Specific-1 ................................28 + 4.2. Extended-Vendor-Specific-2 ................................29 + 4.3. Extended-Vendor-Specific-3 ................................30 + 4.4. Extended-Vendor-Specific-4 ................................31 + 4.5. Extended-Vendor-Specific-5 ................................32 + 4.6. Extended-Vendor-Specific-6 ................................34 + 5. Compatibility with Traditional RADIUS ..........................35 + 5.1. Attribute Allocation ......................................35 + 5.2. Proxy Servers .............................................36 + + + + + + + + + + + + +DeKok & Lior Standards Track [Page 2] + +RFC 6929 RADIUS Extensions April 2013 + + + 6. Guidelines .....................................................37 + 6.1. Updates to RFC 6158 .......................................37 + 6.2. Guidelines for Simple Data Types ..........................38 + 6.3. Guidelines for Complex Data Types .........................38 + 6.4. Design Guidelines for the New Types .......................39 + 6.5. TLV Guidelines ............................................40 + 6.6. Allocation Request Guidelines .............................40 + 6.7. Allocation Request Guidelines for TLVs ....................41 + 6.8. Implementation Guidelines .................................42 + 6.9. Vendor Guidelines .........................................42 + 7. Rationale for This Design ......................................42 + 7.1. Attribute Audit ...........................................43 + 8. Diameter Considerations ........................................44 + 9. Examples .......................................................44 + 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 ..................................52 + 10.3.1. Requested Allocation from the Standard Space ......52 + 10.3.2. Requested Allocation from the Short + Extended Space ....................................52 + 10.3.3. Requested Allocation from the Long + Extended Space ....................................52 + 10.3.4. Allocation Preferences ............................52 + 10.3.5. Extending the Type Space via the 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 + 13. Acknowledgments ...............................................55 + Appendix A. Extended Attribute Generator Program ..................56 + +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 that 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 + + + +DeKok & Lior Standards Track [Page 3] + +RFC 6929 RADIUS Extensions April 2013 + + + 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 more functionality to + the protocol (Section 2.2). + + * Defining a method that 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. This 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 (Section 2.3). + + * Defining a new "Extended-Vendor-Specific" (EVS) data type. This + data type allows an attribute to carry Vendor-Specific Attributes + (VSAs) inside of the new Attribute formats (Section 2.4). + + * Defining a new "integer64" data type. This data type allows + counters that track more than 2^32 octets of data (Section 2.5). + + * Allocating 6 attributes using the new EVS data type. This + allocation extends the Vendor-Specific Attribute Type space by over + 1500 values (Sections 4.1 through 4.6). + + + + +DeKok & Lior Standards Track [Page 4] + +RFC 6929 RADIUS Extensions April 2013 + + + * Defining the "Vendor-Id" for Vendor-Specific Attributes to + encompass the entire 4 octets of the Vendor field. [RFC2865] + Section 5.26 defined it to be 3 octets, with the fourth octet being + zero (Section 2.6). + + * Describing compatibility with existing RADIUS systems (Section 5). + + * Defining guidelines for the use of these changes for IANA, + implementations of this specification, and for future RADIUS + specifications (Section 6). + + 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, space in the RADIUS message, compatibility with existing + deployments, and difficulty of implementation. + +1.1. Caveats and Limitations + + This section describes some caveats and limitations of the proposal. + +1.1.1. Failure to Meet Certain Goals + + One goal that was not met by the above modifications is to have an + incentive for standards to use the new space. That incentive is + being provided by the exhaustion of the standard space. + +1.1.2. Implementation Recommendations + + It is RECOMMENDED that implementations support this specification. + It is RECOMMENDED that new specifications use the formats defined in + this specification. + + The alternative to the above recommendations is a circular argument + of not implementing this specification because no other standards + reference it, and also not defining new standards referencing this + specification because no implementations exist. + + As noted earlier, the standard space is almost entirely allocated. + Ignoring the looming crisis benefits no one. + + + + + + + + + + + + +DeKok & Lior Standards Track [Page 5] + +RFC 6929 RADIUS Extensions April 2013 + + +1.2. 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. + + Invalid attribute + + This means that the Length field of an Attribute is valid (as per + [RFC2865], Section 5, top of page 25) but the contents of the + Attribute do not follow the correct format, for example, an + Attribute of type "address" that encapsulates more than four, or + less than four, octets of data. See Section 2.8 for a more + complete definition. + + Standard space + + This refers to codes in the RADIUS Attribute Type space that are + allocated by IANA and that follow the format defined in Section 5 + of [RFC2865]. + + Extended space + + This refers to codes in the RADIUS Attribute Type space that + require the extensions defined in this document and are an + extension of the standard space, but that cannot be represented + within the standard space. + + Short extended space + + This refers to codes in the extended space that use the "Extended + Type" format. + + Long extended space + + This refers to codes in the extended space that use the "Long + Extended Type" format. + + The following terms are used here with the meanings defined in BCP 26 + [RFC5226]: "namespace", "assigned value", "registration", "Private + Use", "Reserved", "Unassigned", "IETF Review", and "Standards + Action". + + + +DeKok & Lior Standards Track [Page 6] + +RFC 6929 RADIUS Extensions April 2013 + + +1.3. 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]. + +2. Extensions to RADIUS + + This section defines two new Attribute formats: "Extended Type" and + "Long Extended Type". It defines a new Type-Length-Value (TLV) data + type, an Extended-Vendor-Specific (EVS) data type, and an Integer64 + data type. It defines a new method for naming attributes and + identifying Attributes using the new Attribute formats. It finally + defines the new term "invalid attribute" and describes how it affects + implementations. + + The new Attribute formats are designed to be compatible with the + Attribute format given in [RFC2865] Section 5. The meaning and + interpretation of the Type and Length fields are unchanged from that + specification. This reuse allows the new formats to be compatible + with RADIUS implementations that do not implement this specification. + Those implementations can simply ignore the "Value" field of an + attribute or forward it verbatim. + + The changes to the Attribute format come about by "stealing" one or + more octets from the "Value" field. This change has the effect that + the "Value" field of [RFC2865] Section 5 contains both the new octets + given here and any attribute-specific Value. The result is that + "Value"s in this specification are limited to less than 253 octets in + size. This limitation is overcome through the use of the "Long + Extended Type" format. + + We reiterate that the formats given in this document do not insert + new data into an attribute. Instead, we "steal" one octet of Value, + so that the definition of the Length field remains unchanged. The + new Attribute formats are designed to be compatible with the + Attribute format given in [RFC2865] Section 5. The meaning and + interpretation of the Type and Length fields is unchanged from that + specification. This reuse allows the new formats to be compatible + with RADIUS implementations that do not implement this specification. + Those implementations can simply ignore the "Value" field of an + attribute or forward it verbatim. + + + + + + + +DeKok & Lior Standards Track [Page 7] + +RFC 6929 RADIUS Extensions April 2013 + + +2.1. Extended Type + + This section defines a new Attribute format, called "Extended Type". + 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 + + The Length field is one octet and indicates the length of this + Attribute, including the Type, Length, "Extended-Type", and + "Value" fields. Permitted values are between 4 and 255. If a + client or server receives an Extended Attribute with a Length of 2 + or 3, then that Attribute MUST be considered to be an "invalid + attribute" and handled as per Section 2.8, below. + + Extended-Type + + The Extended-Type field is one octet. Up-to-date values of this + field are specified according to the policies and rules described + in Section 10. Unlike the Type field defined in [RFC2865] + Section 5, no values are allocated for experimental or + implementation-specific use. Values 241-255 are reserved and MUST + NOT be used. + + The Extended-Type is meaningful only within a context defined by + the Type field. That is, this field may be thought of as defining + a new type space of the form "Type.Extended-Type". See + Section 3.5, below, for additional discussion. + + A RADIUS server MAY ignore Attributes with an unknown + "Type.Extended-Type". + + A RADIUS client MAY ignore Attributes with an unknown + "Type.Extended-Type". + + + + + + +DeKok & Lior Standards Track [Page 8] + +RFC 6929 RADIUS Extensions April 2013 + + + Value + + This field is similar to the "Value" field of the Attribute format + defined in [RFC2865] Section 5. The format of the data MUST be a + valid RADIUS data type. + + The "Value" field is one or more octets. + + Implementations supporting this specification MUST use the + identifier of "Type.Extended-Type" to determine the interpretation + of the "Value" field. + + The addition of the Extended-Type field decreases the maximum + length for attributes of type "text" or "string" from 253 to + 252 octets. Where an Attribute needs to carry more than + 252 octets of data, the "Long Extended Type" format MUST be used. + + Experience has shown that the "experimental" and "implementation- + specific" attributes defined in [RFC2865] Section 5 have had little + practical value. We therefore do not continue that practice here + with the Extended-Type field. + +2.2. Long Extended Type + + This section defines a new Attribute format, called "Long Extended + Type". 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| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + This field is identical to the Type field of the Attribute format + defined in [RFC2865] Section 5. + + Length + + The Length field is one octet and indicates the length of this + Attribute, including the Type, Length, Extended-Type, and "Value" + fields. Permitted values are between 5 and 255. If a client or + + + +DeKok & Lior Standards Track [Page 9] + +RFC 6929 RADIUS Extensions April 2013 + + + server receives a "Long Extended Type" with a Length of 2, 3, or + 4, then that Attribute MUST be considered to be an "invalid + attribute" and handled as per Section 2.8, below. + + Note that this Length is limited to the length of this fragment. + There is no field that gives an explicit value for the total size + of the fragmented attribute. + + Extended-Type + + This field is identical to the Extended-Type field defined above + in Section 2.1. + + M (More) + + The More field is one (1) bit in length and indicates whether or + not the current attribute contains "more" than 251 octets of data. + The More field MUST be clear (0) if the Length field has a value + of less than 255. The More field MAY be set (1) if the Length + field has a value of 255. + + If the More field is set (1), it indicates that the "Value" field + has been fragmented across multiple RADIUS attributes. When the + More field is set (1), the Attribute MUST have a Length field of + value 255, there MUST be an attribute following this one, and the + next 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 the packet, and the last + attribute in a packet MUST NOT have the More field set (1). + + That is, a packet containing a fragmented attribute needs to + contain all fragments of the Attribute, and those fragments need + to be contiguous in the packet. RADIUS does not support + inter-packet fragmentation, which means that fragmenting an + attribute across multiple packets is impossible. + + If a client or server receives an attribute fragment with the + "More" field set (1) but for which no subsequent fragment can be + found, then the fragmented attribute is considered to be an + "invalid attribute" and handled as per Section 2.8, below. + + Reserved + + 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. + + + + +DeKok & Lior Standards Track [Page 10] + +RFC 6929 RADIUS Extensions April 2013 + + + Future specifications may define additional meaning for this + field. Implementations therefore MUST NOT treat this field as + invalid if it is non-zero. + + Value + + This field is similar to the "Value" field of the Attribute format + defined in [RFC2865] Section 5. It may contain a complete set of + data (when the Length field has a value of less than 255), or it + may contain a fragment of data. + + The "Value" field is one or more octets. + + Implementations supporting this specification MUST use the + identifier of "Type.Extended-Type" to determine the interpretation + of the "Value" field. + + 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. If the reassembled data does + not match the expected format, all fragments MUST be treated as + "invalid attributes", and the reassembled data MUST be discarded. + + We note that the maximum size of a fragmented attribute is limited + only by the RADIUS packet length limitation (i.e., 4096 octets, + not counting various headers and overhead). Implementations MUST + be able to handle the case where one fragmented attribute + completely fills the packet. + + This definition increases the RADIUS Attribute Type space as above + but also provides for transport of Attributes that could contain more + than 253 octets of data. + + Note that [RFC2865] Section 5 says: + + If multiple Attributes with the same Type are present, the order + of Attributes with the same Type MUST be preserved by any proxies. + The order of Attributes of different Types is not required to be + preserved. A RADIUS server or client MUST NOT have any + dependencies on the order of attributes of different types. A + RADIUS server or client MUST NOT require attributes of the same + type to be contiguous. + + These requirements also apply to the "Long Extended Type" Attribute, + including fragments. Implementations MUST be able to process + non-contiguous fragments -- that is, fragments that are mixed + + + +DeKok & Lior Standards Track [Page 11] + +RFC 6929 RADIUS Extensions April 2013 + + + together with other attributes of a different Type. This will allow + them to accept packets, so long as the Attributes can be correctly + decoded. + +2.3. TLV Data Type + + We define a new data type in RADIUS, called "tlv". The "tlv" data + type is an encapsulation layer that 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 reuses 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 + + The TLV-Type field is one octet. Up-to-date values of this field + are specified according to the policies and rules described in + Section 10. Values 254-255 are "Reserved" for use by future + extensions to RADIUS. The value 26 has no special meaning and + MUST NOT be treated as a Vendor-Specific Attribute. + + As with the Extended-Type field defined above, the TLV-Type is + meaningful only within the context defined by "Type" fields of the + encapsulating Attributes. That is, the field may be thought of as + defining a new type space of the form + "Type.Extended-Type.TLV-Type". Where TLVs are nested, the type + space is of the form "Type.Extended-Type.TLV-Type.TLV-Type", etc. + + A RADIUS server MAY ignore Attributes with an unknown "TLV-Type". + + A RADIUS client MAY ignore Attributes with an unknown "TLV-Type". + + A RADIUS proxy SHOULD forward Attributes with an unknown + "TLV-Type" verbatim. + + + + + + + +DeKok & Lior Standards Track [Page 12] + +RFC 6929 RADIUS Extensions April 2013 + + + 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 client or server + receives a TLV with an invalid TLV-Length, then the Attribute that + encapsulates that TLV MUST be considered to be an "invalid + attribute" and handled as per Section 2.8, below. + + TLV-Value + + The TLV-Value field is one or more octets and contains information + specific to the Attribute. The format and length of the TLV-Value + field are determined by the TLV-Type and TLV-Length fields. + + The TLV-Value field SHOULD encapsulate a standard RADIUS data + type. Non-standard data types SHOULD NOT be used within TLV-Value + fields. We note that the TLV-Value field MAY also contain one or + more attributes of data type TLV; data type TLV allows for simple + grouping and multiple layers of nesting. + + The TLV-Value field is limited to containing 253 or fewer octets + of data. Specifications that require a TLV to contain more than + 253 octets of data are incompatible with RADIUS and need to be + redesigned. Specifications that require the transport of empty + "Value"s (i.e., Length = 2) are incompatible with RADIUS and need + to be redesigned. + + The TLV-Value field MUST NOT contain data using the "Extended + Type" formats defined in this document. The base Extended + Attributes format allows for sufficient flexibility that nesting + them inside of a TLV offers little additional value. + + This TLV 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. It is RECOMMENDED to use type "TLV" for VSAs, in + preference to any other format. + + If multiple TLVs with the same TLV-Type are present, the order of + TLVs with the same TLV-Type MUST be preserved by any proxies. The + order of TLVs of different TLV-Types is not required to be preserved. + A RADIUS server or client MUST NOT have any dependencies on the order + of TLVs of different TLV-Types. A RADIUS server or client MUST NOT + require TLVs of the same TLV-Type to be contiguous. + + + +DeKok & Lior Standards Track [Page 13] + +RFC 6929 RADIUS Extensions April 2013 + + + The interpretation of multiple TLVs of the same TLV-Type MUST be that + of a logical "and", unless otherwise specified. That is, multiple + TLVs are interpreted as specifying an unordered set of values. + Specifications SHOULD NOT define TLVs to be interpreted as a logical + "or". Doing so would mean that a RADIUS client or server would make + an arbitrary and non-deterministic choice among the values. + +2.3.1. TLV Nesting + + TLVs may contain other TLVs. When this occurs, the "container" TLV + MUST be completely filled by 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 + overfill the "container" TLV, the "container" TLV MUST be considered + to be an "invalid attribute" and handled as described in Section 2.8, + below. + + 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. They have not been demonstrated to be necessary in + practice, and they appear to make implementations more complex. + Reception of packets with such deeply nested TLVs may indicate + implementation errors or deliberate attacks. Where implementations + do not support deep nesting of TLVs, it is RECOMMENDED that the + unsupported layers are treated as "invalid attributes". + +2.4. EVS Data Type + + We define a new data type in RADIUS, called "evs", for "Extended- + Vendor-Specific". The "evs" data type is an encapsulation layer that + permits the EVS-Value field of an Attribute to contain a Vendor-Id, + followed by an EVS-Type, and then vendor-defined data. This data can + in turn contain valid RADIUS data types or any other data as + determined by the vendor. + + This data type is intended for use in attributes that carry vendor- + specific information, as is done with the Vendor-Specific Attribute + (Attribute number 26). It is RECOMMENDED that this data type be used + by a vendor only when the Vendor-Specific Attribute Type space has + been fully allocated. + + Where [RFC2865] Section 5.26 makes a recommendation for the format of + the data following the Vendor-Id, we give a strict definition. + Experience has shown that many vendors have not followed the + [RFC2865] recommendations, leading to interoperability issues. We + hope here to give vendors sufficient flexibility as to meet their + needs while minimizing the use of non-standard VSA formats. + + + +DeKok & Lior Standards Track [Page 14] + +RFC 6929 RADIUS Extensions April 2013 + + + The "evs" data type MAY be used in Attributes having the format of + "Extended Type" or "Long Extended Type". It MUST NOT be used in any + other Attribute definition, including standard RADIUS attributes, + TLVs, and VSAs. + + A summary of the "evs" data type 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Id | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | EVS-Type | EVS-Value .... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Id + + The 4 octets of the Vendor-Id field are the Network Management + Private Enterprise Code [PEN] of the vendor in network byte order. + + EVS-Type + + The EVS-Type field is one octet. Values are assigned at the sole + discretion of the vendor. + + EVS-Value + + The EVS-Value field is one or more octets. It SHOULD encapsulate + a standard RADIUS data type. Using non-standard data types is NOT + RECOMMENDED. We note that the EVS-Value field may be of data type + TLV. However, it MUST NOT be of data type "evs", as the use cases + are unclear for one vendor delegating Attribute Type space to + another vendor. + + The actual format of the information is site or application + specific, and a robust implementation SHOULD support the field as + undistinguished octets. While we recognize that vendors have + complete control over the contents and format of the EVS-Value + field, we recommend that good practices be followed. + + Further codification of the range of allowed usage of this field + is outside the scope of this specification. + + Note that unlike the format described in [RFC2865] Section 5.26, this + data type has no "Vendor-Length" field. The length of the EVS-Value + field is implicit and is determined by taking the "Length" of the + encapsulating RADIUS attribute and then subtracting the length of the + + + +DeKok & Lior Standards Track [Page 15] + +RFC 6929 RADIUS Extensions April 2013 + + + Attribute header (2 octets), the "Extended Type" (1 octet), the + Vendor-Id (4 octets), and the EVS-Type (1 octet). That is, for + "Extended Type" Attributes the length of the EVS-Value field is eight + (8) less than the value of the Length field, and for "Long Extended + Type" Attributes the length of the EVS-Value field is nine (9) less + than the value of the Length field. + +2.5. Integer64 Data Type + + We define a new data type in RADIUS, called "integer64", which + carries a 64-bit unsigned integer in network byte order. + + This data type is intended to be used in any situation where there is + a need to have counters that can count past 2^32. The expected use + of this data type is within Accounting-Request packets, but this data + type SHOULD be used in any packet where 32-bit integers are expected + to be insufficient. + + The "integer64" data type can be used in Attributes of any format, + standard space, extended attributes, TLVs, and VSAs. + + A summary of the "integer64" data type 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Attributes having data type "integer64" MUST have the relevant Length + field set to eight more than the length of the Attribute header. For + standard space Attributes and TLVs, this means that the Length field + MUST be set to ten (10). For "Extended Type" Attributes, the Length + field MUST be set to eleven (11). For "Long Extended Type" + Attributes, the Length field MUST be set to twelve (12). + +2.6. Vendor-Id Field + + We define the Vendor-Id field of Vendor-Specific Attributes + to encompass the entire 4 octets of the Vendor field. + [RFC2865] Section 5.26 defined it to be 3 octets, with the fourth + octet being zero. This change has no immediate impact on RADIUS, as + the maximum Private Enterprise Code defined is still within 16 bits. + + + + + +DeKok & Lior Standards Track [Page 16] + +RFC 6929 RADIUS Extensions April 2013 + + + However, it is best to make advance preparations for changes in the + protocol. As such, it is RECOMMENDED that all implementations + support four (4) octets for the Vendor-Id field, instead of + three (3). + +2.7. Attribute Naming and Type Identifiers + + Attributes have traditionally been identified by a unique name and + number. For example, the Attribute "User-Name" has been allocated + number one (1). This 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 allocating RADIUS Attribute Type values. + + The names and identifiers given here are intended to be used only in + specifications. The system presented here may not be useful when + referring to the contents of a RADIUS packet. It imposes no + requirements on implementations, as implementations are free to + reference RADIUS attributes via any method they choose. + +2.7.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. + + Similarly, vendors have often used their company name as the prefix + for VSA names, though this practice is not universal. For example, + for a vendor named "Example", the name "Example-Attribute-Name" + SHOULD be used instead of "Attribute-Name". The second form can + conflict with attributes from other vendors, whereas the first form + cannot. + + It is therefore RECOMMENDED that specifications give names to + Attributes that attempt to be globally unique across all RADIUS + Attributes. It is RECOMMENDED that a vendor use its name as a unique + prefix for attribute names, e.g., Livingston-IP-Pool instead of + IP-Pool. It is RECOMMENDED that implementations enforce uniqueness + on names; not doing so would lead to ambiguity and problems. + + We recognize that these suggestions may sometimes be difficult to + implement in practice. + + TLVs SHOULD be named with a unique prefix that is shared among + related attributes. For example, a specification that defines a set + of TLVs related to time could create attributes called "Time-Zone", + "Time-Day", "Time-Hour", "Time-Minute", etc. + + + + +DeKok & Lior Standards Track [Page 17] + +RFC 6929 RADIUS Extensions April 2013 + + +2.7.2. Attribute Type Identifiers + + The RADIUS Attribute Type space defines a context for a particular + "Extended-Type" field. The "Extended-Type" field allows for 256 + possible type code values, with values 1 through 240 available for + allocation. We define here an identification method that uses a + "dotted number" notation similar to that used for Object Identifiers + (OIDs), formatted as "Type.Extended-Type". + + For example, an attribute within the Type space of 241, having + Extended-Type of one (1), is uniquely identified as "241.1". + Similarly, an attribute within the Type space of 246, having + Extended-Type of ten (10), is uniquely identified as "246.10". + +2.7.3. TLV Identifiers + + 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 identify the + TLV. This method can be repeated in sequence for nested TLVs. + + For example, let us say that "245.1" identifies RADIUS Attribute Type + 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 identified by appending a ".1" to the number of the + encapsulating attribute ("241.1"), to yield "241.1.1". Similarly, + the sequence "245.2.3.4" identifies 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, with TLV-Type number four (4). + +2.7.4. VSA Identifiers + + There has historically been no method for numerically addressing + VSAs. The "dotted number" method defined here can also be leveraged + to create such an addressing scheme. However, as the VSAs are + completely under the control of each individual vendor, this section + provides a suggested practice but does not define a standard of any + kind. + + The Vendor-Specific Attribute has been assigned the Attribute + number 26. It in turn carries a 32-bit Vendor-Id, and possibly + additional VSAs. Where the VSAs follow the format recommended + by [RFC2865] Section 5.26, a VSA can be identified as + "26.Vendor-Id.Vendor-Type". + + + + +DeKok & Lior Standards Track [Page 18] + +RFC 6929 RADIUS Extensions April 2013 + + + For example, Livingston has Vendor-Id 307 and has defined an + attribute "IP-Pool" as number 6. This VSA can be uniquely identified + as 26.307.6, but it cannot be uniquely identified by name, as other + vendors may have used the same name. + + Note that there are few restrictions on the size of the numerical + values in this notation. The Vendor-Id is a 32-bit number, and the + VSA may have been assigned from a 16-bit Vendor-Specific Attribute + Type space. Implementations SHOULD be capable of handling 32-bit + numbers at each level of the "dotted number" notation. + + For example, the company USR has historically used Vendor-Id 429 and + has defined a "Version-Id" attribute as number 32768. This VSA can + be uniquely identified as 26.429.32768 but again cannot be uniquely + identified by name. + + Where a VSA is a TLV, the "dotted number" notation can be used as + above: 26.Vendor-Id.Vendor-Type.TLV1.TLV2.TLV3, where the "TLVn" + values are the numerical values assigned by the vendor to the + different nested TLVs. + +2.8. Invalid Attributes + + The term "invalid attribute" is new to this specification. It is + defined to mean that the Length field of an Attribute permits the + packet to be accepted as not being "malformed". However, the "Value" + field of the Attribute does not follow the format required by the + data type defined for that Attribute, and therefore the Attribute is + "malformed". In order to distinguish the two cases, we refer to + "malformed" packets and "invalid attributes". + + For example, an implementation receives a packet that is well formed. + That packet contains an Attribute allegedly of data type "address" + but that has Length not equal to four. In that situation, the packet + is well formed, but the Attribute is not. Therefore, it is an + "invalid attribute". + + A similar analysis can be performed when an attribute carries TLVs. + The encapsulating attribute may be well formed, but the TLV may be an + "invalid attribute". The existence of an "invalid attribute" in a + packet or attribute MUST NOT result in the implementation discarding + the entire packet or treating the packet as a negative + acknowledgment. Instead, only the "invalid attribute" is treated + specially. + + When an implementation receives an "invalid attribute", it SHOULD be + silently discarded, except when the implementation is acting as a + proxy (see Section 5.2 for discussion of proxy servers). If it is + + + +DeKok & Lior Standards Track [Page 19] + +RFC 6929 RADIUS Extensions April 2013 + + + not discarded, it MUST NOT be handled in the same manner as a well- + formed attribute. For example, receiving an Attribute of data type + "address" containing either less than four octets or more than + four octets of data means that the Attribute MUST NOT be treated as + being of data type "address". The reason here is that if the + Attribute does not carry an IPv4 address, the receiver has no idea + what format the data is in, and it is therefore not an IPv4 address. + + For Attributes of type "Long Extended Type", an Attribute is + considered to be an "invalid attribute" when it does not match the + criteria set out in Section 2.2, above. + + For Attributes of type "TLV", an Attribute is considered to be an + "invalid attribute" when the TLV-Length field allows the + encapsulating Attribute to be parsed but the TLV-Value field does not + match the criteria for that TLV. Implementations SHOULD NOT treat + the "invalid attribute" property as being transitive. That is, the + Attribute encapsulating the "invalid attribute" SHOULD NOT be treated + as an "invalid attribute". That encapsulating Attribute might + contain multiple TLVs, only one of which is an "invalid attribute". + + However, a TLV definition may require particular sub-TLVs to be + present and/or to have specific values. If a sub-TLV is missing or + contains incorrect value(s), or if it is an "invalid attribute", then + the encapsulating TLV SHOULD be treated as an "invalid attribute". + This requirement ensures that strongly connected TLVs are either + handled as a coherent whole or ignored entirely. + + It is RECOMMENDED that Attributes with unknown Type, Extended-Type, + TLV-Type, or EVS-Type are treated as "invalid attributes". This + recommendation is compatible with the suggestion in [RFC2865] + Section 5 that implementations "MAY ignore Attributes with an + unknown Type". + + + + + + + + + + + + + + + + + + +DeKok & Lior Standards Track [Page 20] + +RFC 6929 RADIUS Extensions April 2013 + + +3. Attribute Definitions + + We define four (4) attributes of "Extended Type", which are allocated + from the "Reserved" Attribute Type codes of 241, 242, 243, and 244. + We also define two (2) attributes of "Long Extended Type", which are + allocated from the "Reserved" Attribute Type codes of 245 and 246. + + Type Name + ---- ---- + 241 Extended-Type-1 + 242 Extended-Type-2 + 243 Extended-Type-3 + 244 Extended-Type-4 + 245 Long-Extended-Type-1 + 246 Long-Extended-Type-2 + + The rest of this section gives detailed definitions for each + Attribute based on the above summary. + +3.1. Extended-Type-1 + + Description + + This attribute encapsulates attributes of the "Extended Type" + format, in the RADIUS Attribute Type space of 241.{1-255}. + + A summary of the Extended-Type-1 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 + + 241 for Extended-Type-1. + + Length + + >= 4 + + + + + + + + + +DeKok & Lior Standards Track [Page 21] + +RFC 6929 RADIUS Extensions April 2013 + + + Extended-Type + + The Extended-Type field is one octet. Up-to-date values of this + field are specified in the 241.{1-255} RADIUS Attribute Type + space, according to the policies and rules described in + Section 10. Further definition of this field is given in + Section 2.1, above. + + Value + + The "Value" field is one or more octets. + + Implementations supporting this specification MUST use the + identifier of "Type.Extended-Type" to determine the interpretation + of the "Value" field. + +3.2. Extended-Type-2 + + Description + + This attribute encapsulates attributes of the "Extended Type" + format, in the RADIUS Attribute Type space of 242.{1-255}. + + A summary of the Extended-Type-2 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 + + 242 for Extended-Type-2. + + Length + + >= 4 + + Extended-Type + + The Extended-Type field is one octet. Up-to-date values of this + field are specified in the 242.{1-255} RADIUS Attribute Type + space, according to the policies and rules described in + Section 10. Further definition of this field is given in + Section 2.1, above. + + + + +DeKok & Lior Standards Track [Page 22] + +RFC 6929 RADIUS Extensions April 2013 + + + Value + + The "Value" field is one or more octets. + + Implementations supporting this specification MUST use the + identifier of "Type.Extended-Type" to determine the interpretation + of the "Value" field. + +3.3. Extended-Type-3 + + Description + + This attribute encapsulates attributes of the "Extended Type" + format, in the RADIUS Attribute Type space of 243.{1-255}. + + A summary of the Extended-Type-3 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 + + 243 for Extended-Type-3. + + Length + + >= 4 + + Extended-Type + + The Extended-Type field is one octet. Up-to-date values of this + field are specified in the 243.{1-255} RADIUS Attribute Type + space, according to the policies and rules described in + Section 10. Further definition of this field is given in + Section 2.1, above. + + Value + + The "Value" field is one or more octets. + + Implementations supporting this specification MUST use the + identifier of "Type.Extended-Type" to determine the interpretation + of the "Value" field. + + + + +DeKok & Lior Standards Track [Page 23] + +RFC 6929 RADIUS Extensions April 2013 + + +3.4. Extended-Type-4 + + Description + + This attribute encapsulates attributes of the "Extended Type" + format, in the RADIUS Attribute Type space of 244.{1-255}. + + A summary of the Extended-Type-4 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 + + 244 for Extended-Type-4. + + Length + + >= 4 + + Extended-Type + + The Extended-Type field is one octet. Up-to-date values of this + field are specified in the 244.{1-255} RADIUS Attribute Type + space, according to the policies and rules described in + Section 10. Further definition of this field is given in + Section 2.1, above. + + Value + + The "Value" field is one or more octets. + + Implementations supporting this specification MUST use the + identifier of "Type.Extended-Type" to determine the interpretation + of the Value Field. + + + + + + + + + + + + +DeKok & Lior Standards Track [Page 24] + +RFC 6929 RADIUS Extensions April 2013 + + +3.5. Long-Extended-Type-1 + + Description + + This attribute encapsulates attributes of the "Long Extended Type" + format, in the RADIUS Attribute Type space of 245.{1-255}. + + A summary of the Long-Extended-Type-1 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| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 245 for Long-Extended-Type-1 + + Length + + >= 5 + + Extended-Type + + The Extended-Type field is one octet. Up-to-date values of this + field are specified in the 245.{1-255} RADIUS Attribute Type + space, according to the policies and rules described in + Section 10. Further definition of this field is given in + Section 2.1, above. + + M (More) + + The More field is one (1) bit in length and indicates whether or + not the current attribute contains "more" than 251 octets of data. + Further definition of this field is given in Section 2.2, above. + + Reserved + + 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. + + + + + +DeKok & Lior Standards Track [Page 25] + +RFC 6929 RADIUS Extensions April 2013 + + + Value + + The "Value" field is one or more octets. + + Implementations supporting this specification MUST use the + identifier of "Type.Extended-Type" to determine the interpretation + of the "Value" field. + +3.6. Long-Extended-Type-2 + + Description + + This attribute encapsulates attributes of the "Long Extended Type" + format, in the RADIUS Attribute Type space of 246.{1-255}. + + A summary of the Long-Extended-Type-2 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| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 246 for Long-Extended-Type-2 + + Length + + >= 5 + + Extended-Type + + The Extended-Type field is one octet. Up-to-date values of this + field are specified in the 246.{1-255} RADIUS Attribute Type + space, according to the policies and rules described in + Section 10. Further definition of this field is given in + Section 2.1, above. + + M (More) + + The More field is one (1) bit in length and indicates whether or + not the current attribute contains "more" than 251 octets of data. + Further definition of this field is given in Section 2.2, above. + + + + +DeKok & Lior Standards Track [Page 26] + +RFC 6929 RADIUS Extensions April 2013 + + + Reserved + + 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 + + The "Value" field is one or more octets. + + Implementations supporting this specification MUST use the + identifier of "Type.Extended-Type" to determine the interpretation + of the "Value" field. + +4. Vendor-Specific Attributes + + We define six new attributes that can carry vendor-specific + information. We define four (4) attributes of the "Extended Type" + format, with Type codes (241.26, 242.26, 243.26, 244.26), using the + "evs" data type. We also define two (2) attributes using "Long + Extended Type" format, with Type codes (245.26, 246.26), which are of + the "evs" data type. + + Type.Extended-Type Name + ------------------ ---- + 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 + + The rest of this section gives detailed definitions for each + Attribute based on the above summary. + + + + + + + + + + + + + + + + +DeKok & Lior Standards Track [Page 27] + +RFC 6929 RADIUS Extensions April 2013 + + +4.1. Extended-Vendor-Specific-1 + + Description + + This attribute defines a RADIUS Type Code of 241.26, using the + "evs" data type. + + A summary of the Extended-Vendor-Specific-1 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 | Vendor-Id ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ... Vendor-Id (cont) | Vendor-Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value .... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type.Extended-Type + + 241.26 for Extended-Vendor-Specific-1 + + Length + + >= 9 + + Vendor-Id + + The 4 octets of the Vendor-Id field are the Network Management + Private Enterprise Code [PEN] of the vendor in network byte order. + + Vendor-Type + + The Vendor-Type field is one octet. Values are assigned at the + sole discretion of the vendor. + + Value + + 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. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + + + + + +DeKok & Lior Standards Track [Page 28] + +RFC 6929 RADIUS Extensions April 2013 + + + The length of the "Value" field is eight (8) less than the value + of the Length field. + + Implementations supporting this specification MUST use the + identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to + determine the interpretation of the "Value" field. + +4.2. Extended-Vendor-Specific-2 + + Description + + This attribute defines a RADIUS Type Code of 242.26, using the + "evs" data type. + + A summary of the Extended-Vendor-Specific-2 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 | Vendor-Id ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ... Vendor-Id (cont) | Vendor-Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value .... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type.Extended-Type + + 242.26 for Extended-Vendor-Specific-2 + + Length + + >= 9 + + Vendor-Id + + The 4 octets of the Vendor-Id field are the Network Management + Private Enterprise Code [PEN] of the vendor in network byte order. + + Vendor-Type + + The Vendor-Type field is one octet. Values are assigned at the + sole discretion of the vendor. + + + + + + + +DeKok & Lior Standards Track [Page 29] + +RFC 6929 RADIUS Extensions April 2013 + + + Value + + 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. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + + The length of the "Value" field is eight (8) less than the value + of the Length field. + + Implementations supporting this specification MUST use the + identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to + determine the interpretation of the "Value" field. + +4.3. Extended-Vendor-Specific-3 + + Description + + This attribute defines a RADIUS Type Code of 243.26, using the + "evs" data type. + + A summary of the Extended-Vendor-Specific-3 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 | Vendor-Id ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ... Vendor-Id (cont) | Vendor-Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value .... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type.Extended-Type + + 243.26 for Extended-Vendor-Specific-3 + + Length + + >= 9 + + Vendor-Id + + The 4 octets of the Vendor-Id field are the Network Management + Private Enterprise Code [PEN] of the vendor in network byte order. + + + +DeKok & Lior Standards Track [Page 30] + +RFC 6929 RADIUS Extensions April 2013 + + + Vendor-Type + + The Vendor-Type field is one octet. Values are assigned at the + sole discretion of the vendor. + + Value + + 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. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + + The length of the "Value" field is eight (8) less than the value + of the Length field. + + Implementations supporting this specification MUST use the + identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to + determine the interpretation of the "Value" field. + +4.4. Extended-Vendor-Specific-4 + + Description + + This attribute defines a RADIUS Type Code of 244.26, using the + "evs" data type. + + A summary of the Extended-Vendor-Specific-4 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 | Vendor-Id ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ... Vendor-Id (cont) | Vendor-Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value .... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type.Extended-Type + + 244.26 for Extended-Vendor-Specific-4 + + Length + + >= 9 + + + +DeKok & Lior Standards Track [Page 31] + +RFC 6929 RADIUS Extensions April 2013 + + + Vendor-Id + + The 4 octets of the Vendor-Id field are the Network Management + Private Enterprise Code [PEN] of the vendor in network byte order. + + Vendor-Type + + The Vendor-Type field is one octet. Values are assigned at the + sole discretion of the vendor. + + Value + + 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. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + + The length of the "Value" field is eight (8) less than the value + of the Length field. + + Implementations supporting this specification MUST use the + identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to + determine the interpretation of the "Value" field. + +4.5. Extended-Vendor-Specific-5 + + Description + + This attribute defines a RADIUS Type Code of 245.26, using the + "evs" data type. + + A summary of the Extended-Vendor-Specific-5 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| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Id | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Value .... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + +DeKok & Lior Standards Track [Page 32] + +RFC 6929 RADIUS Extensions April 2013 + + + Type.Extended-Type + + 245.26 for Extended-Vendor-Specific-5 + + Length + + >= 10 (first fragment) + >= 5 (subsequent fragments) + + When a VSA is fragmented across multiple Attributes, only the + first Attribute contains the Vendor-Id and Vendor-Type fields. + Subsequent Attributes contain fragments of the "Value" field only. + + M (More) + + The More field is one (1) bit in length and indicates whether or + not the current attribute contains "more" than 251 octets of data. + Further definition of this field is given in Section 2.2, above. + + Reserved + + 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. + + Vendor-Id + + The 4 octets of the Vendor-Id field are the Network Management + Private Enterprise Code [PEN] of the vendor in network byte order. + + Vendor-Type + + The Vendor-Type field is one octet. Values are assigned at the + sole discretion of the vendor. + + Value + + 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. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + + Implementations supporting this specification MUST use the + identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to + determine the interpretation of the "Value" field. + + + +DeKok & Lior Standards Track [Page 33] + +RFC 6929 RADIUS Extensions April 2013 + + +4.6. Extended-Vendor-Specific-6 + + Description + + This attribute defines a RADIUS Type Code of 246.26, using the + "evs" data type. + + A summary of the Extended-Vendor-Specific-6 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| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Id | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Value .... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type.Extended-Type + + 246.26 for Extended-Vendor-Specific-6 + + Length + + >= 10 (first fragment) + >= 5 (subsequent fragments) + + When a VSA is fragmented across multiple Attributes, only the + first Attribute contains the Vendor-Id and Vendor-Type fields. + Subsequent Attributes contain fragments of the "Value" field only. + + M (More) + + The More field is one (1) bit in length and indicates whether or + not the current attribute contains "more" than 251 octets of data. + Further definition of this field is given in Section 2.2, above. + + Reserved + + 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. + + + + + + +DeKok & Lior Standards Track [Page 34] + +RFC 6929 RADIUS Extensions April 2013 + + + Vendor-Id + + The 4 octets of the Vendor-Id field are the Network Management + Private Enterprise Code [PEN] of the vendor in network byte order. + + Vendor-Type + + The Vendor-Type field is one octet. Values are assigned at the + sole discretion of the vendor. + + Value + + 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. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + + Implementations supporting this specification MUST use the + identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to + determine the interpretation of the "Value" field. + +5. Compatibility with Traditional RADIUS + + There are a number of potential compatibility issues with traditional + RADIUS, as defined in [RFC6158] and earlier. This section describes + them. + +5.1. Attribute Allocation + + Some vendors have used Attribute Type codes from the "Reserved" space + as part of vendor-defined dictionaries. This practice is considered + antisocial behavior, as noted in [RFC6158]. These vendor definitions + conflict with the Attributes in the RADIUS Attribute Type space. The + conflicting definitions may make it difficult for implementations to + support both those Vendor Attributes, and the new Extended Attribute + formats. + + We RECOMMEND that RADIUS client and server implementations delete all + references to these improperly defined attributes. Failing that, we + RECOMMEND that RADIUS server implementations have a per-client + configurable flag that indicates which type of attributes are being + sent from the client. If the flag is set to "Non-Standard + Attributes", the conflicting attributes can be interpreted as being + improperly defined Vendor-Specific Attributes. If the flag is set to + + + + + +DeKok & Lior Standards Track [Page 35] + +RFC 6929 RADIUS Extensions April 2013 + + + "IETF Attributes", 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. + + Other methods of determining how to decode the Attributes into a + "correct" form are NOT RECOMMENDED. Those methods are likely to be + fragile and prone to error. + + We RECOMMEND that RADIUS server implementations reuse the above flag + to determine which types of attributes to send in a reply message. + If the request is expected to contain the improperly defined + attributes, the reply SHOULD NOT contain Extended Attributes. If the + request is expected to contain Extended Attributes, the reply MUST + NOT contain the improper Attributes. + + RADIUS clients will have fewer issues than servers. Clients MUST NOT + send improperly defined Attributes in a request. For replies, + clients MUST interpret attributes as being of the Extended Attributes + format, instead of the improper definitions. These requirements + impose no change in the RADIUS specifications, as such usage by + vendors has always been in conflict with the standard requirements + and the standards process. + + Existing clients that send these improperly defined attributes + usually have a configuration setting that can disable this behavior. + We RECOMMEND that vendors ship products with the default set to + "disabled". We RECOMMEND that administrators set this flag to + "disabled" on all equipment that they manage. + +5.2. Proxy Servers + + RADIUS proxy servers will need to forward Attributes having the new + format, even if they do not implement support for the encoding and + decoding of those attributes. We remind implementers 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 + refuse to forward attributes that they do not understand (i.e., + attributes for which they have no local dictionary definitions). + + + + + + +DeKok & Lior Standards Track [Page 36] + +RFC 6929 RADIUS Extensions April 2013 + + + This practice is NOT RECOMMENDED. Proxy servers SHOULD forward + attributes, even attributes that they do not understand or that are + not in a local dictionary. When forwarded, these attributes SHOULD + be sent verbatim, with no modifications or changes. This requirement + includes "invalid attributes", as there may be some other system in + the network that understands them. + + 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 that apply to the home network but not to the + visited network. This filtering can sometimes be done even when the + contents of the Attributes are unknown, such as when all Vendor- + Specific Attributes are designated for removal. + + As seen during testing performed in 2010 via the EDUcation ROAMing + (EDUROAM) service (A. DeKok, unpublished data), many proxies do not + follow these practices for unknown Attributes. Some proxies filter + out unknown attributes or attributes that have unexpected lengths + (24%, 17/70), some truncate the Attributes to the "expected" length + (11%, 8/70), some discard the request entirely (1%, 1/70), and the + rest (63%, 44/70) follow the recommended practice of passing the + Attributes verbatim. It will be difficult to widely use the Extended + Attributes format until all non-conformant proxies are fixed. We + therefore RECOMMEND that all proxies that do not support the Extended + Attributes (241 through 246) define them as being of data type + "string" and delete all other local definitions for those attributes. + + This last change should enable wider usage of the Extended Attributes + format. + +6. Guidelines + + This specification proposes a number of changes to RADIUS and + therefore requires a set of guidelines, as has been done in + [RFC6158]. These guidelines include suggestions related to design, + interaction with IANA, usage, and implementation of attributes using + the new formats. + +6.1. Updates to RFC 6158 + + This specification updates [RFC6158] by adding the data types "evs", + "tlv", and "integer64"; defining them to be "basic" data types; and + permitting their use subject to the restrictions outlined below. + + The recommendations for the use of the new data types and Attribute + formats are given below. + + + + +DeKok & Lior Standards Track [Page 37] + +RFC 6929 RADIUS Extensions April 2013 + + +6.2. Guidelines for Simple Data Types + + [RFC6158] Section A.2.1 says in part: + + * Unsigned integers of size other than 32 bits. SHOULD be replaced + by an unsigned integer of 32 bits. There is insufficient + justification to define a new size of integer. + + We update that specification to permit unsigned integers of 64 bits, + for the reasons defined above in Section 2.5. The updated text is as + follows: + + * Unsigned integers of size other than 32 or 64 bits. SHOULD be + replaced by an unsigned integer of 32 or 64 bits. There is + insufficient justification to define a new size of integer. + + That section later continues with the following list item: + + * Nested attribute-value pairs (AVPs). Attributes should be defined + in a flat typespace. + + We update that specification to permit nested TLVs, as defined in + this document: + + * Nested attribute-value pairs (AVPs) using the extended Attribute + format MAY be used. All other nested AVP or TLV formats MUST NOT + be used. + + The [RFC6158] recommendations for "basic" data types apply to the + three types listed above. All other recommendations given in + [RFC6158] for "basic" data types remain unchanged. + +6.3. Guidelines for Complex Data Types + + [RFC6158] Section 2.1 says: + + Complex data types MAY be used in situations where they reduce + complexity in non-RADIUS systems or where using the basic data + types would be awkward (such as where grouping would be required + in order to link related attributes). + + Since the extended Attribute format allows for grouping of complex + types via TLVs, the guidelines for complex data types need to be + updated as follows: + + [RFC6158], Section 3.2.4, describes situations in which complex + data types might be appropriate. They SHOULD NOT be used even in + those situations, without careful consideration of the described + + + +DeKok & Lior Standards Track [Page 38] + +RFC 6929 RADIUS Extensions April 2013 + + + limitations. In all other cases not covered by the complex data + type exceptions, complex data types MUST NOT be used. Instead, + complex data types MUST be decomposed into TLVs. + + The checklist in [RFC6158] Appendix A.2.2 is similarly updated to add + a new requirement at the top of that section, as follows: + + Does the Attribute + + * define a complex type that can be represented via TLVs? + + If so, this data type MUST be represented via TLVs. + + Note that this requirement does not override [RFC6158] Appendix A.1, + which permits the transport of complex types in certain situations. + + All other recommendations given in [RFC6158] for "complex" data types + remain unchanged. + +6.4. Design Guidelines for the New Types + + This section gives design guidelines for specifications defining + attributes using the new format. The items listed below are not + exhaustive. As experience is gained with the new formats, later + specifications may define additional guidelines. + + * The data type "evs" MUST NOT be used for standard RADIUS + Attributes, or for TLVs, or for VSAs. + + * The data type TLV SHOULD NOT be used for standard RADIUS + attributes. + + * [RFC2866] "tagged" attributes MUST NOT be defined in the + Extended-Type space. The "tlv" data type should be used instead to + group attributes. + + * The "integer64" data type MAY be used in any RADIUS attribute. The + use of 64-bit integers was not recommended in [RFC6158], but their + utility is now evident. + + * Any attribute that is allocated from the long extended space of + data type "text", "string", or "tlv" can potentially carry more + than 251 octets of data. Specifications defining such attributes + SHOULD define a maximum length to guide implementations. + + All other recommendations given in [RFC6158] for attribute design + guidelines apply to attributes using the short extended space and + long extended space. + + + +DeKok & Lior Standards Track [Page 39] + +RFC 6929 RADIUS Extensions April 2013 + + +6.5. TLV Guidelines + + The following items give design guidelines for specifications using + TLVs. + + * When multiple Attributes are intended to be grouped or managed + together, the use of TLVs to group related attributes is + RECOMMENDED. + + * More than 4 layers (depth) of TLV nesting is NOT RECOMMENDED. + + * Interpretation of an attribute depends only on its type definition + (e.g., Type.Extended-Type.TLV-Type) and not on its encoding or + location in the RADIUS packet. + + * Where a group of TLVs is strictly defined, and not expected to + change, and totals less than 247 octets of data, the specifications + SHOULD request allocation from the short extended space. + + * Where a group of TLVs is loosely defined or is expected to change, + the specifications SHOULD request allocation from the long extended + space. + + All other recommendations given in [RFC6158] for attribute design + guidelines apply to attributes using the TLV format. + +6.6. Allocation Request Guidelines + + The following items give guidelines for allocation requests made in a + RADIUS specification. + + * Discretion is recommended when requesting allocation of attributes. + The new space is much larger than the old one, but it is not + infinite. + + * Specifications that allocate many attributes MUST NOT request that + allocation be made from the standard space. That space is under + allocation pressure, and the extended space is more suitable for + large allocations. As a guideline, we suggest that one + specification allocating twenty percent (20%) or more of the + standard space would meet the above criteria. + + * Specifications that allocate many related attributes SHOULD define + one or more TLVs to contain related attributes. + + + + + + + +DeKok & Lior Standards Track [Page 40] + +RFC 6929 RADIUS Extensions April 2013 + + + * Specifications SHOULD request allocation from a specific space. + The IANA considerations given in Section 10, below, give + instructions to IANA, but authors should assist IANA where + possible. + + * Specifications of an attribute that encodes 252 octets or less of + data MAY request allocation from the short extended space. + + * Specifications of an attribute that always encode less than + 253 octets of data MUST NOT request allocation from the long + extended space. The standard space or the short extended space + MUST be used instead. + + * Specifications of an attribute that encodes 253 octets or more of + data MUST request allocation from the long extended space. + + * When the extended space is nearing exhaustion, a new specification + will have to be written that requests allocation of one or more + RADIUS attributes from the "Reserved" portion of the standard + space, values 247-255, using an appropriate format ("Short Extended + Type", or "Long Extended Type"). + + An allocation request made in a specification SHOULD use one of the + following formats when allocating an attribute type code: + + * TBDn - request allocation of an attribute from the standard space. + The value "n" should be 1 or more, to track individual attributes + that are to be allocated. + + * SHORT-TBDn - request allocation of an attribute from the short + extended space. The value "n" should be 1 or more, to track + individual attributes that are to be allocated. + + * LONG-TBDn - request allocation of an attribute from the long + extended space. The value "n" should be 1 or more, to track + individual attributes that are to be allocated. + + These guidelines should help specification authors and IANA + communicate effectively and clearly. + +6.7. Allocation Request Guidelines for TLVs + + Specifications may allocate a new attribute of type TLV and at the + same time allocate sub-Attributes within that TLV. These + specifications SHOULD request allocation of specific values for the + sub-TLV. The "dotted number" notation MUST be used. + + + + + +DeKok & Lior Standards Track [Page 41] + +RFC 6929 RADIUS Extensions April 2013 + + + For example, a specification may request allocation of a TLV as + SHORT-TBD1. Within that attribute, it could request allocation of + three sub-TLVs, as SHORT-TBD1.1, SHORT-TBD1.2, and SHORT-TBD1.3. + + Specifications may request allocation of additional sub-TLVs within + an existing attribute of type TLV. Those specifications SHOULD use + the "TBDn" format for every entry in the "dotted number" notation. + + For example, a specification may request allocation within an + existing TLV, with "dotted number" notation MM.NN. Within that + attribute, the specification could request allocation of three + sub-TLVs, as MM.NN.TBD1, MM.NN.TBD2, and MM.NN.TBD3. + +6.8. Implementation Guidelines + + * RADIUS client implementations SHOULD support this specification in + order to permit the easy deployment of specifications using the + changes defined herein. + + * RADIUS server implementations SHOULD support this specification in + order to permit the easy deployment of specifications using the + changes defined herein. + + * RADIUS proxy servers MUST follow the specifications in Section 5.2. + +6.9. Vendor Guidelines + + * Vendors SHOULD use the existing Vendor-Specific Attribute Type + space in preference to the new Extended-Vendor-Specific Attributes, + as this specification may take time to become widely deployed. + + * Vendors SHOULD implement this specification. The changes to RADIUS + are relatively small and are likely to quickly be used in new + specifications. + +7. Rationale for This Design + + The path to extending the RADIUS protocol has been long and arduous. + A number of proposals have been made and discarded by the RADEXT + working group. These proposals have been judged to be either too + bulky, too complex, too simple, or unworkable in practice. We do not + otherwise explain here why earlier proposals did not obtain working + group consensus. + + + + + + + + +DeKok & Lior Standards Track [Page 42] + +RFC 6929 RADIUS Extensions April 2013 + + + The changes outlined here have the benefit of being simple, as the + "Extended Type" format requires only a one-octet change to the + Attribute format. The downside is that the "Long Extended Type" + format is awkward, and the 7 Reserved bits will likely never be used + for anything. + +7.1. Attribute Audit + + An audit of almost five thousand publicly available attributes [ATTR] + (2010) shows the statistics summarized below. The Attributes include + over 100 Vendor dictionaries, along with the IANA-assigned + attributes: + + Count Data Type + ----- --------- + 2257 integer + 1762 text + 273 IPv4 Address + 225 string + 96 other data types + 35 IPv6 Address + 18 date + 10 integer64 + 4 Interface Id + 3 IPv6 Prefix + + 4683 Total + + The entries in the "Data Type" column are data types recommended by + [RFC6158], along with "integer64". The "other data types" row + encompasses all other data types, including complex data types and + data types transporting opaque data. + + We see that over half of the Attributes encode less than 16 octets of + data. It is therefore important to have an extension mechanism that + adds as little as possible to the size of these attributes. Another + result is that the overwhelming majority of attributes use simple + data types. + + Of the Attributes defined above, 177 were declared as being inside of + a TLV. This is approximately 4% of the total. We did not + investigate whether additional attributes were defined in a flat + namespace but could have been defined as being inside of a TLV. We + expect that the number could be as high as 10% of attributes. + + + + + + + +DeKok & Lior Standards Track [Page 43] + +RFC 6929 RADIUS Extensions April 2013 + + + Manual inspection of the dictionaries shows that approximately 20 (or + 0.5%) attributes have the ability to transport more than 253 octets + of data. These attributes are divided between VSAs and a small + number of standard Attributes such as EAP-Message. + + The results of this audit and analysis are reflected in the design of + the extended attributes. The extended format has minimal overhead, + permits TLVs, and has support for "long" attributes. + +8. Diameter Considerations + + The Attribute formats defined in this specification need to be + transported in Diameter. While Diameter supports attributes longer + than 253 octets and grouped attributes, we do not use that + functionality here. Instead, we define the simplest possible + encapsulation method. + + The new formats MUST be treated the same as traditional RADIUS + attributes when converting from RADIUS to Diameter, or vice versa. + That is, the new attribute space is not converted to any "extended" + Diameter attribute space. Fragmented attributes are not converted to + a single long Diameter attribute. The new EVS data types are not + converted to Diameter attributes with the "V" bit set. + + In short, this document mandates no changes for existing RADIUS-to- + Diameter or Diameter-to-RADIUS gateways. + +9. Examples + + A few examples are presented here in order to illustrate the encoding + of the new Attribute formats. These examples are not intended to be + exhaustive, as many others are possible. For simplicity, we do not + show complete packets, but only attributes. + + + + + + + + + + + + + + + + + + +DeKok & Lior Standards Track [Page 44] + +RFC 6929 RADIUS Extensions April 2013 + + + The examples are given using a domain-specific language implemented + by the program given in Appendix A of this document. The language is + line oriented and composed of a sequence of lines matching the ABNF + grammar ([RFC5234]) given below: + + Identifier = 1*DIGIT *( "." 1*DIGIT ) + + HEXCHAR = HEXDIG HEXDIG + + STRING = DQUOTE 1*CHAR DQUOTE + + TLV = "{" SP 1*DIGIT SP DATA SP "}" + + DATA = (HEXCHAR *(SP HEXCHAR)) / (TLV *(SP TLV)) / STRING + + LINE = Identifier SP DATA + + The program has additional restrictions on its input that are not + reflected in the above grammar. For example, the portions of the + identifier that refer to Type and Extended-Type are limited to values + between 1 and 255. We trust that the source code in Appendix A is + clear and that these restrictions do not negatively affect the + comprehensibility of the examples. + + The program reads the input text and interprets it as a set of + instructions to create RADIUS attributes. It then prints the hex + encoding of those attributes. It implements the minimum set of + functionality that achieves that goal. This minimalism means that it + does not use attribute dictionaries; it does not implement support + for RADIUS data types; it can be used to encode attributes with + invalid data fields; and there is no requirement for consistency from + one example to the next. For example, it can be used to encode a + User-Name attribute that contains non-UTF8 data or a + Framed-IP-Address that contains 253 octets of ASCII data. As a + result, it MUST NOT be used to create RADIUS attributes for transport + in a RADIUS message. + + However, the program correctly encodes the RADIUS attribute fields of + "Type", "Length", "Extended-Type", "More", "Reserved", "Vendor-Id", + "Vendor-Type", and "Vendor-Length". It encodes RADIUS attribute data + types "evs" and "tlv". It can therefore be used to encode example + attributes from inputs that are human readable. + + We do not give examples of "invalid attributes". We also note that + the examples show format, rather than consistent meaning. A + particular Attribute Type code may be used to demonstrate two + different formats. In real specifications, attributes have a static + definitions based on their type code. + + + +DeKok & Lior Standards Track [Page 45] + +RFC 6929 RADIUS Extensions April 2013 + + + The examples given below are strictly for demonstration purposes only + and do not provide a standard of any kind. + +9.1. Extended Type + + The following is a series of examples of the "Extended Type" format. + + Attribute encapsulating textual data: + + 241.1 "bob" + -> f1 06 01 62 6f 62 + + Attribute encapsulating a TLV with TLV-Type of one (1): + + 241.2 { 1 23 45 } + -> f1 07 02 01 04 23 45 + + Attribute encapsulating two TLVs, one after the other: + + 241.2 { 1 23 45 } { 2 67 89 } + -> f1 0b 02 01 04 23 45 02 04 67 89 + + Attribute encapsulating two TLVs, where the second TLV is itself + encapsulating a TLV: + + 241.2 { 1 23 45 } { 3 { 1 ab cd } } + -> f1 0d 02 01 04 23 45 03 06 01 04 ab cd + + Attribute encapsulating two TLVs, where the second TLV is itself + encapsulating two TLVs: + + 241.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } + -> f1 12 02 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f + + Attribute encapsulating a TLV, which in turn encapsulates a TLV, to a + depth of 5 nestings: + + 241.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } + -> f1 0f 01 01 0c 02 0a 03 08 04 06 05 04 cd ef + + Attribute encapsulating an Extended-Vendor-Specific Attribute, with + Vendor-Id of 1 and Vendor-Type of 4, which in turn encapsulates + textual data: + + 241.26.1.4 "test" + -> f1 0c 1a 00 00 00 01 04 74 65 73 74 + + + + + +DeKok & Lior Standards Track [Page 46] + +RFC 6929 RADIUS Extensions April 2013 + + + Attribute encapsulating an Extended-Vendor-Specific Attribute, with + Vendor-Id of 1 and Vendor-Type of 5, which in turn encapsulates a TLV + with TLV-Type of 3, which encapsulates textual data: + + 241.26.1.5 { 3 "test" } + -> f1 0e 1a 00 00 00 01 05 03 06 74 65 73 74 + +9.2. Long Extended Type + + The following is a series of examples of the "Long Extended Type" + format. + + Attribute encapsulating textual data: + + 245.1 "bob" + -> f5 07 01 00 62 6f 62 + + Attribute encapsulating a TLV with TLV-Type of one (1): + + 245.2 { 1 23 45 } + -> f5 08 02 00 01 04 23 45 + + Attribute encapsulating two TLVs, one after the other: + + 245.2 { 1 23 45 } { 2 67 89 } + -> f5 0c 02 00 01 04 23 45 02 04 67 89 + + Attribute encapsulating two TLVs, where the second TLV is itself + encapsulating a TLV: + + 245.2 { 1 23 45 } { 3 { 1 ab cd } } + -> f5 0e 02 00 01 04 23 45 03 06 01 04 ab cd + + Attribute encapsulating two TLVs, where the second TLV is itself + encapsulating two TLVs: + + 245.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } + -> f5 13 02 00 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f + + Attribute encapsulating a TLV, which in turn encapsulates a TLV, to a + depth of 5 nestings: + + 245.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } + -> f5 10 01 00 01 0c 02 0a 03 08 04 06 05 04 cd ef + + + + + + + +DeKok & Lior Standards Track [Page 47] + +RFC 6929 RADIUS Extensions April 2013 + + + Attribute encapsulating an Extended-Vendor-Specific Attribute, with + Vendor-Id of 1 and Vendor-Type of 4, which in turn encapsulates + textual data: + + 245.26.1.4 "test" + -> f5 0d 1a 00 00 00 00 01 04 74 65 73 74 + + Attribute encapsulating an Extended-Vendor-Specific Attribute, with + Vendor-Id of 1 and Vendor-Type of 5, which in turn encapsulates a TLV + with TLV-Type of 3, which encapsulates textual data: + + 245.26.1.5 { 3 "test" } + -> f5 0f 1a 00 00 00 00 01 05 03 06 74 65 73 74 + + Attribute encapsulating more than 251 octets of data. The "Data" + portions are indented for readability: + + 245.4 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa + aaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb + bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb + bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb + bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb + bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbcccccccccccccccccccc + ccccccccccc" + -> f5 ff 04 80 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa + aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa + aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa + aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa + aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa + aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa + aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb bb bb bb bb bb + bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb + bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb + bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb + bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb + bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb + bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 13 04 00 cc + cc cc cc cc cc cc cc cc cc cc cc cc cc cc + + + + + + + + + + +DeKok & Lior Standards Track [Page 48] + +RFC 6929 RADIUS Extensions April 2013 + + + Below is an example of an attribute encapsulating an Extended-Vendor- + Specific Attribute, with Vendor-Id of 1 and Vendor-Type of 6, which + in turn encapsulates more than 251 octets of data. + + As the VSA encapsulates more than 251 octets of data, it is split + into two RADIUS attributes. The first attribute has the More field + set, and it carries the Vendor-Id and Vendor-Type. The second + attribute has the More field clear and carries the rest of the data + portion of the VSA. Note that the second attribute does not include + the Vendor-Id ad Vendor-Type fields. + + The "Data" portions are indented for readability: + + 245.26.1.6 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa + aaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb + bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb + bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb + bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb + bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbccccccccccccc + ccccccccccccccccc" + -> f5 ff 1a 80 00 00 00 01 06 aa aa aa aa aa aa aa aa aa aa aa + aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa + aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa + aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa + aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa + aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa + aa aa aa aa aa aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb + bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb + bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb + bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb + bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb + bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb + bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 18 1a 00 bb + bb bb bb bb cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc + + + + + + + + + + + + + + +DeKok & Lior Standards Track [Page 49] + +RFC 6929 RADIUS Extensions April 2013 + + +10. IANA Considerations + + This document updates [RFC3575] in that it adds new IANA + considerations for RADIUS attributes. These considerations modify + and extend the IANA considerations for RADIUS, rather than replacing + them. + + The IANA considerations of this document are limited to the "RADIUS + Attribute Types" registry. Some Attribute Type values that were + previously marked "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 nodes. Detailed instructions are given below. + +10.1. Attribute Allocations + + IANA has moved the following Attribute Type values from "Reserved" to + "Allocated" with the corresponding names: + + * 241 Extended-Type-1 + * 242 Extended-Type-2 + * 243 Extended-Type-3 + * 244 Extended-Type-4 + * 245 Long-Extended-Type-1 + * 246 Long-Extended-Type-2 + + These values serve as an encapsulation layer for the new RADIUS + Attribute Type tree. + +10.2. RADIUS Attribute Type Tree + + Each of the Attribute Type values allocated above extends the "RADIUS + Attribute Types" to an N-ary tree, via a "dotted number" notation. + Allocation of an Attribute Type value "TYPE" using the new "Extended + Type" format results in allocation of 255 new Attribute Type values + of format "TYPE.1" through "TYPE.255". Value twenty-six (26) is + assigned as "Extended-Vendor-Specific-*". Values "TYPE.241" through + "TYPE.255" are marked "Reserved". All other values are "Unassigned". + + + + + + + + + + + + + + +DeKok & Lior Standards Track [Page 50] + +RFC 6929 RADIUS Extensions April 2013 + + + The initial set of Attribute Type values and names assigned by this + document is given below. + + * 241 Extended-Attribute-1 + * 241.{1-25} Unassigned + * 241.26 Extended-Vendor-Specific-1 + * 241.{27-240} Unassigned + * 241.{241-255} Reserved + * 242 Extended-Attribute-2 + * 242.{1-25} Unassigned + * 242.26 Extended-Vendor-Specific-2 + * 242.{27-240} Unassigned + * 242.{241-255} Reserved + * 243 Extended-Attribute-3 + * 243.{1-25} Unassigned + * 243.26 Extended-Vendor-Specific-3 + * 243.{27-240} Unassigned + * 243.{241-255} Reserved + * 244 Extended-Attribute-4 + * 244.{1-25} Unassigned + * 244.26 Extended-Vendor-Specific-4 + * 244.{27-240} Unassigned + * 244.{241-255} Reserved + * 245 Extended-Attribute-5 + * 245.{1-25} Unassigned + * 245.26 Extended-Vendor-Specific-5 + * 245.{27-240} Unassigned + * 245.{241-255} Reserved + * 246 Extended-Attribute-6 + * 246.{1-25} Unassigned + * 246.26 Extended-Vendor-Specific-6 + * 246.{27-240} Unassigned + * 246.{241-255} Reserved + + As per [RFC5226], the values marked "Unassigned" above are available + for assignment by IANA in future RADIUS specifications. The values + marked "Reserved" are reserved for future use. + + The Extended-Vendor-Specific spaces (TYPE.26) are for Private Use, + and allocations are not managed by IANA. + + Allocation of Reserved entries in the extended space requires + Standards Action. + + All other allocations in the extended space require IETF Review. + + + + + + +DeKok & Lior Standards Track [Page 51] + +RFC 6929 RADIUS Extensions April 2013 + + +10.3. Allocation Instructions + + This section defines what actions IANA needs to take when allocating + new attributes. Different actions are required when allocating + attributes from the standard space, attributes of the "Extended Type" + format, attributes of the "Long Extended Type" format, preferential + allocations, attributes of data type TLV, attributes within a TLV, + and attributes of other data types. + +10.3.1. Requested Allocation from the Standard Space + + Specifications can request allocation of an Attribute from within the + standard space (e.g., Attribute Type Codes 1 through 255), subject to + the considerations of [RFC3575] and this document. + +10.3.2. Requested Allocation from the Short Extended Space + + Specifications can request allocation of an Attribute that requires + the format "Extended Type", by specifying the short extended space. + In that case, IANA should assign the lowest Unassigned number from + the Attribute Type space with the relevant format. + +10.3.3. Requested Allocation from the Long Extended Space + + Specifications can request allocation of an Attribute that requires + the format "Long Extended Type", by specifying the extended space + (long). In that case, IANA should assign the lowest Unassigned + number from the Attribute Type space with the relevant format. + +10.3.4. Allocation Preferences + + Specifications that make no request for allocation from a specific + type space should have Attributes allocated using the following + criteria: + + * When the standard space has no more Unassigned attributes, all + allocations should be performed from the extended space. + + * Specifications that allocate a small number of attributes (i.e., + less than ten) should have all allocations made from the standard + space. + + * Specifications that would allocate more than twenty percent of the + remaining standard space attributes should have all allocations + made from the extended space. + + * Specifications that request allocation of an attribute of data type + TLV should have that attribute allocated from the extended space. + + + +DeKok & Lior Standards Track [Page 52] + +RFC 6929 RADIUS Extensions April 2013 + + + * Specifications that request allocation of an attribute that can + transport 253 or more octets of data should have that attribute + allocated from within the long extended space. We note that + Section 6.5 above makes recommendations related to this allocation. + + There is otherwise no requirement that all attributes within a + specification be allocated from one type space or another. + Specifications can simultaneously allocate attributes from both the + standard space and the extended space. + +10.3.5. Extending the Type Space via the TLV Data Type + + When specifications request allocation of an attribute of data type + TLV, that allocation extends the Attribute Type tree by one more + level. Allocation of an Attribute Type value "TYPE.TLV", with data + type TLV, results in allocation of 255 new Attribute Type values, of + format "TYPE.TLV.1" through "TYPE.TLV.255". Values 254-255 are + marked "Reserved". All other values are "Unassigned". Value 26 has + no special meaning. + + For example, if a new attribute "Example-TLV" of data type TLV is + assigned the identifier "245.1", then the extended tree will be + allocated as below: + + * 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 Attribute Type tree can be extended multiple levels in one + specification when the specification requests allocation of nested + TLVs, as discussed below. + +10.3.6. Allocation within a TLV + + Specifications can request allocation of Attribute Type values within + an Attribute of data type TLV. The encapsulating TLV can be + allocated in the same specification, or it can have been previously + allocated. + + Specifications need to request allocation within a specific Attribute + Type value (e.g., "TYPE.TLV.*"). Allocations are performed from the + smallest Unassigned value, proceeding to the largest Unassigned + value. + + + + + + +DeKok & Lior Standards Track [Page 53] + +RFC 6929 RADIUS Extensions April 2013 + + + Where the Attribute being allocated is of data type TLV, the + Attribute Type tree is extended by one level, as given in the + previous section. Allocations can then be made within that level. + +10.3.7. Allocation of Other Data Types + + Attribute Type value allocations are otherwise allocated from the + smallest Unassigned value, proceeding to the largest Unassigned + value, e.g., starting from 241.1, proceeding through 241.255, then to + 242.1, through 242.255, etc. + +11. 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]. The security of the RADIUS + protocol is dependent on MD5 [RFC1321], which has security issues as + discussed in [RFC6151]. It is not known if the issues described in + [RFC6151] apply to RADIUS. For other issues, we incorporate by + reference the security considerations of [RFC6158] Section 5. + + As with any protocol change, code changes are required in order to + 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 access to RADIUS servers be kept to a + minimum. + +12. References + +12.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, + July 2003. + + + + +DeKok & Lior Standards Track [Page 54] + +RFC 6929 RADIUS Extensions April 2013 + + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC6158] DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines", + BCP 158, RFC 6158, March 2011. + + [PEN] IANA, "PRIVATE ENTERPRISE NUMBERS", + <http://www.iana.org/assignments/enterprise-numbers>. + +12.2. Informative References + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + + [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, + M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol + Support", RFC 2868, June 2000. + + [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic + Hashes in Internet Protocols", RFC 4270, November 2005. + + [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", STD 68, RFC 5234, + January 2008. + + [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations + for the MD5 Message-Digest and the HMAC-MD5 Algorithms", + RFC 6151, March 2011. + + [ATTR] "alandekok/freeradius-server", available from GitHub, data + retrieved September 2010, <http://github.com/alandekok/ + freeradius-server/tree/master/share/>. + +13. 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 & Lior Standards Track [Page 55] + +RFC 6929 RADIUS Extensions April 2013 + + +Appendix A. Extended Attribute Generator Program + + This section contains "C" program source code that can be used for + testing. It reads a line-oriented text file, parses it to create + RADIUS formatted attributes, and prints the hex version of those + attributes to standard output. + + The input accepts grammar similar to that given in Section 9, with + some modifications for usability. For example, blank lines are + allowed, lines beginning with a '#' character are interpreted as + comments, numbers (RADIUS Types, etc.) are checked for minimum/ + maximum values, and RADIUS attribute lengths are enforced. + + The program is included here for demonstration purposes only, and + does not define a standard of any kind. + + ------------------------------------------------------------ + /* + * Copyright (c) 2013 IETF Trust and the persons identified as + * authors of the code. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * - Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * - Redistributions in binary form must reproduce the above + * copyright notice, this list of conditions and the following + * disclaimer in the documentation and/or other materials provided + * with the distribution. + * + * - Neither the name of Internet Society, IETF or IETF Trust, nor + * the names of specific contributors, may be used to endorse or + * promote products derived from this software without specific + * prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND + * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, + * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS + * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, + * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED + * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, + + + +DeKok & Lior Standards Track [Page 56] + +RFC 6929 RADIUS Extensions April 2013 + + + * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT + * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * Author: Alan DeKok <aland@networkradius.com> + */ + #include <stdlib.h> + #include <stdio.h> + #include <stdint.h> + #include <string.h> + #include <errno.h> + #include <ctype.h> + + static int encode_tlv(char *buffer, uint8_t *output, size_t outlen); + + static const char *hextab = "0123456789abcdef"; + + static int encode_data_string(char *buffer, + uint8_t *output, size_t outlen) + { + int length = 0; + char *p; + + p = buffer + 1; + + while (*p && (outlen > 0)) { + if (*p == '"') { + return length; + } + + if (*p != '\\') { + *(output++) = *(p++); + outlen--; + length++; + continue; + } + + switch (p[1]) { + default: + *(output++) = p[1]; + break; + + case 'n': + *(output++) = '\n'; + break; + + + + + + +DeKok & Lior Standards Track [Page 57] + +RFC 6929 RADIUS Extensions April 2013 + + + case 'r': + *(output++) = '\r'; + break; + + case 't': + *(output++) = '\t'; + break; + } + + outlen--; + length++; + } + + fprintf(stderr, "String is not terminated\n"); + return 0; + } + + static int encode_data_tlv(char *buffer, char **endptr, + uint8_t *output, size_t outlen) + { + int depth = 0; + int length; + char *p; + + for (p = buffer; *p != '\0'; p++) { + if (*p == '{') depth++; + if (*p == '}') { + depth--; + if (depth == 0) break; + } + } + + if (*p != '}') { + fprintf(stderr, "No trailing '}' in string starting " + "with \"%s\"\n", + buffer); + return 0; + } + + *endptr = p + 1; + *p = '\0'; + + p = buffer + 1; + while (isspace((int) *p)) p++; + + + + + + + +DeKok & Lior Standards Track [Page 58] + +RFC 6929 RADIUS Extensions April 2013 + + + length = encode_tlv(p, output, outlen); + if (length == 0) return 0; + + return length; + } + + static int encode_data(char *p, uint8_t *output, size_t outlen) + { + int length; + + if (!isspace((int) *p)) { + fprintf(stderr, "Invalid character following attribute " + "definition\n"); + return 0; + } + + while (isspace((int) *p)) p++; + + if (*p == '{') { + int sublen; + char *q; + + length = 0; + + do { + while (isspace((int) *p)) p++; + if (!*p) { + if (length == 0) { + fprintf(stderr, "No data\n"); + return 0; + } + + break; + } + + sublen = encode_data_tlv(p, &q, output, outlen); + if (sublen == 0) return 0; + + length += sublen; + output += sublen; + outlen -= sublen; + p = q; + } while (*q); + + return length; + } + + + + + +DeKok & Lior Standards Track [Page 59] + +RFC 6929 RADIUS Extensions April 2013 + + + if (*p == '"') { + length = encode_data_string(p, output, outlen); + return length; + } + + length = 0; + while (*p) { + + char *c1, *c2; + + while (isspace((int) *p)) p++; + + if (!*p) break; + + if(!(c1 = memchr(hextab, tolower((int) p[0]), 16)) || + !(c2 = memchr(hextab, tolower((int) p[1]), 16))) { + fprintf(stderr, "Invalid data starting at " + "\"%s\"\n", p); + return 0; + } + + *output = ((c1 - hextab) << 4) + (c2 - hextab); + output++; + length++; + p += 2; + + outlen--; + if (outlen == 0) { + fprintf(stderr, "Too much data\n"); + return 0; + } + } + + if (length == 0) { + fprintf(stderr, "Empty string\n"); + return 0; + } + + return length; + } + + + + + + + + + + + +DeKok & Lior Standards Track [Page 60] + +RFC 6929 RADIUS Extensions April 2013 + + + static int decode_attr(char *buffer, char **endptr) + { + long attr; + + attr = strtol(buffer, endptr, 10); + if (*endptr == buffer) { + fprintf(stderr, "No valid number found in string " + "starting with \"%s\"\n", buffer); + return 0; + } + + if (!**endptr) { + fprintf(stderr, "Nothing follows attribute number\n"); + return 0; + } + + if ((attr <= 0) || (attr > 256)) { + fprintf(stderr, "Attribute number is out of valid " + "range\n"); + return 0; + } + + return (int) attr; + } + + static int decode_vendor(char *buffer, char **endptr) + { + long vendor; + + if (*buffer != '.') { + fprintf(stderr, "Invalid separator before vendor id\n"); + return 0; + } + + vendor = strtol(buffer + 1, endptr, 10); + if (*endptr == (buffer + 1)) { + fprintf(stderr, "No valid vendor number found\n"); + return 0; + } + + if (!**endptr) { + fprintf(stderr, "Nothing follows vendor number\n"); + return 0; + } + + + + + + + +DeKok & Lior Standards Track [Page 61] + +RFC 6929 RADIUS Extensions April 2013 + + + if ((vendor <= 0) || (vendor > (1 << 24))) { + fprintf(stderr, "Vendor number is out of valid range\n"); + return 0; + } + + if (**endptr != '.') { + fprintf(stderr, "Invalid data following vendor number\n"); + return 0; + } + (*endptr)++; + + return (int) vendor; + } + + static int encode_tlv(char *buffer, uint8_t *output, size_t outlen) + { + int attr; + int length; + char *p; + + attr = decode_attr(buffer, &p); + if (attr == 0) return 0; + + output[0] = attr; + output[1] = 2; + + if (*p == '.') { + p++; + length = encode_tlv(p, output + 2, outlen - 2); + + } else { + length = encode_data(p, output + 2, outlen - 2); + } + + if (length == 0) return 0; + if (length > (255 - 2)) { + fprintf(stderr, "TLV data is too long\n"); + return 0; + } + + output[1] += length; + + return length + 2; + } + + + + + + + +DeKok & Lior Standards Track [Page 62] + +RFC 6929 RADIUS Extensions April 2013 + + + static int encode_vsa(char *buffer, uint8_t *output, size_t outlen) + { + int vendor; + int attr; + int length; + char *p; + + vendor = decode_vendor(buffer, &p); + if (vendor == 0) return 0; + + output[0] = 0; + output[1] = (vendor >> 16) & 0xff; + output[2] = (vendor >> 8) & 0xff; + output[3] = vendor & 0xff; + + length = encode_tlv(p, output + 4, outlen - 4); + if (length == 0) return 0; + if (length > (255 - 6)) { + fprintf(stderr, "VSA data is too long\n"); + return 0; + } + + return length + 4; + } + + static int encode_evs(char *buffer, uint8_t *output, size_t outlen) + { + int vendor; + int attr; + int length; + char *p; + + vendor = decode_vendor(buffer, &p); + if (vendor == 0) return 0; + + attr = decode_attr(p, &p); + if (attr == 0) return 0; + + output[0] = 0; + output[1] = (vendor >> 16) & 0xff; + output[2] = (vendor >> 8) & 0xff; + output[3] = vendor & 0xff; + output[4] = attr; + + length = encode_data(p, output + 5, outlen - 5); + if (length == 0) return 0; + + + + + +DeKok & Lior Standards Track [Page 63] + +RFC 6929 RADIUS Extensions April 2013 + + + return length + 5; + } + + static int encode_extended(char *buffer, + uint8_t *output, size_t outlen) + { + int attr; + int length; + char *p; + + attr = decode_attr(buffer, &p); + if (attr == 0) return 0; + + output[0] = attr; + + if (attr == 26) { + length = encode_evs(p, output + 1, outlen - 1); + } else { + length = encode_data(p, output + 1, outlen - 1); + } + if (length == 0) return 0; + if (length > (255 - 3)) { + fprintf(stderr, "Extended Attr data is too long\n"); + + return 0; + } + + return length + 1; + } + + static int encode_extended_flags(char *buffer, + uint8_t *output, size_t outlen) + { + int attr; + int length, total; + char *p; + + attr = decode_attr(buffer, &p); + if (attr == 0) return 0; + + /* output[0] is the extended attribute */ + output[1] = 4; + output[2] = attr; + output[3] = 0; + + + + + + + +DeKok & Lior Standards Track [Page 64] + +RFC 6929 RADIUS Extensions April 2013 + + + if (attr == 26) { + length = encode_evs(p, output + 4, outlen - 4); + if (length == 0) return 0; + + output[1] += 5; + length -= 5; + } else { + length = encode_data(p, output + 4, outlen - 4); + } + if (length == 0) return 0; + + total = 0; + while (1) { + int sublen = 255 - output[1]; + + if (length <= sublen) { + output[1] += length; + total += output[1]; + break; + } + + length -= sublen; + + memmove(output + 255 + 4, output + 255, length); + memcpy(output + 255, output, 4); + + output[1] = 255; + + output[3] |= 0x80; + + output += 255; + output[1] = 4; + total += 255; + } + + return total; + } + + static int encode_rfc(char *buffer, uint8_t *output, size_t outlen) + { + int attr; + int length, sublen; + char *p; + + attr = decode_attr(buffer, &p); + if (attr == 0) return 0; + + + + + +DeKok & Lior Standards Track [Page 65] + +RFC 6929 RADIUS Extensions April 2013 + + + length = 2; + output[0] = attr; + output[1] = 2; + + if (attr == 26) { + sublen = encode_vsa(p, output + 2, outlen - 2); + + } else if ((*p == ' ') || ((attr < 241) || (attr > 246))) { + sublen = encode_data(p, output + 2, outlen - 2); + + } else { + if (*p != '.') { + fprintf(stderr, "Invalid data following " + "attribute number\n"); + return 0; + } + + if (attr < 245) { + sublen = encode_extended(p + 1, + output + 2, outlen - 2); + } else { + + /* + * Not like the others! + */ + return encode_extended_flags(p + 1, output, outlen); + } + } + if (sublen == 0) return 0; + + if (sublen > (255 -2)) { + fprintf(stderr, "RFC Data is too long\n"); + return 0; + } + + output[1] += sublen; + return length + sublen; + } + + int main(int argc, char *argv[]) + { + int lineno; + size_t i, outlen; + FILE *fp; + char input[8192], buffer[8192]; + uint8_t output[4096]; + + + + + +DeKok & Lior Standards Track [Page 66] + +RFC 6929 RADIUS Extensions April 2013 + + + if ((argc < 2) || (strcmp(argv[1], "-") == 0)) { + fp = stdin; + } else { + fp = fopen(argv[1], "r"); + if (!fp) { + fprintf(stderr, "Error opening %s: %s\n", + argv[1], strerror(errno)); + exit(1); + } + } + + lineno = 0; + while (fgets(buffer, sizeof(buffer), fp) != NULL) { + char *p = strchr(buffer, '\n'); + + lineno++; + + if (!p) { + if (!feof(fp)) { + fprintf(stderr, "Line %d too long in %s\n", + lineno, argv[1]); + exit(1); + } + } else { + *p = '\0'; + } + + p = strchr(buffer, '#'); + if (p) *p = '\0'; + + p = buffer; + + while (isspace((int) *p)) p++; + if (!*p) continue; + + strcpy(input, p); + outlen = encode_rfc(input, output, sizeof(output)); + if (outlen == 0) { + fprintf(stderr, "Parse error in line %d of %s\n", + lineno, input); + exit(1); + } + + printf("%s -> ", buffer); + for (i = 0; i < outlen; i++) { + printf("%02x ", output[i]); + } + + + + +DeKok & Lior Standards Track [Page 67] + +RFC 6929 RADIUS Extensions April 2013 + + + printf("\n"); + } + + if (fp != stdin) fclose(fp); + + return 0; + } + ------------------------------------------------------------ + +Authors' Addresses + + Alan DeKok + Network RADIUS SARL + 57bis blvd des Alpes + 38240 Meylan + France + + EMail: aland@networkradius.com + URI: http://networkradius.com + + + Avi Lior + + EMail: avi.ietf@lior.org + + + + + + + + + + + + + + + + + + + + + + + + + + + +DeKok & Lior Standards Track [Page 68] + |