idnits 2.17.1 draft-ietf-radext-radius-extensions-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC2865, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3575, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2866, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5176, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC6158, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (Using the creation date from RFC2865, updated by this document, for RFC5378 checks: 1999-03-04) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (8 January 2013) is 4125 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 2957 -- Looks like a reference, but probably isn't: '0' on line 2892 -- Looks like a reference, but probably isn't: '2' on line 2842 -- Looks like a reference, but probably isn't: '3' on line 2872 -- Looks like a reference, but probably isn't: '4' on line 2796 -- Looks like a reference, but probably isn't: '8192' on line 2934 -- Looks like a reference, but probably isn't: '4096' on line 2935 == Unused Reference: 'RFC5176' is defined on line 2403, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2866 ** Downref: Normative reference to an Informational RFC: RFC 5176 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'PEN' Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Alan DeKok 3 INTERNET-DRAFT Network RADIUS 4 Category: Proposed Standard Avi Lior 5 Updates: 2865, 2866, 3575, 5176, 6158 BWS 6 7 Expires: July 8, 2013 8 8 January 2013 10 Remote Authentication Dial In User Service (RADIUS) Protocol 11 Extensions 12 draft-ietf-radext-radius-extensions-08.txt 14 Abstract 16 The Remote Authentication Dial In User Service (RADIUS) protocol is 17 nearing exhaustion of its current 8-bit Attribute Type space. In 18 addition, experience shows a growing need for complex grouping, along 19 with attributes which can carry more than 253 octets of data. This 20 document defines changes to RADIUS which address all of the above 21 problems. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on June 26, 2013. 46 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info/) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction ............................................. 5 63 1.1. Caveats and Limitations ............................. 6 64 1.1.1. Failure to Meet Certain Goals .................. 6 65 1.1.2. Implementation Recommendations ................. 6 66 1.2. Terminology ......................................... 7 67 1.3. Requirements Language ............................... 8 68 2. Extensions to RADIUS ..................................... 9 69 2.1. Extended Type ....................................... 10 70 2.2. Long Extended Type .................................. 11 71 2.3. TLV Data Type ....................................... 13 72 2.3.1. TLV Nesting .................................... 15 73 2.4. EVS Data Type ....................................... 16 74 2.5. Integer64 Data Type ................................. 17 75 2.6. Vendor-ID Field ..................................... 18 76 2.7. Attribute Naming and Type Identifiers ............... 18 77 2.7.1. Attribute and TLV Naming ....................... 18 78 2.7.2. Attribute Type Identifiers ..................... 19 79 2.7.3. TLV Identifiers ................................ 19 80 2.7.4. VSA Identifiers ................................ 20 81 2.8. Invalid Attributes .................................. 20 82 3. Attribute Definitions .................................... 21 83 3.1. Extended-Type-1 ..................................... 22 84 3.2. Extended-Type-2 ..................................... 23 85 3.3. Extended-Type-3 ..................................... 23 86 3.4. Extended-Type-4 ..................................... 24 87 3.5. Long-Extended-Type-1 ................................ 25 88 3.6. Long-Extended-Type-2 ................................ 26 89 4. Vendor Specific Attributes ............................... 28 90 4.1. Extended-Vendor-Specific-1 .......................... 28 91 4.2. Extended-Vendor-Specific-2 .......................... 29 92 4.3. Extended-Vendor-Specific-3 .......................... 30 93 4.4. Extended-Vendor-Specific-4 .......................... 31 94 4.5. Extended-Vendor-Specific-5 .......................... 33 95 4.6. Extended-Vendor-Specific-6 .......................... 34 96 5. Compatibility with traditional RADIUS .................... 35 97 5.1. Attribute Allocation ................................ 36 98 5.2. Proxy Servers ....................................... 37 99 6. Guidelines ............................................... 38 100 6.1. Updates to RFC 6158 ................................. 38 101 6.2. Guidelines for Simple Data Types .................... 38 102 6.3. Guidelines for Complex Data Types ................... 39 103 6.4. Guidelines For the New Types ........................ 39 104 6.5. Allocation Request Guidelines ....................... 40 105 6.6. TLV Guidelines ...................................... 41 106 6.7. Implementation Guidelines ........................... 41 107 6.8. Vendor Guidelines ................................... 42 109 7. Rationale for This Design ................................ 42 110 7.1. Attribute Audit ..................................... 42 111 8. Diameter Considerations .................................. 43 112 9. Examples ................................................. 43 113 9.1. Extended Type ....................................... 45 114 9.2. Long Extended Type .................................. 46 115 10. IANA Considerations ..................................... 48 116 10.1. Attribute Allocations .............................. 49 117 10.2. RADIUS Attribute Type Tree ......................... 49 118 10.3. Allocation Instructions ............................ 50 119 10.3.1. Requested Allocation from the Standard Space .. 50 120 10.3.2. Requested Allocation from the short extended sp 50 121 10.3.3. Requested Allocation from the long extended spa 51 122 10.3.4. Allocation Preferences ........................ 51 123 10.3.5. Extending the Type Space via TLV Data Type .... 51 124 10.3.6. Allocation within a TLV ....................... 52 125 10.3.7. Allocation of Other Data Types ................ 52 126 11. Security Considerations ................................. 52 127 12. References .............................................. 53 128 12.1. Normative references ............................... 53 129 12.2. Informative references ............................. 53 130 Appendix A - Extended Attribute Generator Program ............ 55 131 1. Introduction 133 Under current allocation pressure, we expect that the RADIUS 134 Attribute Type space will be exhausted by 2014 or 2015. We therefore 135 need a way to extend the type space, so that new specifications may 136 continue to be developed. Other issues have also been shown with 137 RADIUS. The attribute grouping method defined in [RFC2868] has been 138 shown to be impractical, and a more powerful mechanism is needed. 139 Multiple attributes have been defined which transport more than the 140 253 octets of data originally envisioned with the protocol. Each of 141 these attributes is handled as a "special case" inside of RADIUS 142 implementations, instead of as a general method. We therefore also 143 need a standardized method of transporting large quantities of data. 144 Finally, some vendors are close to allocating all of the Attributes 145 within their Vendor-Specific Attribute space. It would be useful to 146 leverage changes to the base protocol for extending the Vendor- 147 Specific Attribute space. 149 We satisfy all of these requirements through the following changes 150 given in this document: 152 * defining an "Extended Type" format, which adds 8 bits of "Extended 153 Type" to the RADIUS Attribute Type space, by using one octet of the 154 "Value" field. This method gives us a general way of extending 155 the Attribute Type Space. (Section 2.1) 157 * allocating 4 attributes as using the format of "Extended Type". 158 This allocation extends the RADIUS Attribute Type Space by 159 approximately 1000 values. (Sections 3.1, 3.2, 3.3, and 3.4) 161 * defining a "Long Extended Type" format, which inserts an additional 162 octet between the "Extended Type" octet, and the "Value" field. 163 This method gives us a general way of adding additional 164 functionality to the protocol. (Section 2.2) 166 * defining a method which uses the additional octet in the "Long 167 Extended Type" to indicate data fragmentation across multiple 168 Attributes. This method provides a standard way for an Attribute 169 to carry more than 253 octets of data. (Section 2.2) 171 * allocating 2 attributes as using the format "Long Extended Type". 172 This allocation extends the RADIUS Attribute Type Space 173 by an additional 500 values. (Sections 3.5 and 3.6) 175 * defining a new "Type Length Value" (TLV) data type. The data type 176 allows an attribute to carry TLVs as "sub-attributes", which can in 177 turn encapsulate other TLVs as "sub-sub-attributes." This change 178 creates a standard way to group a set of Attributes. (Section 2.3) 180 * defining a new "extended Vendor-Specific" (EVS) data type. The 181 data type allows an attribute to carry Vendor-Specific Attributes 182 (VSAs) inside of the new attribute formats. (Section 2.4) 184 * defining a new "integer64" data type. The data type allows 185 counters which track more than 2^32 octets of data. (Section 2.5) 187 * allocating 6 attributes using the new EVS data type. This 188 allocation extends the Vendor-Specific Attribute Type space by 189 over 1500 values. (Sections 4.1 through 4.6) 191 * Define the "Vendor-ID" for Vendor-Specific attributes to encompass 192 the entire 4 octets of the Vendor field. [RFC2865] Section 5.26 193 defined it to be 3 octets, with the high octet being zero. 194 (Section 2.5) 196 * Describing compatibility with existing RADIUS systems. (Section 5) 198 * Defining guidelines for the use of these changes for IANA, 199 implementations of this specification, and for future RADIUS 200 specifications. (Section 6) 202 As with any protocol change, the changes defined here are the result 203 of a series of compromises. We have tried to find a balance between 204 flexibility, space in the RADIUS message, compatibility with existing 205 deployments, and implementation difficulty. 207 1.1. Caveats and Limitations 209 This section describes some caveats and limitations with the 210 proposal. 212 1.1.1. Failure to Meet Certain Goals 214 One gaol which was not met by the above modifications is to have an 215 incentive for standards to use the new space. We would ideally like 216 to deprecate the "Unassigned" attributes in the standard space, which 217 would permit allocation, but under more stringent guidelines. 218 However, [RFC5226] has no provisions for a "Deprecated" entry in an 219 IANA managed registry. 221 1.1.2. Implementation Recommendations 223 It is RECOMMENDED that implementations support this specification. 224 It is RECOMMENDED that new specifications use the formats defined in 225 this specification. 227 The alternative to the above recommendations is a circular argument 228 of not implementing this specification because no other standards 229 reference it, and also not defining new standards referencing this 230 specification because no implementations exist. 232 As noted earlier, the "standard space" is almost entirely allocated. 233 Ignoring the looming crisis benefits no one. 235 1.2. Terminology 237 This document uses the following terms: 239 silently discard 240 This means the implementation discards the packet without further 241 processing. The implementation MAY provide the capability of 242 logging the error, including the contents of the silently discarded 243 packet, and SHOULD record the event in a statistics counter. 245 invalid attribute 246 This means that the Length field of an Attribute is valid (as per 247 [RFC2865], Section 5, top of page 25). However, the Value field of 248 the attribute does not follow the format required by the data type 249 defined for that Attribute. e.g. an Attribute of type "address" 250 which encapsulates more than four, or less than four, octets of 251 data. See Section 2.8 for a more complete definition. 253 Standard space 254 Codes in the RADIUS Attribute Type Space that are allocated by IANA 255 and that follow the format defined in Section 5 of [RFC2865]. 257 Extended space 258 Codes in the RADIUS Attribute Type Space that require the 259 extensions defined in this document, and are an extension of the 260 standard space, but which cannot be represented within the standard 261 space. 263 Short extended space 264 Codes in the extended space which use the "Extended Type" format. 266 Long extended space 267 Codes in the extended space which use the "Long Extended Type" 268 format. 270 The following terms are used here with the meanings defined in BCP 271 26 [RFC5226]: "name space", "assigned value", "registration", 272 "Private Use", "Reserved", "Unassigned", "IETF Review", and 273 "Standards Action". 275 1.3. Requirements Language 277 In this document, several words are used to signify the requirements 278 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 279 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 280 and "OPTIONAL" in this document are to be interpreted as described in 281 [RFC2119]. 283 2. Extensions to RADIUS 285 This section defines two new attribute formats; "Extended Type"; and 286 "Long Extended Type". It defines a new Type-Length-Value (TLV) data 287 type, an Extended-Vendor-Specific (EVS) data type, and an Integer64 288 data type. It defines a new method for naming attributes and 289 identifying Attributes using the new attribute formats. It finally 290 defines the new term "invalid attribute", and describes how it 291 affects implementations. 293 The new attribute formats are designed to be compatible with the 294 attribute format given in [RFC2865] Section 5. The meaning and 295 interpretation of the Type and Length fields is unchanged from that 296 specification. This reuse allows the new formats to be compatible 297 RADIUS implementations which do not implement this specification. 298 Those implementations can simply ignore the Value field of an 299 attribute, or forward it verbatim. 301 The changes to the attribute format come about by "stealing" one or 302 more octets from the Value field. This change has the effect that 303 the Value field of [RFC2865] Section 5 contains both the new octets 304 given here, and any attribute-specific Value. The result is that 305 Values in this specification are limited to less than 253 octets in 306 size. This limitation is overcome through the use of the "Long 307 Extended Type" format. 309 We reiterate that the formats given in this document do not insert 310 new data into an attribute. Instead, we "steal" one octet of Value, 311 so that the definition of the Length field remains unchanged. The 312 new attribute formats are designed to be compatible with the 313 attribute format given in [RFC2865] Section 5. The meaning and 314 interpretation of the Type and Length fields is unchanged from that 315 specification. This reuse allows the new formats to be compatible 316 RADIUS implementations which do not implement this specification. 317 Those implementations can simply ignore the Value field of an 318 attribute, or forward it verbatim. 320 The changes to the attribute format come about by "stealing" one or 321 more octets from the Value field. This change has the effect that 322 the Value field of [RFC2865] Section 5 contains both the new octets 323 given here, and any attribute-specific Value. The result is that 324 Values in this specification are limited to less than 253 octets in 325 size. This limitation is overcome through the use of the "Long 326 Extended Type" format. 328 We reiterate that the formats given in this document do not insert 329 new data into an attribute. Instead, we "steal" one octet of Value, 330 so that the definition of the Length field remains unchanged. 332 2.1. Extended Type 334 This section defines a new attribute format, called "Extended Type". 335 A summary of the Attribute format is shown below. The fields are 336 transmitted from left to right. 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Type | Length | Extended-Type | Value ... 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 Type 346 This field is identical to the Type field of the Attribute format 347 defined in [RFC2865] Section 5. 349 Length 351 The Length field is one octet, and indicates the length of this 352 Attribute including the Type, Length, Extended-Type, and Value 353 fields. Permitted values are between 4 and 255. If a client or 354 server receives an Extended Attribute with a Length of 2 or 3, 355 then that Attribute MUST be considered to be an "invalid 356 attribute", and handled as per Section 2.8, below. 358 Extended-Type 360 The Extended-Type field is one octet. Up-to-date values of this 361 field are specified according to the policies and rules described 362 in Section 10. Unlike the Type field defined in [RFC2865] Section 363 5, no values are allocated for experimental or implementation- 364 specific use. Values 241-255 are reserved and SHOULD NOT be used. 366 The Extended-Type is meaningful only within a context defined by 367 the Type field. That is, this field may be thought of as defining 368 a new type space of the form "Type.Extended-Type". See Section 369 2.5, below, for additional discussion. 371 A RADIUS server MAY ignore Attributes with an unknown 372 "Type.Extended-Type". 374 A RADIUS client MAY ignore Attributes with an unknown 375 "Type.Extended-Type". 377 Value 379 This field is similar to the Value field of the Attribute format 380 defined in [RFC2865] Section 5. The format of the data SHOULD be 381 a valid RADIUS data type. 383 The addition of the Extended-Type field decreases the maximum 384 length for attributes of type "text" or "string" from 253 to 252 385 octets. Where an Attribute needs to carry more than 252 octets of 386 data, the "Long Extended Type" format SHOULD be used. 388 Experience has shown that the "experimental" and "implementation 389 specific" attributes defined in [RFC2865] Section 5 have had little 390 practical value. We therefore do not continue that practice here 391 with the Extended-Type field. 393 2.2. Long Extended Type 395 This section defines a new attribute format, called "Long Extended 396 Type". It leverages the "Extended Type" format in order to permit 397 the transport of attributes encapsulating more than 253 octets of 398 data. A summary of the Attribute format is shown below. The fields 399 are transmitted from left to right. 401 0 1 2 3 402 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 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Type | Length | Extended-Type |M| Reserved | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Value ... 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 Type 411 This field is identical to the Type field of the Attribute format 412 defined in [RFC2865] Section 5. 414 Length 416 The Length field is one octet, and indicates the length of this 417 Attribute including the Type, Length, Extended-Type, and Value 418 fields. Permitted values are between 5 and 255. If a client or 419 server receives a "Long Extended Type" with a Length of 2, 3, or 420 4, then that Attribute MUST be considered to be an "invalid 421 attribute", and be handled as per Section 2.8, below. 423 Note that this Length is limited to the length of this fragment. 424 There is no field which gives an explicit value for the total size 425 of the fragmented attribute. 427 Extended-Type 428 This field is identical to the Extended-Type field defined above 429 in Section 2.1. 431 M (More) 433 The More field is one (1) bit in length, and indicates whether or 434 not the current attribute contains "more" than 251 octets of data. 435 The More field MUST be clear (0) if the Length field has value 436 less than 255. The More field MAY be set (1) if the Length field 437 has value of 255. 439 If the More field is set (1), it indicates that the Value field 440 has been fragmented across multiple RADIUS attributes. When the 441 More field is set (1), the attribute SHOULD have a Length field of 442 value 255; it MUST NOT have a length Field of value 4; there MUST 443 be an attribute following this one; and the next attribute MUST 444 have both the same Type and Extended Type. That is, multiple 445 fragments of the same value MUST be in order and MUST be 446 consecutive attributes in the packet, and the last attribute in a 447 packet MUST NOT have the More field set (1). 449 When the Length field of an attribute has value less than 255, the 450 More field SHOULD be clear (0). 452 If a client or server receives an attribute fragment with the 453 "More" field set (1), but for which no subsequent fragment can be 454 found, then the fragmented attribute is considered to be an 455 "invalid attribute", and handled as per Section 2.8, below. 457 Reserved 459 This field is 7 bits long, and is reserved for future use. 460 Implementations MUST set it to zero (0) when encoding an attribute 461 for sending in a packet. The contents SHOULD be ignored on 462 reception. 464 Future specifications may define additional meaning for this 465 field. Implementations therefore MUST NOT treat this field as 466 invalid if it is non-zero. 468 Value 470 This field is similar to the Value field of the Attribute format 471 defined in [RFC2865] Section 5. It may contain a complete set of 472 data (when the Length field has value less than 255), or it may 473 contain a fragment of data (when the More field is set). 475 Any interpretation of the resulting data MUST occur after the 476 fragments have been reassembled. The length of the data MUST be 477 taken as the sum of the lengths of the fragments (i.e. Value 478 fields) from which it is constructed. The format of the data 479 SHOULD be a valid RADIUS data type. 481 We note that the maximum size of a fragmented attribute is limited 482 only by the RADIUS packet length limitation (i.e. 4096 octets, not 483 counting various headers and overhead). Implementations SHOULD be 484 able to handle fragmented attributes of 4096 octets. 486 This definition increases the RADIUS Attribute Type space as above, 487 but also provides for transport of Attributes which could contain 488 more than 253 octets of data. 490 Note that [RFC2865] Section 5 says: 492 If multiple Attributes with the same Type are present, the order 493 of 494 Attributes with the same Type MUST be preserved by any proxies. 495 The 496 order of Attributes of different Types is not required to be 497 preserved. A RADIUS server or client MUST NOT have any 498 dependencies 499 on the order of attributes of different types. A RADIUS server or 500 client MUST NOT require attributes of the same type to be 501 contiguous. 503 These requirements also apply to the "Long Extended Type" attribute, 504 including fragments. Implementations MUST be able to process non- 505 contiguous fragments. That is, fragments which are mixed together 506 with other attributes of a different Type. 508 2.3. TLV Data Type 510 We define a new data type in RADIUS, called "tlv". The "tlv" data 511 type is an encapsulation layer which permits the "Value" field of an 512 Attribute to contain new sub-Attributes. These sub-Attributes can in 513 turn contain "Value"s of data type TLV. This capability both extends 514 the attribute space, and permits "nested" attributes to be used. 515 This nesting can be used to encapsulate or group data into one or 516 more logical containers. 518 The "tlv" data type re-uses the RADIUS attribute format, as given 519 below: 521 0 1 2 3 522 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 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | TLV-Type | TLV-Length | TLV-Value ... 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 TLV-Type 529 The Type field is one octet. Up-to-date values of this field are 530 specified according to the policies and rules described in Section 531 10. Values of zero (0) MUST NOT be used. Values 254-255 are 532 "Reserved" for use by future extensions to RADIUS. The value 26 533 has no special meaning, and MUST NOT be treated as a Vendor 534 Specific attribute. 536 As with Extended-Type above, the TLV-Type is meaningful only 537 within the context defined by "Type" fields of the encapsulating 538 Attributes. That is, the field may be thought of as defining a 539 new type space of the form "Type.Extended-Type.TLV-Type". Where 540 TLVs are nested, the type space is of the form "Type.Extended- 541 Type.TLV-Type.TLV-Type", etc. 543 A RADIUS server MAY ignore Attributes with an unknown "TLV-Type". 545 A RADIUS client MAY ignore Attributes with an unknown "TLV-Type". 547 A RADIUS proxy SHOULD forward Attributes with an unknown "TLV- 548 Type" verbatim. 550 TLV-Length 552 The TLV-Length field is one octet, and indicates the length of 553 this TLV including the TLV-Type, TLV-Length and TLV-Value fields. 554 It MUST have a value between 3 and 255. If a client or server 555 receives a TLV with an invalid TLV-Length, then the attribute 556 which encapsulates that TLV MUST be considered to be an "invalid 557 attribute", and handled as per Section 2.8, below. 559 TLV-Value 561 The Value field is one or more octets and contains information 562 specific to the Attribute. The format and length of the TLV-Value 563 field is determined by the TLV-Type and TLV-Length fields. 565 The TLV-Value field SHOULD encapsulate a previously defined RADIUS 566 data type. Use of non-standard data types SHOULD NOT be done. We 567 note that the TLV-Value field MAY also contain one or more 568 attributes of data type "tlv", which allows for simple grouping 569 and multiple layers of nesting. 571 The TLV-Value field is limited to containing 253 or fewer octets 572 of data. Specifications which require a TLV to contain more than 573 253 octets of data are incompatible with RADIUS, and need to be 574 redesigned. Specifications which require the transport of empty 575 Values (i.e. Length = 2) are incompatible with RADIUS, and need to 576 be redesigned. 578 The TLV-Value field MUST NOT contain data using the "Extended 579 Type" formats defined in this document. The base Extended 580 Attributes format allows for sufficient flexibility that nesting 581 them inside of a TLV offers little additional value. 583 This TLV definition is compatible with the suggested format of the 584 "String" field of the Vendor-Specific attribute, as defined in 585 [RFC2865] Section 5.26, though that specification does not discuss 586 nesting. 588 Vendors MAY use attributes of type "tlv" in any Vendor Specific 589 Attribute. It is RECOMMENDED to use type "tlv" for VSAs, in 590 preference to any other format. 592 If multiple TLVs with the same TLV-Type are present, the order of 593 TLVs with the same TLV-Type MUST be preserved by any proxies. The 594 order of TLVs of different TLV-Types is not required to be preserved. 595 A RADIUS server or client MUST NOT have any dependencies on the order 596 of TLVs of different TLV-Types. A RADIUS server or client MUST NOT 597 require TLVs of the same TLV-type to be contiguous. 599 The interpretation of multiple TLVs of the same TLV-Type MUST be that 600 of a logical "and", unless otherwise specified. That is, multiple 601 TLVs are interpreted as specifying a set or a list of values. 602 Specifications SHOULD NOT define TLVs to be interpreted as a logical 603 "or". Doing so would mean that a RADIUS client or server would make 604 an arbitrary, and non-deterministic choice among the values. 606 2.3.1. TLV Nesting 608 TLVs may contain other TLVs. When this occurs, the "container" TLV 609 MUST be completely filled by the "contained" TLVs. That is, the 610 "container" TLV-Length field MUST be exactly two (2) more than the 611 sum of the "contained" TLV-Length fields. If the "contained" TLVs 612 over-fill the "container" TLV, the "container" TLV MUST be considered 613 to be an "invalid attribute", and handled as described in Section 614 2.8, below. 616 The depth of TLV nesting is limited only by the restrictions on the 617 TLV-Length field. The limit of 253 octets of data results in a limit 618 of 126 levels of nesting. However, nesting depths of more than 4 are 619 NOT RECOMMENDED. 621 2.4. EVS Data Type 623 We define a new data type in RADIUS, called "evs", for "Extended 624 Vendor-Specific". The "evs" data type is an encapsulation layer 625 which permits the "Value" field of an Attribute to contain a Vendor- 626 Id, followed by a Vendor-Type, and then vendor-defined data. This 627 data can in turn contain valid RADIUS data types, or any other data 628 as determined by the vendor. 630 This data type is intended use in attributes which carry Vendor- 631 Specific information, as is done with the Vendor-Specific Attribute 632 (26). It is RECOMMENDED that this data type be used by a vendor only 633 when the Vendor-Specific Attribute Type space has been fully 634 allocated. 636 Where [RFC2865] Section 5.26 makes a recommendation for the format of 637 the data following the Vendor-Id, we give a strict definition. 638 Experience has shown that many vendors have not followed the 639 [RFC2865] recommendations, leading to interoperability issues. We 640 hope here to give vendors sufficient flexibility as to meet their 641 needs, while minimizing the use of non-standard VSA formats. 643 The "evs" data type MAY be used in Attributes having the format of 644 "Extended Type" or "Long Extended Type". It MUST NOT be used in any 645 other Attribute definition, including standard RADIUS Attributes, 646 TLVs, and VSAs. 648 A summary of the "evs" data type format is shown below. The fields 649 are transmitted from left to right. 651 0 1 2 3 652 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 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Vendor-Id | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Vendor-Type | String .... 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 Vendor-Id 661 The 4 octets are the Network Management Private Enterprise Code 662 [PEN] of the Vendor in network byte order. 664 Vendor-Type 666 The Vendor-Type field is one octet. Values are assigned at the 667 sole discretion of the Vendor. 669 Value 671 The Value field is one or more octets. It SHOULD encapsulate a 672 previously defined RADIUS data type. Using non-standard data 673 types is NOT RECOMMENDED. We note that the Value field may be of 674 data type "tlv". However, it MUST NOT be of data type "evs", as 675 the use cases are unclear for one vendor delegating Attribute Type 676 space to another vendor. 678 The actual format of the information is site or application 679 specific, and a robust implementation SHOULD support the field as 680 undistinguished octets. We recognise that Vendors have complete 681 control over the contents and format of the Value field, while at 682 the same time recommending that good practices be followed. 684 Further codification of the range of allowed usage of this field 685 is outside the scope of this specification. 687 Note that unlike the format described in [RFC2865] Section 5.26, this 688 data type has no "Vendor length" field. The length of the "String" 689 field is implicit, and is determined by taking the "Length" of the 690 encapsulating RADIUS Attribute, and subtracting the length of the 691 attribute header (2 octets), the extended type (1 octet), the Vendor- 692 Id (4 octets), and the Vendor-type (1 octet). i.e. For "Extended 693 Type" attributes, the length of the String field is eight (8) less 694 than the value of the Length field. For "Long Extended Type" 695 attributes, the length of the String field is nine (9) less than the 696 value of the Length field. 698 2.5. Integer64 Data Type 700 We define a new data type in RADIUS, called "integer64", which 701 carries a 64-bit unsigned integer in network byte order. 703 This data type is intended to be used in any situation where there is 704 a need to have counters which can count past 2^32. The expected use 705 of this data type is within Accounting-Request packets, but this data 706 type SHOULD be used in any packet where 32-bit integers are expected 707 to be insufficient. 709 The "integer64" data type can be used in Attributes of any format, 710 standard space, extended attributes, TLVs, and VSAs. 712 A summary of the "integer64" data type format is shown below. The 713 fields are transmitted from left to right. 715 0 1 2 3 716 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 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Value ... 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 Attributes having data type "integer64" MUST have the relevant Length 725 field set to eight more than the length of the Attribute header. For 726 standard space Attributes and TLVs, this means that the Length field 727 MUST be set to ten (10). For "Extended Type" Attributes, the Length 728 field MUST be set to eleven (11). For "Long Extended Type" 729 Attributes, the Length field MUST be set to twelve (12). 731 2.6. Vendor-ID Field 733 We define the Vendor-ID field of Vendor-Specific Attributes to 734 encompass the entire 4 octets of the Vendor field. [RFC2865] Section 735 5.26 defined it to be 3 octets, with the high octet being zero. This 736 change has no immediate impact on RADIUS, as the maximum Private 737 Enterprise Code defined is still within 16 bits. 739 However, it is best to make advance preparations for changes in the 740 protocol. As such, it is RECOMMENDED that all implementations 741 support four (4) octets for the Vendor-ID field, instead of three 742 (3). 744 2.7. Attribute Naming and Type Identifiers 746 Attributes have traditionally been identified by a unique name and 747 number. For example, the attribute named "User-Name" has been 748 allocated number one (1). This scheme needs to be extended in order 749 to be able to refer to attributes of Extended Type, and to TLVs. It 750 will also be used by IANA for allocating RADIUS Attribute Type 751 values. 753 The names and identifiers given here are intended to be used only in 754 specifications. The system presented here may not be useful when 755 referring to the contents of a RADIUS packet. It imposes no 756 requirements on implementations, as implementations are free to 757 reference RADIUS Attributes via any method they choose. 759 2.7.1. Attribute and TLV Naming 761 RADIUS specifications traditionally use names consisting of one or 762 more words, separated by hyphens, e.g. "User-Name". However, these 763 names are not allocated from a registry, and there is no restriction 764 other than convention on their global uniqueness. 766 Similarly, vendors have often used their company name as the prefix 767 for VSA names, though this practice is not universal. For example, 768 for a vendor named "Example", the name "Example-Attribute-Name" 769 SHOULD be used instead of "Attribute-Name". The second form can 770 conflict with attributes from other vendors, whereas the first form 771 cannot. 773 It is therefore RECOMMENDED that specifications give names to 774 Attributes which attempt to be globally unique across all RADIUS 775 Attributes. It is RECOMMENDED that vendors use their name as a 776 unique prefix for attribute names, e.g. Livingston-IP-Pool instead of 777 IP-Pool. It is RECOMMENDED that implementations enforce uniqueness 778 on names, which would otherwise lead to ambiguity and problems. 780 We recognise that these suggestion may sometimes be difficult to 781 implement in practice. 783 TLVs SHOULD be named with a unique prefix that is shared among 784 related attributes. For example, a specification that defines a set 785 of TLVs related to time could create attributes named "Time-Zone", 786 "Time-Day", "Time-Hour", "Time-Minute", etc. 788 2.7.2. Attribute Type Identifiers 790 The RADIUS Attribute Type space defines a context for a particular 791 "Extended-Type" field. The "Extended-Type" field allows for 256 792 possible type code values, with values 1 through 240 available for 793 allocation. We define here an identification method that uses a 794 "dotted number" notation similar to that used for Object Identifiers 795 (OIDs), formatted as "Type.Extended-Type". 797 For example, and attribute within the Type space of 241, having 798 Extended-Type of one (1), is uniquely identified as "241.1". 799 Similarly, an attribute within the Type space of 246, having 800 Extended-Type of ten (10), is uniquely identified as "246.10". 802 The algorithm used to create the Attribute Identifier is simply to 803 concatenate all of the various identification fields (e.g. Type, 804 Extended-Type, etc.), starting from the encapsulating attribute, down 805 to the final encapsulated TLV, separated by a '.' character. 807 2.7.3. TLV Identifiers 809 We can extend the Attribute reference scheme defined above for TLVs. 810 This is done by leveraging the "dotted number" notation. As above, 811 we define an additional TLV type space, within the "Extended Type" 812 space, by appending another "dotted number" in order to identify the 813 TLV. This method can be replied in sequence for nested TLVs. 815 For example, let us say that "245.1" identifies RADIUS Attribute Type 816 245, containing an "Extended Type" of one (1), which is of type 817 "tlv". That attribute will contain 256 possible TLVs, one for each 818 value of the TLV-Type field. The first TLV-Type value of one (1) can 819 then be identified by appending a ".1" to the number of the 820 encapsulating attribute ("241.1"), to yield "241.1.1". Similarly, 821 the sequence "245.2.3.4" identifies RADIUS attribute 245, containing 822 an "Extended Type" of two (2) which is of type "tlv", which in turn 823 contains a TLV with TLV-Type number three (3), which in turn contains 824 another TLV, wth TLV-Type number four (4). 826 2.7.4. VSA Identifiers 828 There has historically been no method for numerically addressing 829 VSAs. The "dotted number" method defined here can also be leveraged 830 to create such an addressing scheme. However, as the VSAs are 831 completely under the control of each individual vendor, this section 832 provides a suggested practice, but does not define a standard of any 833 kind. 835 The Vendor-Specific Attribute has been assigned the Attribute number 836 26. It in turn carries a 24-bit Vendor-Id, and possibly additional 837 VSAs. Where the VSAs follow the [RFC2865] Section 5.26 recommended 838 format, a VSA can be identified as "26.Vendor-Id"."Vendor-Type". 840 For example, Livingston has Vendor-Id 307, and has defined an 841 attribute "IP-Pool" as number 6. This VSA can be uniquely identified 842 as 26.307.6, but it cannot be uniquely identified by name. 844 Note that there is no restriction on the size of the numerical values 845 in this notation. The Vendor-Id is a 24-bit number, and the VSA may 846 have been assigned from a 16-bit vendor-specific Attribute Type 847 space. 849 For example, the company USR has been allocated Vendor-Id 429, and 850 has defined a "Version-Id" attribute as number 32768. This VSA can 851 be uniquely identified as 26.429.32768, and again cannot be uniquely 852 identified by name. 854 Where a VSA is a TLV, the "dotted number" notation can be used as 855 above: 26.VID.VSA.TLV1.TLV2.TLV3 where "TLVn" are the numerical 856 values assigned by the vendor to the different nested TLVs. 858 2.8. Invalid Attributes 860 The term "invalid attribute" is new to this specification. It is 861 defined to mean that the Length field of an Attribute is valid (as 862 per [RFC2865], Section 5, top of page 25). However, the Value field 863 of the attribute does not follow the format required by the data type 864 defined for that Attribute. e.g. an Attribute of data type "address" 865 which encapsulates more than four, or less than four, octets of data. 866 Or, an IPV6 Prefix attribute which has a Prefix value of more than 867 128. 869 While the content of these attributes is malformed, we emphasize that 870 the encapsulating RADIUS packet (or TLV) is well formed, and can be 871 correctly decoded. The existence of an "invalid attribute" in a 872 packet MUST NOT result in the implementation discarding the entire 873 packet, or treating the packet as a negative acknowledgement. 874 Instead, only the "invalid attribute" is treated differently. 876 When an implementation receives an "invalid attribute", it SHOULD be 877 silently discarded. If it is not discarded, it MUST NOT be handled 878 in the same manner as a well-formed attribute. For example, 879 receiving an Attribute of data type "address" containing more than 880 four, or less than four octets of data means that the Attribute MUST 881 NOT be treated as being of data type "address". 883 For Attributes of type "Long Extended Type", an Attribute is 884 considered to be an "invalid attribute" when does not match the 885 criteria set out in Section 2.2, above. 887 For Attributes of type "TLV", an Attribute is considered to be an 888 "invalid attribute" when the TLV-Length field is valid, but the TLV- 889 Value field does not match the criteria for that Attribute. 890 Implementations SHOULD NOT treat the "invalid attribute" property as 891 being transitive. That is, the encapsulating Attribute SHOULD NOT be 892 treated as being an "invalid attribute" if it encapsulates an 893 "invalid attribute". 895 3. Attribute Definitions 897 We define four (4) attributes of "Extended Type", which are allocated 898 from the "Reserved" Attribute Type codes of 241, 242, 243, and 244. 899 We also define two (2) attributes of "Long Extended Type", which are 900 allocated from the "Reserved" Attribute Type codes of 245 and 246. 902 Type Name 903 ---- ---- 904 241 Extended-Type-1 905 242 Extended-Type-2 906 243 Extended-Type-3 907 244 Extended-Type-4 908 245 Long-Extended-Type-1 909 246 Long-Extended-Type-2 911 The rest of this section gives a detailed definition for each 912 Attribute based on the above summary. 914 3.1. Extended-Type-1 916 Description 918 This attribute encapsulates attributes of the "Extended Type" 919 format, in the RADIUS Attribute Type Space of 241.{1-255}. 921 A summary of the Extended-Type-1 Attribute format is shown below. 922 The fields are transmitted from left to right. 924 0 1 2 3 925 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 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | Type | Length | Extended-Type | Value ... 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 Type 932 241 for Extended-Type-1. 934 Length 936 >= 4 938 Extended-Type 940 The Extended-Type field is one octet. Up-to-date values of this 941 field are specified in the 241.{1-255} RADIUS Attribute Type 942 Space, according to the policies and rules described in Section 943 10. Further definition of this field is given in Section 2.1, 944 above. 946 Value 948 The Value field is one or more octets. Implementations not 949 supporting this specification SHOULD support the field as 950 undistinguished octets. 952 Implementations supporting this specification MUST use the 953 Identifier of "Type.Extended-Type" to determine the interpretation 954 of the Value field. 956 3.2. Extended-Type-2 958 Description 960 This attribute encapsulates attributes of the "Extended Type" 961 format, in the RADIUS Attribute Type Space of 242.{1-255}. 963 A summary of the Extended-Type-2 Attribute format is shown below. 964 The fields are transmitted from left to right. 966 0 1 2 3 967 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 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Type | Length | Extended-Type | Value ... 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 Type 974 242 for Extended-Type-2. 976 Length 978 >= 4 980 Extended-Type 982 The Extended-Type field is one octet. Up-to-date values of this 983 field are specified in the 242.{1-255} RADIUS Attribute Type 984 Space, according to the policies and rules described in Section 985 10. Further definition of this field is given in Section 2.1, 986 above. 988 Value 990 The Value field is one or more octets. Implementations not 991 supporting this specification SHOULD support the field as 992 undistinguished octets. 994 Implementations supporting this specification MUST use the 995 Identifier of "Type.Extended-Type" to determine the interpretation 996 of the Value field 998 3.3. Extended-Type-3 1000 Description 1002 This attribute encapsulates attributes of the "Extended Type" 1003 format, in the RADIUS Attribute Type Space of 243.{1-255}. 1005 A summary of the Extended-Type-3 Attribute format is shown below. 1006 The fields are transmitted from left to right. 1008 0 1 2 3 1009 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 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | Type | Length | Extended-Type | Value ... 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 Type 1016 243 for Extended-Type-3. 1018 Length 1020 >= 4 1022 Extended-Type 1024 The Extended-Type field is one octet. Up-to-date values of this 1025 field are specified in the 243.{1-255} RADIUS Attribute Type 1026 Space, according to the policies and rules described in Section 1027 10. Further definition of this field is given in Section 2.1, 1028 above. 1030 Value 1032 The Value field is one or more octets. Implementations not 1033 supporting this specification SHOULD support the field as 1034 undistinguished octets. 1036 Implementations supporting this specification MUST use the 1037 Identifier of "Type.Extended-Type" to determine the interpretation 1038 of the Value field. 1040 3.4. Extended-Type-4 1042 Description 1044 This attribute encapsulates attributes of the "Extended Type" 1045 format, in the RADIUS Attribute Type Space of 244.{1-255}. 1047 A summary of the Extended-Type-4 Attribute format is shown below. 1048 The fields are transmitted from left to right. 1050 0 1 2 3 1051 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 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | Type | Length | Extended-Type | Value ... 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 Type 1058 244 for Extended-Type-4. 1060 Length 1062 >= 4 1064 Extended-Type 1066 The Extended-Type field is one octet. Up-to-date values of this 1067 field are specified in the 244.{1-255} RADIUS Attribute Type 1068 Space, according to the policies and rules described in Section 1069 10. Further definition of this field is given in Section 2.1, 1070 above. 1072 Value 1074 The Value field is one or more octets. Implementations not 1075 supporting this specification SHOULD support the field as 1076 undistinguished octets. 1078 Implementations supporting this specification MUST use the 1079 Identifier of "Type.Extended-Type" to determine the interpretation 1080 of the Value Field. 1082 3.5. Long-Extended-Type-1 1084 Description 1086 This attribute encapsulates attributes of the "Long Extended Type" 1087 format, in the RADIUS Attribute Type Space of 245.{1-255}. 1089 A summary of the Long-Extended-Type-1 Attribute format is shown 1090 below. The fields are transmitted from left to right. 1092 0 1 2 3 1093 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 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Type | Length | Extended-Type |M| Reserved | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Value ... 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 Type 1103 245 for Long-Extended-Type-1 1105 Length 1107 >= 5 1109 Extended-Type 1111 The Extended-Type field is one octet. Up-to-date values of this 1112 field are specified in the 245.{1-255} RADIUS Attribute Type 1113 Space, according to the policies and rules described in Section 1114 10. Further definition of this field is given in Section 2.1, 1115 above. 1117 M (More) 1119 The More field is one (1) bit in length, and indicates whether or 1120 not the current attribute contains "more" than 251 octets of data. 1121 Further definition of this field is given in Section 2.2, above. 1123 Reserved 1125 This field is 7 bits long, and is reserved for future use. 1126 Implementations MUST set it to zero (0) when encoding an attribute 1127 for sending in a packet. The contents SHOULD be ignored on 1128 reception. 1130 Value 1132 The Value field is one or more octets. Implementations not 1133 supporting this specification SHOULD support the field as 1134 undistinguished octets. 1136 Implementations supporting this specification MUST use the 1137 Identifier of "Type.Extended-Type" to determine the interpretation 1138 of the Value field. 1140 3.6. Long-Extended-Type-2 1142 Description 1144 This attribute encapsulates attributes of the "Long Extended Type" 1145 format, in the RADIUS Attribute Type Space of 246.{1-255}. 1147 A summary of the Long-Extended-Type-2 Attribute format is shown 1148 below. The fields are transmitted from left to right. 1150 0 1 2 3 1151 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 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | Type | Length | Extended-Type |M| Reserved | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 | Value ... 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 Type 1160 246 for Long-Extended-Type-2 1162 Length 1164 >= 5 1166 Extended-Type 1168 The Extended-Type field is one octet. Up-to-date values of this 1169 field are specified in the 246.{1-255} RADIUS Attribute Type 1170 Space, according to the policies and rules described in Section 1171 10. Further definition of this field is given in Section 2.1, 1172 above. 1174 M (More) 1176 The More field is one (1) bit in length, and indicates whether or 1177 not the current attribute contains "more" than 251 octets of data. 1178 Further definition of this field is given in Section 2.2, above. 1180 Reserved 1182 This field is 7 bits long, and is reserved for future use. 1183 Implementations MUST set it to zero (0) when encoding an attribute 1184 for sending in a packet. The contents SHOULD be ignored on 1185 reception. 1187 Value 1189 The Value field is one or more octets. Implementations not 1190 supporting this specification SHOULD support the field as 1191 undistinguished octets. 1193 Implementations supporting this specification MUST use the 1194 Identifier of "Type.Extended-Type" to determine the interpretation 1195 of the Value field. 1197 4. Vendor Specific Attributes 1199 We define six new attributes which can carry Vendor Specific 1200 information. We define four (4) attributes of the "Extended Type" 1201 format, with Type codes (241.26, 242.26, 243.26, 244.26), using the 1202 "evs" data type. We also define two (2) attributes using "Long 1203 Extended Type" format, with Type codes (245.26, 246.26), which are of 1204 the "evs" data type. 1206 Type.Extended-Type Name 1207 ------------------ ---- 1208 241.26 Extended-Vendor-Specific-1 1209 242.26 Extended-Vendor-Specific-2 1210 243.26 Extended-Vendor-Specific-3 1211 244.26 Extended-Vendor-Specific-4 1212 245.26 Extended-Vendor-Specific-5 1213 246.26 Extended-Vendor-Specific-6 1215 The rest of this section gives a detailed definition for each 1216 Attribute based on the above summary. 1218 4.1. Extended-Vendor-Specific-1 1220 Description 1222 This attribute defines a RADIUS Type Code of 241.26, using the 1223 "evs" data type. 1225 A summary of the Extended-Vendor-Specific-1 Attribute format is shown 1226 below. The fields are transmitted from left to right. 1228 0 1 2 3 1229 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 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 | Type | Length | Extended-Type | Vendor-Id ... 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 ... Vendor-Id (cont) | Vendor-Type | 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 | Value .... 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 Type.Extended-Type 1240 241.26 for Extended-Vendor-Specific-1 1242 Length 1243 >= 9 1245 Vendor-Id 1247 The 4 octets are the Network Management Private Enterprise Code 1248 [PEN] of the Vendor in network byte order. 1250 Vendor-Type 1252 The Vendor-Type field is one octet. Values are assigned at the 1253 sole discretion of the Vendor. 1255 Value 1257 The Value field is one or more octets. The actual format of the 1258 information is site or application specific, and a robust 1259 implementation SHOULD support the field as undistinguished octets. 1261 The codification of the range of allowed usage of this field is 1262 outside the scope of this specification. 1264 The length of the Value field is eight (8) less then the value of 1265 the Length field. 1267 Implementations supporting this specification MUST use the 1268 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1269 determine the interpretation of the Value field. 1271 4.2. Extended-Vendor-Specific-2 1273 Description 1275 This attribute defines a RADIUS Type Code of 242.26, using the 1276 "evs" data type. 1278 A summary of the Extended-Vendor-Specific-2 Attribute format is shown 1279 below. The fields are transmitted from left to right. 1281 0 1 2 3 1282 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 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1284 | Type | Length | Extended-Type | Vendor-Id ... 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 ... Vendor-Id (cont) | Vendor-Type | 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 | Value .... 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 Type.Extended-Type 1292 242.26 for Extended-Vendor-Specific-2 1294 Length 1296 >= 9 1298 Vendor-Id 1300 The 4 octets are the Network Management Private Enterprise Code 1301 [PEN] of the Vendor in network byte order. 1303 Vendor-Type 1305 The Vendor-Type field is one octet. Values are assigned at the 1306 sole discretion of the Vendor. 1308 Value 1310 The Value field is one or more octets. The actual format of the 1311 information is site or application specific, and a robust 1312 implementation SHOULD support the field as undistinguished octets. 1314 The codification of the range of allowed usage of this field is 1315 outside the scope of this specification. 1317 The length of the Value field is eight (8) less then the value of 1318 the Length field. 1320 Implementations supporting this specification MUST use the 1321 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1322 determine the interpretation of the Value field. 1324 4.3. Extended-Vendor-Specific-3 1326 Description 1328 This attribute defines a RADIUS Type Code of 243.26, using the 1329 "evs" data type. 1331 A summary of the Extended-Vendor-Specific-3 Attribute format is shown 1332 below. The fields are transmitted from left to right. 1334 0 1 2 3 1335 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 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 | Type | Length | Extended-Type | Vendor-Id ... 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 ... Vendor-Id (cont) | Vendor-Type | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 | Value .... 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 Type.Extended-Type 1347 243.26 for Extended-Vendor-Specific-3 1349 Length 1351 >= 9 1353 Vendor-Id 1355 The 4 octets are the Network Management Private Enterprise Code 1356 [PEN] of the Vendor in network byte order. 1358 Vendor-Type 1360 The Vendor-Type field is one octet. Values are assigned at the 1361 sole discretion of the Vendor. 1363 Value 1365 The Value field is one or more octets. The actual format of the 1366 information is site or application specific, and a robust 1367 implementation SHOULD support the field as undistinguished octets. 1369 The codification of the range of allowed usage of this field is 1370 outside the scope of this specification. 1372 The length of the Value field is eight (8) less then the value of 1373 the Length field. 1375 Implementations supporting this specification MUST use the 1376 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1377 determine the interpretation of the Value field. 1379 4.4. Extended-Vendor-Specific-4 1381 Description 1383 This attribute defines a RADIUS Type Code of 244.26, using the 1384 "evs" data type. 1386 A summary of the Extended-Vendor-Specific-3 Attribute format is shown 1387 below. The fields are transmitted from left to right. 1389 0 1 2 3 1390 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 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | Type | Length | Extended-Type | Vendor-Id ... 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 ... Vendor-Id (cont) | Vendor-Type | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 | Value .... 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1399 Type.Extended-Type 1401 244.26 for Extended-Vendor-Specific-4 1403 Length 1405 >= 9 1407 Vendor-Id 1409 The 4 octets are the Network Management Private Enterprise Code 1410 [PEN] of the Vendor in network byte order. 1412 Vendor-Type 1414 The Vendor-Type field is one octet. Values are assigned at the 1415 sole discretion of the Vendor. 1417 Value 1419 The Value field is one or more octets. The actual format of the 1420 information is site or application specific, and a robust 1421 implementation SHOULD support the field as undistinguished octets. 1423 The codification of the range of allowed usage of this field is 1424 outside the scope of this specification. 1426 The length of the Value field is eight (8) less then the value of 1427 the Length field. 1429 Implementations supporting this specification MUST use the 1430 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1431 determine the interpretation of the Value field. 1433 4.5. Extended-Vendor-Specific-5 1435 Description 1437 This attribute defines a RADIUS Type Code of 245.26, using the 1438 "evs" data type. 1440 A summary of the Extended-Vendor-Specific-5 Attribute format is shown 1441 below. The fields are transmitted from left to right. 1443 0 1 2 3 1444 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 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 | Type | Length | Extended-Type |M| Reserved | 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 | Vendor-Id | 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 | Vendor-Type | Value .... 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 Type.Extended-Type 1455 245.26 for Extended-Vendor-Specific-5 1457 Length 1459 >= 10 (first fragment) 1460 >= 5 (subsequent fragments) 1462 When a VSA is fragmented across multiple Attributes, only the 1463 first Attribute contains the Vendor-Id and Vendor-Type fields. 1464 Subsequent Attributes contain fragments of the Value field only. 1466 M (More) 1468 The More field is one (1) bit in length, and indicates whether or 1469 not the current attribute contains "more" than 251 octets of data. 1470 Further definition of this field is given in Section 2.2, above. 1472 Reserved 1474 This field is 7 bits long, and is reserved for future use. 1475 Implementations MUST set it to zero (0) when encoding an attribute 1476 for sending in a packet. The contents SHOULD be ignored on 1477 reception. 1479 Vendor-Id 1480 The 4 octets are the Network Management Private Enterprise Code 1481 [PEN] of the Vendor in network byte order. 1483 Vendor-Type 1485 The Vendor-Type field is one octet. Values are assigned at the 1486 sole discretion of the Vendor. 1488 Value 1490 The Value field is one or more octets. The actual format of the 1491 information is site or application specific, and a robust 1492 implementation SHOULD support the field as undistinguished octets. 1494 The codification of the range of allowed usage of this field is 1495 outside the scope of this specification. 1497 Implementations supporting this specification MUST use the 1498 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1499 determine the interpretation of the Value field. 1501 4.6. Extended-Vendor-Specific-6 1503 Description 1505 This attribute defines a RADIUS Type Code of 246.26, using the 1506 "evs" data type. 1508 A summary of the Extended-Vendor-Specific-6 Attribute format is shown 1509 below. The fields are transmitted from left to right. 1511 0 1 2 3 1512 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 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 | Type | Length | Extended-Type |M| Reserved | 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 | Vendor-Id | 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 | Vendor-Type | Value .... 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1521 Type.Extended-Type 1523 246.26 for Extended-Vendor-Specific-6 1525 Length 1527 >= 10 (first fragment) 1528 >= 5 (subsequent fragments) 1530 When a VSA is fragmented across multiple Attributes, only the 1531 first Attribute contains the Vendor-Id and Vendor-Type fields. 1532 Subsequent Attributes contain fragments of the Value field only. 1534 M (More) 1536 The More field is one (1) bit in length, and indicates whether or 1537 not the current attribute contains "more" than 251 octets of data. 1538 Further definition of this field is given in Section 2.2, above. 1540 Reserved 1542 This field is 7 bits long, and is reserved for future use. 1543 Implementations MUST set it to zero (0) when encoding an attribute 1544 for sending in a packet. The contents SHOULD be ignored on 1545 reception. 1547 Vendor-Id 1549 The 4 octets are the Network Management Private Enterprise Code 1550 [PEN] of the Vendor in network byte order. 1552 Vendor-Type 1554 The Vendor-Type field is one octet. Values are assigned at the 1555 sole discretion of the Vendor. 1557 Value 1559 The Value field is one or more octets. The actual format of the 1560 information is site or application specific, and a robust 1561 implementation SHOULD support the field as undistinguished octets. 1563 The codification of the range of allowed usage of this field is 1564 outside the scope of this specification. 1566 Implementations supporting this specification MUST use the 1567 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1568 determine the interpretation of the Value field. 1570 5. Compatibility with traditional RADIUS 1572 There are a number of potential compatibility issues with traditional 1573 RADIUS, as defined in [RFC6158] and earlier. This section describes 1574 them. 1576 5.1. Attribute Allocation 1578 Some vendors have used Attribute Type codes from the "Reserved" 1579 space, as part of vendor-defined dictionaries. This practice is 1580 considered anti-social behavior, as noted in [RFC6158]. These vendor 1581 definitions conflict with the attributes in the RADIUS Attribute Type 1582 space. The conflicting definitions may make it difficult for 1583 implementations to support both those Vendor Attributes, and the new 1584 Extended Attribute formats. 1586 We RECOMMEND that RADIUS client and server implementations delete all 1587 references to these improperly defined attributes. Failing that, we 1588 RECOMMEND that RADIUS server implementations have a per-client 1589 configurable flag which indicates which type of attributes are being 1590 sent from the client. If the flag is set to "Non-Standard 1591 Attributes", the conflicting attributes can be interpreted as being 1592 improperly defined Vendor Specific Attributes. If the flag is set the 1593 "IETF Attributes", the attributes MUST be interpreted as being of the 1594 Extended Attributes format. The default SHOULD be to interpret the 1595 attributes as being of the Extended Attributes format. 1597 Other methods of determining how to decode the attributes into a 1598 "correct" form are NOT RECOMMENDED. Those methods are likely to be 1599 fragile and prone to error. 1601 We RECOMMEND that RADIUS server implementations re-use the above flag 1602 to determine which type of attributes to send in a reply message. If 1603 the request is expected to contain the improperly defined attributes, 1604 the reply SHOULD NOT contain Extended Attributes. If the request is 1605 expected to contain Extended Attributes, the reply MUST NOT contain 1606 the improper Attributes. 1608 RADIUS clients will have fewer issues than servers. Clients MUST NOT 1609 send improperly defined Attributes in a request. For replies, 1610 clients MUST interpret attributes as being of the Extended Attributes 1611 format, instead of the improper definitions. These requirements 1612 impose no change in the RADIUS specifications, as such usage by 1613 vendors has always been in conflict with the standard requirements 1614 and the standards process. 1616 Existing clients that send these improperly defined attributes 1617 usually have a configuration setting which can disable this behavior. 1618 We RECOMMEND that vendors ship products with the default set to 1619 "disabled". We RECOMMEND that administrators set this flag to 1620 "disabled" on all equipment that they manage. 1622 5.2. Proxy Servers 1624 RADIUS Proxy servers will need to forward Attributes having the new 1625 format, even if they do not implement support for the encoding and 1626 decoding of those attributes. We remind implementors of the 1627 following text in [RFC2865] Section 2.3: 1629 The forwarding server MUST NOT change the order of any attributes 1630 of the same type, including Proxy-State. 1632 This requirement solves some of the issues related to proxying of the 1633 new format, but not all. The reason is that proxy servers are 1634 permitted to examine the contents of the packets that they forward. 1635 Many proxy implementations not only examine the attributes, but they 1636 refuse to forward attributes which they do not understand (i.e. 1637 attributes for which they have no local dictionary definitions). 1639 This practice is NOT RECOMMENDED. Proxy servers SHOULD forward 1640 attributes, even ones which they do not understand, or which are not 1641 in a local dictionary. When forwarded, these attributes SHOULD be 1642 sent verbatim, with no modifications or changes. This requirement 1643 includes "invalid attributes", as there may be some other system in 1644 the network which understands them. 1646 The only exception to this recommendation is when local site policy 1647 dictates that filtering of attributes has to occur. For example, a 1648 filter at a visited network may require removal of certain 1649 authorization rules which apply to the home network, but not to the 1650 visited network. This filtering can sometimes be done even when the 1651 contents of the attributes are unknown, such as when all Vendor- 1652 Specific Attributes are designated for removal. 1654 As seen in [EDUROAM] many proxies do not follow these practices for 1655 unknown Attributes. Some proxies filter out unknown attributes or 1656 attributes which have unexpected lengths (24%, 17/70), some truncate 1657 the attributes to the "expected" length (11%, 8/70), some discard the 1658 request entirely (1%, 1/70), with the rest (63%, 44/70) following the 1659 recommended practice of passing the attributes verbatim. It will be 1660 difficult to widely use the Extended Attributes format until all non- 1661 conformant proxies are fixed. We therefore RECOMMEND that all 1662 proxies which do not support the Extended Attributes (241 through 1663 246) define them as being of data type "string", and delete all other 1664 local definitions for those attributes. 1666 This last change should enable wider usage of the Extended Attributes 1667 format. 1669 6. Guidelines 1671 This specification proposes a number of changes to RADIUS, and 1672 therefore requires a set of guidelines, as has been done in 1673 [RFC6158]. 1675 6.1. Updates to RFC 6158 1677 This specification updates [RFC6158] by adding the data types "evs", 1678 "tlv" and "integer64"; defining them to be "basic" data types; and 1679 permitting their use subject to the restrictions outlined below. 1681 The recommendations for the use of the new data types and attribute 1682 formats are given below. All other recommendations given in 1683 [RFC6158] are unchanged. 1685 6.2. Guidelines for Simple Data Types 1687 [RFC6158] Section A.2.1 says in part: 1689 * Unsigned integers of size other than 32 bits. 1690 SHOULD be replaced by an unsigned integer of 32 bits. There is 1691 insufficient justification to define a new size of integer. 1693 We update that specification to permit unsigned integers of 64 bits, 1694 for the reasons defined above in Section 2.5. The updated text is as 1695 follows: 1697 * Unsigned integers of size other than 32 or 64 bits. 1698 SHOULD be replaced by an unsigned integer of 32 or 64 bits. 1699 There is insufficient justification to define a new size 1700 of integer. 1702 That section later continues with the following list item: 1704 * Nested attribute-value pairs (AVPs). 1705 Attributes should be defined in a flat typespace. 1707 We update that specification to permit nested TLVs, as defined in 1708 this document: 1710 * Nested attribute-value pairs (AVPs) using the extended 1711 attribute format MAY be used. All other nested AVP or TLV 1712 formats MUST NOT be used. 1714 6.3. Guidelines for Complex Data Types 1716 [RFC6158] Section 2.1 says: 1718 Complex data types MAY be used in situations where they reduce 1719 complexity in non-RADIUS systems or where using the basic data 1720 types 1721 would be awkward (such as where grouping would be required in 1722 order 1723 to link related attributes). 1725 Since the extended attribute format allows for grouping of complex 1726 types via TLVs, the guidelines for complex data types need to be 1727 updated as follows: 1729 Complex data types MAY be used where they reduce complexity in 1730 non-RADIUS systems, though this practice is NOT RECOMMENDED. The 1731 complex data type exceptions of [RFC6158] Section 3.2.4 still 1732 apply. In all other situations, complex data types MUST NOT be 1733 used. Instead, complex data types MUST be decomposed into TLVs, 1734 using the extended attribute format. 1736 The checklist in Appendix A.2.2 is similarly updated to add a new 1737 requirement at the top of that section, 1739 Does the attribute: 1741 * define a complex type which can be represented via TLVs? 1743 If so, this data type MUST be represented via TLVs. 1745 Note that this requirement does not over-ride Section A.1, which 1746 permits the transport of complex types in certain situations. 1748 6.4. Guidelines For the New Types 1750 We recommend the following guidelines when designing attributes using 1751 the new format. The items listed below are not exhaustive. As 1752 experience is gained with the new formats, later specifications may 1753 define additional guidelines. 1755 * The data type "evs" MUST NOT be used for standard RADIUS 1756 Attributes, or for TLVs, or for VSAs. 1758 * The data type "tlv" SHOULD NOT be used for standard RADIUS 1759 attributes. While its use is NOT RECOMMENDED by [RFC6158], this 1760 specification updates [RFC6158] to permit the "tlv" data type in 1761 attributes using the Extended-Type format. 1763 * [RFC2866] "tagged" attributes MUST NOT be defined in the 1764 Extended-Type space. The "tlv" data type should be used instead to 1765 group attributes. 1767 * The "integer64" data type MAY be used in any RADIUS attribute. 1768 The use of 64-bit integers is NOT RECOMMENDED by [RFC6158], but 1769 their utility is now evident. 1771 * Any attribute which is allocated from the Type spaces of 245.* or 1772 246.*, of data type "text", "string", or "tlv" can end up carrying 1773 more than 251 octets of data, up to the maximum RADIUS packet 1774 length (~4096 octets). Specifications defining such attributes 1775 SHOULD define a maximum length. 1777 * For all other circumstances, the guidelines in [RFC6158] MUST 1778 be followed. 1780 6.5. Allocation Request Guidelines 1782 The following items give guidelines for allocation requests made in a 1783 RADIUS specification. 1785 * Discretion is RECOMMENDED when requesting allocation of attributes. 1786 The new space is much larger than the old one, but it is not 1787 infinite. 1789 * Specifications which allocate many attributes MUST NOT request that 1790 allocation be made from from the standard space. That space is 1791 under allocation pressure, and the extended space is more suitable 1792 for large allocations. 1794 * Specifications which allocate many related attributes SHOULD define 1795 one or more TLVs to contain related attributes. 1797 * Specifications should not request allocation from a specific space. 1798 The IANA considerations given in Section 9, below, should be 1799 sufficient for attribute allocation. 1801 * Specifications of an attribute which encodes 252 octets or less 1802 of data MAY request allocation from the exended space, using 1803 format "Extended Type" 1805 * Specifications of an attribute which always encode less than 253 1806 octets of data MUST NOT request allocation from the long extended 1807 space. The standard space, or the short extended space MUST be 1808 used instead. 1810 * Specifications of an attribute which encodes 253 octets or more of 1811 data MUST request allocation from the long extended space. 1813 * When the extended space is nearing exhaustion, a new specification 1814 SHOULD be written which requests allocation of one or more RADIUS 1815 Attributes from the "Reserved" portion of the standard space, 1816 values 247-255, using an appropriate format ("Extended Type", or 1817 "Long Extended Type") 1819 6.6. TLV Guidelines 1821 The following items give guidelines for specifications using TLVs. 1823 * when multiple attributes are intended to be grouped or managed 1824 together, the use of TLVs to group related attributes is 1825 RECOMMENDED. 1827 * more than 4 layers (depth) of TLV nesting is NOT RECOMMENDED. 1829 * Interpretation of an attribute depends only on its type 1830 definition (e.g. Type.Extended-Type.TLV-Type), and 1831 not on its encoding or location in the RADIUS packet. 1833 * Where a group of TLVs is strictly defined, and not expected to 1834 change, and and totals less than 247 octets of data, they SHOULD 1835 request allocation from the Type spaces of 241.*, 242.*, 243.*, or 1836 244.*. 1838 * Where a group of TLVs is loosely defined, or is expected to change, 1839 they SHOULD request allocation from the Type spaces of 245.* or 1840 246.*. 1842 6.7. Implementation Guidelines 1844 * RADIUS client implementations SHOULD support this specification, 1845 in order to permit the easy deployment of specifications using 1846 the changes defined herein. 1848 * RADIUS server implementations SHOULD support this specification, 1849 in order to permit the easy deployment of specifications using 1850 the changes defined herein. 1852 * RADIUS proxy servers MUST follow the specifications in section 5.2 1854 6.8. Vendor Guidelines 1856 * Vendors SHOULD use the existing Vendor-Specific Attribute Type 1857 space in preference to the new Extended-Vendor-Specific 1858 attributes, as this specification may take time to become widely 1859 deployed. 1861 * Vendors SHOULD implement this specification. The changes to 1862 RADIUS are relatively small, and are likely to quickly be used 1863 in new specifications. 1865 7. Rationale for This Design 1867 The path to extending the RADIUS protocol has been long and arduous. 1868 A number of proposals have been made and discarded by the RADEXT 1869 working group. These proposals have been judged to be either too 1870 bulky, too complex, too simple, or to be unworkable in practice. We 1871 do not otherwise explain here why earlier proposals did not obtain 1872 working group consensus. 1874 The changes outlined here have the benefit of being simple, as the 1875 "Extended Type" format requires only a one octet change to the 1876 Attribute format. The downside is that the "Long Extended Type" 1877 format is awkward, and the 7 Reserved bits will likey never be used 1878 for anything. 1880 7.1. Attribute Audit 1882 An audit of almost five thousand publicly available attributes 1883 [ATTR], shows the statistics summarized below. The attributes include 1884 over 100 Vendor dictionaries, along with the IANA assigned 1885 attributes: 1887 Count Data Type 1888 ----- --------- 1889 2257 integer 1890 1762 text 1891 273 IPv4 Address 1892 225 string 1893 96 other data types 1894 35 IPv6 Address 1895 18 date 1896 10 integer64 1897 4 Interface Id 1898 3 IPv6 Prefix 1900 4683 Total 1902 The entries in the "Data Type" column are data types recommended by 1903 [RFC6158], along with "integer64". The "other data types" row 1904 encompasses all other data types, including complex data types and 1905 data types transporting opaque data. 1907 We see that over half of the attributes encode less than 16 octets of 1908 data. It is therefore important to have an extension mechanism which 1909 adds as little as possible to the size of these attributes. Another 1910 result is that the overwhelming majority of attributes use simple 1911 data types. 1913 Of the attributes defined above, 177 were declared as being inside of 1914 a TLV. This is approximately 4% of the total. We did not 1915 investigate whether additional attributes were defined in a flat name 1916 space, but could have been defined as being inside of a TLV. We 1917 expect that the number could be as high as 10% of attributes. 1919 Manual inspection of the dictionaries shows that approximately 20 (or 1920 0.5%) attributes have the ability to transport more than 253 octets 1921 of data. These attributes are divided between VSAs, and a small 1922 number of standard Attributes such as EAP-Message. 1924 The results of this audit and analysis is reflected in the design of 1925 the extended attributes. The extended format has minimal overhead, 1926 it permits TLVs, and it has support for "long" attributes. 1928 8. Diameter Considerations 1930 The attribute formats defined in this specification need to be 1931 transported in Diameter. While Diameter supports attributes longer 1932 than 253 octets and grouped attributes, we do not use that 1933 functionality here. Instead, we define the simplest possible 1934 encapsulation method. 1936 The new formats MUST be treated the same as traditional RADIUS 1937 attributes when converting from RADIUS to Diameter, or vice versa. 1938 That is, the new attribute space is not converted to any "extended" 1939 Diameter attribute space. Fragmented attributes are not converted to 1940 a single long Diameter attribute. The new EVS data types are not 1941 converted to Diameter attributes with the "V" bit set. 1943 In short, this document mandates no changes for existing RADIUS to 1944 Diameter, or Diameter to RADIUS gateways. 1946 9. Examples 1948 A few examples are presented here in order to illustrate the encoding 1949 of the new attribute formats. These examples are not intended to be 1950 exhaustive, as many others are possible. For simplicity, we do not 1951 show complete packets, only attributes. 1953 The examples are given using a domain-specific language implemented 1954 by the program given in Appendix A. The language is line oriented, 1955 and composed of a sequence of lines matching the grammar ([RFC5234]) 1956 given below: 1958 Identifier = 1*DIGIT *( "." 1*DIGIT ) 1960 HEXCHAR = HEXDIG HEXDIG 1962 STRING = DQUOTE 1*CHAR DQUOTE 1964 TLV = "{" 1*DIGIT DATA "}" 1966 DATA = 1*HEXCHAR / 1*TLV / STRING 1968 LINE = Identifier DATA 1970 The progam has additional restrictions on its input that are not 1971 reflected in the above grammar. For example, the portions of the 1972 Identifier which refer to Type and Extended-Type are limited to 1973 values between 1 and 255. We trust that the source code in Appendix 1974 A is clear, and that these restrictions do not negatively affect the 1975 comprehensability of the examples. 1977 The program reads the input text, and interprets it as a set of 1978 instructions to create RADIUS Attributes. It then prints the hex 1979 encoding of those attributes. It implements the minimum set of 1980 functionality which achieves that goal. This minimalism means that 1981 it does not use attribute dictionaries; it does not implement support 1982 for RADIUS data types; it can be used to encode attributes with 1983 invalid data fields; and there is no requirement for consistency from 1984 one example to the next. For example, it can be used to encode a 1985 User-Name attribute which contains non-UTF8 data, or a Framed-IP- 1986 Address which contains 253 octets of ASCII data. As a result, it 1987 MUST NOT be used to create RADIUS Attributes for transport in a 1988 RADIUS message. 1990 However, the program correctly encodes the RADIUS attribute fields of 1991 "Type", "Length", "Extended-Type", "More", "Reserved", "Vendor-Id", 1992 "Vendor-Type", and "Vendor-Length". It encodes RADIUS attribute data 1993 types "evs" and TLV. It can therefore be used to encode example 1994 attributes from inputs which are humanly readable. 1996 We do not give examples of "malformed" or "invalid attributes". We 1997 also note that the examples show format, rather than consistent 1998 meaning. A particular Attribute Type code may be used to demonstrate 1999 two different formats. In real specifications, attributes have a 2000 static definitions based on their type code. 2002 The examples given below are strictly for demonstration purposes 2003 only, and do not provide a standard of any kind. 2005 9.1. Extended Type 2007 The following are a series of examples of the "Extended Type" format. 2009 Attribute encapsulating textual data. 2011 241.1 "bob" 2012 -> f1 06 01 62 6f 62 2014 Attribute encapsulating a TLV with TLV-Type of one (1). 2016 241.2 { 1 23 45 } 2017 -> f1 07 02 01 04 23 45 2019 Attribute encapsulating two TLVs, one after the other. 2021 241.2 { 1 23 45 } { 2 67 89 } 2022 -> f1 0b 02 01 04 23 45 02 04 67 89 2024 Attribute encapsulating two TLVs, where the second TLV is itself 2025 encapsulating a TLV. 2027 241.2 { 1 23 45 } { 3 { 1 ab cd } } 2028 -> f1 0d 02 01 04 23 45 03 06 01 04 ab cd 2030 Attribute encapsulating two TLVs, where the second TLV is itself 2031 encapsulating two TLVs. 2033 241.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } 2034 -> f1 12 02 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f 2036 Attribute encapsulating a TLV, which in turn encapsulates a TLV, 2037 to a depth of 5 nestings. 2039 241.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } 2040 -> f1 0f 01 01 0c 02 0a 03 08 04 06 05 04 cd ef 2042 Attribute encapsulating an extended Vendor Specific attribute, 2043 with Vendor-Id of 1, and Vendor-Type of 4, which in turn 2044 encapsulates textual data. 2046 241.26.1.4 "test" 2047 -> f1 0c 1a 00 00 00 01 04 74 65 73 74 2049 Attribute encapsulating an extended Vendor Specific attribute, with 2050 Vendor-Id of 1, and Vendor-Type of 5, which in turn encapsulates 2051 a TLV with TLV-Type of 3, which encapsulates textual data. 2053 241.26.1.5 { 3 "test" } 2054 -> f1 0e 1a 00 00 00 01 05 03 06 74 65 73 74 2056 9.2. Long Extended Type 2058 The following are a series of examples of the "Long Extended Type" 2059 format. 2061 Attribute encapsulating textual data. 2063 245.1 "bob" 2064 -> f5 07 01 00 62 6f 62 2066 Attribute encapsulating a TLV with TLV-Type of one (1). 2068 245.2 { 1 23 45 } 2069 -> f5 08 02 00 01 04 23 45 2071 Attribute encapsulating two TLVs, one after the other. 2073 245.2 { 1 23 45 } { 2 67 89 } 2074 -> f5 0c 02 00 01 04 23 45 02 04 67 89 2076 Attribute encapsulating two TLVs, where the second TLV is itself 2077 encapsulating a TLV. 2079 245.2 { 1 23 45 } { 3 { 1 ab cd } } 2080 -> f5 0e 02 00 01 04 23 45 03 06 01 04 ab cd 2082 Attribute encapsulating two TLVs, where the second TLV is itself 2083 encapsulating two TLVs. 2085 245.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } 2086 -> f5 13 02 00 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f 2088 Attribute encapsulating a TLV, which in turn encapsulates a TLV, 2089 to a depth of 5 nestings. 2091 245.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } 2092 -> f5 10 01 00 01 0c 02 0a 03 08 04 06 05 04 cd ef 2094 Attribute encapsulating an extended Vendor Specific attribute, 2095 with Vendor-Id of 1, and Vendor-Type of 4, which in turn 2096 encapsulates textual data. 2098 245.26.1.4 "test" 2099 -> f5 0d 1a 00 00 00 00 01 04 74 65 73 74 2101 Attribute encapsulating an extended Vendor Specific attribute, 2102 with Vendor-Id of 1, and Vendor-Type of 5, which in turn 2103 encapsulates a TLV with TLV-Type of 3, which encapsulates 2104 textual data. 2106 245.26.1.5 { 3 "test" } 2107 -> f5 0f 1a 00 00 00 00 01 05 03 06 74 65 73 74 2109 Attribute encapsulating more than 251 octets of data. The "Data" 2110 portions are indented for readability. 2112 245.4 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2113 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2114 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2115 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2116 aaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2117 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2118 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2119 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2120 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbcccccccccccccccccccc 2121 cccccccccc 2122 -> f5 ff 04 80 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2123 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2124 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2125 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2126 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2127 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2128 aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb bb bb bb bb bb 2129 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2130 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2131 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2132 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2133 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2134 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 13 04 00 cc 2135 cc cc cc cc cc cc cc cc cc cc cc cc cc cc 2137 Attribute encapsulating an extended Vendor Specific attribute, 2138 with Vendor-Id of 1, and Vendor-Type of 6, which in turn 2139 encapsulates more than 251 octets of data. 2141 As the VSA encapsulates more than 251 octets of data, it is 2142 split into two RADIUS attributes. The first attribute has the 2143 More field set, and carries the Vendor-Id and Vendor-Type. 2144 The second attribute has the More field clear, and carries 2145 the rest of the data portion of the VSA. Note that the second 2146 attribute does not include the Vendor-Id ad Vendor-Type fields. 2148 The "Data" portions are indented for readability. 2150 245.26.1.6 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2151 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2152 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2153 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2154 aaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2155 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2156 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2157 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2158 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbccccccccccccc 2159 ccccccccccccccccc 2160 -> f5 ff 1a 80 00 00 00 01 06 aa aa aa aa aa aa aa aa aa aa aa 2161 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2162 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2163 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2164 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2165 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2166 aa aa aa aa aa aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb 2167 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2168 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2169 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2170 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2171 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2172 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 18 1a 00 bb 2173 bb bb bb bb cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 2175 10. IANA Considerations 2177 This document updates [RFC3575] in that it adds new IANA 2178 considerations for RADIUS Attributes. These considerations modify 2179 and extend the IANA considerations for RADIUS, rather than replacing 2180 them. 2182 The IANA considerations of this document are limited to the "RADIUS 2183 Attribute Types" registry. Some Attribute Type values which were 2184 previously marked "Reserved" are now allocated, and the registry is 2185 extended from a simple 8-bit array to a tree-like structure, up to a 2186 maximum depth of 125 nodes. Detailed instructions are given below. 2188 10.1. Attribute Allocations 2190 IANA is requested to move the following Attribute Type values from 2191 "Reserved", to "Allocated", with the corresponding names: 2193 * 241 Extended-Type-1 2194 * 242 Extended-Type-2 2195 * 243 Extended-Type-3 2196 * 244 Extended-Type-4 2197 * 245 Long-Extended-Type-1 2198 * 246 Long-Extended-Type-2 2200 These values serve as an encapsulation layer for the new RADIUS 2201 Attribute Type tree. 2203 10.2. RADIUS Attribute Type Tree 2205 Each of the Attribute Type values allocated above extends the "RADIUS 2206 Attribute Types" to an N-ary tree, via a "dotted number" notation. 2207 Allocation of an Attribute Type value "TYPE" using the new Extended 2208 type format results in allocation of 255 new Attribute Type values, 2209 of format "TYPE.1" through "TYPE.255". The value zero "TYPE.0" is not 2210 used. Value twenty-six (26) is assigned as "Extended-Vendor- 2211 Specific-*". Values "TYPE.241" through "TYPE.255" are marked 2212 "Reserved". All other values are "Unassigned". 2214 The initial set of Attribute Type values and names assigned by this 2215 document is given below. 2217 * 241 Extended-Attribute-1 2218 * 241.{1-25} Unassigned 2219 * 241.26 Extended-Vendor-Specific-1 2220 * 241.{27-240} Unassigned 2221 * 241.{241-255} Reserved 2222 * 242 Extended-Attribute-2 2223 * 242.{1-25} Unassigned 2224 * 242.26 Extended-Vendor-Specific-2 2225 * 242.{27-240} Unassigned 2226 * 243 Extended-Attribute-3 2227 * 242.{241-255} Reserved 2228 * 243.{1-25} Unassigned 2229 * 243.26 Extended-Vendor-Specific-3 2230 * 243.{27-240} Unassigned 2231 * 243.{241-255} Reserved 2232 * 244 Extended-Attribute-4 2233 * 244.{1-25} Unassigned 2234 * 244.26 Extended-Vendor-Specific-4 2235 * 244.{27-240} Unassigned 2236 * 244.{241-255} Reserved 2237 * 245 Extended-Attribute-5 2238 * 245.{1-25} Unassigned 2239 * 245.26 Extended-Vendor-Specific-5 2240 * 245.{27-240} Unassigned 2241 * 245.{241-255} Reserved 2242 * 246 Extended-Attribute-6 2243 * 246.{1-25} Unassigned 2244 * 245.26 Extended-Vendor-Specific-6 2245 * 246.{27-240} Unassigned 2246 * 246.{241-255} Reserved 2248 As per [RFC5226], the values marked "Unassigned" above are available 2249 via for assignment by IANA in future RADIUS specifications. The 2250 values marked "Reserved" are reserved for future use. 2252 The Extended-Vendor-Specific spaces (TYPE.26) are for Private Use, 2253 and allocations are not managed by IANA. 2255 Allocation of Reserved entries in the extended space requires 2256 Standards Action. 2258 All other allocations in the extended space require IETF Review. 2260 10.3. Allocation Instructions 2262 This section defines what actions IANA needs to take when allocating 2263 new attributes. Different actions are required when allocating 2264 attributes from the standard space, attributes of Extended Type 2265 format, attributes of the "Long Extended Type" format, perferential 2266 allocations, attributes of data type TLV, attributes within a TLV, 2267 and attributes of other data types. 2269 10.3.1. Requested Allocation from the Standard Space 2271 Specifications can request allocation of an Attribute from within the 2272 standard space (e.g. Attribute Type Codes 1 through 255), subject to 2273 the considerations of [RFC3575] and this document. 2275 10.3.2. Requested Allocation from the short extended space 2277 Specifications can request allocation of an Attribute which requires 2278 the format Extended Type, by specifying the short extended space In 2279 that case, IANA should assign the lowest Unassigned number from the 2280 Attribute Type space with the relevant format. 2282 10.3.3. Requested Allocation from the long extended space 2284 Specifications can request allocation of an Attribute which requires 2285 the format "Long Extended Type", by specifying the extended space 2286 (long). In that case, IANA should assign the lowest Unassigned 2287 number from the Attribute Type space with the relevant format. 2289 10.3.4. Allocation Preferences 2291 Specifications which make no request for allocation from a specific 2292 Type Space should have Attributes allocated using the following 2293 criteria: 2295 * when the standard space has no more Unassigned attributes, 2296 all allocations should be performed from the extended space. 2298 * specifications which allocate a small number of attributes 2299 (i.e. less than ten) should have all allocations made from 2300 the standard space. 2302 * specifications which would allocate a large percentage of the 2303 remaining standard space attributes should have all allocations 2304 made from the extended space. 2306 * specifications which request allocation of an attribute of 2307 data type TLV should have that attribute allocated from the 2308 extended space. 2310 * specifications which request allocation of an attribute 2311 which can transport 253 or more octets of data should have 2312 that attribute allocated from within the long extended space, 2313 We note that Section 6.5, above requires specifications to 2314 request this allocation. 2316 There is otherwise no requirement that all attributes within a 2317 specification be allocated from one type space or another. 2318 Specifications can simultaneously allocate attributes from both the 2319 standard space and the extended space. 2321 10.3.5. Extending the Type Space via TLV Data Type 2323 When specifications request allocation of an attribute of data type 2324 "tlv", that allocation extends the Attribute Type Tree by one more 2325 level. Allocation of an Attribute Type value "TYPE.TLV", with Data 2326 Type TLV, results in allocation of 255 new Attribute Type values, of 2327 format "TYPE.TLV.1" through "TYPE.TLV.255". The value zero "VALUE.0" 2328 is not used. Values 254-255 are marked "Reserved". All other values 2329 are "Unassigned". Value 26 has no special meaning. 2331 For example, if a new attribute "Example-TLV" of data type "tlv" is 2332 assigned the identifier "245.1", then the extended tree will be 2333 allocated as below: 2335 * 245.1 Example-TLV 2336 * 245.1.{1-253} Unassigned 2337 * 245.1.{254-255} Reserved 2339 Note that this example does not define an "Example-TLV" attribute. 2341 The Attribute Type Tree can be extended multiple levels in one 2342 specification when the specification requests allocation of nested 2343 TLVs, as discussed below. 2345 10.3.6. Allocation within a TLV 2347 Specifications can request allocation of Attribute Type values within 2348 an Attribute of Data Type TLV. The encapsulating TLV can be 2349 allocated in the same specification, or it can have been previously 2350 allocated. 2352 Specifications need to request allocation within a specific Attribute 2353 Type value (e.g. "TYPE.TLV.*"). Allocations are performed from the 2354 smallest Unassigned value, proceeding to the largest Unassigned 2355 value. 2357 Where the Attribute being allocated is of Data Type TLV, the 2358 Attribute Type tree is extended by one level, as given in the 2359 previous section. Allocations can then be made within that level. 2361 10.3.7. Allocation of Other Data Types 2363 Attribute Type value allocations are otherwise allocated from the 2364 smallest Unassigned value, proceeding to the largest Unassigned 2365 value. e.g. Starting from 241.1, proceeding through 241.255, then to 2366 242.1, through 242.255, etc. 2368 11. Security Considerations 2370 This document defines new formats for data carried inside of RADIUS, 2371 but otherwise makes no changes to the security of the RADIUS 2372 protocol. 2374 Attacks on cryptographic hashes are well known, and are getting 2375 better with time, as discussed in[RFC4270]. RADIUS uses the MD5 hash 2376 [RFC1321] for packet authentication and attribute obfuscation. There 2377 are ongoing efforts in the IETF to analyze and address these issues 2378 for the RADIUS protocol. 2380 As with any protocol change, code changes are required in order to 2381 implement the new features. These code changes have the potential to 2382 introduce new vulnerabilities in the software. Since the RADIUS 2383 server performs network authentication, it is an inviting target for 2384 attackers. We RECOMMEND that access to RADIUS servers be kept to a 2385 minimum. 2387 12. References 2389 12.1. Normative references 2391 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2392 Requirement Levels", RFC 2119, March, 1997. 2394 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 2395 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2396 2000. 2398 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 2400 [RFC3575] Aboba, B, "IANA Considerations for RADIUS (Remote 2401 Authentication Dial In User Service)", RFC 3575, July 2003. 2403 [RFC5176] Chiba, M, et. al., "Dynamic Authorization Extensions to Remote 2404 Authentication Dial In User Service (RADIUS)", RFC 5176, 2405 January 2008. 2407 [RFC5226] Narten, T. and Alvestrand, H, "Guidelines for Writing an IANA 2408 Considerations Section in RFCs", RFC 5226, May 2008. 2410 [RFC6158] DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC 2411 6158, March 2011. 2413 [PEN] http://www.iana.org/assignments/enterprise-numbers 2415 12.2. Informative references 2417 [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, 2418 April, 1992 2420 [RFC2868] Zorn, G., et al, " RADIUS Attributes for Tunnel Protocol 2421 Support", RFC 2868, June 2000. 2423 [RFC4270] Hoffman, P, and Schneier, B, "Attacks on Cryptographic Hashes 2424 in Internet Protocols", RFC 4270, November 2005. 2426 [RFC5234] Crocker, D. (Ed.), and Overell, P., "Augmented BNF for Syntax 2427 Specifications: ABNF", RFC 5234, October 2005. 2429 [EDUROAM] Internal Eduroam testing page, data retrieved 04 August 2010. 2431 [ATTR] http://github.com/alandekok/freeradius- 2432 server/tree/master/share/, data retrieved September 2010. 2434 Acknowledgments 2436 This document is the result of long discussions in the IETF RADEXT 2437 working group. The authors would like to thank all of the 2438 participants who contributed various ideas over the years. Their 2439 feedback has been invaluable, and has helped to make this 2440 specification better. 2442 Appendix A - Extended Attribute Generator Program 2444 This section contains "C" program source which can be used for 2445 testing. It reads a line-oriented text file, parses it to create 2446 RADIUS formatted attributes, and prints the hex version of those 2447 attributes to standard output. 2449 The input accepts a grammar similar to that given in Section 8, with 2450 some modifications for usability. For example, blank lines are 2451 allowed, lines beginning with a '#' character are interpreted as 2452 comments, numbers (RADIUS Types, etc.) are checked for minimum / 2453 maximum values, and RADIUS Attribute lengths are enforced. 2455 The program is included here for demonstration purposes only, and 2456 does not define a standard of any kind. 2458 ------------------------------------------------------------ 2459 /* 2460 * Copyright (c) 2010 IETF Trust and the persons identified as 2461 * authors of the code. All rights reserved. 2462 * 2463 * Redistribution and use in source and binary forms, with or without 2464 * modification, are permitted provided that the following conditions 2465 * are met: 2466 * 2467 * Redistributions of source code must retain the above copyright 2468 * notice, this list of conditions and the following disclaimer. 2469 * 2470 * Redistributions in binary form must reproduce the above copyright 2471 * notice, this list of conditions and the following disclaimer in 2472 * the documentation and/or other materials provided with the 2473 * distribution. 2474 * 2475 * Neither the name of Internet Society, IETF or IETF Trust, nor the 2476 * names of specific contributors, may be used to endorse or promote 2477 * products derived from this software without specific prior written 2478 * permission. 2479 * 2480 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 2481 * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, 2482 * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 2483 * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 2484 * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS 2485 * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 2486 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED 2487 * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 2488 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON 2489 * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 2490 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT 2491 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 2492 * SUCH DAMAGE. 2493 * 2494 * Author: Alan DeKok 2495 */ 2496 #include 2497 #include 2498 #include 2499 #include 2500 #include 2501 #include 2503 static int encode_tlv(char *buffer, uint8_t *output, size_t outlen); 2505 static const char *hextab = "0123456789abcdef"; 2507 static int encode_data_string(char *buffer, 2508 uint8_t *output, size_t outlen) 2509 { 2510 int length = 0; 2511 char *p; 2513 p = buffer + 1; 2515 while (*p && (outlen > 0)) { 2516 if (*p == '"') { 2517 return length; 2518 } 2520 if (*p != '\\') { 2521 *(output++) = *(p++); 2522 outlen--; 2523 length++; 2524 continue; 2525 } 2527 switch (p[1]) { 2528 default: 2529 *(output++) = p[1]; 2530 break; 2532 case 'n': 2533 *(output++) = '\n'; 2534 break; 2536 case 'r': 2537 *(output++) = '\r'; 2538 break; 2540 case 't': 2541 *(output++) = '\t'; 2542 break; 2543 } 2545 outlen--; 2546 length++; 2547 } 2549 fprintf(stderr, "String is not terminated\n"); 2550 return 0; 2551 } 2553 static int encode_data_tlv(char *buffer, char **endptr, 2554 uint8_t *output, size_t outlen) 2555 { 2556 int depth = 0; 2557 int length; 2558 char *p; 2560 for (p = buffer; *p != '\0'; p++) { 2561 if (*p == '{') depth++; 2562 if (*p == '}') { 2563 depth--; 2564 if (depth == 0) break; 2565 } 2566 } 2568 if (*p != '}') { 2569 fprintf(stderr, "No trailing '}' in string starting " 2570 "with \"%s\"\n", 2571 buffer); 2572 return 0; 2573 } 2575 *endptr = p + 1; 2576 *p = '\0'; 2578 p = buffer + 1; 2579 while (isspace((int) *p)) p++; 2581 length = encode_tlv(p, output, outlen); 2582 if (length == 0) return 0; 2584 return length; 2585 } 2586 static int encode_data(char *p, uint8_t *output, size_t outlen) 2587 { 2588 int length; 2590 if (!isspace((int) *p)) { 2591 fprintf(stderr, "Invalid character following attribute " 2592 "definition\n"); 2593 return 0; 2594 } 2596 while (isspace((int) *p)) p++; 2598 if (*p == '{') { 2599 int sublen; 2600 char *q; 2602 length = 0; 2604 do { 2605 while (isspace((int) *p)) p++; 2606 if (!*p) { 2607 if (length == 0) { 2608 fprintf(stderr, "No data\n"); 2609 return 0; 2610 } 2612 break; 2613 } 2615 sublen = encode_data_tlv(p, &q, output, outlen); 2616 if (sublen == 0) return 0; 2618 length += sublen; 2619 output += sublen; 2620 outlen -= sublen; 2621 p = q; 2622 } while (*q); 2624 return length; 2625 } 2627 if (*p == '"') { 2628 length = encode_data_string(p, output, outlen); 2629 return length; 2630 } 2632 length = 0; 2633 while (*p) { 2634 char *c1, *c2; 2636 while (isspace((int) *p)) p++; 2638 if (!*p) break; 2640 if(!(c1 = memchr(hextab, tolower((int) p[0]), 16)) || 2641 !(c2 = memchr(hextab, tolower((int) p[1]), 16))) { 2642 fprintf(stderr, "Invalid data starting at " 2643 "\"%s\"\n", p); 2644 return 0; 2645 } 2647 *output = ((c1 - hextab) << 4) + (c2 - hextab); 2648 output++; 2649 length++; 2650 p += 2; 2652 outlen--; 2653 if (outlen == 0) { 2654 fprintf(stderr, "Too much data\n"); 2655 return 0; 2656 } 2657 } 2659 if (length == 0) { 2660 fprintf(stderr, "Empty string\n"); 2661 return 0; 2662 } 2664 return length; 2665 } 2667 static int decode_attr(char *buffer, char **endptr) 2668 { 2669 long attr; 2671 attr = strtol(buffer, endptr, 10); 2672 if (*endptr == buffer) { 2673 fprintf(stderr, "No valid number found in string " 2674 "starting with \"%s\"\n", buffer); 2675 return 0; 2676 } 2678 if (!**endptr) { 2679 fprintf(stderr, "Nothing follows attribute number\n"); 2680 return 0; 2681 } 2682 if ((attr <= 0) || (attr > 256)) { 2683 fprintf(stderr, "Attribute number is out of valid " 2684 "range\n"); 2685 return 0; 2686 } 2688 return (int) attr; 2689 } 2691 static int decode_vendor(char *buffer, char **endptr) 2692 { 2693 long vendor; 2695 if (*buffer != '.') { 2696 fprintf(stderr, "Invalid separator before vendor id\n"); 2697 return 0; 2698 } 2700 vendor = strtol(buffer + 1, endptr, 10); 2701 if (*endptr == (buffer + 1)) { 2702 fprintf(stderr, "No valid vendor number found\n"); 2703 return 0; 2704 } 2706 if (!**endptr) { 2707 fprintf(stderr, "Nothing follows vendor number\n"); 2708 return 0; 2709 } 2711 if ((vendor <= 0) || (vendor > (1 << 24))) { 2712 fprintf(stderr, "Vendor number is out of valid range\n"); 2713 return 0; 2714 } 2716 if (**endptr != '.') { 2717 fprintf(stderr, "Invalid data following vendor number\n"); 2718 return 0; 2719 } 2720 (*endptr)++; 2722 return (int) vendor; 2723 } 2725 static int encode_tlv(char *buffer, uint8_t *output, size_t outlen) 2726 { 2727 int attr; 2728 int length; 2729 char *p; 2730 attr = decode_attr(buffer, &p); 2731 if (attr == 0) return 0; 2733 output[0] = attr; 2734 output[1] = 2; 2736 if (*p == '.') { 2737 p++; 2738 length = encode_tlv(p, output + 2, outlen - 2); 2740 } else { 2741 length = encode_data(p, output + 2, outlen - 2); 2742 } 2744 if (length == 0) return 0; 2745 if (length > (255 - 2)) { 2746 fprintf(stderr, "TLV data is too long\n"); 2747 return 0; 2748 } 2750 output[1] += length; 2752 return length + 2; 2753 } 2755 static int encode_vsa(char *buffer, uint8_t *output, size_t outlen) 2756 { 2757 int vendor; 2758 int attr; 2759 int length; 2760 char *p; 2762 vendor = decode_vendor(buffer, &p); 2763 if (vendor == 0) return 0; 2765 output[0] = 0; 2766 output[1] = (vendor >> 16) & 0xff; 2767 output[2] = (vendor >> 8) & 0xff; 2768 output[3] = vendor & 0xff; 2770 length = encode_tlv(p, output + 4, outlen - 4); 2771 if (length == 0) return 0; 2772 if (length > (255 - 6)) { 2773 fprintf(stderr, "VSA data is too long\n"); 2774 return 0; 2775 } 2776 return length + 4; 2777 } 2779 static int encode_evs(char *buffer, uint8_t *output, size_t outlen) 2780 { 2781 int vendor; 2782 int attr; 2783 int length; 2784 char *p; 2786 vendor = decode_vendor(buffer, &p); 2787 if (vendor == 0) return 0; 2789 attr = decode_attr(p, &p); 2790 if (attr == 0) return 0; 2792 output[0] = 0; 2793 output[1] = (vendor >> 16) & 0xff; 2794 output[2] = (vendor >> 8) & 0xff; 2795 output[3] = vendor & 0xff; 2796 output[4] = attr; 2798 length = encode_data(p, output + 5, outlen - 5); 2799 if (length == 0) return 0; 2801 return length + 5; 2802 } 2804 static int encode_extended(char *buffer, 2805 uint8_t *output, size_t outlen) 2806 { 2807 int attr; 2808 int length; 2809 char *p; 2811 attr = decode_attr(buffer, &p); 2812 if (attr == 0) return 0; 2814 output[0] = attr; 2816 if (attr == 26) { 2817 length = encode_evs(p, output + 1, outlen - 1); 2818 } else { 2819 length = encode_data(p, output + 1, outlen - 1); 2820 } 2821 if (length == 0) return 0; 2822 if (length > (255 - 3)) { 2823 fprintf(stderr, "Extended Attr data is too long\n"); 2824 return 0; 2825 } 2827 return length + 1; 2828 } 2830 static int encode_extended_flags(char *buffer, 2831 uint8_t *output, size_t outlen) 2832 { 2833 int attr; 2834 int length, total; 2835 char *p; 2837 attr = decode_attr(buffer, &p); 2838 if (attr == 0) return 0; 2840 /* output[0] is the extended attribute */ 2841 output[1] = 4; 2842 output[2] = attr; 2843 output[3] = 0; 2845 if (attr == 26) { 2846 length = encode_evs(p, output + 4, outlen - 4); 2847 if (length == 0) return 0; 2849 output[1] += 5; 2850 length -= 5; 2851 } else { 2852 length = encode_data(p, output + 4, outlen - 4); 2853 } 2854 if (length == 0) return 0; 2856 total = 0; 2857 while (1) { 2858 int sublen = 255 - output[1]; 2860 if (length <= sublen) { 2861 output[1] += length; 2862 total += output[1]; 2863 break; 2864 } 2866 length -= sublen; 2868 memmove(output + 255 + 4, output + 255, length); 2869 memcpy(output + 255, output, 4); 2871 output[1] = 255; 2872 output[3] |= 0x80; 2874 output += 255; 2875 output[1] = 4; 2876 total += 255; 2877 } 2879 return total; 2880 } 2882 static int encode_rfc(char *buffer, uint8_t *output, size_t outlen) 2883 { 2884 int attr; 2885 int length, sublen; 2886 char *p; 2888 attr = decode_attr(buffer, &p); 2889 if (attr == 0) return 0; 2891 length = 2; 2892 output[0] = attr; 2893 output[1] = 2; 2895 if (attr == 26) { 2896 sublen = encode_vsa(p, output + 2, outlen - 2); 2898 } else if ((*p == ' ') || ((attr < 241) || (attr > 246))) { 2899 sublen = encode_data(p, output + 2, outlen - 2); 2901 } else { 2902 if (*p != '.') { 2903 fprintf(stderr, "Invalid data following " 2904 "attribute number\n"); 2905 return 0; 2906 } 2908 if (attr < 245) { 2909 sublen = encode_extended(p + 1, 2910 output + 2, outlen - 2); 2911 } else { 2913 /* 2914 * Not like the others! 2915 */ 2916 return encode_extended_flags(p + 1, output, outlen); 2917 } 2918 } 2919 if (sublen == 0) return 0; 2920 if (sublen > (255 -2)) { 2921 fprintf(stderr, "RFC Data is too long\n"); 2922 return 0; 2923 } 2925 output[1] += sublen; 2926 return length + sublen; 2927 } 2929 int main(int argc, char *argv[]) 2930 { 2931 int lineno; 2932 size_t i, outlen; 2933 FILE *fp; 2934 char input[8192], buffer[8192]; 2935 uint8_t output[4096]; 2937 if ((argc < 2) || (strcmp(argv[1], "-") == 0)) { 2938 fp = stdin; 2939 } else { 2940 fp = fopen(argv[1], "r"); 2941 if (!fp) { 2942 fprintf(stderr, "Error opening %s: %s\n", 2943 argv[1], strerror(errno)); 2944 exit(1); 2945 } 2946 } 2948 lineno = 0; 2949 while (fgets(buffer, sizeof(buffer), fp) != NULL) { 2950 char *p = strchr(buffer, '\n'); 2952 lineno++; 2954 if (!p) { 2955 if (!feof(fp)) { 2956 fprintf(stderr, "Line %d too long in %s\n", 2957 lineno, argv[1]); 2958 exit(1); 2959 } 2960 } else { 2961 *p = '\0'; 2962 } 2964 p = strchr(buffer, '#'); 2965 if (p) *p = '\0'; 2967 p = buffer; 2968 while (isspace((int) *p)) p++; 2969 if (!*p) continue; 2971 strcpy(input, p); 2972 outlen = encode_rfc(input, output, sizeof(output)); 2973 if (outlen == 0) { 2974 fprintf(stderr, "Parse error in line %d of %s\n", 2975 lineno, input); 2976 exit(1); 2977 } 2979 printf("%s -> ", buffer); 2980 for (i = 0; i < outlen; i++) { 2981 printf("%02x ", output[i]); 2982 } 2983 printf("\n"); 2984 } 2986 if (fp != stdin) fclose(fp); 2988 return 0; 2989 } 2990 ------------------------------------------------------------ 2992 Author's Address 2994 Alan DeKok 2995 Network RADIUS SARL 2996 15 av du Granier 2997 38240 Meylan 2998 France 3000 Email: aland@networkradius.com 3001 URI: http://networkradius.com 3003 Avi Lior 3004 Bridgewater Systems Corporation 3005 303 Terry Fox Drive 3006 Suite 100 3007 Ottawa, Ontario K2K 3J1 3008 Canada 3010 Phone: +1 (613) 591-6655 3011 Email: avi@bridgewatersystems.com 3012 URI: http://www.bridgewatersystems.com/