RFC 6929
Remote Authentication Dial In User Service (RADIUS) Protocol Extensions
RFC 6929: Remote Authentication Dial-In User Service (RADIUS) Protocol Extensions 🎀
okay bestie, let's start with the basics 💅 This is an Internet Engineering Task Force (IETF) doc, published as Request for Comments 6929. The authors are A. DeKok (from Network RADIUS) and A. Lior 🫶
- Category: Standards Track 🌸
- Date: April 2013 🦋
- ISSN: 2070-1721 ✨
- Updates: 2865, 3575, 6158 🔥
So yes, this one updates RFCs 2865, 3575, and 6158. It's giving "I'm building on top of what you already made" energy 💜
Abstract
okay so RADIUS is literally running out of room 😭 Its Attribute Type space is stuck at 8 bits, and that space is nearly used up. People also really want complex grouping and attributes that can carry more than 253 octets of data. This doc sorts out all of those problems at once 💖
Status of This Memo
this is an Internet Standards Track document 🔥
it's a product of the IETF, so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 5741 🧚
for the current status, any errata, and how to give feedback, go to 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 doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the publication date. Please actually read those, bestie, because they explain your rights and restrictions 🙈
also, any Code Components pulled out of this doc have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no 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 🦋
okay so the RADIUS Attribute Type space is projected to be fully exhausted by 2014 or 2015 😱 We need a way to extend it so new specs can keep getting built. There are other issues too. The attribute grouping method from [RFC2868] turned out to be impractical, so we need something more powerful. A bunch of attributes already carry more than the 253 octets of data the protocol originally imagined, but each one gets handled as a "special case" inside RADIUS implementations instead of through one general method. So we also need a standard way to transport big chunks of data 💅 And finally, some vendors are almost out of Attributes in their Vendor-Specific Attribute space. It would be useful to use changes to the base protocol to extend that space too 🌸
here's how this doc handles all of it:
- 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 gives us a general way to extend the Attribute Type space (Section 2.1). 💖
- Allocating 4 attributes as using the format of "Extended Type". This 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 gives us a general way to add 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 gives 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 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 lets an attribute carry TLVs as "sub-Attributes", which can in turn encapsulate other TLVs as "sub-sub-Attributes". This creates a standard way to group a set of Attributes (Section 2.3). 🧚
- Defining a new "Extended-Vendor-Specific" (EVS) data type. This lets an attribute carry Vendor-Specific Attributes (VSAs) inside the new Attribute formats (Section 2.4). 🌈
- Defining a new "integer64" data type. This lets counters track more than 2^32 octets of data (Section 2.5). 💜
- Allocating 6 attributes using the new EVS data type. This 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 cover the entire 4 octets of the Vendor field. [RFC2865] Section 5.26 defined it as 3 octets, with the fourth octet being zero (Section 2.6). 🎀
- Describing compatibility with existing RADIUS systems (Section 5). 🦋
- Defining guidelines for using these changes, for IANA, for implementations of this spec, and for future RADIUS specs (Section 6). ⭐
as with any protocol change, these changes are the result of a bunch of compromises 🙈 The goal was to balance flexibility, space in the RADIUS message, compatibility with existing deployments, and how hard it is to implement.
1.1. Caveats and Limitations
this section covers some caveats and limitations of the proposal 💀
1.1.1. Failure to Meet Certain Goals
one goal the changes above did not meet is giving standards an incentive to use the new space. That incentive is coming from the exhaustion of the standard space instead 😭🫠
1.1.2. Implementation Recommendations ✨
Okay bestie, the big ask here is that implementations support this spec, and that new specs use these formats. It is RECOMMENDED that implementations support this specification. It is RECOMMENDED that new specifications use the formats defined in this specification. 💖
The alternative is kind of a circular trap 🙃 Nobody implements it because no other standards reference it, and nobody writes new standards that reference it because there are no implementations. Chaotic loop, no thank you 💀
As I mentioned earlier, the standard space is almost completely full 😭 Ignoring the looming crisis benefits no one. 🫶
1.2. Terminology 🎀
Here are the terms we're using in this doc, so we're all on the same page 📖
Silently discard
This means the implementation drops the packet without any 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 the Length field of an Attribute is valid (as per [RFC2865], Section 5, top of page 25), but the contents of the Attribute don't follow the correct format. Like, an Attribute of type "address" that holds more than four, or less than four, octets of data. 🙈 See Section 2.8 for the full, more complete definition.
Standard space
This refers to codes in the RADIUS Attribute Type space that IANA allocates and that follow the format defined in Section 5 of [RFC2865]. 🌸
Extended space
This refers to codes in the RADIUS Attribute Type space that need the extensions defined in this document. It's an extension of the standard space, but these codes can't be represented inside 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 💅
Okay, so there are a few special words in this doc that signal how strict a requirement is. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119]. 🔥 These are the words that tell you what's mandatory, what's optional, and everything in between, so pay attention to them! 👑
2. Extensions to RADIUS 🌸
This section defines two new Attribute formats: "Extended Type" and "Long Extended Type". 🎀 It also defines a new Type-Length-Value (TLV) data type, an Extended-Vendor-Specific (EVS) data type, and an Integer64 data type. ✨ It gives a new way to name attributes and identify them using the new Attribute formats. And finally, it defines the new term "invalid attribute" and explains how that 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 spec. This reuse lets the new formats play nicely with RADIUS implementations that don't implement this specification. Those implementations can simply ignore the "Value" field of an attribute or forward it verbatim. 🦋
The changes to the Attribute format happen by "stealing" one or more octets from the "Value" field. 😳 This means the "Value" field of [RFC2865] Section 5 holds both the new octets defined here and any attribute-specific Value. As a result, "Value"s in this specification are limited to less than 253 octets in size. 📏 This limit is overcome through the use of the "Long Extended Type" format. 🌈
We reiterate that the formats in this document don't insert new data into an attribute. Instead, we "steal" one octet of Value, so the definition of the Length field stays 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 lets the new formats be compatible with RADIUS implementations that don't 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". 🎀 Here's a quick summary of the Attribute format. 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. 🚫
Heads up: Length 2 or 3 on an Extended Attribute means it gets treated as an "invalid attribute". Handle it per Section 2.8. ⚠️
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 only meaningful within a context defined by the Type field. 🌈 So this field can 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 don't continue that practice here with the Extended-Type field. 🫶
2.2. Long Extended Type ✨
okay so this section introduces "Long Extended Type" 🎀, which is basically the Extended Type format leveled up so it can carry attributes with more than 253 octets of data 💅. Here's the layout, fields go 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 tells you the length of this Attribute, counting the Type, Length, Extended-Type, and "Value" fields too. Permitted values are between 5 and 255. If a client or server gets 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 only covers this fragment. There's no field that gives the total size of the whole fragmented attribute, so it's not in there anywhere 🙈
Extended-Type 💜 This field is identical to the Extended-Type field defined above in Section 2.1.
M (More) 🔥 This one is a single bit, and it tells you whether 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), that means 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". So basically, 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). Not allowed, bestie 🚫
To say it another way, a packet with a fragmented attribute needs to hold every single fragment of that Attribute, and those fragments need to sit next to each other in the packet 🫶 RADIUS does not support inter-packet fragmentation, which means you can't split one attribute across multiple packets. Impossible, no cap 💀
If a client or server gets an attribute fragment with the "More" field set (1) but can't find any subsequent fragment for it, then that 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 give this field extra meaning, so implementations MUST NOT treat this field as invalid if it is non-zero. Main character energy for future-proofing ✨
Value 🌈 This field is similar to the "Value" field of the Attribute format defined in [RFC2865] Section 5. It may hold a complete set of data (when the Length field has a value of less than 255), or it may hold 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. Like, that combo is the key 🔑
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) they were built from. 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. Reassemble first, judge later 🧁
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. Full send, no notes 🚀
This definition increases the RADIUS Attribute Type space as above, but it also makes room for 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, fragments included. Implementations MUST be able to process non-contiguous fragments, meaning fragments that are mixed together with other attributes of a different Type. This lets them accept packets, as long as the Attributes can still be decoded correctly 🫧
2.3. TLV Data Type 🧚
okay this is where we define a brand new data type in RADIUS called "tlv" 💖 The "tlv" data type is an encapsulation layer, so the "Value" field of an Attribute can hold brand new sub-Attributes inside it. Those sub-Attributes can have their own "Value"s of data type TLV too 🪆 This extends the Attribute space AND lets you nest attributes, which is so iconic. You can use the nesting to group data into one or more logical containers 📦
The "tlv" data type reuses the RADIUS Attribute format, which looks like this:
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. Nope, 26 is not VSA, don't even 🙅♀️
Like the Extended-Type field from before, the TLV-Type only means something inside the context of the "Type" fields of the attributes wrapping it 🎭 So you can think of it as making a new type space that looks like "Type.Extended-Type.TLV-Type". When TLVs are nested, the type space looks like "Type.Extended-Type.TLV-Type.TLV-Type", and so on, layer by layer 🪞
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. Pass it along exactly as it came in 📬
TLV-Length 🍒 The TLV-Length field is one octet and tells you the length of this TLV, counting the TLV-Type, TLV-Length, and TLV-Value fields too. It MUST have a value between 3 and 255. If a client or server gets 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. Big yikes if that happens 😬
TLV-Value 🌷 The TLV-Value field is one or more octets and holds information specific to the Attribute. Its format and length are decided 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, since 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 also incompatible with RADIUS and need to be redesigned. Not it, sweetie 🙃
The TLV-Value field MUST NOT contain data using the "Extended Type" formats defined in this document. The base Extended Attributes format is already flexible enough that nesting them inside of a TLV adds very little 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 doesn't 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. Pick TLV for your VSAs, it's the move 🏆
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. Ordering drama, but make it structured 🎀
The interpretation of multiple TLVs of the same TLV-Type MUST be that of a logical "and", unless otherwise specified. That means multiple TLVs are read as an unordered set of values 🫶 Specifications SHOULD NOT define TLVs to be interpreted as a logical "or". Doing so would mean a RADIUS client or server would make an arbitrary and non-deterministic choice among the values, and that's just chaos 🌀
2.3.1. TLV Nesting 🪆💜
TLVs may contain other TLVs. When this happens, the "container" TLV MUST be completely filled by the "contained" TLVs. That means 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. Overstuffed containers are a no-go 🚫📦
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 haven't been shown to be necessary in practice, and they seem to make implementations more complex 🙈 Reception of packets with such deeply nested TLVs may point to implementation errors or deliberate attacks, so be suspicious, bestie 🚨 Where implementations don't support deep nesting of TLVs, it is RECOMMENDED that the unsupported layers are treated as "invalid attributes" 💖
2.4. EVS Data Type 💖
okay so, we're introducing a brand new data type in RADIUS called "evs", short for "Extended-Vendor-Specific" 🎀 it's basically an encapsulation layer. The EVS-Value field of an Attribute can hold a Vendor-Id, then an EVS-Type, then whatever vendor-defined data the vendor wants. That data can even contain valid RADIUS data types, or anything else the vendor decides ✨
This data type is meant for attributes that carry vendor-specific info, the same job the Vendor-Specific Attribute (Attribute number 26) already does 🦋 It is RECOMMENDED that a vendor only use this data type once the Vendor-Specific Attribute Type space has been fully allocated 💅
Now, where [RFC2865] Section 5.26 gives a recommendation for the format of the data after the Vendor-Id, we give a strict definition 🔥 Real talk, lots of vendors didn't follow the [RFC2865] recommendations, and that caused interoperability drama 💀 So the goal here is to give vendors enough flexibility to meet their needs while keeping non-standard VSA formats to a minimum 🌸
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 🙈
Here's a summary of the "evs" format. Fields go 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 🌈 This one is a single octet. The values are assigned at the sole discretion of the vendor, so the vendor is the boss here 👑
EVS-Value ✨ This field is one or more octets. It SHOULD encapsulate a standard RADIUS data type. Using non-standard data types is NOT RECOMMENDED 😭 We also note that the EVS-Value field may be of data type TLV. However, it MUST NOT be of data type "evs", because the use cases are unclear for one vendor delegating Attribute Type space to another vendor 🙅♀️
The actual format of the info is site or application specific. A robust implementation SHOULD support the field as undistinguished octets 🫶 We know vendors have complete control over what goes in the EVS-Value field and how it's formatted, but 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 🙈
Quick but important detail: unlike the format in [RFC2865] Section 5.26, this data type has no "Vendor-Length" field 🎀 So the EVS-Value length is implicit. You take the "Length" of the encapsulating RADIUS attribute, then subtract the Attribute header (2 octets), the "Extended Type" (1 octet), the Vendor-Id (4 octets), and the EVS-Type (1 octet). For "Extended Type" Attributes that means the EVS-Value length is eight (8) less than the Length field, and for "Long Extended Type" Attributes it's nine (9) less than the Length field 🧮💅
2.5. Integer64 Data Type 🔥
we're defining another new RADIUS data type, called "integer64" 🦋 It carries a 64-bit unsigned integer in network byte order.
This one is for any situation where you need counters that can count past 2^32 🌸 The expected home for it is 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 💖
Here's the summary of the "integer64" format. Again, 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 with 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, the Length field MUST be set to ten (10). For "Extended Type" Attributes, it MUST be set to eleven (11). For "Long Extended Type" Attributes, it MUST be set to twelve (12) 🎀
2.6. Vendor-Id Field 🌸
okay so we're defining the Vendor-Id field of Vendor-Specific Attributes to cover the entire 4 octets of the Vendor field 🍓 [RFC2865] Section 5.26 said it was 3 octets, with the fourth octet being zero. This change has no immediate impact on RADIUS, because the maximum Private Enterprise Code defined is still within 16 bits 🙌
Still, it's smart to prep for protocol changes ahead of time 🔮 So 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 so that we can refer to attributes of "Extended Type" and to TLVs. IANA will also use it when allocating RADIUS Attribute Type values 📋
The names and identifiers here are meant only for use in specifications 🤓 The system may not be useful when referring to the contents of a RADIUS packet. It imposes no requirements on implementations, because implementations are free to reference RADIUS attributes via any method they choose 🦋
2.7.1. Attribute and TLV Naming 🎀
RADIUS specs traditionally use names made of one or more words, separated by hyphens, like "User-Name" 💖 These names aren't allocated from a registry, and the only restriction on global uniqueness is convention 🙃
Vendors have often used their company name as the prefix for VSA names, though it's not universal 🌈 For example, for a vendor named "Example", "Example-Attribute-Name" SHOULD be used instead of "Attribute-Name". The second form can conflict with attributes from other vendors, but the first form can't 😤
So it is RECOMMENDED that specifications name Attributes in a way that tries to be globally unique across all RADIUS Attributes. It is RECOMMENDED that a vendor use its name as a unique prefix for attribute names, like Livingston-IP-Pool instead of IP-Pool 🍓 It is RECOMMENDED that implementations enforce uniqueness on names, because not doing so leads to ambiguity and problems 🚨
We know these suggestions can be hard to implement in practice 🫶
TLVs SHOULD be named with a unique prefix that's shared among related attributes. For example, a spec defining a set of TLVs related to time could create attributes called "Time-Zone", "Time-Day", "Time-Hour", "Time-Minute", and so on ⏰
2.7.2. Attribute Type Identifiers 🔢
The RADIUS Attribute Type space gives 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 an identification method using a "dotted number" notation, similar to the one used for Object Identifiers (OIDs), formatted as "Type.Extended-Type" 🌟
For example, an attribute in the Type space of 241, with an Extended-Type of one (1), is uniquely identified as "241.1" 💜 Similarly, an attribute in the Type space of 246, with an Extended-Type of ten (10), is uniquely identified as "246.10" ✨
2.7.3. TLV Identifiers 🧩
We can extend the Attribute reference scheme above to TLVs 🎀 We do this 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" to identify the TLV. This can be repeated in sequence for nested TLVs 🪆
Say "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 ".1" to the number of the encapsulating attribute ("241.1"), giving "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 🦋
Historically there's been no method for numerically addressing VSAs 😭 The "dotted number" method defined here can also be used to create that kind of addressing scheme. However, since VSAs are completely under the control of each individual vendor, this section gives a suggested practice but does not define a standard of any kind 🙏
The Vendor-Specific Attribute has been assigned Attribute number 26. It 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 can't be uniquely identified by name, because other vendors may have used the same name 🙈
Note that there are few restrictions on the size of the numbers 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 not uniquely 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 the vendor assigned to the different nested TLVs 🫶
2.8. Invalid Attributes ✨
okay bestie, "invalid attribute" is a brand new term in this spec 💅 It means the Length field of an Attribute is fine enough that the packet can still be accepted as not "malformed" 🌸 BUT the Value field doesn't follow the format that the data type for that Attribute requires 😭 So the Attribute itself is "malformed". We call packets "malformed" and Attributes "invalid attributes" so nobody gets confused 🫶
Here's a good example. An implementation gets a packet that is well formed 💖 Inside it is an Attribute that's supposedly data type "address", but its Length isn't equal to four. The packet is well formed, but the Attribute isn't, so it's an "invalid attribute" 🙈
The same logic works when an attribute carries TLVs 🧚 The encapsulating attribute can be well formed while the TLV inside is an "invalid attribute". Now, the existence of an "invalid attribute" in a packet or attribute MUST NOT make the implementation throw away the entire packet, or treat the packet as a negative acknowledgment. Only the "invalid attribute" gets special handling 🎀
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 isn't discarded, it MUST NOT be handled the same way as a well-formed attribute. For instance, an Attribute of data type "address" with either less than four octets or more than four octets of data MUST NOT be treated as data type "address". Why? If the Attribute doesn't carry an IPv4 address, the receiver has no idea what format the data is in, so it's definitely not an IPv4 address 💀
For Attributes of type "Long Extended Type", an Attribute counts as an "invalid attribute" when it doesn't match the criteria in Section 2.2, above 🌈
For Attributes of type "TLV", an Attribute counts as an "invalid attribute" when the TLV-Length field lets the encapsulating Attribute be parsed, but the TLV-Value field doesn't match the criteria for that TLV 🍓 Implementations SHOULD NOT treat the "invalid attribute" property as transitive. Like, the Attribute that encapsulates the "invalid attribute" SHOULD NOT be treated as an "invalid attribute" itself 🙃 That encapsulating Attribute might hold multiple TLVs, and only one of them is the bad one 💜
Now, a TLV definition might require certain sub-TLVs to be present and/or to have specific values 👑 If a sub-TLV is missing, has incorrect value(s), or is itself an "invalid attribute", then the encapsulating TLV SHOULD be treated as an "invalid attribute". This is what keeps strongly connected TLVs either handled as a coherent whole or ignored entirely 🫶✨
It is RECOMMENDED that Attributes with unknown Type, Extended-Type, TLV-Type, or EVS-Type get treated as "invalid attributes" 🔥 This fits the suggestion in [RFC2865] Section 5 that implementations "MAY ignore Attributes with an unknown Type" 🦋
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-2The rest of this section gives the detailed definitions for each Attribute, based on the summary above 🧚
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} 💅
Here's a summary of the Extended-Type-1 Attribute format 👇 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 ✨
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, following the policies and rules in Section 10. More on this field is 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 figure out how to interpret 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} 💖
Here's a summary of the Extended-Type-2 Attribute format 👇 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, following the policies and rules in Section 10. More on this field is 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 figure out how to interpret 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} 🌸
Here's a summary of the Extended-Type-3 Attribute format 👇 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, following the policies and rules in Section 10. More on this field is 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 figure out how to interpret the "Value" field 💅
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} ✨
Here's a summary of the Extended-Type-4 Attribute format 👇 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, following the policies and rules in Section 10. More on this field is 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 figure out how to interpret the Value Field 🎀
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} 🦋
Here's a summary of the Long-Extended-Type-1 Attribute format 👇 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, following the policies and rules in Section 10. More on this field is in Section 2.1, above ✨
M (More)
The More field is one (1) bit long and shows whether the current attribute contains "more" than 251 octets of data 🫶 More on this field is 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 💅
Value
The "Value" field is one or more octets 🔥 Implementations supporting this specification MUST use the identifier of "Type.Extended-Type" to figure out how to interpret the "Value" field 👑
3.6. Long-Extended-Type-2 🎀
Description
okay so this attribute is a wrapper for attributes using the "Long Extended Type" format 🫶 It lives in the RADIUS Attribute Type space of 246.{1-255}. ✨
Here's the layout of the Long-Extended-Type-2 Attribute format. Fields go 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 🦋 Its up-to-date values live in the 246.{1-255} RADIUS Attribute Type space, following the policies and rules in Section 10. You'll find more on this field in Section 2.1, above.
M (More)
The More field is one (1) bit and tells you whether the current attribute holds "more" than 251 octets of data. 👀 More on this 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.
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. ✨ That's the key to decoding it, bestie 🔑
4. Vendor-Specific Attributes ✨
okay this section is where the vendor-specific magic happens 🧚 We define six new attributes that can carry vendor-specific information 💅 Four (4) are in the "Extended Type" format, with Type codes (241.26, 242.26, 243.26, 244.26), and they use the "evs" data type. Two (2) are in the "Long Extended Type" format, with Type codes (245.26, 246.26), and they're also 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-6The rest of this section gives the detailed definitions for each Attribute, based on the summary above. 📝
4.1. Extended-Vendor-Specific-1 💜
Description
This attribute defines a RADIUS Type Code of 241.26, using the "evs" data type. 🎀
Here's the Extended-Vendor-Specific-1 Attribute format, 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 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.2. Extended-Vendor-Specific-2 🦋
Description
This attribute defines a RADIUS Type Code of 242.26, using the "evs" data type. 💅
Here's the Extended-Vendor-Specific-2 Attribute format, 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. 🦄
Value
The "Value" field is one or more octets. The actual format 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. 🍓
Here's the Extended-Vendor-Specific-3 Attribute format, 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. 🏢
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 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. 🫶
Here's the Extended-Vendor-Specific-4 Attribute format, 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
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 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
okay so this attribute defines a RADIUS Type Code of 245.26, and it uses the "evs" data type 💅
Here's what the Extended-Vendor-Specific-5 Attribute looks like. The fields go left to right, obviously 🦋
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
it's 245.26 for Extended-Vendor-Specific-5, no notes 🌸
Length
the length has two possible vibes:
>= 10for the first fragment 🍓>= 5for subsequent fragments ✨
bestie, when a VSA gets fragmented across multiple Attributes, ONLY the first Attribute has the Vendor-Id and Vendor-Type fields. The later ones are just fragments of the "Value" field 🧚
M (More)
the More field is one (1) bit long, and it tells you whether the current attribute has "more" than 251 octets of data. We'll get the full tea on this in Section 2.2, above 🫶
Reserved
this field is 7 bits long and it's reserved for future use, so it's just chilling for now 💜 Implementations MUST set it to zero (0) when encoding an attribute for sending in a packet. On reception the contents SHOULD be ignored, which is very "don't touch what's not yours" energy 💅
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
this one is just one octet, and the values are assigned at the sole discretion of the vendor. Their call, their rules 👑
Value
the "Value" field is one or more octets. The actual format is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets 🌈
the codification of the range of allowed usage for this field is outside the scope of this specification, so that's a no from us 🙈
Implementations supporting this specification MUST use the identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to determine the interpretation of the "Value" field. This part is non-negotiable, periodt 😭
4.6. Extended-Vendor-Specific-6 🌸
Description
this attribute defines a RADIUS Type Code of 246.26, and it uses the "evs" data type. Iconic 💖
The Extended-Vendor-Specific-6 Attribute format is below, and once again the fields go 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
it's 246.26 for Extended-Vendor-Specific-6 🦋
Length
>= 10for the first fragment 💅>= 5for subsequent fragments 🫶
same drama as before: 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 long and indicates whether or not the current attribute contains "more" than 251 octets of data. Section 2.2, above, has the deets 🌈
Reserved
seven bits, 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. Same as last time, no notes 💜
Vendor-Type
one octet. Values are assigned at the sole discretion of the vendor, so the vendor is the boss here 👑
Value
the "Value" field is one or more octets. The actual format 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. Rules are rules, bestie 🍓
5. Compatibility with Traditional RADIUS 🧚
okay this is the part where we talk about the compat drama with traditional RADIUS. There are a bunch of potential issues with traditional RADIUS, which is defined in [RFC6158] and earlier, and this section spills all the tea on them 🫶
5.1. Attribute Allocation 💅
some vendors have used Attribute Type codes from the "Reserved" space as part of vendor-defined dictionaries. Honestly? That's considered antisocial behavior, as noted in [RFC6158] 💀 These vendor definitions conflict with the Attributes in the RADIUS Attribute Type space, so it can be really hard 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 "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, so no thank you 🙈
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, lucky them ✨ 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, because that kind of vendor usage has always clashed 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 don't implement support for encoding and decoding 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 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 don't understand (i.e., attributes for which they have no local dictionary definitions). 🙈
This practice is NOT RECOMMENDED. Proxy servers SHOULD forward attributes, even attributes that they don't understand or that aren't in a local dictionary. When forwarded, these attributes SHOULD be sent verbatim, with no modifications or changes. This requirement includes "invalid attributes", because 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, so it needs a set of guidelines, just like [RFC6158] got. 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 💅
6.2. Guidelines for Simple Data Types ✨
okay so [RFC6158] Section A.2.1 has this bit, and it's giving very strict vibes 💅:
- 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're updating that one to allow 64-bit unsigned integers 🫶, for the reasons from Section 2.5 up above. The updated text reads:
- 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 also has a second list item, which says:
- Nested attribute-value pairs (AVPs). Attributes should be defined in a flat typespace.
We're updating this one to allow 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. Everything else [RFC6158] says about "basic" data types stays exactly the same 🌸.
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).
Okay, so the extended Attribute format lets you group complex types with TLVs 🧚, which means the complex data type guidelines need an update too:
[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 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 gets a new requirement at the very top, like this 👑:
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 still allows complex types to be carried in certain situations 🙈.
Everything else [RFC6158] says about "complex" data types stays unchanged.
6.4. Design Guidelines for the New Types 🦋
This section has design guidelines for specs that define attributes in the new format. The list below is NOT exhaustive 💅, so later specs might add more guidelines as we get more experience with the new formats.
- The data type "evs" MUST NOT be used for standard RADIUS Attributes, 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. 64-bit integers weren't recommended in [RFC6158], but their usefulness is now obvious 😭🔥.
- Any attribute allocated from the long extended space with data type "text", "string", or "tlv" can potentially carry more than 251 octets of data. Specs defining these attributes SHOULD define a maximum length to guide implementations 🍓.
Everything else [RFC6158] says about attribute design guidelines applies to attributes using the short extended space and the long extended space 🌈.
6.5. TLV Guidelines 🌸
Here are some design guidelines for specs that use TLVs ✨:
- When multiple Attributes are meant to be grouped or managed together, using 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, is 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 🦋.
Everything else [RFC6158] says about attribute design guidelines applies to attributes using the TLV format 💅.
6.6. Allocation Request Guidelines 🍓
These are 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 better suited to 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.
- 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 encodes 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 spec authors and IANA communicate 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 💖.
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 so that specs using the changes defined here can be deployed easily 🎀.
- RADIUS server implementations SHOULD support this specification so that specs using the changes defined here can be deployed easily 👑.
- 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, since this specification may take a while to become widely deployed 🌸.
- Vendors SHOULD implement this specification. The changes to RADIUS are relatively small and are likely to be picked up quickly in new specifications 💅✨.
7. Rationale for This Design 🧚
okay so the road to extending RADIUS has been long and rough 😭. A bunch of proposals got made and then tossed by the RADEXT working group. They were judged to be too bulky, too complex, too simple, or just unworkable in practice 💀. We don't go into why earlier proposals didn't get working group consensus here 🙈.
The changes here are lowkey genius because they're simple: the "Extended Type" format only needs a one-octet change to the Attribute format 🦋. The catch is that the "Long Extended Type" format is kind of awkward, and the 7 Reserved bits will probably 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 TotalThe entries in the "Data Type" column are data types recommended by [RFC6158], along with "integer64". The "other data types" row covers everything else, including complex data types and data types carrying opaque data 🎀.
We see that over half of the Attributes encode less than 16 octets of data 👀. So it's 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. That's approximately 4% of the total. We didn't investigate whether additional attributes were defined in a flat namespace but could have been defined as being inside of a TLV. We expect the number could be as high as 10% of attributes 🧚.
Manual inspection of the dictionaries shows that approximately 20 (or 0.5%) attributes can transport more than 253 octets of data. These attributes are split 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 supports "long" attributes 👑✨.
8. Diameter Considerations ✨
okay so the Attribute formats in this spec have to ride along in Diameter 🚗💨. Diameter can handle attributes longer than 253 octets and grouped attributes, but we're not using any of that here. We went with the simplest possible encapsulation method, bestie 🫶
the new formats MUST be treated the same as traditional RADIUS attributes when you're converting from RADIUS to Diameter or the other way around 💅 the new attribute space doesn't get converted into any "extended" Diameter attribute space. fragmented attributes don't get squished into one long Diameter attribute either. and the new EVS data types don't turn into Diameter attributes with the "V" bit set. no notes 🙅♀️
so yeah, this document doesn't require any changes for existing RADIUS-to-Diameter or Diameter-to-RADIUS gateways 🎀 gateways stay chill!
9. Examples
we're gonna look at a few examples so you can see how the new Attribute formats get encoded 🦋 these are just a taste, not the full menu, because there are soooo many other possibilities 🍓 and to keep things simple, we're showing attributes only, not complete packets.
the examples are written in a domain-specific language that's run by the program in Appendix A of this document. the language is line oriented, and every line matches this ABNF grammar ([RFC5234]):
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 DATAthe program has extra restrictions on its input that the grammar above doesn't show. for example, the parts of the identifier that stand for Type and Extended-Type are limited to values between 1 and 255. we trust the source code in Appendix A to be clear, and we don't think these restrictions make the examples any harder to follow 🧚
the program reads the input text and treats it as instructions for creating RADIUS attributes. then it prints the hex encoding of those attributes 💖 it only does the bare minimum to get there. so it doesn't use attribute dictionaries, it doesn't support RADIUS data types, it can encode attributes with invalid data fields, and the examples aren't consistent with each other. for example, it'll happily encode a User-Name attribute holding non-UTF8 data, or a Framed-IP-Address holding 253 octets of ASCII data 💀 which means it MUST NOT be used to create RADIUS attributes for transport in a RADIUS message. not for the real deal, only for the examples!!
BUT the program does encode the RADIUS attribute fields "Type", "Length", "Extended-Type", "More", "Reserved", "Vendor-Id", "Vendor-Type", and "Vendor-Length" correctly ✨ it also handles the RADIUS attribute data types "evs" and "tlv". so it's totally fine for turning human-readable inputs into example attributes 🌸
we're not giving any examples of "invalid attributes" 🙈 also, the examples are about showing the format, not about keeping a consistent meaning. the same Attribute Type code can show up with two different formats. in real specs, attributes have static definitions tied to their type code, so don't get confused 😭
the examples below are strictly for demonstration and aren't a standard of any kind, so please don't treat them as one 🫶
9.1. Extended Type
here's a bunch of examples of the "Extended Type" format 🌈
attribute encapsulating textual data:
241.1 "bob"
-> f1 06 01 62 6f 62attribute encapsulating a TLV with TLV-Type of one (1):
241.2 { 1 23 45 }
-> f1 07 02 01 04 23 45attribute 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 89attribute 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 cdattribute 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 6fattribute 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 efattribute 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 74attribute 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 749.2. Long Extended Type
now the same vibe for the "Long Extended Type" format 🦋
attribute encapsulating textual data:
245.1 "bob"
-> f5 07 01 00 62 6f 62attribute encapsulating a TLV with TLV-Type of one (1):
245.2 { 1 23 45 }
-> f5 08 02 00 01 04 23 45attribute 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 89attribute 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 cdattribute 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 6fattribute 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 efattribute 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 74attribute 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 74attribute encapsulating more than 251 octets of data. the "Data" portions are indented so they're easier to read 👀:
245.4 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbcccccccccccccccccccc
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 ccbelow 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 🍓
since the VSA holds more than 251 octets of data, it gets 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. the second attribute does NOT include the Vendor-Id and Vendor-Type fields, so don't go looking for them there 🙅♀️
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 cc10. IANA Considerations
okay IANA stuff 📋 this document UPDATES [RFC3575] because it adds new IANA considerations for RADIUS attributes 💜 but these are a glow-up, not a replacement. they modify and extend the existing RADIUS IANA considerations, they don't wipe them out 🫶
the IANA considerations in this document are limited to the "RADIUS Attribute Types" registry 🌸 some Attribute Type values that used to be marked "Reserved" are now allocated, and the registry grows from a simple 8-bit array into a tree-like structure, with a maximum depth of 125 nodes. the detailed instructions are 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 work as an encapsulation layer for the new RADIUS Attribute Type tree 🌳 they're the front door, bestie 🚪💅
10.2. RADIUS Attribute Type Tree
Okay so every Attribute Type value we allocated above basically grows the "RADIUS Attribute Types" space into an N-ary tree 🌳 using dotted numbers. If somebody allocates a TYPE using the new "Extended Type" format, they instantly get 255 brand new Attribute Type values, from TYPE.1 all the way up to TYPE.255 ✨. Value 26 is taken as "Extended-Vendor-Specific-*" 🎀, and values TYPE.241 through TYPE.255 are marked "Reserved" 🔒. Everything else is "Unassigned" 💅.
Here's the initial set of Attribute Type values and names that this document assigns 👑:
* 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} ReservedAs per [RFC5226] 📚, the values marked "Unassigned" above are up for grabs for IANA to hand out in future RADIUS specifications ✨. The values marked "Reserved" are kept aside for future use, so hands off 🙅♀️.
The Extended-Vendor-Specific spaces (TYPE.26) are for Private Use 🔐, and IANA does not manage those allocations.
Allocating Reserved entries in the extended space requires Standards Action 🫶. All other allocations in the extended space require IETF Review.
10.3. Allocation Instructions
This section spells out what IANA needs to do when new attributes get allocated 📝. The steps are different depending on whether the attribute comes from the standard space, the "Extended Type" format, the "Long Extended Type" format, preferential allocations, a TLV data type, something nested inside a TLV, or any other data type. Pay attention, it matters 💖.
10.3.1. Requested Allocation from the Standard Space
Specifications can ask for an Attribute from within the standard space (e.g., Attribute Type Codes 1 through 255) 🎯, but that's subject to the considerations of [RFC3575] and this document.
10.3.2. Requested Allocation from the Short Extended Space
Specifications can ask for an Attribute that needs the "Extended Type" format by naming the short extended space 🌸. When that happens, 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 ask for an Attribute that needs the "Long Extended Type" format by naming the extended space (long) 🧚. When that happens, IANA should assign the lowest Unassigned number from the Attribute Type space with the relevant format.
10.3.4. Allocation Preferences
If a specification doesn't ask for allocation from any particular type space, its Attributes should be allocated using these 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.
- 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's otherwise no requirement that all the attributes in a specification come from one type space or another 🦋. A specification can allocate attributes from both the standard space and the extended space at the same time.
10.3.5. Extending the Type Space via the TLV Data Type
When a specification requests allocation of an attribute of data type TLV, that allocation pushes the Attribute Type tree one more level deeper 🌈. Allocating an Attribute Type value "TYPE.TLV" with data type TLV results in 255 new Attribute Type values, of format "TYPE.TLV.1" through "TYPE.TLV.255". Values 254-255 are marked "Reserved", and all other values are "Unassigned". Value 26 has no special meaning here.
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 like this:
* 245.1 Example-TLV
* 245.1.{1-253} Unassigned
* 245.1.{254-255} ReservedNote that this example does not define an "Example-TLV" attribute 🙈.
The Attribute Type tree can be extended multiple levels in one specification when that 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 allocated previously.
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.
When 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 for everything else are made 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 🔐
Okay, serious moment, bestie 🥺. 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 they keep getting better with time, as discussed in [RFC4270] 😭. The security of the RADIUS protocol depends 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. Those 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.
[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 everyone who contributed ideas over the years. Their feedback has been invaluable and has made this specification better 💜.
Appendix A. Extended Attribute Generator Program 🧚
This section contains "C" program source code that you can use 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 a grammar similar to the one given in Section 9, with a few modifications for usability ✨. For example, blank lines are allowed, lines beginning with a '#' character are treated 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 🎀.
Okay bestie, this part is the license header and the start of the generator's C code. The code has to stay exactly as written, so it's all verbatim below, and the license text is still the same legal fine print 💅
/*
* 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,
* 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;
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++;
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;
}
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;
}
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;
}
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;
}
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;
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;
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;
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;
}Authors' Addresses ✨
Okay bestie, the code is wrapping up, and then we get to the people who wrote this whole thing! 🫶
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];
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]);
}
printf("\n");
}
if (fp != stdin) fclose(fp);
return 0;
}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 💖
📦 where this page comes from
- ietf: rfc6929 2013-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms