idnits 2.17.1 draft-ietf-radext-radius-extensions-04.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 == Line 2185 has weird spacing: '...tribute alloc...' == 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 (2 January 2012) is 4495 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 2824 -- Looks like a reference, but probably isn't: '0' on line 2759 -- Looks like a reference, but probably isn't: '2' on line 2709 -- Looks like a reference, but probably isn't: '3' on line 2739 -- Looks like a reference, but probably isn't: '4' on line 2663 -- Looks like a reference, but probably isn't: '8192' on line 2801 -- Looks like a reference, but probably isn't: '4096' on line 2802 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 15 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 2, 2012 8 2 January 2012 10 Remote Authentication Dial In User Service (RADIUS) Protocol 11 Extensions 12 draft-ietf-radext-radius-extensions-04.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 July 2, 2012. 46 Copyright Notice 47 Copyright (c) 2011 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. Unmet Requirements .................................. 6 64 1.2. Terminology ......................................... 6 65 1.3. Requirements Language ............................... 7 66 2. Extensions to RADIUS ..................................... 9 67 2.1. Extended Type ....................................... 9 68 2.2. Extended Type with Flags ............................ 10 69 2.3. TLV Data Type ....................................... 12 70 2.3.1. TLV Nesting .................................... 14 71 2.4. EVS Data Type ....................................... 14 72 2.5. Integer64 Data Type ................................. 15 73 2.6. Attribute Naming and Type Identifiers ............... 16 74 2.6.1. Attribute and TLV Naming ....................... 16 75 2.6.2. Attribute Type Identifiers ..................... 17 76 2.6.3. TLV Identifiers ................................ 17 77 2.6.4. VSA Identifiers ................................ 18 78 2.7. Invalid Attributes .................................. 18 79 3. Attribute Definitions .................................... 19 80 3.1. Extended-Type-1 ..................................... 20 81 3.2. Extended-Type-2 ..................................... 21 82 3.3. Extended-Type-3 ..................................... 21 83 3.4. Extended-Type-4 ..................................... 22 84 3.5. Extended-Type-Flagged-1 ............................. 23 85 3.6. Extended-Type-Flagged-2 ............................. 24 86 4. Vendor Specific Attributes ............................... 25 87 4.1. Extended-Vendor-Specific-1 .......................... 26 88 4.2. Extended-Vendor-Specific-2 .......................... 27 89 4.3. Extended-Vendor-Specific-3 .......................... 28 90 4.4. Extended-Vendor-Specific-4 .......................... 29 91 4.5. Extended-Vendor-Specific-5 .......................... 31 92 4.6. Extended-Vendor-Specific-6 .......................... 32 93 5. Compatibility with traditional RADIUS .................... 33 94 5.1. Attribute Allocation ................................ 34 95 5.2. Proxy Servers ....................................... 35 96 6. Guidelines ............................................... 35 97 6.1. Updates to RFC 6158 ................................. 36 98 6.2. Guidelines for Simple Data Types .................... 36 99 6.3. Guidelines for Complex Data Types ................... 36 100 6.4. Guidelines For the New Types ........................ 37 101 6.5. Allocation Request Guidelines ....................... 38 102 6.6. TLV Guidelines ...................................... 39 103 6.7. Implementation Guidelines ........................... 39 104 6.8. Vendor Guidelines ................................... 40 105 7. Rationale ................................................ 40 106 7.1. Attribute Audit ..................................... 40 107 8. Examples ................................................. 41 108 8.1. Extended Type ....................................... 42 109 8.2. Extended Type with Flags ............................ 43 110 9. IANA Considerations ...................................... 46 111 9.1. Attribute Allocations ............................... 46 112 9.2. RADIUS Attribute Type Tree .......................... 47 113 9.3. Allocation Instructions ............................. 48 114 9.3.1. Requested Allocation from the Standard Space ... 48 115 9.3.2. Requested Allocation from the short extended spa 48 116 9.3.3. Requested Allocation from the long extended spac 48 117 9.3.4. Allocation Preferences ......................... 48 118 9.3.5. Extending the Type Space via TLV Data Type ..... 49 119 9.3.6. Allocation within a TLV ........................ 50 120 9.3.7. Allocation of Other Data Types ................. 50 121 10. Security Considerations ................................. 50 122 11. References .............................................. 50 123 11.1. Normative references ............................... 50 124 11.2. Informative references ............................. 51 125 Appendix A - Extended Attribute Generator Program ............ 52 126 1. Introduction 128 Under current allocation pressure, we expect that the RADIUS 129 Attribute Type space will be exhausted by 2014 or 2015. We therefore 130 need a way to extend the type space, so that new specifications may 131 continue to be developed. Other issues have also been shown with 132 RADIUS. The attribute grouping method defined in [RFC2868] has been 133 shown to be imnpractical, and a more powerful mechanism is needed. 134 Multiple attributes have been defined which transport more than the 135 253 octets of data originally envisioned with the protocol. Each of 136 these attributes is handled as a "special case" inside of RADIUS 137 implementations, instead of as a general method. We therefore also 138 need a standardized method of transporting large quantities of data. 139 Finally, some vendors are close to allocating all of the Attributes 140 within their Vendor-Specific Attribute space. It would be useful to 141 leverage changes to the base protocol for extending the Vendor- 142 Specific Attribute space. 144 We satisfy all of these requirements through the following 145 modifications to RADIUS: 147 * defining an "Extended Type" format, which adds 8 bits of "Extended 148 Type" to the RADIUS Attribute Type space, by using one octet of the 149 "Value" field. This method gives us a general way of extending 150 the Attribute Type Space. 152 * allocating 4 attributes as using the format of "Extended Type". 153 This allocation extends the RADIUS Attribute Type Space by 154 approximately 1000 values. 156 * defining an "Extended Type with Flags" format, which inserts 157 an additional "Flags" octet between the "Extended Type" octet, 158 and the "Value" field. This method gives us a general way of 159 adding additional functionality to the protocol. 161 * defining a method which uses the "Flags" field to indicate data 162 fragmentation across multiple Attributes. This method provides a 163 standard way for an Attribute to carry more than 253 octets of 164 data. 166 * allocating 2 attributes as using the format of "Extended Type with 167 Flags". This allocation extends the RADIUS Attribute Type Space 168 by an additional 500 values. 170 * defining a new "Type Length Value" (TLV) data type. The data type 171 allows an attribute to carry TLVs as "sub-attributes", which can in 172 turn encapsulate other TLVs as "sub-sub-attributes." This change 173 creates a standard way to group a set of Attributes. 175 * defining a new "extended Vendor-Specific" (EVS) data type. The 176 data type allows an attribute to carry Vendor-Specific Attributes 177 (VSAs) inside of the new attribute formats. 179 * defining a new "integer64" data type. The data type allows 180 counters which track more than 2^32 octets of data. 182 * allocating 6 attributes using the new EVS data type. This 183 allocation extends the Vendor-Specific Attribute Type space by 184 over 1500 values. 186 As with any protocol change, the changes defined here are the result 187 of a series of compromises. We have tried to find a balance between 188 flexibility, space in the RADIUS message, compatibility with existing 189 deployments, and implementation difficulty. 191 1.1. Unmet Requirements 193 One requirement which was not met by the above modifications is to 194 have an incentive for standards to use the new space. We would 195 ideally like to deprecate the "Unassigned" attributes in the standard 196 space, which would permit allocation, but under more stringent 197 guidelines. However, [RFC5226] has no provisions for a "Deprecated" 198 entry in an IANA managed registry. 200 It is RECOMMENDED that implementations support this specification as 201 soon as possible. It is RECOMMENDED that new specifications use the 202 formats defined in this specification. 204 The alternative to the above recommendations is a circular argument 205 of not implementing this specification because no other standards 206 reference it, and also not defining new standards referencing this 207 specification because no implementations exist. 209 1.2. Terminology 211 This document uses the following terms: 213 silently discard 214 This means the implementation discards the packet without further 215 processing. The implementation MAY provide the capability of 216 logging the error, including the contents of the silently discarded 217 packet, and SHOULD record the event in a statistics counter. 219 invalid attribute 220 This means that the Length field of an Attribute is valid (as per 221 [RFC2865], Section 5, top of page 25). However, the Value field of 222 the attribute does not follow the format required by the data type 223 defined for that Attribute. e.g. an Attribute of type "address" 224 which encapsulates more than four, or less than four, octets of 225 data. See Section 2.7 for a more complete definition. 227 Standard space 228 Codes in the RADIUS Attribute Type Space that are allocated by IANA 229 and that follow the format defined in Section 5 of RFC 2865 230 [RFC2865]. 232 Extended space 233 Codes in the RADIUS Attribute Type Space that require the 234 extensions defined in this document, and are an extension of the 235 standard space, but which cannot be represented within the standard 236 space. 238 Short extended space 239 Codes in the extended space which use the "Extended Type" format. 241 Long extended space 242 Codes in the extended space which use the "Extended Type with 243 Flags" format. 245 The following terms are used here with the meanings defined in BCP 246 26: "name space", "assigned value", "registration". 248 The following terms are used here with the meanings defined in BCP 249 26: "Private Use", "Reserved", "Unassigned". 251 The following policies are used here with the meanings defined in 252 BCP 26: "Private Use", "IETF Review", "Standards Action". 254 1.3. Requirements Language 256 In this document, several words are used to signify the requirements 257 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 258 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 259 and "OPTIONAL" in this document are to be interpreted as described in 260 [RFC2119]. 262 An implementation is not compliant if it fails to satisfy one or more 263 of the must or must not requirements for the protocols it implements. 264 An implementation that satisfies all the MUST, MUST NOT, SHOULD, and 265 SHOULD NOT requirements for its protocols is said to be 266 "unconditionally compliant"; one that satisfies all the MUST and MUST 267 NOT requirements but not all the SHOULD or SHOULD NOT requirements 268 for its protocols is said to be "conditionally compliant". 270 2. Extensions to RADIUS 272 This section defines two new attribute formats; "Extended Type"; and 273 "Extended Type with Flags". It defines a new Type-Length-Value (TLV) 274 data type, an Extended-Vendor-Specific (EVS) data type, and an 275 Integer64 data type. It defines a new method for naming attributes 276 and identifying Attributes using the new attribute formats. It 277 finally defines the new term "invalid attribute", and describes how 278 it affects implementations. 280 2.1. Extended Type 282 This section defines a new attribute format, called "Extended Type". 283 A summary of the Attribute format is shown below. The fields are 284 transmitted from left to right. 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Type | Length | Extended-Type | Value ... 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 Type 294 This field is identical to the Type field of the Attribute format 295 defined in [RFC2865] Section 5. 297 Length 299 This field is identical to the Length field of the Attribute 300 format defined in [RFC2865] Section 5. Permitted values are 301 between 4 and 255. If a client or server receives an Extended 302 Attribute with a Length of 2 or 3, then that Attribute MUST be 303 deemed to be an "invalid attribute", and handled as per Section 304 XXX, below. 306 Extended-Type 308 The Extended-Type field is one octet. Up-to-date values of this 309 field are specified by IANA. Unlike the Type field defined in 310 [RFC2865] Section 5, no values are allocated for experimental or 311 implementation-specific use. Values 241-255 are reserved and 312 SHOULD NOT be used. 314 The Extended-Type is meaningful only within a context defined by 315 the Type field. That is, this field may be thought of as defining 316 a new type space of the form "Type.Extended-Type". See Section 317 2.5, below, for additional discussion. 319 A RADIUS server MAY ignore Attributes with an unknown 320 "Type.Extended-Type". 322 A RADIUS client MAY ignore Attributes with an unknown 323 "Type.Extended-Type". 325 Value 327 This field is similar to the Value field of the Attribute format 328 defined in [RFC2865] Section 5. The format of the data SHOULD be 329 a valid RADIUS data type. 331 The addition of the Extended-Type field decreases the maximum 332 length for attributes of type "text" or "string" from 253 to 252 333 octets. Where an Attribute needs to carry more than 252 octets of 334 data, the "Extended Type with flags" format should be used. 336 Experience has shown that the "experimental" and "implementation 337 specific" attributes defined in [RFC2865] Section 5 have had little 338 practical value. We therefore do not continue that practice here 339 with the Extended-Type field. 341 2.2. Extended Type with Flags 343 This section defines a new attribute format, called "Extended Type 344 with Flags". It leverages the "Extended Type" format in order to 345 permit the transport of attributes encapsulating more than 253 octets 346 of data. A summary of the Attribute format is shown below. The 347 fields are transmitted from left to right. 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Type | Length | Extended-Type |M| Flags | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Value ... 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Type 359 This field is identical to the Type field of the Attribute format 360 defined in [RFC2865] Section 5. 362 Length 364 This field is identical to the Length field of the Attribute 365 format defined in [RFC2865] Section 5. Permitted values are 366 between 5 and 255. If a client or server receives an "Extended 367 Attribute with Flags" with a Length of 2, 3, or 4, then that 368 Attribute MUST be deemed to be an "invalid attribute", and be 369 handled as per Section 2.7, below. 371 Extended-Type 373 This field is identical to the Extended-Type field defined above 374 in Section 2.1. 376 M (More) 378 The More Flag is one (1) bit in length, and indicates whether or 379 not the current attribute contains "more" than 251 octets of data. 380 The More flag MUST be clear (0) if the Length field has value less 381 than 255. The More flag MAY be set (1) if the Length field has 382 value of 255. 384 If the More flag is set (1), it indicates that the Value field has 385 been fragmented across multiple RADIUS attributes. When the More 386 flag is set (1), the attribute SHOULD have a Length field of value 387 255; it MUST NOT have a length Field of value 4; there MUST be an 388 attribute following this one; and the next attribute MUST have 389 both the same Type and Extended Type. That is, multiple fragments 390 of the same value MUST be in order and MUST be consecutive 391 attributes in the packet, and the last attribute in a packet MUST 392 NOT have the More flag set (1). 394 When the Length field of an attribute has value less than 255, the 395 More flag SHOULD be clear (0). 397 If a client or server receives an attribute fragment with the 398 "More" flag set (1), but for which no subsequent fragment can be 399 found, then the fragmented attribute is deemed to be an "invalid 400 attribute", and handled as per Section 2.7, below. 402 Flags 404 This field is 7 bits long, and is reserved for future use. 405 Implementations MUST set it to zero (0) when encoding an attribute 406 for sending in a packet. The contents SHOULD be ignored on 407 reception. 409 Future specifications may define additional meaning for this 410 field. Implementations therefore MUST NOT treat this field as 411 invalid if it is non-zero. 413 Value 414 This field is similar to the Value field of the Attribute format 415 defined in [RFC2865] Section 5. It may contain a complete set of 416 data (when the Length field has value less than 255), or it may 417 contain a fragment of data (when the More field is set). 419 Any interpretation of the resulting data MUST occur after the 420 fragments have been reassembled. The length of the data MUST be 421 taken as the sum of the lengths of the fragments (i.e. Value 422 fields) from which it is constructed. The format of the data 423 SHOULD be a valid RADIUS data type. 425 This definition increases the RADIUS Attribute Type space as above, 426 but also provides for transport of Attributes which could contain 427 more than 253 octets of data. 429 2.3. TLV Data Type 431 We define a new data type in RADIUS, called "tlv". The "tlv" data 432 type is an encapsulation layer which permits the "Value" field of an 433 Attribute to contain new sub-Attributes. These sub-Attributes can in 434 turn contain "Value"s of data type TLV. This capability both extends 435 the attribute space, and permits "nested" attributes to be used. 436 This nesting can be used to encapsulate or group data into one or 437 more logical containers. 439 The "tlv" data type re-uses the RADIUS attribute format, as given 440 below: 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | TLV-Type | TLV-Length | TLV-Value ... 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 TLV-Type 450 The Type field is one octet. Up-to-date values of this field are 451 specified by IANA. Values of zero (0) MUST NOT be used. Values 452 254-255 are "Reserved" for use by future extensions to RADIUS. 453 The value 26 has no special meaning, and MUST NOT be treated as a 454 Vendor Specific attribute. 456 As with Extended-Type above, the TLV-Type is meaningful only 457 within the context defined by "Type" fields of the encapsulating 458 Attributes. That is, the field may be thought of as defining a 459 new type space of the form "Type.Extended-Type.TLV-Type". Where 460 TLVs are nested, the type space is of the form "Type.Extended- 461 Type.TLV-Type.TLV-Type", etc. 463 A RADIUS server MAY ignore Attributes with an unknown "TLV-Type". 465 A RADIUS client MAY ignore Attributes with an unknown "TLV-Type". 467 A RADIUS proxy SHOULD forward Attributes with an unknown "TLV- 468 Type" verbatim. 470 TLV-Length 472 The TLV-Length field is one octet, and indicates the length of 473 this TLV including the TLV-Type, TLV-Length and TLV-Value fields. 474 It MUST have a value between 3 and 255. If a client or server 475 receives a TLV with an invalid TLV-Length, then the attribute 476 which encapsulates that TLV MUST be deemed to be an "invalid 477 attribute", and handled as per Section 2.7, below. 479 TLV-Value 481 The Value field is one or more octets and contains information 482 specific to the Attribute. The format and length of the TLV-Value 483 field is determined by the TLV-Type and TLV-Length fields. 485 The TLV-Value field SHOULD encapsulate a previously defined RADIUS 486 data type. Using non-standard data types is NOT RECOMMENDED. We 487 note that the TLV-Value field MAY also contain one or more 488 attributes of data type "tlv", which allows for simple grouping 489 and multiple layers of nesting. 491 The TLV-Value field is limited to containing 253 or fewer octets 492 of data. Specifications which require a TLV to contain more than 493 253 octets of data are incompatible with RADIUS, and need to be 494 redesigned. Specifications which require the transport of empty 495 Values (i.e. Length = 2) are incompatible with RADIUS, and need to 496 be redesigned. 498 The TLV-Value field MUST NOT contain data using the "Extended 499 Type" formats defined in this document. The base Extended 500 Attributes format allows for sufficient flexibility that nesting 501 them inside of a TLV offers little additional value. 503 This TLV definition is compatible with the suggested format of the 504 "String" field of the Vendor-Specific attribute, as defined in 505 [RFC2865] Section 5.26, though that specification does not discuss 506 nesting. 508 Vendors MAY use attributes of type "tlv" in any Vendor Specific 509 Attribute. We RECOMMEND using type "tlv" for VSAs, in preference to 510 any other format. 512 2.3.1. TLV Nesting 514 TLVs may contain other TLVs. When this occurs, the "container" TLV 515 MUST be completely filled by the "contained" TLVs. That is, the 516 "container" TLV-Length field MUST be exactly two (2) more than the 517 sum of the "contained" TLV-Length fields. If the "contained" TLVs 518 over-fill the "container" TLV, the "container" TLV MUST be considered 519 to be an "invalid attribute", and handled as described in Section 520 XXX, below. 522 The depth of TLV nesting is limited only by the restrictions on the 523 TLV-Length field. The limit of 253 octets of data results in a limit 524 of 126 levels of nesting. However, nesting depths of more than 4 are 525 NOT RECOMMENDED. 527 2.4. EVS Data Type 529 We define a new data type in RADIUS, called "evs", for "Extended 530 Vendor-Specific". The "evs" data type is an encapsulation layer 531 which which permits the "Value" field of an Attribute to contain a 532 Vendor-Id, followed by a Vendor-Type, and then vendor-defined data. 533 This data can in turn contain valid RADIUS data types, or any other 534 data as determined by the vendor. 536 This data type is intended use in attributes which carry Vendor- 537 Specific information, as is done with the Vendor-Specific Attribute 538 (26). It is RECOMMENDED that this data type be used by a vendor only 539 when the Vendor-Specific Attribute Type space has been fully 540 allocated. 542 Where [RFC2865] Section 5.26 makes a recommendation for the format of 543 the data following the Vendor-Id, we give a strict definition. 544 Experience has shown that many vendors have not followed the 545 [RFC2865] recommendations, leading to interoperability issues. We 546 hope here to give vendors sufficient flexibility as to meet their 547 needs, while minimizing the use of non-standard VSA formats. 549 The "evs" data type MAY be used in Attributes having the format of 550 "Extended Type" or "Extended Type with Flags". It MUST NOT be used 551 in any other Attribute definition, including standard RADIUS 552 Attributes, TLVs, and VSAs. 554 A summary of the "evs" data type format is shown below. The fields 555 are transmitted from left to right. 557 0 1 2 3 558 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 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Vendor-Id | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Vendor-Type | String .... 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 Vendor-Id 567 The high-order octet is 0 and the low-order 3 octets are the SMI 568 Network Management Private Enterprise Code of the Vendor in 569 network byte order. 571 Vendor-Type 573 The Vendor-Type field is one octet. Values are assigned at the 574 sole discretion of the Vendor. 576 Value 578 The Value field is one or more octets. It SHOULD encapsulate a 579 previously defined RADIUS data type. Using non-standard data 580 types is NOT RECOMMENDED. We note that the Value field may be of 581 data type "tlv". However, it MUST NOT be of data type "evs", as 582 the use cases are unclear for one vendor delegating Attribute Type 583 space to another vendor. 585 The actual format of the information is site or application 586 specific, and a robust implementation SHOULD support the field as 587 undistinguished octets. We recognise that Vendors have complete 588 control over the contents and format of the Value field, while at 589 the same time recommending that good practices be followed. 591 Further codification of the range of allowed usage of this field 592 is outside the scope of this specification. 594 Note that unlike the format described in [RFC2865] Section 5.26, this 595 data type has no "Vendor length" field. The length of the "String" 596 field is implicit, and is determined by taking the "Length" of the 597 encapsulating RADIUS Attribute, and subtracting the length of the 598 attribute header including the 4 octets of Vendor-Id. i.e. For 599 "Extended Type" attributes, the length of the String field is seven 600 (7) less than the value of the Length field. For "Extended Type with 601 Flags" attributes, the length of the String field is eight (8) less 602 than the value of the Length field. 604 2.5. Integer64 Data Type 606 We define a new data type in RADIUS, called "integer64", which 607 carries a 64-bit unsigned integer in network byte order. 609 This data type is intended to be used in any situation where there is 610 a need to have counters which can count past 2^32. The expected use 611 of this data type is within Accounting-Request packets, but this data 612 type SHOULD be used in any packet where 32-bit integers are expected 613 to be insufficient. 615 The "integer64" data type MAY be used in Attributes of any format, 616 standard space, extended attributes, TLVs, and VSAs. 618 A summary of the "integer64" data type format is shown below. The 619 fields are transmitted from left to right. 621 0 1 2 3 622 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 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Value ... 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 Attributes having data type "integer64" MUST have the relevant Length 630 field set to eight more than the length of the Attribute header. For 631 standard space Attributes and TLVs, this means that the Length field 632 MUST be set to ten (10). For "Extended Type" Attributes, the Length 633 field MUST be set to eleven (11). For "Extended Type with Flags" 634 Attributes, the Length field MUST be set to twelve (12). 636 2.6. Attribute Naming and Type Identifiers 638 Attributes have traditionally been identified by a unique name and 639 number. For example, the attribute named "User-Name" has been 640 allocated number one (1). This scheme needs to be extended in order 641 to be able to refer to attributes of Extended Type, and to TLVs. It 642 will also be used by IANA for allocating RADIUS Attribute Type 643 values. 645 The names and identifiers given here are intended to be used only in 646 specifications. The system presented here may not be useful when 647 referring to the contents of a RADIUS packet. It imposes no 648 requirements on implementations, as implementations are free to 649 reference RADIUS Attributes via any method they choose. 651 2.6.1. Attribute and TLV Naming 653 RADIUS specifications traditionally use names consisting of one or 654 more words, separated by hyphens, e.g. "User-Name". However, these 655 names are not allocated from a registry, and there is no restriction 656 other than convention on their global uniqueness. 658 Similarly, vendors have often used their company name as the prefix 659 for VSA names, though this practice is not universal. For example, 660 for a vendor named "Example", the name "Example-Attribute-Name" 661 SHOULD be used instead of "Attribute-Name". The second form can 662 conflict with attributes from other vendors, whereas the first form 663 cannot. 665 We therefore RECOMMEND that specifications give names to Attributes 666 which attempt to be globally unique across all RADIUS Attributes. We 667 RECOMMEND that vendors use their name as a unique prefix for 668 attribute names. We recognise that these suggestion may sometimes be 669 difficult to implement in practice. 671 TLVs SHOULD be named with a unique prefix that is shared among 672 related attributes. For example, a specification that defines a set 673 of TLVs related to time could create attributes named "Time-Zone", 674 "Time-Day", "Time-Hour", "Time-Minute", etc. 676 2.6.2. Attribute Type Identifiers 678 The RADIUS Attribute Type space defines a context for a particular 679 "Extended-Type" field. The "Extended-Type" field allows for 256 680 possible type code values, with values 1 through 240 available for 681 allocation. We define here an identification method that uses a 682 "dotted number" notation similar to that used for Object Identifiers 683 (OIDs), formatted as "Type.Extended-Type". 685 For example, and attribute within the Type space of 241, having 686 Extended-Type of one (1), is uniquely identified as "241.1". 687 Similarly, an attribute within the Type space of 246, having 688 Extended-Type of ten (10), is uniquely identified as "246.10". 690 The algorithm used to create the Attribute Identifier is simply to 691 concatenate all of the various identification fields (e.g. Type, 692 Extended-Type, etc.), starting from the encapsulating attribute, down 693 to the final encapsulated TLV, separated by a '.' character. 695 2.6.3. TLV Identifiers 697 We can extend the Attribute reference scheme defined above for TLVs. 698 This is done by leveraging the "dotted number" notation. As above, 699 we define an additional TLV type space, within the "Extended Type" 700 space, by appending another "dotted number" in order to identify the 701 TLV. This method can be replied in sequence for nested TLVs. 703 For example, let us say that "245.1" identifies RADIUS Attribute Type 704 245, containing an "Extended Type" of one (1), which is of type 705 "tlv". That attribute will contain 256 possible TLVs, one for each 706 value of the TLV-Type field. The first TLV-Type value of one (1) can 707 then be identified by appending a ".1" to the number of the 708 encapsulating attribute ("241.1"), to yield "241.1.1". Similarly, 709 the sequence "245.2.3.4" identifies RADIUS attribute 245, containing 710 an "Extended Type" of two (2) which is of type "tlv", which in turn 711 contains a TLV with TLV-Type number three (3), which in turn contains 712 another TLV, wth TLV-Type number four (4). 714 2.6.4. VSA Identifiers 716 There has historically been no method for numerically addressing 717 VSAs. The "dotted number" method defined here can also be leveraged 718 to create such an addressing scheme. However, as the VSAs are 719 completely under the control of each individual vendor, this section 720 provides a suggested practice, but does not define a standard of any 721 kind. 723 The Vendor-Specific Attribute has been assigned the Attribute number 724 26. It in turn carries a 24-bit Vendor-Id, and possibly additional 725 VSAs. Where the VSAs follow the [RFC2865] Section 5.26 recommended 726 format, a VSA can be identified as "26.Vendor-Id"."Vendor-Type". 728 For example, Livingston has Vendor-Id 307, and has defined an 729 attribute "IP-Pool" as number 6. This VSA can be uniquely identified 730 as 26.307.6. 732 Note that there is no restriction on the size of the numerical values 733 in this notation. The Vendor-Id is a 24-bit number, and the VSA may 734 have been assigned from a 16-bit vendor-specific Attribute Type 735 space. 737 For example, the company USR has been allocated Vendor-Id 429, and 738 has defined a "Version-Id" attribute as number 32768. This VSA can 739 be uniquely identified as 26.429.32768. 741 Where a VSA is a TLV, the "dotted number" notation can be used as 742 above: 26.VID.VSA.TLV1.TLV2.TLV3 where "TLVn" are the numerical 743 values assigned by the vendor to the different nested TLVs. 745 2.7. Invalid Attributes 747 The term "invalid attribute" is new to this specification. It is 748 defined to mean that the Length field of an Attribute is valid (as 749 per [RFC2865], Section 5, top of page 25). However, the Value field 750 of the attribute does not follow the format required by the data type 751 defined for that Attribute. e.g. an Attribute of data type "address" 752 which encapsulates more than four, or less than four, octets of data. 753 Or, an IPV6 Prefix attribute which has a Prefix value of more than 754 128. 756 While the content of these attributes is malformed, we emphasize that 757 the encapsulating RADIUS packet (or TLV) is well formed, and can be 758 correctly decoded. The existence of an "invalid attribute" in a 759 packet MUST NOT result in the implementation discarding the entire 760 packet, or treating the packet as a negative acknowledgement. 761 Instead, only the "invalid attribute" is treated differently. 763 When an implementation receives an "invalid attribute", it SHOULD be 764 silently discarded. If it is not discarded, it MUST NOT be handled 765 in the same manner as a well-formed attribute. For example, 766 receiving an Attribute of data type "address" containing more than 767 four, or less than four octets of data means that the Attribute MUST 768 NOT be treated as being of data type "address". 770 For Attributes of type "Extended Type with Flags", an Attribute is 771 deemed to be an "invalid attribute" when does not match the criteria 772 set out in Section 2.2, above. 774 For Attributes of type "TLV", an Attribute is deemed to be an 775 "invalid attribute" when the TLV-Length field is valid, but the TLV- 776 Value field does not match the criteria for that Attribute. 777 Implementations SHOULD NOT treat the "invalid attribute" property as 778 being transitive. That is, the encapsulating Attribute SHOULD NOT be 779 treated as being an "invalid attribute" if it encapsulates an 780 "invalid attribute". 782 3. Attribute Definitions 784 We define four (4) attributes of "Extended Type", which are allocated 785 from the "Reserved" Attribute Type codes of 241, 242, 243, and 244. 786 We also define two (2) attributes of "Extended Type with Flags", 787 which are allocated from the "Reserved" Attribute Type codes of 245 788 and 246. 790 Type Name 791 ---- ---- 792 241 Extended-Type-1 793 242 Extended-Type-2 794 243 Extended-Type-3 795 244 Extended-Type-4 796 245 Extended-Type-Flagged-1 797 246 Extended-Type-Flagged-2 799 The rest of this section gives a detailed definition for each 800 Attribute based on the above summary. 802 3.1. Extended-Type-1 804 Description 806 This attribute encapsulates attributes of the "Extended Type" 807 format, in the RADIUS Attribute Type Space of 241.{1-255}. 809 A summary of the Extended-Type-1 Attribute format is shown below. 810 The fields are transmitted from left to right. 812 0 1 2 3 813 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 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Type | Length | Extended-Type | Value ... 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 Type 820 241 for Extended-Type-1. 822 Length 824 >= 4 826 Extended-Type 828 The Extended-Type field is one octet. Up-to-date values of this 829 field are specified by IANA, in the 241.{1-255} RADIUS Attribute 830 Type Space. Further definition of this field is given in Section 831 2.1, above. 833 Value 835 The Value field is one or more octets. Implementations not 836 supporting this specification SHOULD support the field as 837 undistinguished octets. 839 Implementations supporting this specification MUST use the 840 Identifier of "Type.Extended-Type" to determine the interpretation 841 of the Value field. 843 3.2. Extended-Type-2 845 Description 847 This attribute encapsulates attributes of the "Extended Type" 848 format, in the RADIUS Attribute Type Space of 242.{1-255}. 850 A summary of the Extended-Type-2 Attribute format is shown below. 851 The fields are transmitted from left to right. 853 0 1 2 3 854 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 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Type | Length | Extended-Type | Value ... 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 Type 861 242 for Extended-Type-2. 863 Length 865 >= 4 867 Extended-Type 869 The Extended-Type field is one octet. Up-to-date values of this 870 field are specified by IANA, in the 242.{1-255} RADIUS Attribute 871 Type Space. Further definition of this field is given in Section 872 2.1, above. 874 Value 876 The Value field is one or more octets. Implementations not 877 supporting this specification SHOULD support the field as 878 undistinguished octets. 880 Implementations supporting this specification MUST use the 881 Identifier of "Type.Extended-Type" to determine the interpretation 882 of the Value field 884 3.3. Extended-Type-3 886 Description 888 This attribute encapsulates attributes of the "Extended Type" 889 format, in the RADIUS Attribute Type Space of 243.{1-255}. 891 A summary of the Extended-Type-3 Attribute format is shown below. 892 The fields are transmitted from left to right. 894 0 1 2 3 895 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 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Type | Length | Extended-Type | Value ... 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 Type 902 243 for Extended-Type-3. 904 Length 906 >= 4 908 Extended-Type 910 The Extended-Type field is one octet. Up-to-date values of this 911 field are specified by IANA, in the 243.{1-255} RADIUS Attribute 912 Type Space. Further definition of this field is given in Section 913 2.1, above. 915 Value 917 The Value field is one or more octets. Implementations not 918 supporting this specification SHOULD support the field as 919 undistinguished octets. 921 Implementations supporting this specification MUST use the 922 Identifier of "Type.Extended-Type" to determine the interpretation 923 of the Value field. 925 3.4. Extended-Type-4 927 Description 929 This attribute encapsulates attributes of the "Extended Type" 930 format, in the RADIUS Attribute Type Space of 244.{1-255}. 932 A summary of the Extended-Type-4 Attribute format is shown below. 933 The fields are transmitted from left to right. 935 0 1 2 3 936 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 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Type | Length | Extended-Type | Value ... 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 Type 944 244 for Extended-Type-4. 946 Length 948 >= 4 950 Extended-Type 952 The Extended-Type field is one octet. Up-to-date values of this 953 field are specified by IANA, in the 244.{1-255} RADIUS Attribute 954 Type Space. Further definition of this field is given in Section 955 2.1, above. 957 Value 959 The Value field is one or more octets. Implementations not 960 supporting this specification SHOULD support the field as 961 undistinguished octets. 963 Implementations supporting this specification MUST use the 964 Identifier of "Type.Extended-Type" to determine the interpretation 965 of the Value Field. 967 3.5. Extended-Type-Flagged-1 969 Description 971 This attribute encapsulates attributes of the "Extended Type with 972 Flags" format, in the RADIUS Attribute Type Space of 245.{1-255}. 974 A summary of the Extended-Type-Flagged-1 Attribute format is shown 975 below. The fields are transmitted from left to right. 977 0 1 2 3 978 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 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | Type | Length | Extended-Type |M| Flags | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Value ... 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 Type 986 245 for Extended-Type-Flagged-1 988 Length 990 >= 5 992 Extended-Type 994 The Extended-Type field is one octet. Up-to-date values of this 995 field are specified by IANA, in the 245.{1-255} RADIUS Attribute 996 Type Space. Further definition of this field is given in Section 997 2.1, above. 999 M (More) 1001 The More Flag is one (1) bit in length, and indicates whether or 1002 not the current attribute contains "more" than 251 octets of data. 1003 Further definition of this field is given in Section 2.2, above. 1005 Flags 1007 This field is 7 bits long, and is reserved for future use. 1008 Implementations MUST set it to zero (0) when encoding an attribute 1009 for sending in a packet. The contents SHOULD be ignored on 1010 reception. 1012 Value 1014 The Value field is one or more octets. Implementations not 1015 supporting this specification SHOULD support the field as 1016 undistinguished octets. 1018 Implementations supporting this specification MUST use the 1019 Identifier of "Type.Extended-Type" to determine the interpretation 1020 of the Value field. 1022 3.6. Extended-Type-Flagged-2 1024 Description 1026 This attribute encapsulates attributes of the "Extended Type with 1027 Flags" format, in the RADIUS Attribute Type Space of 246.{1-255}. 1029 A summary of the Extended-Type-Flagged-2 Attribute format is shown 1030 below. The fields are transmitted from left to right. 1032 0 1 2 3 1033 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 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Type | Length | Extended-Type |M| Flags | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | Value ... 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 Type 1043 246 for Extended-Type-Flagged-2 1045 Length 1047 >= 5 1049 Extended-Type 1051 The Extended-Type field is one octet. Up-to-date values of this 1052 field are specified by IANA, in the 246.{1-255} RADIUS Attribute 1053 Type Space. Further definition of this field is given in Section 1054 2.1, above. 1056 M (More) 1058 The More Flag is one (1) bit in length, and indicates whether or 1059 not the current attribute contains "more" than 251 octets of data. 1060 Further definition of this field is given in Section 2.2, above. 1062 Flags 1064 This field is 7 bits long, and is reserved for future use. 1065 Implementations MUST set it to zero (0) when encoding an attribute 1066 for sending in a packet. The contents SHOULD be ignored on 1067 reception. 1069 Value 1071 The Value field is one or more octets. Implementations not 1072 supporting this specification SHOULD support the field as 1073 undistinguished octets. 1075 Implementations supporting this specification MUST use the 1076 Identifier of "Type.Extended-Type" to determine the interpretation 1077 of the Value field. 1079 4. Vendor Specific Attributes 1081 We define six new attributes which can carry Vendor Specific 1082 information. We define four (4) attributes of the "Extended Type" 1083 format, with Type codes (241.26, 242.26, 243.26, 244.26), using the 1084 "evs" data type. We also define two (2) attributes of "Extended Type 1085 with Flags" format, with Type codes (245.26, 246.26), using the "evs" 1086 data type. 1088 Type.Extended-Type Name 1089 ------------------ ---- 1090 241.26 Extended-Vendor-Specific-1 1091 242.26 Extended-Vendor-Specific-2 1092 243.26 Extended-Vendor-Specific-3 1093 244.26 Extended-Vendor-Specific-4 1094 245.26 Extended-Vendor-Specific-5 1095 246.26 Extended-Vendor-Specific-6 1097 The rest of this section gives a detailed definition for each 1098 Attribute based on the above summary. 1100 4.1. Extended-Vendor-Specific-1 1102 Description 1104 This attribute defines a RADIUS Type Code of 241.26, using the 1105 "evs" data type. 1107 A summary of the Extended-Vendor-Specific-1 Attribute format is shown 1108 below. The fields are transmitted from left to right. 1110 0 1 2 3 1111 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 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | Type | Length | Extended-Type | Vendor-Id ... 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 ... Vendor-Id (cont) | Vendor-Type | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | Value .... 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 Type.Extended-Type 1122 241.26 for Extended-Vendor-Specific-1 1124 Length 1126 >= 9 1128 Vendor-Id 1130 The high-order octet is 0 and the low-order 3 octets are the SMI 1131 Network Management Private Enterprise Code of the Vendor in 1132 network byte order. 1134 Vendor-Type 1136 The Vendor-Type field is one octet. Values are assigned at the 1137 sole discretion of the Vendor. 1139 Value 1141 The Value field is one or more octets. The actual format of the 1142 information is site or application specific, and a robust 1143 implementation SHOULD support the field as undistinguished octets. 1145 The codification of the range of allowed usage of this field is 1146 outside the scope of this specification. 1148 The length of the Value field is eight (8) less then the value of 1149 the Length field. 1151 Implementations supporting this specification MUST use the 1152 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1153 determine the interpretation of the Value field. 1155 4.2. Extended-Vendor-Specific-2 1157 Description 1159 This attribute defines a RADIUS Type Code of 242.26, using the 1160 "evs" data type. 1162 A summary of the Extended-Vendor-Specific-2 Attribute format is shown 1163 below. The fields are transmitted from left to right. 1165 0 1 2 3 1166 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 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 | Type | Length | Extended-Type | Vendor-Id ... 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 ... Vendor-Id (cont) | Vendor-Type | 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1172 | Value .... 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 Type.Extended-Type 1177 242.26 for Extended-Vendor-Specific-2 1179 Length 1181 >= 9 1183 Vendor-Id 1185 The high-order octet is 0 and the low-order 3 octets are the SMI 1186 Network Management Private Enterprise Code of the Vendor in 1187 network byte order. 1189 Vendor-Type 1191 The Vendor-Type field is one octet. Values are assigned at the 1192 sole discretion of the Vendor. 1194 Value 1196 The Value field is one or more octets. The actual format of the 1197 information is site or application specific, and a robust 1198 implementation SHOULD support the field as undistinguished octets. 1200 The codification of the range of allowed usage of this field is 1201 outside the scope of this specification. 1203 The length of the Value field is eight (8) less then the value of 1204 the Length field. 1206 Implementations supporting this specification MUST use the 1207 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1208 determine the interpretation of the Value field. 1210 4.3. Extended-Vendor-Specific-3 1212 Description 1214 This attribute defines a RADIUS Type Code of 243.26, using the 1215 "evs" data type. 1217 A summary of the Extended-Vendor-Specific-3 Attribute format is shown 1218 below. The fields are transmitted from left to right. 1220 0 1 2 3 1221 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 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 | Type | Length | Extended-Type | Vendor-Id ... 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 ... Vendor-Id (cont) | Vendor-Type | 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 | Value .... 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 Type.Extended-Type 1232 243.26 for Extended-Vendor-Specific-3 1234 Length 1236 >= 9 1238 Vendor-Id 1240 The high-order octet is 0 and the low-order 3 octets are the SMI 1241 Network Management Private Enterprise Code of the Vendor in 1242 network byte order. 1244 Vendor-Type 1246 The Vendor-Type field is one octet. Values are assigned at the 1247 sole discretion of the Vendor. 1249 Value 1251 The Value field is one or more octets. The actual format of the 1252 information is site or application specific, and a robust 1253 implementation SHOULD support the field as undistinguished octets. 1255 The codification of the range of allowed usage of this field is 1256 outside the scope of this specification. 1258 The length of the Value field is eight (8) less then the value of 1259 the Length field. 1261 Implementations supporting this specification MUST use the 1262 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1263 determine the interpretation of the Value field. 1265 4.4. Extended-Vendor-Specific-4 1267 Description 1269 This attribute defines a RADIUS Type Code of 244.26, using the 1270 "evs" data type. 1272 A summary of the Extended-Vendor-Specific-3 Attribute format is shown 1273 below. The fields are transmitted from left to right. 1275 0 1 2 3 1276 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 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1278 | Type | Length | Extended-Type | Vendor-Id ... 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 ... Vendor-Id (cont) | Vendor-Type | 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 | Value .... 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 Type.Extended-Type 1287 244.26 for Extended-Vendor-Specific-4 1289 Length 1291 >= 9 1293 Vendor-Id 1295 The high-order octet is 0 and the low-order 3 octets are the SMI 1296 Network Management Private Enterprise Code of the Vendor in 1297 network byte order. 1299 Vendor-Type 1301 The Vendor-Type field is one octet. Values are assigned at the 1302 sole discretion of the Vendor. 1304 Value 1306 The Value field is one or more octets. The actual format of the 1307 information is site or application specific, and a robust 1308 implementation SHOULD support the field as undistinguished octets. 1310 The codification of the range of allowed usage of this field is 1311 outside the scope of this specification. 1313 The length of the Value field is eight (8) less then the value of 1314 the Length field. 1316 Implementations supporting this specification MUST use the 1317 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1318 determine the interpretation of the Value field. 1320 4.5. Extended-Vendor-Specific-5 1322 Description 1324 This attribute defines a RADIUS Type Code of 245.26, using the 1325 "evs" data type. 1327 A summary of the Extended-Vendor-Specific-5 Attribute format is shown 1328 below. The fields are transmitted from left to right. 1330 0 1 2 3 1331 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 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 | Type | Length | Extended-Type |M| Flags | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 | Vendor-Id | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 | Vendor-Type | Value .... 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 Type.Extended-Type 1342 245.26 for Extended-Vendor-Specific-5 1344 Length 1346 >= 10 (first fragment) 1347 >= 5 (subsequent fragments) 1349 When a VSA is fragmented across multiple Attributes, only the 1350 first Attribute contains the Vendor-Id and Vendor-Type fields. 1351 Subsequent Attributes contain fragments of the Value field only. 1353 M (More) 1355 The More Flag is one (1) bit in length, and indicates whether or 1356 not the current attribute contains "more" than 251 octets of data. 1357 Further definition of this field is given in Section 2.2, above. 1359 Flags 1361 This field is 7 bits long, and is reserved for future use. 1362 Implementations MUST set it to zero (0) when encoding an attribute 1363 for sending in a packet. The contents SHOULD be ignored on 1364 reception. 1366 Vendor-Id 1367 The high-order octet is 0 and the low-order 3 octets are the SMI 1368 Network Management Private Enterprise Code of the Vendor in 1369 network byte order. 1371 Vendor-Type 1373 The Vendor-Type field is one octet. Values are assigned at the 1374 sole discretion of the Vendor. 1376 Value 1378 The Value field is one or more octets. The actual format of the 1379 information is site or application specific, and a robust 1380 implementation SHOULD support the field as undistinguished octets. 1382 The codification of the range of allowed usage of this field is 1383 outside the scope of this specification. 1385 Implementations supporting this specification MUST use the 1386 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1387 determine the interpretation of the Value field. 1389 4.6. Extended-Vendor-Specific-6 1391 Description 1393 This attribute defines a RADIUS Type Code of 246.26, using the 1394 "evs" data type. 1396 A summary of the Extended-Vendor-Specific-6 Attribute format is shown 1397 below. The fields are transmitted from left to right. 1399 0 1 2 3 1400 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 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 | Type | Length | Extended-Type |M| Flags | 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 | Vendor-Id | 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 | Vendor-Type | Value .... 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 Type.Extended-Type 1411 246.26 for Extended-Vendor-Specific-6 1413 Length 1414 >= 10 (first fragment) 1415 >= 5 (subsequent fragments) 1417 When a VSA is fragmented across multiple Attributes, only the 1418 first Attribute contains the Vendor-Id and Vendor-Type fields. 1419 Subsequent Attributes contain fragments of the Value field only. 1421 M (More) 1423 The More Flag is one (1) bit in length, and indicates whether or 1424 not the current attribute contains "more" than 251 octets of data. 1425 Further definition of this field is given in Section 2.2, above. 1427 Flags 1429 This field is 7 bits long, and is reserved for future use. 1430 Implementations MUST set it to zero (0) when encoding an attribute 1431 for sending in a packet. The contents SHOULD be ignored on 1432 reception. 1434 Vendor-Id 1436 The high-order octet is 0 and the low-order 3 octets are the SMI 1437 Network Management Private Enterprise Code of the Vendor in 1438 network byte order. 1440 Vendor-Type 1442 The Vendor-Type field is one octet. Values are assigned at the 1443 sole discretion of the Vendor. 1445 Value 1447 The Value field is one or more octets. The actual format of the 1448 information is site or application specific, and a robust 1449 implementation SHOULD support the field as undistinguished octets. 1451 The codification of the range of allowed usage of this field is 1452 outside the scope of this specification. 1454 Implementations supporting this specification MUST use the 1455 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1456 determine the interpretation of the Value field. 1458 5. Compatibility with traditional RADIUS 1460 There are a number of potential compatibility issues with traditional 1461 RADIUS. This section describes them. 1463 5.1. Attribute Allocation 1465 Some vendors have used Attribute Type codes from the "Reserved" 1466 space, as part of vendor-defined dictionaries. This practice is 1467 considered anti-social behavior, as noted in [RFC6158]. These vendor 1468 definitions conflict with the attributes in the RADIUS Attribute Type 1469 space. The conflicting definitions may make it difficult for 1470 implementations to support both those Vendor Attributes, and the new 1471 Extended Attribute formats. 1473 We RECOMMEND that RADIUS client and server implementations delete all 1474 references to these improperly defined attributes. Failing that, we 1475 RECOMMEND that RADIUS server implementations have a per-client 1476 configurable flag which indicates which type of attributes are being 1477 sent from the client. If the flag is set one way, the conflicting 1478 attributes can be interpreted as being improperly defined Vendor 1479 Specific Attributes. If the flag is set the other way, the attributes 1480 MUST be interpreted as being of the Extended Attributes format. The 1481 default SHOULD be to interpret the attributes as being of the 1482 Extended Attributes format. 1484 Other methods of determining how to decode the attributes into a 1485 "correct" form are NOT RECOMMENDED. Those methods are likely to be 1486 fragile and prone to error. 1488 We RECOMMEND that RADIUS server implementations re-use the above flag 1489 to determine which type of attributes to send in a reply message. If 1490 the request is expected to contain the improperly defined attributes, 1491 the reply SHOULD NOT contain Extended Attributes. If the request is 1492 expected to contain Extended Attributes, the reply MUST NOT contain 1493 the improper Attributes. 1495 RADIUS clients will have fewer issues than servers. Clients MUST NOT 1496 send improperly defined Attributes in a request. For replies, 1497 clients MUST interpret attributes as being of the Extended Attributes 1498 format, instead of the improper definitions. These requirements 1499 impose no change in the RADIUS specifications, as such usage by 1500 vendors has always been in conflict with the standard requirements 1501 and the standards process. 1503 Existing clients that send these improperly defined attributes 1504 usually have a configuration setting which can disable this behavior. 1505 We RECOMMEND that vendors ship products with the default set to 1506 "disabled". We RECOMMEND that administrators set this flag to 1507 "disabled" on all equipment that they manage. 1509 5.2. Proxy Servers 1511 RADIUS Proxy servers will need to forward Attributes having the new 1512 format, even if they do not implement support for the encoding and 1513 decoding of those attributes. We remind implementors of the 1514 following text in [RFC2865] Section 2.3: 1516 The forwarding server MUST NOT change the order of any attributes 1517 of the same type, including Proxy-State. 1519 This requirement solves some of the issues related to proxying of the 1520 new format, but not all. The reason is that proxy servers are 1521 permitted to examine the contents of the packets that they forward. 1522 Many proxy implementations not only examine the attributes, but they 1523 refuse to forward attributes which they do not understand (i.e. 1524 attributes for which they have no local dictionary definitions). 1526 This practice is NOT RECOMMENDED. Proxy servers SHOULD forward 1527 attributes, even ones which they do not understand, or which are not 1528 in a local dictionary. When forwarded, these attributes SHOULD be 1529 sent verbatim, with no modifications or changes. The only exception 1530 to this recommendation is when local site policy dictates that 1531 filtering of attributes has to occur. For example, a filter at a 1532 visited network may require removal of certain authorization rules 1533 which apply to the home network, but not to the visited network. 1534 This filtering can sometimes be done even when the contents of the 1535 attributes are unknown, such as when all Vendor-Specific Attributes 1536 are designated for removal. 1538 As seen in [EDUROAM] many proxies do not follow these practices for 1539 unknown Attributes. Some proxies filter out unknown attributes or 1540 attributes which have unexpected lengths (24%, 17/70), some truncate 1541 the attributes to the "expected" length (11%, 8/70), some discard the 1542 request entirely (1%, 1/70), with the rest (63%, 44/70) following the 1543 recommended practice of passing the attributes verbatim. It will be 1544 difficult to widely use the Extended Attributes format until all non- 1545 conformant proxies are fixed. We therefore RECOMMEND that all 1546 proxies which do not support the Extended Attributes (241 through 1547 246) define them as being of data type "string", and delete all other 1548 local definitions for those attributes. 1550 This last change should enable wider usage of the Extended Attributes 1551 format. 1553 6. Guidelines 1555 This specification proposes a number of changes to RADIUS, and 1556 therefore requires a set of guidelines, as has been done in 1558 [RFC6158]. 1560 6.1. Updates to RFC 6158 1562 This specification updates [RFC6158] by adding the data types "evs", 1563 "tlv" and "integer64"; defining them to be "basic" data types; and 1564 permitting their use subject to the restrictions outlined below. 1566 The recommendations for the use of the new data types and attribute 1567 formats are given below. All other recommendations given in 1568 [RFC6158] are unchanged. 1570 6.2. Guidelines for Simple Data Types 1572 [RFC6158] Section A.2.1 says in part: 1574 * Unsigned integers of size other than 32 bits. 1575 SHOULD be replaced by an unsigned integer of 32 bits. There is 1576 insufficient justification to define a new size of integer. 1578 We update that specification to permit unsigned integers of 64 bits, 1579 for the reasons defined above in Section 2.5. The updated text is as 1580 follows: 1582 * Unsigned integers of size other than 32 or 64 bits. 1583 SHOULD be replaced by an unsigned integer of 32 or 64 bits. 1584 There is insufficient justification to define a new size 1585 of integer. 1587 That section later continues with the following list item: 1589 * Nested attribute-value pairs (AVPs). 1590 Attributes should be defined in a flat typespace. 1592 We update that specification to permit nested TLVs, as defined in 1593 this document: 1595 * Nested attribute-value pairs (AVPs) using the extended 1596 attribute format MAY be used. All other nested AVP or TLV 1597 formats MUST NOT be used. 1599 6.3. Guidelines for Complex Data Types 1601 [RFC6158] Section 2.1 says: 1603 Complex data types MAY be used in situations where they reduce 1604 complexity in non-RADIUS systems or where using the basic data 1605 types 1606 would be awkward (such as where grouping would be required in 1607 order 1608 to link related attributes). 1610 Since the extended attribute format allows for grouping of complex 1611 types via TLVs, the guidelines for complex data types need to be 1612 updated as follows: 1614 Complex data types MAY be used where they reduce complexity in 1615 non-RADIUS systems, though this practice is NOT RECOMMENDED. The 1616 complex data type exceptions of [RFC6158] Section 3.2.4 still 1617 apply. In all other situations, complex data types MUST NOT be 1618 used. Instead, complex data types MUST be decomposed into TLVs, 1619 using the extended attribute format. 1621 The checklist in Appendix A.2.2 is similarly updated to add a new 1622 requirement at the top of that section, 1624 Does the attribute: 1626 * define a complex type which can be represented via TLVs? 1628 If so, this data type MUST be represented via TLVs. 1630 Note that this requirement does not over-ride Section A.1, which 1631 permits the transport of complex types in certain situations. 1633 6.4. Guidelines For the New Types 1635 We recommend the following guidelines when designing attributes using 1636 the new format. The items listed below are not exhaustive. As 1637 experience is gained with the new formats, later specifications may 1638 define additional guidelines. 1640 * The data type "evs" MUST NOT be used for standard RADIUS 1641 Attributes, or for TLVs, or for VSAs. 1643 * The data type "tlv" SHOULD NOT be used for standard RADIUS 1644 attributes. While its use is NOT RECOMMENDED by [RFC6158], this 1645 specification updates [RFC6158] to permit the "tlv" data type in 1646 attributes using the Extended-Type format. 1648 * [RFC2866] "tagged" attributes MUST NOT be defined in the 1649 Extended-Type space. The "tlv" data type should be used instead to 1650 group attributes. 1652 * The "integer64" data type MAY be used in any RADIUS attribute. 1653 The use of 64-bit integers is NOT RECOMMENDED by [RFC6158], but 1654 their utility is now evident. 1656 * Any attribute which is allocated from the Type spaces of 245.* or 1657 246.*, of data type "text", "string", or "tlv" can end up carrying 1658 more than 251 octets of data, up to the maximum RADIUS packet 1659 length (~4096 octets). Specifications defining such attributes 1660 SHOULD define a maximum length. 1662 * For all other circumstances, the guidelines in [RFC6158] MUST 1663 be followed. 1665 6.5. Allocation Request Guidelines 1667 The following items give guidelines for allocation requests made in a 1668 RADIUS specification. 1670 * Discretion is RECOMMENDED when requesting allocation of attributes. 1671 The new space is much larger than the old one, but it is not 1672 infinite. 1674 * Specifications which request ten (10) or more attributes MUST 1675 NOT request that all be allocated from the standard space. 1676 That space is under allocation pressure, and the extended space 1677 is more suitable for large allocations. 1679 * New specifications SHOULD NOT request allocation from the standard 1680 Attribute Type Space (i.e. Attributes 1 through 255). That space 1681 is deprecated. 1683 * It is RECOMMENDED that specifications do not request allocation 1684 from a specific space. The IANA considerations given in 1685 Section 9, below, should be sufficient for attribute allocation. 1687 * Specifications of an ttribute which encodes 252 octets or less 1688 of data MAY request allocation from the exended space, using 1689 format "Extended Type" 1691 * Specifications of an attribute which can always encode less than 1692 253 octets of data MUST NOT request allocation from the long 1693 extended space. The standard space, or the short extended space 1694 MUST be used instead. 1696 * Specifications of an attribute which encodes 253 octets or more of 1697 data MUST request allocation from the long extended space. 1699 * When the extended space is nearing exhaustion, a new specification 1700 SHOULD be written which requests allocation of one or more RADIUS 1701 Attributes from the "Reserved" portion of the standard space, 1702 values 247-255, using an appropriate format ("Extended Type", or 1703 "Extended Type with Flags") 1705 6.6. TLV Guidelines 1707 The following items give guidelines for specifications using TLVs. 1709 * when multiple attributes are intended to be grouped or managed 1710 together, the use of TLVs to group related attributes is 1711 RECOMMENDED. 1713 * more than 4 layers (depth) of TLV nesting is NOT RECOMMENDED. 1715 * Interpretation of an attribute depends only on its type 1716 definition (e.g. Type.Extended-Type.TLV-Type), and 1717 not on its encoding or location in the RADIUS packet. 1719 * Where a group of TLVs is strictly defined, and not expected to 1720 change, and and totals less than 247 octets of data, they SHOULD 1721 request allocation from the Type spaces of 241.*, 242.*, 243.*, or 1722 244.*. 1724 * Where a group of TLVs is loosely defined, or is expected to change, 1725 they SHOULD request allocation from the Type spaces of 245.* or 1726 246.*. 1728 6.7. Implementation Guidelines 1730 * RADIUS client implementations SHOULD support this specification 1731 as soon as possible. 1733 * RADIUS server implementations SHOULD support this specification 1734 as soon as possible. 1736 * RADIUS proxy servers SHOULD forward all attributes, even ones 1737 which they do not understand, or which are not in a local 1738 dictionary. These attributes SHOULD be forwarded verbatim, with 1739 no modifications or changes. 1741 * When forwarding attributes, RADIUS proxy servers SHOULD forward 1742 the "Flag" field unchanged. That is, they SHOULD NOT assume that 1743 the "Flag" field is always set to zero on transmission. 1745 6.8. Vendor Guidelines 1747 * Vendors SHOULD use the existing Vendor-Specific Attribute Type 1748 space in preference to the new Extended-Vendor-Specific 1749 attributes, as this specification may take time to become widely 1750 deployed. 1752 * Vendors SHOULD implement this specification as soon as 1753 possible. The changes to RADIUS are relatively small, and are 1754 likely to quickly be used in new specifications. 1756 7. Rationale 1758 The path to extending the RADIUS protocol has been long and arduous. 1759 A number of proposals have been made and discarded by the RADEXT 1760 working group. These proposals have been judged to be either too 1761 bulky, too complex, too simple, or to be unworkable in practice. We 1762 do not otherwise explain here why earlier proposals did not obtain 1763 working group consensus. 1765 The changes outlined here have the benefit of being simple, as the 1766 "Extended Type" format requires only a one octet change to the 1767 Attribute format. The downside is that the "Extended Type with 1768 Flags" format is awkward, and the 7 bits of Flags will likey never be 1769 used for anything. 1771 7.1. Attribute Audit 1773 An audit of almost five thousand publicly available attributes 1774 [ATTR], shows the statistics summarized below. The attributes include 1775 over 100 Vendor dictionaries, along with the IANA assigned 1776 attributes: 1778 Count Data Type 1779 ----- --------- 1780 2257 integer 1781 1762 text 1782 273 IPv4 Address 1783 225 string 1784 96 other data types 1785 35 IPv6 Address 1786 18 date 1787 10 integer64 1788 4 Interface Id 1789 3 IPv6 Prefix 1791 4683 Total 1793 The entries in the "Data Type" column are data types recommended by 1794 [RFC6158], along with "integer64". The "other data types" row 1795 encompasses all other data types, including complex data types and 1796 data types transporting opaque data. 1798 We see that over half of the attributes encode less than 16 octets of 1799 data. It is therefore important to have an extension mechanism which 1800 adds as little as possible to the size of these attributes. Another 1801 result is that the overwhelming majority of attributes use simple 1802 data types. 1804 Of the attributes defined above, 177 were declared as being inside of 1805 a TLV. This is approximately 4% of the total. We did not 1806 investigate whether additional attributes were defined in a flat name 1807 space, but could have been defined as being inside of a TLV. We 1808 expect that the number could be as high as 10% of attributes. 1810 Manual inspection of the dictionaries shows that approximately 20 (or 1811 0.5%) attributes have the ability to transport more than 253 octets 1812 of data. These attributes are divided between VSAs, and a small 1813 number of standard Attributes such as EAP-Message. 1815 The results of this audit and analysis is reflected in the design of 1816 the extended attributes. The extended format has minimal overhead, 1817 it permits TLVs, and it has support for "long" attributes. 1819 8. Examples 1821 A few examples are presented here in order to illustrate the encoding 1822 of the new attribute formats. These examples are not intended to be 1823 exhaustive, as many others are possible. For simplicity, we do not 1824 show complete packets, only attributes. 1826 The examples are given using a domain-specific language implemented 1827 by the program given in Appendix A. The language is line oriented, 1828 and composed of a sequence of lines matching the grammar ([RFC5234]) 1829 given below: 1831 Identifier = 1*DIGIT *( "." 1*DIGIT ) 1833 HEXCHAR = HEXDIG HEXDIG 1835 STRING = DQUOTE 1*CHAR DQUOTE 1837 TLV = "{" 1*DIGIT DATA "}" 1839 DATA = 1*HEXCHAR / 1*TLV / STRING 1840 LINE = Identifier DATA 1842 The progam has additional restrictions on its input that are not 1843 reflected in the above grammar. For example, the portions of the 1844 Identifier which refer to Type and Extended-Type are limited to 1845 values between 1 and 255. We trust that the source code in Appendix 1846 A is clear, and that these restrictions do not negatively affect the 1847 comprehensability of the examples. 1849 The program reads the input text, and interprets it as a set of 1850 instructions to create RADIUS Attributes. It then prints the hex 1851 encoding of those attributes. It implements the minimum set of 1852 functionality which achieves that goal. This minimalism means that 1853 it does not use attribute dictionaries; it does not implement support 1854 for RADIUS data types; it can be used to encode attributes with 1855 invalid data fields; and there is no requirement for consistency from 1856 one example to the next. For example, it can be used to encode a 1857 User-Name attribute which contains non-UTF8 data, or a Framed-IP- 1858 Address which contains 253 octets of ASCII data. As a result, it 1859 MUST NOT be used to create RADIUS Attributes for transport in a 1860 RADIUS message. 1862 However, the program correctly encodes the RADIUS attribute fields of 1863 "Type", "Length", "Extended-Type", "More", "Flags", "Vendor-Id", 1864 "Vendor-Type", and "Vendor-Length". It encodes RADIUS attribute data 1865 types "evs" and TLV. It can therefore be used to encode example 1866 attributes from inputs which are humanly readable. 1868 We do not give examples of "malformed" or "invalid attributes". We 1869 also note that the examples show format, rather than consistent 1870 meaning. A particular Attribute Type code may be used to demonstrate 1871 two different formats. In real specifications, attributes have a 1872 static definitions based on their type code. 1874 The examples given below are strictly for demonstration purposes 1875 only, and do not provide a standard of any kind. 1877 8.1. Extended Type 1879 The following are a series of examples of the "Extended Type" format. 1881 Attribute encapsulating textual data. 1883 241.1 "bob" 1884 -> f1 06 01 62 6f 62 1886 Attribute encapsulating a TLV with TLV-Type of one (1). 1888 241.2 { 1 23 45 } 1889 -> f1 07 02 01 04 23 45 1891 Attribute encapsulating two TLVs, one after the other. 1893 241.2 { 1 23 45 } { 2 67 89 } 1894 -> f1 0b 02 01 04 23 45 02 04 67 89 1896 Attribute encapsulating two TLVs, where the second TLV is itself 1897 encapsulating a TLV. 1899 241.2 { 1 23 45 } { 3 { 1 ab cd } } 1900 -> f1 0d 02 01 04 23 45 03 06 01 04 ab cd 1902 Attribute encapsulating two TLVs, where the second TLV is itself 1903 encapsulating two TLVs. 1905 241.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } 1906 -> f1 12 02 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f 1908 Attribute encapsulating a TLV, which in turn encapsulates a TLV, 1909 to a depth of 5 nestings. 1911 241.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } 1912 -> f1 0f 01 01 0c 02 0a 03 08 04 06 05 04 cd ef 1914 Attribute encapsulating an extended Vendor Specific attribute, 1915 with Vendor-Id of 1, and Vendor-Type of 4, which in turn 1916 encapsulates textual data. 1918 241.26.1.4 "test" 1919 -> f1 0c 1a 00 00 00 01 04 74 65 73 74 1921 Attribute encapsulating an extended Vendor Specific attribute, with 1922 Vendor-Id of 1, and Vendor-Type of 5, which in turn encapsulates 1923 a TLV with TLV-Type of 3, which encapsulates textual data. 1925 241.26.1.5 { 3 "test" } 1926 -> f1 0e 1a 00 00 00 01 05 03 06 74 65 73 74 1928 8.2. Extended Type with Flags 1930 The following are a series of examples of the "Extended Type with 1931 flags" format. 1933 Attribute encapsulating textual data. 1935 245.1 "bob" 1936 -> f5 07 01 00 62 6f 62 1938 Attribute encapsulating a TLV with TLV-Type of one (1). 1940 245.2 { 1 23 45 } 1941 -> f5 08 02 00 01 04 23 45 1943 Attribute encapsulating two TLVs, one after the other. 1945 245.2 { 1 23 45 } { 2 67 89 } 1946 -> f5 0c 02 00 01 04 23 45 02 04 67 89 1948 Attribute encapsulating two TLVs, where the second TLV is itself 1949 encapsulating a TLV. 1951 245.2 { 1 23 45 } { 3 { 1 ab cd } } 1952 -> f5 0e 02 00 01 04 23 45 03 06 01 04 ab cd 1954 Attribute encapsulating two TLVs, where the second TLV is itself 1955 encapsulating two TLVs. 1957 245.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } 1958 -> f5 13 02 00 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f 1960 Attribute encapsulating a TLV, which in turn encapsulates a TLV, 1961 to a depth of 5 nestings. 1963 245.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } 1964 -> f5 10 01 00 01 0c 02 0a 03 08 04 06 05 04 cd ef 1966 Attribute encapsulating an extended Vendor Specific attribute, 1967 with Vendor-Id of 1, and Vendor-Type of 4, which in turn 1968 encapsulates textual data. 1970 245.26.1.4 "test" 1971 -> f5 0d 1a 00 00 00 00 01 04 74 65 73 74 1973 Attribute encapsulating an extended Vendor Specific attribute, 1974 with Vendor-Id of 1, and Vendor-Type of 5, which in turn 1975 encapsulates a TLV with TLV-Type of 3, which encapsulates 1976 textual data. 1978 245.26.1.5 { 3 "test" } 1979 -> f5 0f 1a 00 00 00 00 01 05 03 06 74 65 73 74 1981 Attribute encapsulating more than 251 octets of data. The "Data" 1982 portions are indented for readability. 1984 245.4 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1985 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1986 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1987 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1988 aaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1989 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1990 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1991 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1992 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbcccccccccccccccccccc 1993 cccccccccc 1994 -> f5 ff 04 80 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1995 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1996 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1997 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1998 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1999 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2000 aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb bb bb bb bb bb 2001 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2002 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2003 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2004 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2005 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2006 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 13 04 00 cc 2007 cc cc cc cc cc cc cc cc cc cc cc cc cc cc 2009 Attribute encapsulating an extended Vendor Specific attribute, 2010 with Vendor-Id of 1, and Vendor-Type of 6, which in turn 2011 encapsulates more than 251 octets of data. 2013 As the VSA encapsulates more than 251 octets of data, it is 2014 split into two RADIUS attributes. The first attribute has the 2015 More flag set, and carries the Vendor-Id and Vendor-Type. 2016 The second attribute has the More flag clear, and carries 2017 the rest of the data portion of the VSA. Note that the second 2018 attribute does not include the Vendor-Id ad Vendor-Type fields. 2020 The "Data" portions are indented for readability. 2022 245.26.1.6 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2023 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2024 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2025 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2026 aaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2027 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2028 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2029 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2030 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbccccccccccccc 2031 ccccccccccccccccc 2033 -> f5 ff 1a 80 00 00 00 01 06 aa aa aa aa aa aa aa aa aa aa aa 2034 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2035 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2036 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2037 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2038 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2039 aa aa aa aa aa aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb 2040 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2041 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2042 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2043 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2044 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2045 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 17 1a 00 bb 2046 bb bb bb bb cc cc cc cc cc cc cc cc cc cc 13 45 67 89 2048 9. IANA Considerations 2050 This document updates [RFC3575] in that it adds new IANA 2051 considerations for RADIUS Attributes. These considerations modify 2052 and extend the IANA considerations for RADIUS, rather than replacing 2053 them. 2055 The IANA considerations of this document are limited to the "RADIUS 2056 Attribute Types" registry. Some Attribute Type values which were 2057 previously marked "Reserved" are now allocated, and the registry is 2058 extended from a simple 8-bit array to a tree-like structure, up to a 2059 maximum depth of 125 nodes. Detailed instructions are given below. 2061 9.1. Attribute Allocations 2063 IANA is requested to move the following Attribute Type values from 2064 "Reserved", to "Allocated", with the corresponding names: 2066 * 241 Extended-Type-1 2067 * 242 Extended-Type-2 2068 * 243 Extended-Type-3 2069 * 244 Extended-Type-4 2070 * 245 Extended-Type-Flagged-1 2071 * 246 Extended-Type-Flagged-2 2073 These values serve as an encapsulation layer for the new RADIUS 2074 Attribute Type tree. 2076 9.2. RADIUS Attribute Type Tree 2078 Each of the Attribute Type values allocated above extends the "RADIUS 2079 Attribute Types" to an N-ary tree, via a "dotted number" notation. 2080 Allocation of an Attribute Type value "TYPE" using the new Extended 2081 type format results in allocation of 255 new Attribute Type values, 2082 of format "TYPE.1" through "TYPE.255". The value zero "TYPE.0" is not 2083 used. Value twenty-six (26) is assigned as "Extended-Vendor- 2084 Specific-*". Values "TYPE.241" through "TYPE.255" are marked 2085 "Reserved". All other values are "Unassigned". 2087 The initial set of Attribute Type values and names assigned by this 2088 document is given below. 2090 * 241 Extended-Attribute-1 2091 * 241.{1-25} Unassigned 2092 * 241.26 Extended-Vendor-Specific-1 2093 * 241.{27-240} Unassigned 2094 * 241.{241-255} Reserved 2095 * 242 Extended-Attribute-2 2096 * 242.{1-25} Unassigned 2097 * 242.26 Extended-Vendor-Specific-2 2098 * 242.{27-240} Unassigned 2099 * 243 Extended-Attribute-3 2100 * 242.{241-255} Reserved 2101 * 243.{1-25} Unassigned 2102 * 243.26 Extended-Vendor-Specific-3 2103 * 243.{27-240} Unassigned 2104 * 243.{241-255} Reserved 2105 * 244 Extended-Attribute-4 2106 * 244.{1-25} Unassigned 2107 * 244.26 Extended-Vendor-Specific-4 2108 * 244.{27-240} Unassigned 2109 * 244.{241-255} Reserved 2110 * 245 Extended-Attribute-5 2111 * 245.{1-25} Unassigned 2112 * 245.26 Extended-Vendor-Specific-5 2113 * 245.{27-240} Unassigned 2114 * 245.{241-255} Reserved 2115 * 246 Extended-Attribute-6 2116 * 246.{1-25} Unassigned 2117 * 245.26 Extended-Vendor-Specific-6 2118 * 246.{27-240} Unassigned 2119 * 246.{241-255} Reserved 2121 As per [RFC5226], the values marked "Unassigned" above are available 2122 via for assignment by IANA in future RADIUS specifications. The 2123 values marked "Reserved" are reserved for future use. 2125 The Extended-Vendor-Specific spaces (TYPE.26) are for Private Use, 2126 and allocations are not managed by IANA. 2128 Allocation of Reserved entries in the extended space requires 2129 Standards Action. 2131 All other allocations in the extended space require IETF Review. 2133 9.3. Allocation Instructions 2135 This section defines what actions IANA needs to take when allocating 2136 new attributes. Different actions are required when allocating 2137 attributes from the standard space, attributes of Extended Type 2138 format, attributes of Extended Type with Flags format, perferential 2139 allocations, attributes of data type TLV, attributes within a TLV, 2140 and attributes of other data types. 2142 9.3.1. Requested Allocation from the Standard Space 2144 Specifications can request allocation of an Attribute from within the 2145 standard space (e.g. Attribute Type Codes 1 through 255), subject to 2146 the considerations of [RFC3575] and this document. 2148 9.3.2. Requested Allocation from the short extended space 2150 Specifications can request allocation of an Attribute which requires 2151 the format Extended Type, by specifying the short extended space In 2152 that case, IANA should assign the lowest Unassigned number from the 2153 Attribute Type space with the relevant format. 2155 9.3.3. Requested Allocation from the long extended space 2157 Specifications can request allocation of an Attribute which requires 2158 the format Extended Type with Flags, by specifying the extended space 2159 (long). In that case, IANA should assign the lowest Unassigned 2160 number from the Attribute Type space with the relevant format. 2162 9.3.4. Allocation Preferences 2164 Specifications which make no request for allocation from a specific 2165 Type Space should have Attributes allocated using the following 2166 criteria: 2168 * when the standard space has no more Unassigned attributes, 2169 all allocations should be performed from the extended space. 2171 * specifications which allocate a small number of attributes 2172 (i.e. less than ten) should have all allocations made from 2173 the standard space. 2175 * specifications which allocate a large number of attributes 2176 (i.e. ten or more) should have all allocations made from the 2177 extended space. 2179 * specifications which request allocation of an Attribute of 2180 data type TLV should have that attribute allocated from the 2181 extended space. 2183 * specifications which request allocation of an attribute 2184 which can transport 253 or more octets of data should have 2185 that attribute allocated from within the long extended space, 2186 We note that Section 6.5, above requires specifications to 2187 request this allocation. 2189 There is otherwise no requirement that all attributes within a 2190 specification be allocated from one type space or another. 2191 Specifications can simultaneously allocate attributes from both the 2192 standard space and the extended space. 2194 9.3.5. Extending the Type Space via TLV Data Type 2196 When specifications request allocation of an attribute of data type 2197 "tlv", that allocation extends the Attribute Type Tree by one more 2198 level. Allocation of an Attribute Type value "TYPE.TLV", with Data 2199 Type TLV, results in allocation of 255 new Attribute Type values, of 2200 format "TYPE.TLV.1" through "TYPE.TLV.255". The value zero "VALUE.0" 2201 is not used. Values 254-255 are marked "Reserved". All other values 2202 are "Unassigned". Value 26 has no special meaning. 2204 For example, if a new attribute "Example-TLV" of data type "tlv" is 2205 assigned the identifier "245.1", then the extended tree will be 2206 allocated as below: 2208 * 245.1 Example-TLV 2209 * 245.1.{1-253} Unassigned 2210 * 245.1.{254-255} Reserved 2212 Note that this example does not define an "Example-TLV" attribute. 2214 The Attribute Type Tree can be extended multiple levels in one 2215 specification when the specification requests allocation of nested 2216 TLVs, as discussed below. 2218 9.3.6. Allocation within a TLV 2220 Specifications can request allocation of Attribute Type values within 2221 an Attribute of Data Type TLV. The encapsulating TLV can be 2222 allocated in the same specification, or it can have been previously 2223 allocated. 2225 Specifications need to request allocation within a specific Attribute 2226 Type value (e.g. "TYPE.TLV.*"). Allocations are performed from the 2227 smallest Unassigned value, proceeding to the largest Unassigned 2228 value. 2230 Where the Attribute being allocated is of Data Type TLV, the 2231 Attribute Type tree is extended by one level, as given in the 2232 previous section. Allocations can then be made within that level. 2234 9.3.7. Allocation of Other Data Types 2236 Attribute Type value allocations are otherwise allocated from the 2237 smallest Unassigned value, proceeding to the largest Unassigned 2238 value. e.g. Starting from 241.1, proceeding through 241.255, then to 2239 242.1, through 242.255, etc. 2241 10. Security Considerations 2243 This document defines new formats for data carried inside of RADIUS, 2244 but otherwise makes no changes to the security of the RADIUS 2245 protocol. 2247 Attacks on cryptographic hashes are well known, and are getting 2248 better with time, as discussed in[RFC4270]. RADIUS uses the MD5 hash 2249 [RFC1321] for packet authentication and attribute obfuscation. There 2250 are ongoing efforts in the IETF to analyze and address these issues 2251 for the RADIUS protocol. 2253 As with any protocol change, code changes are required in order to 2254 implement the new features. These code changes have the potential to 2255 introduce new vulnerabilities in the software. Since the RADIUS 2256 server performs network authentication, it is an inviting target for 2257 attackers. We RECOMMEND that access to RADIUS servers be kept to a 2258 minimum. 2260 11. References 2262 11.1. Normative references 2264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2265 Requirement Levels", RFC 2119, March, 1997. 2267 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 2268 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2269 2000. 2271 [RFC5226] Narten, T. and Alvestrand, H, "Guidelines for Writing an IANA 2272 Considerations Section in RFCs", RFC 5226, May 2008. 2274 11.2. Informative references 2276 [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, 2277 April, 1992 2279 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 2281 [RFC2868] Zorn, G., et al, " RADIUS Attributes for Tunnel Protocol 2282 Support", RFC 2868, June 2000. 2284 [RFC3575] Aboba, B, "IANA Considerations for RADIUS (Remote 2285 Authentication Dial In User Service)", RFC 3575, July 2003. 2287 [RFC4270] Hoffman, P, and Schneier, B, "Attacks on Cryptographic Hashes 2288 in Internet Protocols", RFC 4270, November 2005. 2290 [RFC5234] Crocker, D. (Ed.), and Overell, P., "Augmented BNF for Syntax 2291 Specifications: ABNF", RFC 5234, October 2005. 2293 [RFC6158] DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC 2294 6158, March 2011. 2296 [EDUROAM] Internal Eduroam testing page, data retrieved 04 August 2010. 2298 [ATTR] http://github.com/alandekok/freeradius- 2299 server/tree/master/share/, data retrieved September 2010. 2301 Acknowledgments 2303 This document is the result of long discussions in the IETF RADEXT 2304 working group. The authors would like to thank all of the 2305 participants who contributed various ideas over the years. Their 2306 feedback has been invaluable, and has helped to make this 2307 specification better. 2309 Appendix A - Extended Attribute Generator Program 2311 This section contains "C" program source which can be used for 2312 testing. It reads a line-oriented text file, parses it to create 2313 RADIUS formatted attributes, and prints the hex version of those 2314 attributes to standard output. 2316 The input accepts a grammar similar to that given in Section 8, with 2317 some modifications for usability. For example, blank lines are 2318 allowed, lines beginning with a '#' character are interpreted as 2319 comments, numbers (RADIUS Types, etc.) are checked for minimum / 2320 maximum values, and RADIUS Attribute lengths are enforced. 2322 The program is included here for demonstration purposes only, and 2323 does not define a standard of any kind. 2325 ------------------------------------------------------------ 2326 /* 2327 * Copyright (c) 2010 IETF Trust and the persons identified as 2328 * authors of the code. All rights reserved. 2329 * 2330 * Redistribution and use in source and binary forms, with or without 2331 * modification, are permitted provided that the following conditions 2332 * are met: 2333 * 2334 * Redistributions of source code must retain the above copyright 2335 * notice, this list of conditions and the following disclaimer. 2336 * 2337 * Redistributions in binary form must reproduce the above copyright 2338 * notice, this list of conditions and the following disclaimer in 2339 * the documentation and/or other materials provided with the 2340 * distribution. 2341 * 2342 * Neither the name of Internet Society, IETF or IETF Trust, nor the 2343 * names of specific contributors, may be used to endorse or promote 2344 * products derived from this software without specific prior written 2345 * permission. 2346 * 2347 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 2348 * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, 2349 * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 2350 * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 2351 * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS 2352 * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 2353 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED 2354 * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 2355 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON 2356 * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 2357 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT 2358 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 2359 * SUCH DAMAGE. 2360 * 2361 * Author: Alan DeKok 2362 */ 2363 #include 2364 #include 2365 #include 2366 #include 2367 #include 2368 #include 2370 static int encode_tlv(char *buffer, uint8_t *output, size_t outlen); 2372 static const char *hextab = "0123456789abcdef"; 2374 static int encode_data_string(char *buffer, 2375 uint8_t *output, size_t outlen) 2376 { 2377 int length = 0; 2378 char *p; 2380 p = buffer + 1; 2382 while (*p && (outlen > 0)) { 2383 if (*p == '"') { 2384 return length; 2385 } 2387 if (*p != '\\') { 2388 *(output++) = *(p++); 2389 outlen--; 2390 length++; 2391 continue; 2392 } 2394 switch (p[1]) { 2395 default: 2396 *(output++) = p[1]; 2397 break; 2399 case 'n': 2400 *(output++) = '\n'; 2401 break; 2403 case 'r': 2404 *(output++) = '\r'; 2405 break; 2407 case 't': 2408 *(output++) = '\t'; 2409 break; 2410 } 2412 outlen--; 2413 length++; 2414 } 2416 fprintf(stderr, "String is not terminated\n"); 2417 return 0; 2418 } 2420 static int encode_data_tlv(char *buffer, char **endptr, 2421 uint8_t *output, size_t outlen) 2422 { 2423 int depth = 0; 2424 int length; 2425 char *p; 2427 for (p = buffer; *p != '\0'; p++) { 2428 if (*p == '{') depth++; 2429 if (*p == '}') { 2430 depth--; 2431 if (depth == 0) break; 2432 } 2433 } 2435 if (*p != '}') { 2436 fprintf(stderr, "No trailing '}' in string starting " 2437 "with \"%s\"\n", 2438 buffer); 2439 return 0; 2440 } 2442 *endptr = p + 1; 2443 *p = '\0'; 2445 p = buffer + 1; 2446 while (isspace((int) *p)) p++; 2448 length = encode_tlv(p, output, outlen); 2449 if (length == 0) return 0; 2451 return length; 2452 } 2453 static int encode_data(char *p, uint8_t *output, size_t outlen) 2454 { 2455 int length; 2457 if (!isspace((int) *p)) { 2458 fprintf(stderr, "Invalid character following attribute " 2459 "definition\n"); 2460 return 0; 2461 } 2463 while (isspace((int) *p)) p++; 2465 if (*p == '{') { 2466 int sublen; 2467 char *q; 2469 length = 0; 2471 do { 2472 while (isspace((int) *p)) p++; 2473 if (!*p) { 2474 if (length == 0) { 2475 fprintf(stderr, "No data\n"); 2476 return 0; 2477 } 2479 break; 2480 } 2482 sublen = encode_data_tlv(p, &q, output, outlen); 2483 if (sublen == 0) return 0; 2485 length += sublen; 2486 output += sublen; 2487 outlen -= sublen; 2488 p = q; 2489 } while (*q); 2491 return length; 2492 } 2494 if (*p == '"') { 2495 length = encode_data_string(p, output, outlen); 2496 return length; 2497 } 2499 length = 0; 2500 while (*p) { 2501 char *c1, *c2; 2503 while (isspace((int) *p)) p++; 2505 if (!*p) break; 2507 if(!(c1 = memchr(hextab, tolower((int) p[0]), 16)) || 2508 !(c2 = memchr(hextab, tolower((int) p[1]), 16))) { 2509 fprintf(stderr, "Invalid data starting at " 2510 "\"%s\"\n", p); 2511 return 0; 2512 } 2514 *output = ((c1 - hextab) << 4) + (c2 - hextab); 2515 output++; 2516 length++; 2517 p += 2; 2519 outlen--; 2520 if (outlen == 0) { 2521 fprintf(stderr, "Too much data\n"); 2522 return 0; 2523 } 2524 } 2526 if (length == 0) { 2527 fprintf(stderr, "Empty string\n"); 2528 return 0; 2529 } 2531 return length; 2532 } 2534 static int decode_attr(char *buffer, char **endptr) 2535 { 2536 long attr; 2538 attr = strtol(buffer, endptr, 10); 2539 if (*endptr == buffer) { 2540 fprintf(stderr, "No valid number found in string " 2541 "starting with \"%s\"\n", buffer); 2542 return 0; 2543 } 2545 if (!**endptr) { 2546 fprintf(stderr, "Nothing follows attribute number\n"); 2547 return 0; 2548 } 2549 if ((attr <= 0) || (attr > 256)) { 2550 fprintf(stderr, "Attribute number is out of valid " 2551 "range\n"); 2552 return 0; 2553 } 2555 return (int) attr; 2556 } 2558 static int decode_vendor(char *buffer, char **endptr) 2559 { 2560 long vendor; 2562 if (*buffer != '.') { 2563 fprintf(stderr, "Invalid separator before vendor id\n"); 2564 return 0; 2565 } 2567 vendor = strtol(buffer + 1, endptr, 10); 2568 if (*endptr == (buffer + 1)) { 2569 fprintf(stderr, "No valid vendor number found\n"); 2570 return 0; 2571 } 2573 if (!**endptr) { 2574 fprintf(stderr, "Nothing follows vendor number\n"); 2575 return 0; 2576 } 2578 if ((vendor <= 0) || (vendor > (1 << 24))) { 2579 fprintf(stderr, "Vendor number is out of valid range\n"); 2580 return 0; 2581 } 2583 if (**endptr != '.') { 2584 fprintf(stderr, "Invalid data following vendor number\n"); 2585 return 0; 2586 } 2587 (*endptr)++; 2589 return (int) vendor; 2590 } 2592 static int encode_tlv(char *buffer, uint8_t *output, size_t outlen) 2593 { 2594 int attr; 2595 int length; 2596 char *p; 2597 attr = decode_attr(buffer, &p); 2598 if (attr == 0) return 0; 2600 output[0] = attr; 2601 output[1] = 2; 2603 if (*p == '.') { 2604 p++; 2605 length = encode_tlv(p, output + 2, outlen - 2); 2607 } else { 2608 length = encode_data(p, output + 2, outlen - 2); 2609 } 2611 if (length == 0) return 0; 2612 if (length > (255 - 2)) { 2613 fprintf(stderr, "TLV data is too long\n"); 2614 return 0; 2615 } 2617 output[1] += length; 2619 return length + 2; 2620 } 2622 static int encode_vsa(char *buffer, uint8_t *output, size_t outlen) 2623 { 2624 int vendor; 2625 int attr; 2626 int length; 2627 char *p; 2629 vendor = decode_vendor(buffer, &p); 2630 if (vendor == 0) return 0; 2632 output[0] = 0; 2633 output[1] = (vendor >> 16) & 0xff; 2634 output[2] = (vendor >> 8) & 0xff; 2635 output[3] = vendor & 0xff; 2637 length = encode_tlv(p, output + 4, outlen - 4); 2638 if (length == 0) return 0; 2639 if (length > (255 - 6)) { 2640 fprintf(stderr, "VSA data is too long\n"); 2641 return 0; 2642 } 2643 return length + 4; 2644 } 2646 static int encode_evs(char *buffer, uint8_t *output, size_t outlen) 2647 { 2648 int vendor; 2649 int attr; 2650 int length; 2651 char *p; 2653 vendor = decode_vendor(buffer, &p); 2654 if (vendor == 0) return 0; 2656 attr = decode_attr(p, &p); 2657 if (attr == 0) return 0; 2659 output[0] = 0; 2660 output[1] = (vendor >> 16) & 0xff; 2661 output[2] = (vendor >> 8) & 0xff; 2662 output[3] = vendor & 0xff; 2663 output[4] = attr; 2665 length = encode_data(p, output + 5, outlen - 5); 2666 if (length == 0) return 0; 2668 return length + 5; 2669 } 2671 static int encode_extended(char *buffer, 2672 uint8_t *output, size_t outlen) 2673 { 2674 int attr; 2675 int length; 2676 char *p; 2678 attr = decode_attr(buffer, &p); 2679 if (attr == 0) return 0; 2681 output[0] = attr; 2683 if (attr == 26) { 2684 length = encode_evs(p, output + 1, outlen - 1); 2685 } else { 2686 length = encode_data(p, output + 1, outlen - 1); 2687 } 2688 if (length == 0) return 0; 2689 if (length > (255 - 3)) { 2690 fprintf(stderr, "Extended Attr data is too long\n"); 2691 return 0; 2692 } 2694 return length + 1; 2695 } 2697 static int encode_extended_flags(char *buffer, 2698 uint8_t *output, size_t outlen) 2699 { 2700 int attr; 2701 int length, total; 2702 char *p; 2704 attr = decode_attr(buffer, &p); 2705 if (attr == 0) return 0; 2707 /* output[0] is the extended attribute */ 2708 output[1] = 4; 2709 output[2] = attr; 2710 output[3] = 0; 2712 if (attr == 26) { 2713 length = encode_evs(p, output + 4, outlen - 4); 2714 if (length == 0) return 0; 2716 output[1] += 5; 2717 length -= 5; 2718 } else { 2719 length = encode_data(p, output + 4, outlen - 4); 2720 } 2721 if (length == 0) return 0; 2723 total = 0; 2724 while (1) { 2725 int sublen = 255 - output[1]; 2727 if (length <= sublen) { 2728 output[1] += length; 2729 total += output[1]; 2730 break; 2731 } 2733 length -= sublen; 2735 memmove(output + 255 + 4, output + 255, length); 2736 memcpy(output + 255, output, 4); 2738 output[1] = 255; 2739 output[3] |= 0x80; 2741 output += 255; 2742 output[1] = 4; 2743 total += 255; 2744 } 2746 return total; 2747 } 2749 static int encode_rfc(char *buffer, uint8_t *output, size_t outlen) 2750 { 2751 int attr; 2752 int length, sublen; 2753 char *p; 2755 attr = decode_attr(buffer, &p); 2756 if (attr == 0) return 0; 2758 length = 2; 2759 output[0] = attr; 2760 output[1] = 2; 2762 if (attr == 26) { 2763 sublen = encode_vsa(p, output + 2, outlen - 2); 2765 } else if ((*p == ' ') || ((attr < 241) || (attr > 246))) { 2766 sublen = encode_data(p, output + 2, outlen - 2); 2768 } else { 2769 if (*p != '.') { 2770 fprintf(stderr, "Invalid data following " 2771 "attribute number\n"); 2772 return 0; 2773 } 2775 if (attr < 245) { 2776 sublen = encode_extended(p + 1, 2777 output + 2, outlen - 2); 2778 } else { 2780 /* 2781 * Not like the others! 2782 */ 2783 return encode_extended_flags(p + 1, output, outlen); 2784 } 2785 } 2786 if (sublen == 0) return 0; 2787 if (sublen > (255 -2)) { 2788 fprintf(stderr, "RFC Data is too long\n"); 2789 return 0; 2790 } 2792 output[1] += sublen; 2793 return length + sublen; 2794 } 2796 int main(int argc, char *argv[]) 2797 { 2798 int lineno; 2799 size_t i, outlen; 2800 FILE *fp; 2801 char input[8192], buffer[8192]; 2802 uint8_t output[4096]; 2804 if ((argc < 2) || (strcmp(argv[1], "-") == 0)) { 2805 fp = stdin; 2806 } else { 2807 fp = fopen(argv[1], "r"); 2808 if (!fp) { 2809 fprintf(stderr, "Error opening %s: %s\n", 2810 argv[1], strerror(errno)); 2811 exit(1); 2812 } 2813 } 2815 lineno = 0; 2816 while (fgets(buffer, sizeof(buffer), fp) != NULL) { 2817 char *p = strchr(buffer, '\n'); 2819 lineno++; 2821 if (!p) { 2822 if (!feof(fp)) { 2823 fprintf(stderr, "Line %d too long in %s\n", 2824 lineno, argv[1]); 2825 exit(1); 2826 } 2827 } else { 2828 *p = '\0'; 2829 } 2831 p = strchr(buffer, '#'); 2832 if (p) *p = '\0'; 2834 p = buffer; 2835 while (isspace((int) *p)) p++; 2836 if (!*p) continue; 2838 strcpy(input, p); 2839 outlen = encode_rfc(input, output, sizeof(output)); 2840 if (outlen == 0) { 2841 fprintf(stderr, "Parse error in line %d of %s\n", 2842 lineno, input); 2843 exit(1); 2844 } 2846 printf("%s -> ", buffer); 2847 for (i = 0; i < outlen; i++) { 2848 printf("%02x ", output[i]); 2849 } 2850 printf("\n"); 2851 } 2853 if (fp != stdin) fclose(fp); 2855 return 0; 2856 } 2857 ------------------------------------------------------------ 2859 Author's Address 2861 Alan DeKok 2862 Network RADIUS SARL 2863 15 av du Granier 2864 38240 Meylan 2865 France 2867 Email: aland@networkradius.com 2868 URI: http://networkradius.com 2870 Avi Lior 2871 Bridgewater Systems Corporation 2872 303 Terry Fox Drive 2873 Suite 100 2874 Ottawa, Ontario K2K 3J1 2875 Canada 2877 Phone: +1 (613) 591-6655 2878 Email: avi@bridgewatersystems.com 2879 URI: http://www.bridgewatersystems.com/