Remote Authentication Dial In User Service (RADIUS) Protocol Extensions
updates
Extracted elements (30)
The EVS data type is intended for use only when a vendor's existing VSA Type space is fully allocated. Vendors are recommended to exhaust the standard Vendor-Specific Attribute (type 26) space first, because this specification may take time to become widely deployed.
The EVS data type omits the Vendor-Length field present in RFC 2865 Section 5.26 VSAs because many vendors did not follow the RFC 2865 recommendations, causing interoperability issues. The EVS length is made implicit, derived from the encapsulating attribute's Length field.
The Extended Type format deliberately omits 'experimental' and 'implementation-specific' sub-codes (as were defined in RFC 2865 Section 5) because experience showed they had little practical value and their use led to interoperability problems.
The new attribute formats are backward-compatible because they do not insert new fields; instead, they 'steal' one or more octets from the existing Value field, leaving the Type and Length fields unchanged. RADIUS implementations that do not support these extensions can simply forward the Value verbatim.
Some vendors have used Attribute Type codes from the Reserved space (241–246) in proprietary dictionaries, conflicting with the Extended Attributes defined here. Implementations SHOULD support a per-client flag to distinguish 'Non-Standard Attributes' from 'IETF Attributes', defaulting to the IETF interpretation.
Testing via the EDUROAM service in 2010 (70 proxies) found that 24% filtered unknown attributes, 11% truncated them, and 1% discarded the entire request. Only 63% forwarded attributes verbatim as required. Wide deployment of Extended Attributes depends on fixing non-conformant proxies.
After reassembling Long Extended Type fragments, interpretation MUST occur only after full reassembly. If reassembled data does not match the expected format, all fragments MUST be treated as invalid attributes and the data MUST be discarded.
An invalid attribute MUST NOT cause the implementation to discard the entire packet or treat the packet as a negative acknowledgment. Only the invalid attribute itself is treated specially; it SHOULD be silently discarded.
Extended-Type values 241–255 are reserved and MUST NOT be used. Implementations MUST use the composite identifier 'Type.Extended-Type' to determine the interpretation of the Value field.
Proxy servers SHOULD forward unknown or undictionary attributes verbatim, with no modifications. Refusing to forward attributes not in a local dictionary is NOT RECOMMENDED. Implementations MUST be able to process non-contiguous Long Extended Type fragments.
RADIUS clients MUST NOT send improperly defined attributes that conflict with the Reserved Attribute Type space (241–246). For replies, clients MUST interpret these attributes as Extended Attributes, not as vendor-proprietary definitions.
Specifications that allocate attributes encoding 253 octets or more of data MUST request allocation from the long extended space; those always encoding fewer than 253 octets MUST NOT use the long extended space. Specifications allocating 20% or more of the standard space MUST NOT request from the standard space.
The EVS data type MUST NOT be used in standard RADIUS attributes, TLVs, or VSAs; it MAY only appear in Extended Type or Long Extended Type attribute definitions. EVS-Value MUST NOT itself be of data type 'evs'.
The Reserved field (7 bits) in the Long Extended Type format MUST be set to zero when encoding. Implementations MUST NOT treat a non-zero Reserved field as invalid on reception, as future specifications may assign meaning to it.
TLV-Value MUST NOT contain data using the Extended Type formats defined in this document. TLV nesting depths greater than 4 are NOT RECOMMENDED; reception of packets with deeply nested TLVs may indicate implementation errors or deliberate attacks.
When a container TLV holds nested TLVs, the container TLV-Length MUST be exactly two more than the sum of the contained TLV-Length fields. If contained TLVs overfill the container, the container MUST be treated as an invalid attribute.
When the More (M) bit is set to 1, the attribute MUST have Length=255, there MUST be a following attribute with the same Type and Extended-Type, and all fragments MUST be consecutive in the packet. The last attribute in a packet MUST NOT have M set. Missing subsequent fragments render the attribute invalid.
A dotted-number notation is introduced for identifying extended attributes: 'Type.Extended-Type' for simple extended attributes, 'Type.Extended-Type.TLV-Type' for TLVs, and 'Type.Extended-Type.Vendor-Id.Vendor-Type' for EVS attributes. This notation is used by IANA for allocation.
Four Extended Type attributes are allocated from the Reserved space: Extended-Type-1 (241), Extended-Type-2 (242), Extended-Type-3 (243), Extended-Type-4 (244). Each extends the RADIUS Attribute Type space by up to 255 sub-codes, yielding approximately 1000 new attribute slots.
Six Extended Vendor-Specific attributes are defined using the EVS data type: Extended-Vendor-Specific-1 through -4 (241.26–244.26) and Extended-Vendor-Specific-5 and -6 (245.26–246.26). These add over 1500 new vendor-specific attribute slots.
The Vendor-Id field for Vendor-Specific Attributes is redefined to encompass the full 4 octets of the Vendor field. RFC 2865 Section 5.26 had defined it as 3 octets with the fourth forced to zero; implementations are RECOMMENDED to support the full 4-octet form.
Two Long Extended Type attributes are allocated: Long-Extended-Type-1 (245) and Long-Extended-Type-2 (246). These provide approximately 500 additional attribute type codes and support fragmented transport of values larger than 253 octets.
A RADIUS Attribute Type Tree is established, structured as a hierarchical namespace using dotted-number notation. IANA is given instructions for allocating from the standard space (TBDn), short extended space (SHORT-TBDn), and long extended space (LONG-TBDn).
IANA allocates Attribute Type codes 241–244 for Extended Type attributes and 245–246 for Long Extended Type attributes from the previously Reserved space. Three new allocation spaces are defined: standard space, short extended space (241–244.x), and long extended space (245–246.x).
Receipt of RADIUS packets with deeply nested TLVs (more than 4 levels) may indicate implementation errors or deliberate attacks. Where implementations do not support deep nesting, it is RECOMMENDED that unsupported layers be treated as invalid attributes rather than silently accepted.
The EVS (Extended-Vendor-Specific) data type encodes: Vendor-Id (4 octets, network byte order PEN), EVS-Type (1 octet), EVS-Value (1+ octets). Unlike RFC 2865 Section 5.26, there is no Vendor-Length field; EVS-Value length is derived from the encapsulating attribute's Length minus header bytes.
The Extended Type attribute format adds an 8-bit Extended-Type field by stealing one octet from the Value field of the standard RADIUS attribute. Fields: Type (1 octet), Length (1 octet, 4–255), Extended-Type (1 octet), Value (1+ octets). Attributes with Length 2 or 3 MUST be treated as invalid.
The integer64 data type is a 64-bit unsigned integer in network byte order (8 octets). For standard space and TLV attributes the Length field MUST be 10; for Extended Type it MUST be 11; for Long Extended Type it MUST be 12.
The Long Extended Type format inserts an additional flags octet between Extended-Type and Value: Type (1 octet), Length (1 octet, 5–255), Extended-Type (1 octet), M|Reserved (1 octet, 1-bit More flag + 7-bit reserved), Value (1+ octets). Attributes with Length 2, 3, or 4 MUST be treated as invalid.
The TLV data type reuses the RADIUS attribute format as sub-attributes: TLV-Type (1 octet), TLV-Length (1 octet, 3–255), TLV-Value (1+ octets). TLV-Type 26 has no special meaning and MUST NOT be treated as a Vendor-Specific Attribute.