RFC 6929
Remote Authentication Dial In User Service (RADIUS) Protocol Extensions
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 ExtensionsAbstract
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.
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
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 ..................561. 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
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).
* 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.
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".
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.
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".
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
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.
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
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.
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.
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.
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
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.
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.
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".
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
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".
(next page on part 2)
