idnits 2.17.1 draft-ietf-radext-radius-extensions-12.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (Using the creation date from RFC2865, updated by this document, for RFC5378 checks: 1999-03-04) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (18 February 2013) is 4084 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) == Missing Reference: 'RFC1311' is mentioned on line 2452, but not defined -- Looks like a reference, but probably isn't: '1' on line 3038 -- Looks like a reference, but probably isn't: '0' on line 2973 -- Looks like a reference, but probably isn't: '2' on line 2923 -- Looks like a reference, but probably isn't: '3' on line 2953 -- Looks like a reference, but probably isn't: '4' on line 2877 -- Looks like a reference, but probably isn't: '8192' on line 3015 -- Looks like a reference, but probably isn't: '4096' on line 3016 == Unused Reference: 'RFC5176' is defined on line 2480, but no explicit reference was found in the text == Unused Reference: 'RFC1321' is defined on line 2494, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2866 ** Downref: Normative reference to an Informational RFC: RFC 5176 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'PEN' Summary: 3 errors (**), 0 flaws (~~), 7 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 6 7 Expires: August 18, 2013 8 18 February 2013 10 Remote Authentication Dial In User Service (RADIUS) Protocol 11 Extensions 12 draft-ietf-radext-radius-extensions-12.txt 14 Abstract 16 The Remote Authentication Dial In User Service (RADIUS) protocol is 17 nearing exhaustion of its current 8-bit Attribute Type space. In 18 addition, experience shows a growing need for complex grouping, along 19 with attributes which can carry more than 253 octets of data. This 20 document defines changes to RADIUS which address all of the above 21 problems. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on June 26, 2013. 46 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info/) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction ............................................. 5 63 1.1. Caveats and Limitations ............................. 6 64 1.1.1. Failure to Meet Certain Goals .................. 6 65 1.1.2. Implementation Recommendations ................. 6 66 1.2. Terminology ......................................... 7 67 1.3. Requirements Language ............................... 8 68 2. Extensions to RADIUS ..................................... 9 69 2.1. Extended Type ....................................... 10 70 2.2. Long Extended Type .................................. 11 71 2.3. TLV Data Type ....................................... 14 72 2.3.1. TLV Nesting .................................... 16 73 2.4. EVS Data Type ....................................... 16 74 2.5. Integer64 Data Type ................................. 18 75 2.6. Vendor-ID Field ..................................... 18 76 2.7. Attribute Naming and Type Identifiers ............... 19 77 2.7.1. Attribute and TLV Naming ....................... 19 78 2.7.2. Attribute Type Identifiers ..................... 20 79 2.7.3. TLV Identifiers ................................ 20 80 2.7.4. VSA Identifiers ................................ 20 81 2.8. Invalid Attributes .................................. 21 82 3. Attribute Definitions .................................... 22 83 3.1. Extended-Type-1 ..................................... 23 84 3.2. Extended-Type-2 ..................................... 23 85 3.3. Extended-Type-3 ..................................... 24 86 3.4. Extended-Type-4 ..................................... 25 87 3.5. Long-Extended-Type-1 ................................ 26 88 3.6. Long-Extended-Type-2 ................................ 27 89 4. Vendor Specific Attributes ............................... 28 90 4.1. Extended-Vendor-Specific-1 .......................... 29 91 4.2. Extended-Vendor-Specific-2 .......................... 30 92 4.3. Extended-Vendor-Specific-3 .......................... 31 93 4.4. Extended-Vendor-Specific-4 .......................... 32 94 4.5. Extended-Vendor-Specific-5 .......................... 33 95 4.6. Extended-Vendor-Specific-6 .......................... 35 96 5. Compatibility with traditional RADIUS .................... 36 97 5.1. Attribute Allocation ................................ 36 98 5.2. Proxy Servers ....................................... 37 99 6. Guidelines ............................................... 38 100 6.1. Updates to RFC 6158 ................................. 39 101 6.2. Guidelines for Simple Data Types .................... 39 102 6.3. Guidelines for Complex Data Types ................... 39 103 6.4. Design Guidelines For the New Types ................. 40 104 6.5. TLV Guidelines ...................................... 41 105 6.6. Allocation Request Guidelines ....................... 41 106 6.7. Allocation Requests Guidelines for TLVs ............. 43 107 6.8. Implementation Guidelines ........................... 43 108 6.9. Vendor Guidelines ................................... 43 109 7. Rationale for This Design ................................ 43 110 7.1. Attribute Audit ..................................... 44 111 8. Diameter Considerations .................................. 45 112 9. Examples ................................................. 45 113 9.1. Extended Type ....................................... 46 114 9.2. Long Extended Type .................................. 47 115 10. IANA Considerations ..................................... 50 116 10.1. Attribute Allocations .............................. 50 117 10.2. RADIUS Attribute Type Tree ......................... 51 118 10.3. Allocation Instructions ............................ 52 119 10.3.1. Requested Allocation from the Standard Space .. 52 120 10.3.2. Requested Allocation from the short extended sp 52 121 10.3.3. Requested Allocation from the long extended spa 52 122 10.3.4. Allocation Preferences ........................ 52 123 10.3.5. Extending the Type Space via TLV Data Type .... 53 124 10.3.6. Allocation within a TLV ....................... 54 125 10.3.7. Allocation of Other Data Types ................ 54 126 11. Security Considerations ................................. 54 127 12. References .............................................. 54 128 12.1. Normative references ............................... 55 129 12.2. Informative references ............................. 55 130 Appendix A - Extended Attribute Generator Program ............ 57 131 1. Introduction 133 Under current allocation pressure, we expect that the RADIUS 134 Attribute Type space will be exhausted by 2014 or 2015. We therefore 135 need a way to extend the type space, so that new specifications may 136 continue to be developed. Other issues have also been shown with 137 RADIUS. The attribute grouping method defined in [RFC2868] has been 138 shown to be impractical, and a more powerful mechanism is needed. 139 Multiple attributes have been defined which transport more than the 140 253 octets of data originally envisioned with the protocol. Each of 141 these attributes is handled as a "special case" inside of RADIUS 142 implementations, instead of as a general method. We therefore also 143 need a standardized method of transporting large quantities of data. 144 Finally, some vendors are close to allocating all of the Attributes 145 within their Vendor-Specific Attribute space. It would be useful to 146 leverage changes to the base protocol for extending the Vendor- 147 Specific Attribute space. 149 We satisfy all of these requirements through the following changes 150 given in this document: 152 * defining an "Extended Type" format, which adds 8 bits of "Extended 153 Type" to the RADIUS Attribute Type space, by using one octet of the 154 "Value" field. This method gives us a general way of extending 155 the Attribute Type Space. (Section 2.1) 157 * allocating 4 attributes as using the format of "Extended Type". 158 This allocation extends the RADIUS Attribute Type Space by 159 approximately 1000 values. (Sections 3.1, 3.2, 3.3, and 3.4) 161 * defining a "Long Extended Type" format, which inserts an additional 162 octet between the "Extended Type" octet, and the "Value" field. 163 This method gives us a general way of adding additional 164 functionality to the protocol. (Section 2.2) 166 * defining a method which uses the additional octet in the "Long 167 Extended Type" to indicate data fragmentation across multiple 168 Attributes. This method provides a standard way for an Attribute 169 to carry more than 253 octets of data. (Section 2.2) 171 * allocating 2 attributes as using the format "Long Extended Type". 172 This allocation extends the RADIUS Attribute Type Space 173 by an additional 500 values. (Sections 3.5 and 3.6) 175 * defining a new "Type Length Value" (TLV) data type. The data type 176 allows an attribute to carry TLVs as "sub-attributes", which can in 177 turn encapsulate other TLVs as "sub-sub-attributes." This change 178 creates a standard way to group a set of Attributes. (Section 2.3) 180 * defining a new "extended Vendor-Specific" (EVS) data type. The 181 data type allows an attribute to carry Vendor-Specific Attributes 182 (VSAs) inside of the new attribute formats. (Section 2.4) 184 * defining a new "integer64" data type. The data type allows 185 counters which track more than 2^32 octets of data. (Section 2.5) 187 * allocating 6 attributes using the new EVS data type. This 188 allocation extends the Vendor-Specific Attribute Type space by 189 over 1500 values. (Sections 4.1 through 4.6) 191 * Define the "Vendor-ID" for Vendor-Specific attributes to encompass 192 the entire 4 octets of the Vendor field. [RFC2865] Section 5.26 193 defined it to be 3 octets, with the high octet being zero. 194 (Section 2.5) 196 * Describing compatibility with existing RADIUS systems. (Section 5) 198 * Defining guidelines for the use of these changes for IANA, 199 implementations of this specification, and for future RADIUS 200 specifications. (Section 6) 202 As with any protocol change, the changes defined here are the result 203 of a series of compromises. We have tried to find a balance between 204 flexibility, space in the RADIUS message, compatibility with existing 205 deployments, and implementation difficulty. 207 1.1. Caveats and Limitations 209 This section describes some caveats and limitations with the 210 proposal. 212 1.1.1. Failure to Meet Certain Goals 214 One goal which was not met by the above modifications is to have an 215 incentive for standards to use the new space. That incentive is 216 being provided by the exhaustion of the standard space. 218 1.1.2. Implementation Recommendations 220 It is RECOMMENDED that implementations support this specification. 221 It is RECOMMENDED that new specifications use the formats defined in 222 this specification. 224 The alternative to the above recommendations is a circular argument 225 of not implementing this specification because no other standards 226 reference it, and also not defining new standards referencing this 227 specification because no implementations exist. 229 As noted earlier, the "standard space" is almost entirely allocated. 230 Ignoring the looming crisis benefits no one. 232 1.2. Terminology 234 This document uses the following terms: 236 Silently discard 237 This means the implementation discards the packet without further 238 processing. The implementation MAY provide the capability of 239 logging the error, including the contents of the silently discarded 240 packet, and SHOULD record the event in a statistics counter. 242 Invalid attribute 243 This means that the Length field of an Attribute is valid (as per 244 [RFC2865], Section 5, top of page 25), but the contents of the 245 Attribute do not follow the correct format. For example, an 246 Attribute of type "address" which encapsulates more than four, or 247 less than four, octets of data. See Section 2.8 for a more 248 complete definition. 250 Standard space 251 Codes in the RADIUS Attribute Type Space that are allocated by IANA 252 and that follow the format defined in Section 5 of [RFC2865]. 254 Extended space 255 Codes in the RADIUS Attribute Type Space that require the 256 extensions defined in this document, and are an extension of the 257 standard space, but which cannot be represented within the standard 258 space. 260 Short extended space 261 Codes in the extended space which use the "Extended Type" format. 263 Long extended space 264 Codes in the extended space which use the "Long Extended Type" 265 format. 267 The following terms are used here with the meanings defined in BCP 268 26 [RFC5226]: "name space", "assigned value", "registration", 269 "Private Use", "Reserved", "Unassigned", "IETF Review", and 270 "Standards Action". 272 1.3. Requirements Language 274 In this document, several words are used to signify the requirements 275 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 276 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 277 and "OPTIONAL" in this document are to be interpreted as described in 278 [RFC2119]. 280 2. Extensions to RADIUS 282 This section defines two new attribute formats; "Extended Type"; and 283 "Long Extended Type". It defines a new Type-Length-Value (TLV) data 284 type, an Extended-Vendor-Specific (EVS) data type, and an Integer64 285 data type. It defines a new method for naming attributes and 286 identifying Attributes using the new attribute formats. It finally 287 defines the new term "invalid attribute", and describes how it 288 affects implementations. 290 The new attribute formats are designed to be compatible with the 291 attribute format given in [RFC2865] Section 5. The meaning and 292 interpretation of the Type and Length fields is unchanged from that 293 specification. This reuse allows the new formats to be compatible 294 with RADIUS implementations which do not implement this 295 specification. Those implementations can simply ignore the Value 296 field of an attribute, or forward it verbatim. 298 The changes to the attribute format come about by "stealing" one or 299 more octets from the Value field. This change has the effect that 300 the Value field of [RFC2865] Section 5 contains both the new octets 301 given here, and any attribute-specific Value. The result is that 302 Values in this specification are limited to less than 253 octets in 303 size. This limitation is overcome through the use of the "Long 304 Extended Type" format. 306 We reiterate that the formats given in this document do not insert 307 new data into an attribute. Instead, we "steal" one octet of Value, 308 so that the definition of the Length field remains unchanged. The 309 new attribute formats are designed to be compatible with the 310 attribute format given in [RFC2865] Section 5. The meaning and 311 interpretation of the Type and Length fields is unchanged from that 312 specification. This reuse allows the new formats to be compatible 313 RADIUS implementations which do not implement this specification. 314 Those implementations can simply ignore the Value field of an 315 attribute, or forward it verbatim. 317 The changes to the attribute format come about by "stealing" one or 318 more octets from the Value field. This change has the effect that 319 the Value field of [RFC2865] Section 5 contains both the new octets 320 given here, and any attribute-specific Value. The result is that 321 Values in this specification are limited to less than 253 octets in 322 size. This limitation is overcome through the use of the "Long 323 Extended Type" format. 325 2.1. Extended Type 327 This section defines a new attribute format, called "Extended Type". 328 A summary of the Attribute format is shown below. The fields are 329 transmitted from left to right. 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Type | Length | Extended-Type | Value ... 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Type 339 This field is identical to the Type field of the Attribute format 340 defined in [RFC2865] Section 5. 342 Length 344 The Length field is one octet, and indicates the length of this 345 Attribute including the Type, Length, Extended-Type, and Value 346 fields. Permitted values are between 4 and 255. If a client or 347 server receives an Extended Attribute with a Length of 2 or 3, 348 then that Attribute MUST be considered to be an "invalid 349 attribute", and handled as per Section 2.8, below. 351 Extended-Type 353 The Extended-Type field is one octet. Up-to-date values of this 354 field are specified according to the policies and rules described 355 in Section 10. Unlike the Type field defined in [RFC2865] Section 356 5, no values are allocated for experimental or implementation- 357 specific use. Values 241-255 are reserved and MUST NOT be used. 359 The Extended-Type is meaningful only within a context defined by 360 the Type field. That is, this field may be thought of as defining 361 a new type space of the form "Type.Extended-Type". See Section 362 2.5, below, for additional discussion. 364 A RADIUS server MAY ignore Attributes with an unknown 365 "Type.Extended-Type". 367 A RADIUS client MAY ignore Attributes with an unknown 368 "Type.Extended-Type". 370 Value 372 This field is similar to the Value field of the Attribute format 373 defined in [RFC2865] Section 5. The format of the data MUST be a 374 valid RADIUS data type. 376 The Value field is one or more octets. Implementations not 377 supporting this specification SHOULD support the field as 378 undistinguished octets. 380 Implementations supporting this specification MUST use the 381 Identifier of "Type.Extended-Type" to determine the interpretation 382 of the Value field. 384 The addition of the Extended-Type field decreases the maximum 385 length for attributes of type "text" or "string" from 253 to 252 386 octets. Where an Attribute needs to carry more than 252 octets of 387 data, the "Long Extended Type" format MUST be used. 389 Experience has shown that the "experimental" and "implementation 390 specific" attributes defined in [RFC2865] Section 5 have had little 391 practical value. We therefore do not continue that practice here 392 with the Extended-Type field. 394 2.2. Long Extended Type 396 This section defines a new attribute format, called "Long Extended 397 Type". It leverages the "Extended Type" format in order to permit 398 the transport of attributes encapsulating more than 253 octets of 399 data. A summary of the Attribute format is shown below. The fields 400 are transmitted from left to right. 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Type | Length | Extended-Type |M| Reserved | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Value ... 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Type 412 This field is identical to the Type field of the Attribute format 413 defined in [RFC2865] Section 5. 415 Length 417 The Length field is one octet, and indicates the length of this 418 Attribute including the Type, Length, Extended-Type, and Value 419 fields. Permitted values are between 5 and 255. If a client or 420 server receives a "Long Extended Type" with a Length of 2, 3, or 421 4, then that Attribute MUST be considered to be an "invalid 422 attribute", and be handled as per Section 2.8, below. 424 Note that this Length is limited to the length of this fragment. 425 There is no field which gives an explicit value for the total size 426 of the fragmented attribute. 428 Extended-Type 430 This field is identical to the Extended-Type field defined above 431 in Section 2.1. 433 M (More) 435 The More field is one (1) bit in length, and indicates whether or 436 not the current attribute contains "more" than 251 octets of data. 437 The More field MUST be clear (0) if the Length field has value 438 less than 255. The More field MAY be set (1) if the Length field 439 has value of 255. 441 If the More field is set (1), it indicates that the Value field 442 has been fragmented across multiple RADIUS attributes. When the 443 More field is set (1), the attribute MUST have a Length field of 444 value 255; there MUST be an attribute following this one; and the 445 next attribute MUST have both the same Type and Extended Type. 446 That is, multiple fragments of the same value MUST be in order and 447 MUST be consecutive attributes in the packet, and the last 448 attribute in a packet MUST NOT have the More field set (1). 450 That is, a packet containing a fragmented attribute needs to 451 contain all fragments of the attribute, and those fragments need 452 to be contiguous in the packet. RADIUS does not support inter- 453 packet fragmentation, which means that fragmenting an attribute 454 across multiple packets is impossible. 456 If a client or server receives an attribute fragment with the 457 "More" field set (1), but for which no subsequent fragment can be 458 found, then the fragmented attribute is considered to be an 459 "invalid attribute", and handled as per Section 2.8, below. 461 Reserved 463 This field is 7 bits long, and is reserved for future use. 464 Implementations MUST set it to zero (0) when encoding an attribute 465 for sending in a packet. The contents SHOULD be ignored on 466 reception. 468 Future specifications may define additional meaning for this 469 field. Implementations therefore MUST NOT treat this field as 470 invalid if it is non-zero. 472 Value 474 This field is similar to the Value field of the Attribute format 475 defined in [RFC2865] Section 5. It may contain a complete set of 476 data (when the Length field has value less than 255), or it may 477 contain a fragment of data. 479 The Value field is one or more octets. Implementations not 480 supporting this specification SHOULD support the field as 481 undistinguished octets. 483 Implementations supporting this specification MUST use the 484 Identifier of "Type.Extended-Type" to determine the interpretation 485 of the Value field. 487 Any interpretation of the resulting data MUST occur after the 488 fragments have been reassembled. The length of the data MUST be 489 taken as the sum of the lengths of the fragments (i.e. Value 490 fields) from which it is constructed. The format of the data 491 SHOULD be a valid RADIUS data type. If the reassembled data does 492 not match the expected format, all fragments MUST be treated as 493 "invalid attributes", and the reassembled data MUST be discarded. 495 We note that the maximum size of a fragmented attribute is limited 496 only by the RADIUS packet length limitation (i.e. 4096 octets, not 497 counting various headers and overhead). Implementations MUST be 498 able to handle the case where one fragmented attribute completely 499 fills the packet. 501 This definition increases the RADIUS Attribute Type space as above, 502 but also provides for transport of Attributes which could contain 503 more than 253 octets of data. 505 Note that [RFC2865] Section 5 says: 507 If multiple Attributes with the same Type are present, the order 508 of Attributes with the same Type MUST be preserved by any proxies. 509 The order of Attributes of different Types is not required to be 510 preserved. A RADIUS server or client MUST NOT have any 511 dependencies on the order of attributes of different types. A 512 RADIUS server or client MUST NOT require attributes of the same 513 type to be contiguous. 515 These requirements also apply to the "Long Extended Type" attribute, 516 including fragments. Implementations MUST be able to process non- 517 contiguous fragments -- that is, fragments which are mixed together 518 with other attributes of a different Type. This will allow them to 519 accept packets, so long as the attributes can be correctly decoded. 521 2.3. TLV Data Type 523 We define a new data type in RADIUS, called "tlv". The "tlv" data 524 type is an encapsulation layer which permits the "Value" field of an 525 Attribute to contain new sub-Attributes. These sub-Attributes can in 526 turn contain "Value"s of data type TLV. This capability both extends 527 the attribute space, and permits "nested" attributes to be used. 528 This nesting can be used to encapsulate or group data into one or 529 more logical containers. 531 The "tlv" data type re-uses the RADIUS attribute format, as given 532 below: 534 0 1 2 3 535 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 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | TLV-Type | TLV-Length | TLV-Value ... 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 TLV-Type 542 The Type field is one octet. Up-to-date values of this field are 543 specified according to the policies and rules described in Section 544 10. Values 254-255 are "Reserved" for use by future extensions to 545 RADIUS. The value 26 has no special meaning, and MUST NOT be 546 treated as a Vendor Specific attribute. 548 As with Extended-Type above, the TLV-Type is meaningful only 549 within the context defined by "Type" fields of the encapsulating 550 Attributes. That is, the field may be thought of as defining a 551 new type space of the form "Type.Extended-Type.TLV-Type". Where 552 TLVs are nested, the type space is of the form "Type.Extended- 553 Type.TLV-Type.TLV-Type", etc. 555 A RADIUS server MAY ignore Attributes with an unknown "TLV-Type". 557 A RADIUS client MAY ignore Attributes with an unknown "TLV-Type". 559 A RADIUS proxy SHOULD forward Attributes with an unknown "TLV- 560 Type" verbatim. 562 TLV-Length 564 The TLV-Length field is one octet, and indicates the length of 565 this TLV including the TLV-Type, TLV-Length and TLV-Value fields. 566 It MUST have a value between 3 and 255. If a client or server 567 receives a TLV with an invalid TLV-Length, then the attribute 568 which encapsulates that TLV MUST be considered to be an "invalid 569 attribute", and handled as per Section 2.8, below. 571 TLV-Value 573 The TLV-Value field is one or more octets and contains information 574 specific to the Attribute. The format and length of the TLV-Value 575 field is determined by the TLV-Type and TLV-Length fields. 577 The TLV-Value field SHOULD encapsulate a standard RADIUS data 578 type. Non-standard data types SHOULD NOT be used withing TLV- 579 Value fields. We note that the TLV-Value field MAY also contain 580 one or more attributes of data type "tlv", which allows for simple 581 grouping and multiple layers of nesting. 583 The TLV-Value field is limited to containing 253 or fewer octets 584 of data. Specifications which require a TLV to contain more than 585 253 octets of data are incompatible with RADIUS, and need to be 586 redesigned. Specifications which require the transport of empty 587 Values (i.e. Length = 2) are incompatible with RADIUS, and need to 588 be redesigned. 590 The TLV-Value field MUST NOT contain data using the "Extended 591 Type" formats defined in this document. The base Extended 592 Attributes format allows for sufficient flexibility that nesting 593 them inside of a TLV offers little additional value. 595 This TLV definition is compatible with the suggested format of the 596 "String" field of the Vendor-Specific attribute, as defined in 597 [RFC2865] Section 5.26, though that specification does not discuss 598 nesting. 600 Vendors MAY use attributes of type "tlv" in any Vendor Specific 601 Attribute. It is RECOMMENDED to use type "tlv" for VSAs, in 602 preference to any other format. 604 If multiple TLVs with the same TLV-Type are present, the order of 605 TLVs with the same TLV-Type MUST be preserved by any proxies. The 606 order of TLVs of different TLV-Types is not required to be preserved. 607 A RADIUS server or client MUST NOT have any dependencies on the order 608 of TLVs of different TLV-Types. A RADIUS server or client MUST NOT 609 require TLVs of the same TLV-type to be contiguous. 611 The interpretation of multiple TLVs of the same TLV-Type MUST be that 612 of a logical "and", unless otherwise specified. That is, multiple 613 TLVs are interpreted as specifying an unordered set of values. 614 Specifications SHOULD NOT define TLVs to be interpreted as a logical 615 "or". Doing so would mean that a RADIUS client or server would make 616 an arbitrary, and non-deterministic choice among the values. 618 2.3.1. TLV Nesting 620 TLVs may contain other TLVs. When this occurs, the "container" TLV 621 MUST be completely filled by the "contained" TLVs. That is, the 622 "container" TLV-Length field MUST be exactly two (2) more than the 623 sum of the "contained" TLV-Length fields. If the "contained" TLVs 624 over-fill the "container" TLV, the "container" TLV MUST be considered 625 to be an "invalid attribute", and handled as described in Section 626 2.8, below. 628 The depth of TLV nesting is limited only by the restrictions on the 629 TLV-Length field. The limit of 253 octets of data results in a limit 630 of 126 levels of nesting. However, nesting depths of more than 4 are 631 NOT RECOMMENDED. They have not been demonstrated to be necessary in 632 practice, and they appear to make implementations more complex. 633 Reception of packets with such deeply nest TLVs may indicate 634 implementation errors or deliberate attacks. Where implementations 635 do not support deep nesting of TLVs, it is RECOMMENDED that the 636 unsupported layers are treated as "invalid attributes". 638 2.4. EVS Data Type 640 We define a new data type in RADIUS, called "evs", for "Extended 641 Vendor-Specific". The "evs" data type is an encapsulation layer 642 which permits the "Value" field of an Attribute to contain a Vendor- 643 Id, followed by a Vendor-Type, and then vendor-defined data. This 644 data can in turn contain valid RADIUS data types, or any other data 645 as determined by the vendor. 647 This data type is intended use in attributes which carry Vendor- 648 Specific information, as is done with the Vendor-Specific Attribute 649 (26). It is RECOMMENDED that this data type be used by a vendor only 650 when the Vendor-Specific Attribute Type space has been fully 651 allocated. 653 Where [RFC2865] Section 5.26 makes a recommendation for the format of 654 the data following the Vendor-Id, we give a strict definition. 655 Experience has shown that many vendors have not followed the 656 [RFC2865] recommendations, leading to interoperability issues. We 657 hope here to give vendors sufficient flexibility as to meet their 658 needs, while minimizing the use of non-standard VSA formats. 660 The "evs" data type MAY be used in Attributes having the format of 661 "Extended Type" or "Long Extended Type". It MUST NOT be used in any 662 other Attribute definition, including standard RADIUS Attributes, 663 TLVs, and VSAs. 665 A summary of the "evs" data type format is shown below. The fields 666 are transmitted from left to right. 668 0 1 2 3 669 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 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Vendor-Id | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | Vendor-Type | Vendor-Value .... 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 Vendor-Id 678 The 4 octets are the Network Management Private Enterprise Code 679 [PEN] of the Vendor in network byte order. 681 Vendor-Type 683 The Vendor-Type field is one octet. Values are assigned at the 684 sole discretion of the Vendor. 686 Vendor-Value 688 The Vendor-Value field is one or more octets. It SHOULD 689 encapsulate a standard RADIUS data type. Using non-standard data 690 types is NOT RECOMMENDED. We note that the Value field may be of 691 data type "tlv". However, it MUST NOT be of data type "evs", as 692 the use cases are unclear for one vendor delegating Attribute Type 693 space to another vendor. 695 The actual format of the information is site or application 696 specific, and a robust implementation SHOULD support the field as 697 undistinguished octets. We recognise that Vendors have complete 698 control over the contents and format of the Value field, while at 699 the same time recommending that good practices be followed. 701 Further codification of the range of allowed usage of this field 702 is outside the scope of this specification. 704 Note that unlike the format described in [RFC2865] Section 5.26, this 705 data type has no "Vendor length" field. The length of the Vendor- 706 Value field is implicit, and is determined by taking the "Length" of 707 the encapsulating RADIUS Attribute, and subtracting the length of the 708 attribute header (2 octets), the extended type (1 octet), the Vendor- 709 Id (4 octets), and the Vendor-type (1 octet). i.e. For "Extended 710 Type" attributes, the length of the Vendor-Value field is eight (8) 711 less than the value of the Length field. For "Long Extended Type" 712 attributes, the length of the Vendor-Value field is nine (9) less 713 than the value of the Length field. 715 2.5. Integer64 Data Type 717 We define a new data type in RADIUS, called "integer64", which 718 carries a 64-bit unsigned integer in network byte order. 720 This data type is intended to be used in any situation where there is 721 a need to have counters which can count past 2^32. The expected use 722 of this data type is within Accounting-Request packets, but this data 723 type SHOULD be used in any packet where 32-bit integers are expected 724 to be insufficient. 726 The "integer64" data type can be used in Attributes of any format, 727 standard space, extended attributes, TLVs, and VSAs. 729 A summary of the "integer64" data type format is shown below. The 730 fields are transmitted from left to right. 732 0 1 2 3 733 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 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Value ... 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 Attributes having data type "integer64" MUST have the relevant Length 741 field set to eight more than the length of the Attribute header. For 742 standard space Attributes and TLVs, this means that the Length field 743 MUST be set to ten (10). For "Extended Type" Attributes, the Length 744 field MUST be set to eleven (11). For "Long Extended Type" 745 Attributes, the Length field MUST be set to twelve (12). 747 2.6. Vendor-ID Field 749 We define the Vendor-ID field of Vendor-Specific Attributes to 750 encompass the entire 4 octets of the Vendor field. [RFC2865] Section 751 5.26 defined it to be 3 octets, with the high octet being zero. This 752 change has no immediate impact on RADIUS, as the maximum Private 753 Enterprise Code defined is still within 16 bits. 755 However, it is best to make advance preparations for changes in the 756 protocol. As such, it is RECOMMENDED that all implementations 757 support four (4) octets for the Vendor-ID field, instead of three 758 (3). 760 2.7. Attribute Naming and Type Identifiers 762 Attributes have traditionally been identified by a unique name and 763 number. For example, the attribute named "User-Name" has been 764 allocated number one (1). This scheme needs to be extended in order 765 to be able to refer to attributes of Extended Type, and to TLVs. It 766 will also be used by IANA for allocating RADIUS Attribute Type 767 values. 769 The names and identifiers given here are intended to be used only in 770 specifications. The system presented here may not be useful when 771 referring to the contents of a RADIUS packet. It imposes no 772 requirements on implementations, as implementations are free to 773 reference RADIUS Attributes via any method they choose. 775 2.7.1. Attribute and TLV Naming 777 RADIUS specifications traditionally use names consisting of one or 778 more words, separated by hyphens, e.g. "User-Name". However, these 779 names are not allocated from a registry, and there is no restriction 780 other than convention on their global uniqueness. 782 Similarly, vendors have often used their company name as the prefix 783 for VSA names, though this practice is not universal. For example, 784 for a vendor named "Example", the name "Example-Attribute-Name" 785 SHOULD be used instead of "Attribute-Name". The second form can 786 conflict with attributes from other vendors, whereas the first form 787 cannot. 789 It is therefore RECOMMENDED that specifications give names to 790 Attributes which attempt to be globally unique across all RADIUS 791 Attributes. It is RECOMMENDED that vendors use their name as a 792 unique prefix for attribute names, e.g. Livingston-IP-Pool instead of 793 IP-Pool. It is RECOMMENDED that implementations enforce uniqueness 794 on names, which would otherwise lead to ambiguity and problems. 796 We recognise that these suggestions may sometimes be difficult to 797 implement in practice. 799 TLVs SHOULD be named with a unique prefix that is shared among 800 related attributes. For example, a specification that defines a set 801 of TLVs related to time could create attributes named "Time-Zone", 802 "Time-Day", "Time-Hour", "Time-Minute", etc. 804 2.7.2. Attribute Type Identifiers 806 The RADIUS Attribute Type space defines a context for a particular 807 "Extended-Type" field. The "Extended-Type" field allows for 256 808 possible type code values, with values 1 through 240 available for 809 allocation. We define here an identification method that uses a 810 "dotted number" notation similar to that used for Object Identifiers 811 (OIDs), formatted as "Type.Extended-Type". 813 For example, an attribute within the Type space of 241, having 814 Extended-Type of one (1), is uniquely identified as "241.1". 815 Similarly, an attribute within the Type space of 246, having 816 Extended-Type of ten (10), is uniquely identified as "246.10". 818 2.7.3. TLV Identifiers 820 We can extend the Attribute reference scheme defined above for TLVs. 821 This is done by leveraging the "dotted number" notation. As above, 822 we define an additional TLV type space, within the "Extended Type" 823 space, by appending another "dotted number" in order to identify the 824 TLV. This method can be repeated in sequence for nested TLVs. 826 For example, let us say that "245.1" identifies RADIUS Attribute Type 827 245, containing an "Extended Type" of one (1), which is of type 828 "tlv". That attribute will contain 256 possible TLVs, one for each 829 value of the TLV-Type field. The first TLV-Type value of one (1) can 830 then be identified by appending a ".1" to the number of the 831 encapsulating attribute ("241.1"), to yield "241.1.1". Similarly, 832 the sequence "245.2.3.4" identifies RADIUS attribute 245, containing 833 an "Extended Type" of two (2) which is of type "tlv", which in turn 834 contains a TLV with TLV-Type number three (3), which in turn contains 835 another TLV, with TLV-Type number four (4). 837 2.7.4. VSA Identifiers 839 There has historically been no method for numerically addressing 840 VSAs. The "dotted number" method defined here can also be leveraged 841 to create such an addressing scheme. However, as the VSAs are 842 completely under the control of each individual vendor, this section 843 provides a suggested practice, but does not define a standard of any 844 kind. 846 The Vendor-Specific Attribute has been assigned the Attribute number 847 26. It in turn carries a 24-bit Vendor-Id, and possibly additional 848 VSAs. Where the VSAs follow the [RFC2865] Section 5.26 recommended 849 format, a VSA can be identified as "26.Vendor-Id.Vendor-Type". 851 For example, Livingston has Vendor-Id 307, and has defined an 852 attribute "IP-Pool" as number 6. This VSA can be uniquely identified 853 as 26.307.6, but it cannot be uniquely identified by name, as other 854 vendors may have used the same name. 856 Note that there are few restrictions on the size of the numerical 857 values in this notation. The Vendor-Id is a 24-bit number, and the 858 VSA may have been assigned from a 16-bit vendor-specific Attribute 859 Type space. Implementations SHOULD be capable of handling 32-bit 860 numbers at each level of the "dotted number" notation. 862 For example, the company USR has been allocated Vendor-Id 429, and 863 has defined a "Version-Id" attribute as number 32768. This VSA can 864 be uniquely identified as 26.429.32768, and again cannot be uniquely 865 identified by name. 867 Where a VSA is a TLV, the "dotted number" notation can be used as 868 above: 26.Vendor-Id.Vendor-Type.TLV1.TLV2.TLV3 where "TLVn" are the 869 numerical values assigned by the vendor to the different nested TLVs. 871 2.8. Invalid Attributes 873 The term "invalid attribute" is new to this specification. It is 874 defined to mean that the Length field of an Attribute permits the 875 packet to be accepted as not being "malformed". However, the Value 876 field of the attribute does not follow the format required by the 877 data type defined for that Attribute, and therefore the attribute is 878 "malformed". In order to distinguish the two cases, we refer to 879 "malformed" packets, and "invalid attributes". 881 For example, an implementation receives a packet which is well- 882 formed. That packet contains an Attribute allegedly of data type 883 "address", but which has Length not equal to four. In that 884 situation, the packet is well formed, but the attribute is not. 885 Therefore, it is an "invalid attribute". 887 A similar analysis can be performed when an attribute carries TLVs. 888 The encapsulating attribute may be well formed, but the TLV may be an 889 "invalid attribute". The existence of an "invalid attribute" in a 890 packet or attribute MUST NOT result in the implementation discarding 891 the entire packet, or treating the packet as a negative 892 acknowledgment. Instead, only the "invalid attribute" is treated 893 specially. 895 When an implementation receives an "invalid attribute", it SHOULD be 896 silently discarded, except when the implementation is acting as a 897 proxy (see Section 5.2 for discussion of proxy servers). If it is 898 not discarded, it MUST NOT be handled in the same manner as a well- 899 formed attribute. For example, receiving an Attribute of data type 900 "address" containing less than four octets, or more than four octets 901 of data means that the Attribute MUST NOT be treated as being of data 902 type "address". The reason here is that if the attribute does not 903 carry an IPv4 address, the receiver has no idea what format the data 904 is in, and it is therefore not an IPv4 address. 906 For Attributes of type "Long Extended Type", an Attribute is 907 considered to be an "invalid attribute" when it does not match the 908 criteria set out in Section 2.2, above. 910 For Attributes of type "TLV", an Attribute is considered to be an 911 "invalid attribute" when the TLV-Length field allows the 912 encapsulating Attribute to be parsed, but the TLV-Value field does 913 not match the criteria for that TLV. Implementations SHOULD NOT 914 treat the "invalid attribute" property as being transitive. That is, 915 the Attribute encapsulating the "invalid attribute" SHOULD NOT be 916 treated as an "invalid attribute". That encapsulating Attribute 917 might contain multiple TLVs, only one of which is an "invalid 918 attribute". 920 However, a TLV definition may require particular sub-TLVs to be 921 present, and/or to have specific values. If a sub-TLV is missing, or 922 contains incorrect value(s), or is an "invalid attribute", then the 923 encapsulating TLV SHOULD be treated as an "invalid attribute". This 924 requirement ensures that strongly connected TLVs are handled either 925 as a coherent whole, or are ignored entirely. 927 3. Attribute Definitions 929 We define four (4) attributes of "Extended Type", which are allocated 930 from the "Reserved" Attribute Type codes of 241, 242, 243, and 244. 931 We also define two (2) attributes of "Long Extended Type", which are 932 allocated from the "Reserved" Attribute Type codes of 245 and 246. 934 Type Name 935 ---- ---- 936 241 Extended-Type-1 937 242 Extended-Type-2 938 243 Extended-Type-3 939 244 Extended-Type-4 940 245 Long-Extended-Type-1 941 246 Long-Extended-Type-2 943 The rest of this section gives a detailed definition for each 944 Attribute based on the above summary. 946 3.1. Extended-Type-1 948 Description 950 This attribute encapsulates attributes of the "Extended Type" 951 format, in the RADIUS Attribute Type Space of 241.{1-255}. 953 A summary of the Extended-Type-1 Attribute format is shown below. 954 The fields are transmitted from left to right. 956 0 1 2 3 957 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 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Type | Length | Extended-Type | Value ... 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 Type 964 241 for Extended-Type-1. 966 Length 968 >= 4 970 Extended-Type 972 The Extended-Type field is one octet. Up-to-date values of this 973 field are specified in the 241.{1-255} RADIUS Attribute Type 974 Space, according to the policies and rules described in Section 975 10. Further definition of this field is given in Section 2.1, 976 above. 978 Value 980 The Value field is one or more octets. Implementations not 981 supporting this specification SHOULD support the field as 982 undistinguished octets. 984 Implementations supporting this specification MUST use the 985 Identifier of "Type.Extended-Type" to determine the interpretation 986 of the Value field. 988 3.2. Extended-Type-2 990 Description 992 This attribute encapsulates attributes of the "Extended Type" 993 format, in the RADIUS Attribute Type Space of 242.{1-255}. 995 A summary of the Extended-Type-2 Attribute format is shown below. 996 The fields are transmitted from left to right. 998 0 1 2 3 999 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 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | Type | Length | Extended-Type | Value ... 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 Type 1006 242 for Extended-Type-2. 1008 Length 1010 >= 4 1012 Extended-Type 1014 The Extended-Type field is one octet. Up-to-date values of this 1015 field are specified in the 242.{1-255} RADIUS Attribute Type 1016 Space, according to the policies and rules described in Section 1017 10. Further definition of this field is given in Section 2.1, 1018 above. 1020 Value 1022 The Value field is one or more octets. Implementations not 1023 supporting this specification SHOULD support the field as 1024 undistinguished octets. 1026 Implementations supporting this specification MUST use the 1027 Identifier of "Type.Extended-Type" to determine the interpretation 1028 of the Value field 1030 3.3. Extended-Type-3 1032 Description 1034 This attribute encapsulates attributes of the "Extended Type" 1035 format, in the RADIUS Attribute Type Space of 243.{1-255}. 1037 A summary of the Extended-Type-3 Attribute format is shown below. 1038 The fields are transmitted from left to right. 1040 0 1 2 3 1041 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 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | Type | Length | Extended-Type | Value ... 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 Type 1048 243 for Extended-Type-3. 1050 Length 1052 >= 4 1054 Extended-Type 1056 The Extended-Type field is one octet. Up-to-date values of this 1057 field are specified in the 243.{1-255} RADIUS Attribute Type 1058 Space, according to the policies and rules described in Section 1059 10. Further definition of this field is given in Section 2.1, 1060 above. 1062 Value 1064 The Value field is one or more octets. Implementations not 1065 supporting this specification SHOULD support the field as 1066 undistinguished octets. 1068 Implementations supporting this specification MUST use the 1069 Identifier of "Type.Extended-Type" to determine the interpretation 1070 of the Value field. 1072 3.4. Extended-Type-4 1074 Description 1076 This attribute encapsulates attributes of the "Extended Type" 1077 format, in the RADIUS Attribute Type Space of 244.{1-255}. 1079 A summary of the Extended-Type-4 Attribute format is shown below. 1080 The fields are transmitted from left to right. 1082 0 1 2 3 1083 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 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | Type | Length | Extended-Type | Value ... 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 Type 1089 244 for Extended-Type-4. 1091 Length 1093 >= 4 1095 Extended-Type 1097 The Extended-Type field is one octet. Up-to-date values of this 1098 field are specified in the 244.{1-255} RADIUS Attribute Type 1099 Space, according to the policies and rules described in Section 1100 10. Further definition of this field is given in Section 2.1, 1101 above. 1103 Value 1105 The Value field is one or more octets. Implementations not 1106 supporting this specification SHOULD support the field as 1107 undistinguished octets. 1109 Implementations supporting this specification MUST use the 1110 Identifier of "Type.Extended-Type" to determine the interpretation 1111 of the Value Field. 1113 3.5. Long-Extended-Type-1 1115 Description 1117 This attribute encapsulates attributes of the "Long Extended Type" 1118 format, in the RADIUS Attribute Type Space of 245.{1-255}. 1120 A summary of the Long-Extended-Type-1 Attribute format is shown 1121 below. The fields are transmitted from left to right. 1123 0 1 2 3 1124 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 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | Type | Length | Extended-Type |M| Reserved | 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | Value ... 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 Type 1133 245 for Long-Extended-Type-1 1135 Length 1137 >= 5 1139 Extended-Type 1141 The Extended-Type field is one octet. Up-to-date values of this 1142 field are specified in the 245.{1-255} RADIUS Attribute Type 1143 Space, according to the policies and rules described in Section 1144 10. Further definition of this field is given in Section 2.1, 1145 above. 1147 M (More) 1149 The More field is one (1) bit in length, and indicates whether or 1150 not the current attribute contains "more" than 251 octets of data. 1151 Further definition of this field is given in Section 2.2, above. 1153 Reserved 1155 This field is 7 bits long, and is reserved for future use. 1156 Implementations MUST set it to zero (0) when encoding an attribute 1157 for sending in a packet. The contents SHOULD be ignored on 1158 reception. 1160 Value 1162 The Value field is one or more octets. Implementations not 1163 supporting this specification SHOULD support the field as 1164 undistinguished octets. 1166 Implementations supporting this specification MUST use the 1167 Identifier of "Type.Extended-Type" to determine the interpretation 1168 of the Value field. 1170 3.6. Long-Extended-Type-2 1172 Description 1174 This attribute encapsulates attributes of the "Long Extended Type" 1175 format, in the RADIUS Attribute Type Space of 246.{1-255}. 1177 A summary of the Long-Extended-Type-2 Attribute format is shown 1178 below. The fields are transmitted from left to right. 1180 0 1 2 3 1181 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 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | Type | Length | Extended-Type |M| Reserved | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | Value ... 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 Type 1190 246 for Long-Extended-Type-2 1192 Length 1194 >= 5 1196 Extended-Type 1198 The Extended-Type field is one octet. Up-to-date values of this 1199 field are specified in the 246.{1-255} RADIUS Attribute Type 1200 Space, according to the policies and rules described in Section 1201 10. Further definition of this field is given in Section 2.1, 1202 above. 1204 M (More) 1206 The More field is one (1) bit in length, and indicates whether or 1207 not the current attribute contains "more" than 251 octets of data. 1208 Further definition of this field is given in Section 2.2, above. 1210 Reserved 1212 This field is 7 bits long, and is reserved for future use. 1213 Implementations MUST set it to zero (0) when encoding an attribute 1214 for sending in a packet. The contents SHOULD be ignored on 1215 reception. 1217 Value 1219 The Value field is one or more octets. Implementations not 1220 supporting this specification SHOULD support the field as 1221 undistinguished octets. 1223 Implementations supporting this specification MUST use the 1224 Identifier of "Type.Extended-Type" to determine the interpretation 1225 of the Value field. 1227 4. Vendor Specific Attributes 1229 We define six new attributes which can carry Vendor Specific 1230 information. We define four (4) attributes of the "Extended Type" 1231 format, with Type codes (241.26, 242.26, 243.26, 244.26), using the 1232 "evs" data type. We also define two (2) attributes using "Long 1233 Extended Type" format, with Type codes (245.26, 246.26), which are of 1234 the "evs" data type. 1236 Type.Extended-Type Name 1237 ------------------ ---- 1238 241.26 Extended-Vendor-Specific-1 1239 242.26 Extended-Vendor-Specific-2 1240 243.26 Extended-Vendor-Specific-3 1241 244.26 Extended-Vendor-Specific-4 1242 245.26 Extended-Vendor-Specific-5 1243 246.26 Extended-Vendor-Specific-6 1245 The rest of this section gives a detailed definition for each 1246 Attribute based on the above summary. 1248 4.1. Extended-Vendor-Specific-1 1250 Description 1252 This attribute defines a RADIUS Type Code of 241.26, using the 1253 "evs" data type. 1255 A summary of the Extended-Vendor-Specific-1 Attribute format is shown 1256 below. The fields are transmitted from left to right. 1258 0 1 2 3 1259 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 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | Type | Length | Extended-Type | Vendor-Id ... 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 ... Vendor-Id (cont) | Vendor-Type | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 | Value .... 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 Type.Extended-Type 1270 241.26 for Extended-Vendor-Specific-1 1272 Length 1274 >= 9 1276 Vendor-Id 1278 The 4 octets are the Network Management Private Enterprise Code 1280 [PEN] of the Vendor in network byte order. 1282 Vendor-Type 1284 The Vendor-Type field is one octet. Values are assigned at the 1285 sole discretion of the Vendor. 1287 Value 1289 The Value field is one or more octets. The actual format of the 1290 information is site or application specific, and a robust 1291 implementation SHOULD support the field as undistinguished octets. 1293 The codification of the range of allowed usage of this field is 1294 outside the scope of this specification. 1296 The length of the Value field is eight (8) less than the value of 1297 the Length field. 1299 Implementations supporting this specification MUST use the 1300 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1301 determine the interpretation of the Value field. 1303 4.2. Extended-Vendor-Specific-2 1305 Description 1307 This attribute defines a RADIUS Type Code of 242.26, using the 1308 "evs" data type. 1310 A summary of the Extended-Vendor-Specific-2 Attribute format is shown 1311 below. The fields are transmitted from left to right. 1313 0 1 2 3 1314 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 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 | Type | Length | Extended-Type | Vendor-Id ... 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 ... Vendor-Id (cont) | Vendor-Type | 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 | Value .... 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 Type.Extended-Type 1325 242.26 for Extended-Vendor-Specific-2 1327 Length 1328 >= 9 1330 Vendor-Id 1332 The 4 octets are the Network Management Private Enterprise Code 1333 [PEN] of the Vendor in network byte order. 1335 Vendor-Type 1337 The Vendor-Type field is one octet. Values are assigned at the 1338 sole discretion of the Vendor. 1340 Value 1342 The Value field is one or more octets. The actual format of the 1343 information is site or application specific, and a robust 1344 implementation SHOULD support the field as undistinguished octets. 1346 The codification of the range of allowed usage of this field is 1347 outside the scope of this specification. 1349 The length of the Value field is eight (8) less than the value of 1350 the Length field. 1352 Implementations supporting this specification MUST use the 1353 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1354 determine the interpretation of the Value field. 1356 4.3. Extended-Vendor-Specific-3 1358 Description 1360 This attribute defines a RADIUS Type Code of 243.26, using the 1361 "evs" data type. 1363 A summary of the Extended-Vendor-Specific-3 Attribute format is shown 1364 below. The fields are transmitted from left to right. 1366 0 1 2 3 1367 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 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 | Type | Length | Extended-Type | Vendor-Id ... 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 ... Vendor-Id (cont) | Vendor-Type | 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 | Value .... 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 Type.Extended-Type 1377 243.26 for Extended-Vendor-Specific-3 1379 Length 1381 >= 9 1383 Vendor-Id 1385 The 4 octets are the Network Management Private Enterprise Code 1386 [PEN] of the Vendor in network byte order. 1388 Vendor-Type 1390 The Vendor-Type field is one octet. Values are assigned at the 1391 sole discretion of the Vendor. 1393 Value 1395 The Value field is one or more octets. The actual format of the 1396 information is site or application specific, and a robust 1397 implementation SHOULD support the field as undistinguished octets. 1399 The codification of the range of allowed usage of this field is 1400 outside the scope of this specification. 1402 The length of the Value field is eight (8) less than the value of 1403 the Length field. 1405 Implementations supporting this specification MUST use the 1406 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1407 determine the interpretation of the Value field. 1409 4.4. Extended-Vendor-Specific-4 1411 Description 1413 This attribute defines a RADIUS Type Code of 244.26, using the 1414 "evs" data type. 1416 A summary of the Extended-Vendor-Specific-3 Attribute format is shown 1417 below. The fields are transmitted from left to right. 1419 0 1 2 3 1420 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 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 | Type | Length | Extended-Type | Vendor-Id ... 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 ... Vendor-Id (cont) | Vendor-Type | 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 | Value .... 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 Type.Extended-Type 1432 244.26 for Extended-Vendor-Specific-4 1434 Length 1436 >= 9 1438 Vendor-Id 1440 The 4 octets are the Network Management Private Enterprise Code 1441 [PEN] of the Vendor in network byte order. 1443 Vendor-Type 1445 The Vendor-Type field is one octet. Values are assigned at the 1446 sole discretion of the Vendor. 1448 Value 1450 The Value field is one or more octets. The actual format of the 1451 information is site or application specific, and a robust 1452 implementation SHOULD support the field as undistinguished octets. 1454 The codification of the range of allowed usage of this field is 1455 outside the scope of this specification. 1457 The length of the Value field is eight (8) less than the value of 1458 the Length field. 1460 Implementations supporting this specification MUST use the 1461 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1462 determine the interpretation of the Value field. 1464 4.5. Extended-Vendor-Specific-5 1466 Description 1468 This attribute defines a RADIUS Type Code of 245.26, using the 1469 "evs" data type. 1471 A summary of the Extended-Vendor-Specific-5 Attribute format is shown 1472 below. The fields are transmitted from left to right. 1474 0 1 2 3 1475 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 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 | Type | Length | Extended-Type |M| Reserved | 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 | Vendor-Id | 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1481 | Vendor-Type | Value .... 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 Type.Extended-Type 1486 245.26 for Extended-Vendor-Specific-5 1488 Length 1490 >= 10 (first fragment) 1491 >= 5 (subsequent fragments) 1493 When a VSA is fragmented across multiple Attributes, only the 1494 first Attribute contains the Vendor-Id and Vendor-Type fields. 1495 Subsequent Attributes contain fragments of the Value field only. 1497 M (More) 1499 The More field is one (1) bit in length, and indicates whether or 1500 not the current attribute contains "more" than 251 octets of data. 1501 Further definition of this field is given in Section 2.2, above. 1503 Reserved 1505 This field is 7 bits long, and is reserved for future use. 1506 Implementations MUST set it to zero (0) when encoding an attribute 1507 for sending in a packet. The contents SHOULD be ignored on 1508 reception. 1510 Vendor-Id 1512 The 4 octets are the Network Management Private Enterprise Code 1513 [PEN] of the Vendor in network byte order. 1515 Vendor-Type 1517 The Vendor-Type field is one octet. Values are assigned at the 1518 sole discretion of the Vendor. 1520 Value 1522 The Value field is one or more octets. The actual format of the 1523 information is site or application specific, and a robust 1524 implementation SHOULD support the field as undistinguished octets. 1526 The codification of the range of allowed usage of this field is 1527 outside the scope of this specification. 1529 Implementations supporting this specification MUST use the 1530 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1531 determine the interpretation of the Value field. 1533 4.6. Extended-Vendor-Specific-6 1535 Description 1537 This attribute defines a RADIUS Type Code of 246.26, using the 1538 "evs" data type. 1540 A summary of the Extended-Vendor-Specific-6 Attribute format is shown 1541 below. The fields are transmitted from left to right. 1543 0 1 2 3 1544 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 1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 | Type | Length | Extended-Type |M| Reserved | 1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1548 | Vendor-Id | 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 | Vendor-Type | Value .... 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 Type.Extended-Type 1555 246.26 for Extended-Vendor-Specific-6 1557 Length 1559 >= 10 (first fragment) 1560 >= 5 (subsequent fragments) 1562 When a VSA is fragmented across multiple Attributes, only the 1563 first Attribute contains the Vendor-Id and Vendor-Type fields. 1564 Subsequent Attributes contain fragments of the Value field only. 1566 M (More) 1567 The More field is one (1) bit in length, and indicates whether or 1568 not the current attribute contains "more" than 251 octets of data. 1569 Further definition of this field is given in Section 2.2, above. 1571 Reserved 1573 This field is 7 bits long, and is reserved for future use. 1574 Implementations MUST set it to zero (0) when encoding an attribute 1575 for sending in a packet. The contents SHOULD be ignored on 1576 reception. 1578 Vendor-Id 1580 The 4 octets are the Network Management Private Enterprise Code 1581 [PEN] of the Vendor in network byte order. 1583 Vendor-Type 1585 The Vendor-Type field is one octet. Values are assigned at the 1586 sole discretion of the Vendor. 1588 Value 1590 The Value field is one or more octets. The actual format of the 1591 information is site or application specific, and a robust 1592 implementation SHOULD support the field as undistinguished octets. 1594 The codification of the range of allowed usage of this field is 1595 outside the scope of this specification. 1597 Implementations supporting this specification MUST use the 1598 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1599 determine the interpretation of the Value field. 1601 5. Compatibility with traditional RADIUS 1603 There are a number of potential compatibility issues with traditional 1604 RADIUS, as defined in [RFC6158] and earlier. This section describes 1605 them. 1607 5.1. Attribute Allocation 1609 Some vendors have used Attribute Type codes from the "Reserved" 1610 space, as part of vendor-defined dictionaries. This practice is 1611 considered anti-social behavior, as noted in [RFC6158]. These vendor 1612 definitions conflict with the attributes in the RADIUS Attribute Type 1613 space. The conflicting definitions may make it difficult for 1614 implementations to support both those Vendor Attributes, and the new 1615 Extended Attribute formats. 1617 We RECOMMEND that RADIUS client and server implementations delete all 1618 references to these improperly defined attributes. Failing that, we 1619 RECOMMEND that RADIUS server implementations have a per-client 1620 configurable flag which indicates which type of attributes are being 1621 sent from the client. If the flag is set to "Non-Standard 1622 Attributes", the conflicting attributes can be interpreted as being 1623 improperly defined Vendor Specific Attributes. If the flag is set the 1624 "IETF Attributes", the attributes MUST be interpreted as being of the 1625 Extended Attributes format. The default SHOULD be to interpret the 1626 attributes as being of the Extended Attributes format. 1628 Other methods of determining how to decode the attributes into a 1629 "correct" form are NOT RECOMMENDED. Those methods are likely to be 1630 fragile and prone to error. 1632 We RECOMMEND that RADIUS server implementations re-use the above flag 1633 to determine which type of attributes to send in a reply message. If 1634 the request is expected to contain the improperly defined attributes, 1635 the reply SHOULD NOT contain Extended Attributes. If the request is 1636 expected to contain Extended Attributes, the reply MUST NOT contain 1637 the improper Attributes. 1639 RADIUS clients will have fewer issues than servers. Clients MUST NOT 1640 send improperly defined Attributes in a request. For replies, 1641 clients MUST interpret attributes as being of the Extended Attributes 1642 format, instead of the improper definitions. These requirements 1643 impose no change in the RADIUS specifications, as such usage by 1644 vendors has always been in conflict with the standard requirements 1645 and the standards process. 1647 Existing clients that send these improperly defined attributes 1648 usually have a configuration setting which can disable this behavior. 1649 We RECOMMEND that vendors ship products with the default set to 1650 "disabled". We RECOMMEND that administrators set this flag to 1651 "disabled" on all equipment that they manage. 1653 5.2. Proxy Servers 1655 RADIUS Proxy servers will need to forward Attributes having the new 1656 format, even if they do not implement support for the encoding and 1657 decoding of those attributes. We remind implementors of the 1658 following text in [RFC2865] Section 2.3: 1660 The forwarding server MUST NOT change the order of any attributes 1661 of the same type, including Proxy-State. 1663 This requirement solves some of the issues related to proxying of the 1664 new format, but not all. The reason is that proxy servers are 1665 permitted to examine the contents of the packets that they forward. 1666 Many proxy implementations not only examine the attributes, but they 1667 refuse to forward attributes which they do not understand (i.e. 1668 attributes for which they have no local dictionary definitions). 1670 This practice is NOT RECOMMENDED. Proxy servers SHOULD forward 1671 attributes, even ones which they do not understand, or which are not 1672 in a local dictionary. When forwarded, these attributes SHOULD be 1673 sent verbatim, with no modifications or changes. This requirement 1674 includes "invalid attributes", as there may be some other system in 1675 the network which understands them. 1677 The only exception to this recommendation is when local site policy 1678 dictates that filtering of attributes has to occur. For example, a 1679 filter at a visited network may require removal of certain 1680 authorization rules which apply to the home network, but not to the 1681 visited network. This filtering can sometimes be done even when the 1682 contents of the attributes are unknown, such as when all Vendor- 1683 Specific Attributes are designated for removal. 1685 As seen in [EDUROAM] many proxies do not follow these practices for 1686 unknown Attributes. Some proxies filter out unknown attributes or 1687 attributes which have unexpected lengths (24%, 17/70), some truncate 1688 the attributes to the "expected" length (11%, 8/70), some discard the 1689 request entirely (1%, 1/70), with the rest (63%, 44/70) following the 1690 recommended practice of passing the attributes verbatim. It will be 1691 difficult to widely use the Extended Attributes format until all non- 1692 conformant proxies are fixed. We therefore RECOMMEND that all 1693 proxies which do not support the Extended Attributes (241 through 1694 246) define them as being of data type "string", and delete all other 1695 local definitions for those attributes. 1697 This last change should enable wider usage of the Extended Attributes 1698 format. 1700 6. Guidelines 1702 This specification proposes a number of changes to RADIUS, and 1703 therefore requires a set of guidelines, as has been done in 1704 [RFC6158]. These guidelines include suggestions around design, 1705 interaction with IANA, usage, and implementation of attributes using 1706 the new formats. 1708 6.1. Updates to RFC 6158 1710 This specification updates [RFC6158] by adding the data types "evs", 1711 "tlv" and "integer64"; defining them to be "basic" data types; and 1712 permitting their use subject to the restrictions outlined below. 1714 The recommendations for the use of the new data types and attribute 1715 formats are given below. 1717 6.2. Guidelines for Simple Data Types 1719 [RFC6158] Section A.2.1 says in part: 1721 * Unsigned integers of size other than 32 bits. 1722 SHOULD be replaced by an unsigned integer of 32 bits. There is 1723 insufficient justification to define a new size of integer. 1725 We update that specification to permit unsigned integers of 64 bits, 1726 for the reasons defined above in Section 2.5. The updated text is as 1727 follows: 1729 * Unsigned integers of size other than 32 or 64 bits. 1730 SHOULD be replaced by an unsigned integer of 32 or 64 bits. 1731 There is insufficient justification to define a new size 1732 of integer. 1734 That section later continues with the following list item: 1736 * Nested attribute-value pairs (AVPs). 1737 Attributes should be defined in a flat typespace. 1739 We update that specification to permit nested TLVs, as defined in 1740 this document: 1742 * Nested attribute-value pairs (AVPs) using the extended 1743 attribute format MAY be used. All other nested AVP or TLV 1744 formats MUST NOT be used. 1746 The [RFC6158] recommendations for "basic" data types apply to the 1747 three types listed above. All other recommendations given in 1748 [RFC6158] for "basic" data types remain unchanged. 1750 6.3. Guidelines for Complex Data Types 1752 [RFC6158] Section 2.1 says: 1754 Complex data types MAY be used in situations where they reduce 1755 complexity in non-RADIUS systems or where using the basic data 1757 types 1758 would be awkward (such as where grouping would be required in 1759 order 1760 to link related attributes). 1762 Since the extended attribute format allows for grouping of complex 1763 types via TLVs, the guidelines for complex data types need to be 1764 updated as follows: 1766 [RFC6158], Section 3.2.4, describes situations in which complex 1767 data types might be appropriate. They SHOULD NOT be used even in 1768 those situations, without careful consideration of the described 1769 limitations. In all other cases not covered by the complex data 1770 type exceptions, complex data types MUST NOT be used. Instead, 1771 complex data types MUST be decomposed into TLVs. 1773 The checklist in Appendix A.2.2 is similarly updated to add a new 1774 requirement at the top of that section, 1776 Does the attribute: 1778 * define a complex type which can be represented via TLVs? 1780 If so, this data type MUST be represented via TLVs. 1782 Note that this requirement does not over-ride Section A.1, which 1783 permits the transport of complex types in certain situations. 1785 All other recommendations given in [RFC6158] for "complex" data types 1786 remain unchanged. 1788 6.4. Design Guidelines For the New Types 1790 This section gives design guidelines for specifications defining 1791 attributes using the new format. The items listed below are not 1792 exhaustive. As experience is gained with the new formats, later 1793 specifications may define additional guidelines. 1795 * The data type "evs" MUST NOT be used for standard RADIUS 1796 Attributes, or for TLVs, or for VSAs. 1798 * The data type "tlv" SHOULD NOT be used for standard RADIUS 1799 attributes. 1801 * [RFC2866] "tagged" attributes MUST NOT be defined in the 1802 Extended-Type space. The "tlv" data type should be used instead 1803 to group attributes. 1805 * The "integer64" data type MAY be used in any RADIUS attribute. 1806 The use of 64-bit integers is NOT RECOMMENDED by [RFC6158], but 1807 their utility is now evident. 1809 * Any attribute which is allocated from the "long extended space" of 1810 data type "text", "string", or "tlv" can potentially carry more 1811 than 251 octets of data. Specifications defining such attributes 1812 SHOULD define a maximum length to guide implementations. 1814 All other recommendations given in [RFC6158] for attribute design 1815 guidelines apply to attributes using the "short extended space" and 1816 "long extended space". 1818 6.5. TLV Guidelines 1820 The following items give design guidelines for specifications using 1821 TLVs. 1823 * when multiple attributes are intended to be grouped or managed 1824 together, the use of TLVs to group related attributes is 1825 RECOMMENDED. 1827 * more than 4 layers (depth) of TLV nesting is NOT RECOMMENDED. 1829 * Interpretation of an attribute depends only on its type 1830 definition (e.g. Type.Extended-Type.TLV-Type), and 1831 not on its encoding or location in the RADIUS packet. 1833 * Where a group of TLVs is strictly defined, and not expected to 1834 change, and totals less than 247 octets of data, they SHOULD 1835 request allocation from the "short extended space". 1837 * Where a group of TLVs is loosely defined, or is expected to change, 1838 they SHOULD request allocation from the "long extended space". 1840 All other recommendations given in [RFC6158] for attribute design 1841 guidelines apply to attributes using the TLV format. 1843 6.6. Allocation Request Guidelines 1845 The following items give guidelines for allocation requests made in a 1846 RADIUS specification. 1848 * Discretion is RECOMMENDED when requesting allocation of attributes. 1849 The new space is much larger than the old one, but it is not 1850 infinite. 1852 * Specifications which allocate many attributes MUST NOT request that 1853 allocation be made from the standard space. That space is under 1854 allocation pressure, and the extended space is more suitable for 1855 large allocations. 1857 * Specifications which allocate many related attributes SHOULD define 1858 one or more TLVs to contain related attributes. 1860 * Specifications SHOULD request allocation from a specific space. 1861 The IANA considerations given in Section 9, below, give instruction 1862 to IANA, but authors should assist IANA where possible. 1864 * Specifications of an attribute which encodes 252 octets or less of 1865 data MAY request allocation from the "short extended space". 1867 * Specifications of an attribute which always encode less than 253 1868 octets of data MUST NOT request allocation from the long extended 1869 space. The standard space, or the short extended space MUST be 1870 used instead. 1872 * Specifications of an attribute which encodes 253 octets or more of 1873 data MUST request allocation from the "long extended space". 1875 * When the extended space is nearing exhaustion, a new specification 1876 will have to be written which requests allocation of one or more 1877 RADIUS Attributes from the "Reserved" portion of the standard 1878 space, values 247-255, using an appropriate format ("Short 1879 Extended Type", or "Long Extended Type") 1881 An allocation request made in a specification SHOULD use one of the 1882 following formats when allocating an attribute type code: 1884 * TBDn - request allocation of an attribute from the "standard 1885 space". The value "n" should be "1" or more, to track individual 1886 attributes which are to be allocated. 1888 * SHORT-TBDn - request allocation of an attribute from the "short 1889 extended space". The value "n" should be "1" or more, to track 1890 individual attributes which are to be allocated. 1892 * LONG-TBDn - request allocation of an attribute from the "long 1893 extended space". The value "n" should be "1" or more, to track 1894 individual attributes which are to be allocated. 1896 These guidelines should help specification authors and IANA 1897 communicate effectively and clearly. 1899 6.7. Allocation Requests Guidelines for TLVs 1901 Specifications may allocate a new attribute of type TLV, and at the 1902 same time, allocate sub-attributes within that TLV. These 1903 specifications SHOULD request allocation of specific values for the 1904 sub-TLV. The "dotted number" notation MUST be used. 1906 For example, a specification may request allocation of a TLV as 1907 SHORT-TBD1. Within that attribute, it could request allocation of 1908 three sub-TLVs, as SHORT-TBD1.1, SHORT-TBD1.2, and SHORT-TBD1.3. 1910 Specifications may request allocation of additional sub-TLVs within 1911 an existing attribute of type TLV. Those specifications SHOULD use 1912 the "TBDn" format for every entry in the "dotted number" notation. 1914 For example, a specification may request allocation within an 1915 existing TLV, with "dotted number" notation MM.NN. Within that 1916 attribute, the specification could request allocation of three sub- 1917 TLVs, as MM.NN.TBD1, MM.NN.TBD2, and MM.NN.TBD3. 1919 6.8. Implementation Guidelines 1921 * RADIUS client implementations SHOULD support this specification, 1922 in order to permit the easy deployment of specifications using 1923 the changes defined herein. 1925 * RADIUS server implementations SHOULD support this specification, 1926 in order to permit the easy deployment of specifications using 1927 the changes defined herein. 1929 * RADIUS proxy servers MUST follow the specifications in section 5.2 1931 6.9. Vendor Guidelines 1933 * Vendors SHOULD use the existing Vendor-Specific Attribute Type 1934 space in preference to the new Extended-Vendor-Specific 1935 attributes, as this specification may take time to become widely 1936 deployed. 1938 * Vendors SHOULD implement this specification. The changes to 1939 RADIUS are relatively small, and are likely to quickly be used 1940 in new specifications. 1942 7. Rationale for This Design 1944 The path to extending the RADIUS protocol has been long and arduous. 1945 A number of proposals have been made and discarded by the RADEXT 1946 working group. These proposals have been judged to be either too 1947 bulky, too complex, too simple, or to be unworkable in practice. We 1948 do not otherwise explain here why earlier proposals did not obtain 1949 working group consensus. 1951 The changes outlined here have the benefit of being simple, as the 1952 "Extended Type" format requires only a one octet change to the 1953 Attribute format. The downside is that the "Long Extended Type" 1954 format is awkward, and the 7 Reserved bits will likely never be used 1955 for anything. 1957 7.1. Attribute Audit 1959 An audit of almost five thousand publicly available attributes [ATTR] 1960 (2010), shows the statistics summarized below. The attributes include 1961 over 100 Vendor dictionaries, along with the IANA assigned 1962 attributes: 1964 Count Data Type 1965 ----- --------- 1966 2257 integer 1967 1762 text 1968 273 IPv4 Address 1969 225 string 1970 96 other data types 1971 35 IPv6 Address 1972 18 date 1973 10 integer64 1974 4 Interface Id 1975 3 IPv6 Prefix 1977 4683 Total 1979 The entries in the "Data Type" column are data types recommended by 1980 [RFC6158], along with "integer64". The "other data types" row 1981 encompasses all other data types, including complex data types and 1982 data types transporting opaque data. 1984 We see that over half of the attributes encode less than 16 octets of 1985 data. It is therefore important to have an extension mechanism which 1986 adds as little as possible to the size of these attributes. Another 1987 result is that the overwhelming majority of attributes use simple 1988 data types. 1990 Of the attributes defined above, 177 were declared as being inside of 1991 a TLV. This is approximately 4% of the total. We did not 1992 investigate whether additional attributes were defined in a flat name 1993 space, but could have been defined as being inside of a TLV. We 1994 expect that the number could be as high as 10% of attributes. 1996 Manual inspection of the dictionaries shows that approximately 20 (or 1997 0.5%) attributes have the ability to transport more than 253 octets 1998 of data. These attributes are divided between VSAs, and a small 1999 number of standard Attributes such as EAP-Message. 2001 The results of this audit and analysis is reflected in the design of 2002 the extended attributes. The extended format has minimal overhead, 2003 it permits TLVs, and it has support for "long" attributes. 2005 8. Diameter Considerations 2007 The attribute formats defined in this specification need to be 2008 transported in Diameter. While Diameter supports attributes longer 2009 than 253 octets and grouped attributes, we do not use that 2010 functionality here. Instead, we define the simplest possible 2011 encapsulation method. 2013 The new formats MUST be treated the same as traditional RADIUS 2014 attributes when converting from RADIUS to Diameter, or vice versa. 2015 That is, the new attribute space is not converted to any "extended" 2016 Diameter attribute space. Fragmented attributes are not converted to 2017 a single long Diameter attribute. The new EVS data types are not 2018 converted to Diameter attributes with the "V" bit set. 2020 In short, this document mandates no changes for existing RADIUS to 2021 Diameter, or Diameter to RADIUS gateways. 2023 9. Examples 2025 A few examples are presented here in order to illustrate the encoding 2026 of the new attribute formats. These examples are not intended to be 2027 exhaustive, as many others are possible. For simplicity, we do not 2028 show complete packets, only attributes. 2030 The examples are given using a domain-specific language implemented 2031 by the program given in Appendix A. The language is line oriented, 2032 and composed of a sequence of lines matching the grammar ([RFC5234]) 2033 given below: 2035 Identifier = 1*DIGIT *( "." 1*DIGIT ) 2037 HEXCHAR = HEXDIG HEXDIG 2039 STRING = DQUOTE 1*CHAR DQUOTE 2041 TLV = "{" SP 1*DIGIT SP DATA SP "}" 2042 DATA = (HEXCHAR *(SP HEXCHAR)) / (TLV *(SP TLV)) / STRING 2044 LINE = Identifier SP DATA 2046 The program has additional restrictions on its input that are not 2047 reflected in the above grammar. For example, the portions of the 2048 Identifier which refer to Type and Extended-Type are limited to 2049 values between 1 and 255. We trust that the source code in Appendix 2050 A is clear, and that these restrictions do not negatively affect the 2051 comprehensibility of the examples. 2053 The program reads the input text, and interprets it as a set of 2054 instructions to create RADIUS Attributes. It then prints the hex 2055 encoding of those attributes. It implements the minimum set of 2056 functionality which achieves that goal. This minimalism means that 2057 it does not use attribute dictionaries; it does not implement support 2058 for RADIUS data types; it can be used to encode attributes with 2059 invalid data fields; and there is no requirement for consistency from 2060 one example to the next. For example, it can be used to encode a 2061 User-Name attribute which contains non-UTF8 data, or a Framed-IP- 2062 Address which contains 253 octets of ASCII data. As a result, it 2063 MUST NOT be used to create RADIUS Attributes for transport in a 2064 RADIUS message. 2066 However, the program correctly encodes the RADIUS attribute fields of 2067 "Type", "Length", "Extended-Type", "More", "Reserved", "Vendor-Id", 2068 "Vendor-Type", and "Vendor-Length". It encodes RADIUS attribute data 2069 types "evs" and TLV. It can therefore be used to encode example 2070 attributes from inputs which are humanly readable. 2072 We do not give examples of "malformed" or "invalid attributes". We 2073 also note that the examples show format, rather than consistent 2074 meaning. A particular Attribute Type code may be used to demonstrate 2075 two different formats. In real specifications, attributes have a 2076 static definitions based on their type code. 2078 The examples given below are strictly for demonstration purposes 2079 only, and do not provide a standard of any kind. 2081 9.1. Extended Type 2083 The following are a series of examples of the "Extended Type" format. 2085 Attribute encapsulating textual data. 2087 241.1 "bob" 2088 -> f1 06 01 62 6f 62 2090 Attribute encapsulating a TLV with TLV-Type of one (1). 2092 241.2 { 1 23 45 } 2093 -> f1 07 02 01 04 23 45 2095 Attribute encapsulating two TLVs, one after the other. 2097 241.2 { 1 23 45 } { 2 67 89 } 2098 -> f1 0b 02 01 04 23 45 02 04 67 89 2100 Attribute encapsulating two TLVs, where the second TLV is itself 2101 encapsulating a TLV. 2103 241.2 { 1 23 45 } { 3 { 1 ab cd } } 2104 -> f1 0d 02 01 04 23 45 03 06 01 04 ab cd 2106 Attribute encapsulating two TLVs, where the second TLV is itself 2107 encapsulating two TLVs. 2109 241.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } 2110 -> f1 12 02 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f 2112 Attribute encapsulating a TLV, which in turn encapsulates a TLV, 2113 to a depth of 5 nestings. 2115 241.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } 2116 -> f1 0f 01 01 0c 02 0a 03 08 04 06 05 04 cd ef 2118 Attribute encapsulating an extended Vendor Specific attribute, 2119 with Vendor-Id of 1, and Vendor-Type of 4, which in turn 2120 encapsulates textual data. 2122 241.26.1.4 "test" 2123 -> f1 0c 1a 00 00 00 01 04 74 65 73 74 2125 Attribute encapsulating an extended Vendor Specific attribute, with 2126 Vendor-Id of 1, and Vendor-Type of 5, which in turn encapsulates 2127 a TLV with TLV-Type of 3, which encapsulates textual data. 2129 241.26.1.5 { 3 "test" } 2130 -> f1 0e 1a 00 00 00 01 05 03 06 74 65 73 74 2132 9.2. Long Extended Type 2134 The following are a series of examples of the "Long Extended Type" 2135 format. 2137 Attribute encapsulating textual data. 2139 245.1 "bob" 2140 -> f5 07 01 00 62 6f 62 2142 Attribute encapsulating a TLV with TLV-Type of one (1). 2144 245.2 { 1 23 45 } 2145 -> f5 08 02 00 01 04 23 45 2147 Attribute encapsulating two TLVs, one after the other. 2149 245.2 { 1 23 45 } { 2 67 89 } 2150 -> f5 0c 02 00 01 04 23 45 02 04 67 89 2152 Attribute encapsulating two TLVs, where the second TLV is itself 2153 encapsulating a TLV. 2155 245.2 { 1 23 45 } { 3 { 1 ab cd } } 2156 -> f5 0e 02 00 01 04 23 45 03 06 01 04 ab cd 2158 Attribute encapsulating two TLVs, where the second TLV is itself 2159 encapsulating two TLVs. 2161 245.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } 2162 -> f5 13 02 00 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f 2164 Attribute encapsulating a TLV, which in turn encapsulates a TLV, 2165 to a depth of 5 nestings. 2167 245.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } 2168 -> f5 10 01 00 01 0c 02 0a 03 08 04 06 05 04 cd ef 2170 Attribute encapsulating an extended Vendor Specific attribute, 2171 with Vendor-Id of 1, and Vendor-Type of 4, which in turn 2172 encapsulates textual data. 2174 245.26.1.4 "test" 2175 -> f5 0d 1a 00 00 00 00 01 04 74 65 73 74 2177 Attribute encapsulating an extended Vendor Specific attribute, 2178 with Vendor-Id of 1, and Vendor-Type of 5, which in turn 2179 encapsulates a TLV with TLV-Type of 3, which encapsulates 2180 textual data. 2182 245.26.1.5 { 3 "test" } 2183 -> f5 0f 1a 00 00 00 00 01 05 03 06 74 65 73 74 2185 Attribute encapsulating more than 251 octets of data. The "Data" 2186 portions are indented for readability. 2188 245.4 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2189 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2190 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2191 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2192 aaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2193 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2194 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2195 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2196 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbcccccccccccccccccccc 2197 ccccccccccc" 2198 -> f5 ff 04 80 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2199 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2200 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2201 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2202 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2203 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2204 aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb bb bb bb bb bb 2205 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2206 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2207 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2208 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2209 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2210 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 13 04 00 cc 2211 cc cc cc cc cc cc cc cc cc cc cc cc cc cc 2213 Attribute encapsulating an extended Vendor Specific attribute, 2214 with Vendor-Id of 1, and Vendor-Type of 6, which in turn 2215 encapsulates more than 251 octets of data. 2217 As the VSA encapsulates more than 251 octets of data, it is 2218 split into two RADIUS attributes. The first attribute has the 2219 More field set, and carries the Vendor-Id and Vendor-Type. 2220 The second attribute has the More field clear, and carries 2221 the rest of the data portion of the VSA. Note that the second 2222 attribute does not include the Vendor-Id ad Vendor-Type fields. 2224 The "Data" portions are indented for readability. 2226 245.26.1.6 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2227 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2228 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2229 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2230 aaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2231 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2232 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2233 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2234 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbccccccccccccc 2235 ccccccccccccccccc" 2236 -> f5 ff 1a 80 00 00 00 01 06 aa aa aa aa aa aa aa aa aa aa aa 2237 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2238 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2239 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2240 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2241 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2242 aa aa aa aa aa aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb 2243 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2244 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2245 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2246 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2247 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2248 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 18 1a 00 bb 2249 bb bb bb bb cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 2251 10. IANA Considerations 2253 This document updates [RFC3575] in that it adds new IANA 2254 considerations for RADIUS Attributes. These considerations modify 2255 and extend the IANA considerations for RADIUS, rather than replacing 2256 them. 2258 The IANA considerations of this document are limited to the "RADIUS 2259 Attribute Types" registry. Some Attribute Type values which were 2260 previously marked "Reserved" are now allocated, and the registry is 2261 extended from a simple 8-bit array to a tree-like structure, up to a 2262 maximum depth of 125 nodes. Detailed instructions are given below. 2264 10.1. Attribute Allocations 2266 IANA is requested to move the following Attribute Type values from 2267 "Reserved", to "Allocated", with the corresponding names: 2269 * 241 Extended-Type-1 2270 * 242 Extended-Type-2 2271 * 243 Extended-Type-3 2272 * 244 Extended-Type-4 2273 * 245 Long-Extended-Type-1 2274 * 246 Long-Extended-Type-2 2276 These values serve as an encapsulation layer for the new RADIUS 2277 Attribute Type tree. 2279 10.2. RADIUS Attribute Type Tree 2281 Each of the Attribute Type values allocated above extends the "RADIUS 2282 Attribute Types" to an N-ary tree, via a "dotted number" notation. 2283 Allocation of an Attribute Type value "TYPE" using the new Extended 2284 type format results in allocation of 255 new Attribute Type values, 2285 of format "TYPE.1" through "TYPE.255". Value twenty-six (26) is 2286 assigned as "Extended-Vendor-Specific-*". Values "TYPE.241" through 2287 "TYPE.255" are marked "Reserved". All other values are "Unassigned". 2289 The initial set of Attribute Type values and names assigned by this 2290 document is given below. 2292 * 241 Extended-Attribute-1 2293 * 241.{1-25} Unassigned 2294 * 241.26 Extended-Vendor-Specific-1 2295 * 241.{27-240} Unassigned 2296 * 241.{241-255} Reserved 2297 * 242 Extended-Attribute-2 2298 * 242.{1-25} Unassigned 2299 * 242.26 Extended-Vendor-Specific-2 2300 * 242.{27-240} Unassigned 2301 * 243 Extended-Attribute-3 2302 * 242.{241-255} Reserved 2303 * 243.{1-25} Unassigned 2304 * 243.26 Extended-Vendor-Specific-3 2305 * 243.{27-240} Unassigned 2306 * 243.{241-255} Reserved 2307 * 244 Extended-Attribute-4 2308 * 244.{1-25} Unassigned 2309 * 244.26 Extended-Vendor-Specific-4 2310 * 244.{27-240} Unassigned 2311 * 244.{241-255} Reserved 2312 * 245 Extended-Attribute-5 2313 * 245.{1-25} Unassigned 2314 * 245.26 Extended-Vendor-Specific-5 2315 * 245.{27-240} Unassigned 2316 * 245.{241-255} Reserved 2317 * 246 Extended-Attribute-6 2318 * 246.{1-25} Unassigned 2319 * 245.26 Extended-Vendor-Specific-6 2320 * 246.{27-240} Unassigned 2321 * 246.{241-255} Reserved 2323 As per [RFC5226], the values marked "Unassigned" above are available 2324 via for assignment by IANA in future RADIUS specifications. The 2325 values marked "Reserved" are reserved for future use. 2327 The Extended-Vendor-Specific spaces (TYPE.26) are for Private Use, 2328 and allocations are not managed by IANA. 2330 Allocation of Reserved entries in the extended space requires 2331 Standards Action. 2333 All other allocations in the extended space require IETF Review. 2335 10.3. Allocation Instructions 2337 This section defines what actions IANA needs to take when allocating 2338 new attributes. Different actions are required when allocating 2339 attributes from the standard space, attributes of Extended Type 2340 format, attributes of the "Long Extended Type" format, preferential 2341 allocations, attributes of data type TLV, attributes within a TLV, 2342 and attributes of other data types. 2344 10.3.1. Requested Allocation from the Standard Space 2346 Specifications can request allocation of an Attribute from within the 2347 standard space (e.g. Attribute Type Codes 1 through 255), subject to 2348 the considerations of [RFC3575] and this document. 2350 10.3.2. Requested Allocation from the short extended space 2352 Specifications can request allocation of an Attribute which requires 2353 the format Extended Type, by specifying the short extended space In 2354 that case, IANA should assign the lowest Unassigned number from the 2355 Attribute Type space with the relevant format. 2357 10.3.3. Requested Allocation from the long extended space 2359 Specifications can request allocation of an Attribute which requires 2360 the format "Long Extended Type", by specifying the extended space 2361 (long). In that case, IANA should assign the lowest Unassigned 2362 number from the Attribute Type space with the relevant format. 2364 10.3.4. Allocation Preferences 2366 Specifications which make no request for allocation from a specific 2367 Type Space should have Attributes allocated using the following 2368 criteria: 2370 * when the standard space has no more Unassigned attributes, 2371 all allocations should be performed from the extended space. 2373 * specifications which allocate a small number of attributes 2374 (i.e. less than ten) should have all allocations made from 2375 the standard space. 2377 * specifications which would allocate a more than twenty percent 2378 of 2379 the remaining standard space attributes should have all 2380 allocations made from the extended space. 2382 * specifications which request allocation of an attribute of 2383 data type TLV should have that attribute allocated from the 2384 extended space. 2386 * specifications which request allocation of an attribute 2387 which can transport 253 or more octets of data should have 2388 that attribute allocated from within the long extended space, 2389 We note that Section 6.5, above requires specifications to 2390 request this allocation. 2392 There is otherwise no requirement that all attributes within a 2393 specification be allocated from one type space or another. 2394 Specifications can simultaneously allocate attributes from both the 2395 standard space and the extended space. 2397 10.3.5. Extending the Type Space via TLV Data Type 2399 When specifications request allocation of an attribute of data type 2400 "tlv", that allocation extends the Attribute Type Tree by one more 2401 level. Allocation of an Attribute Type value "TYPE.TLV", with Data 2402 Type TLV, results in allocation of 255 new Attribute Type values, of 2403 format "TYPE.TLV.1" through "TYPE.TLV.255". Values 254-255 are 2404 marked "Reserved". All other values are "Unassigned". Value 26 has 2405 no special meaning. 2407 For example, if a new attribute "Example-TLV" of data type "tlv" is 2408 assigned the identifier "245.1", then the extended tree will be 2409 allocated as below: 2411 * 245.1 Example-TLV 2412 * 245.1.{1-253} Unassigned 2413 * 245.1.{254-255} Reserved 2415 Note that this example does not define an "Example-TLV" attribute. 2417 The Attribute Type Tree can be extended multiple levels in one 2418 specification when the specification requests allocation of nested 2419 TLVs, as discussed below. 2421 10.3.6. Allocation within a TLV 2423 Specifications can request allocation of Attribute Type values within 2424 an Attribute of Data Type TLV. The encapsulating TLV can be 2425 allocated in the same specification, or it can have been previously 2426 allocated. 2428 Specifications need to request allocation within a specific Attribute 2429 Type value (e.g. "TYPE.TLV.*"). Allocations are performed from the 2430 smallest Unassigned value, proceeding to the largest Unassigned 2431 value. 2433 Where the Attribute being allocated is of Data Type TLV, the 2434 Attribute Type tree is extended by one level, as given in the 2435 previous section. Allocations can then be made within that level. 2437 10.3.7. Allocation of Other Data Types 2439 Attribute Type value allocations are otherwise allocated from the 2440 smallest Unassigned value, proceeding to the largest Unassigned 2441 value. e.g. Starting from 241.1, proceeding through 241.255, then to 2442 242.1, through 242.255, etc. 2444 11. Security Considerations 2446 This document defines new formats for data carried inside of RADIUS, 2447 but otherwise makes no changes to the security of the RADIUS 2448 protocol. 2450 Attacks on cryptographic hashes are well known, and are getting 2451 better with time, as discussed in [RFC4270]. The security of the 2452 RADIUS protocol is dependent on MD5 [RFC1311], which has security 2453 issues as discussed in [RFC6151]. It is not known if the issues 2454 described in [RFC6151] apply to RADIUS. For other issues, we 2455 incorporate by reference the security considerations of [RFC6158] 2456 Section 5. 2458 As with any protocol change, code changes are required in order to 2459 implement the new features. These code changes have the potential to 2460 introduce new vulnerabilities in the software. Since the RADIUS 2461 server performs network authentication, it is an inviting target for 2462 attackers. We RECOMMEND that access to RADIUS servers be kept to a 2463 minimum. 2465 12. References 2466 12.1. Normative references 2468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2469 Requirement Levels", RFC 2119, March, 1997. 2471 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 2472 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2473 2000. 2475 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 2477 [RFC3575] Aboba, B, "IANA Considerations for RADIUS (Remote 2478 Authentication Dial In User Service)", RFC 3575, July 2003. 2480 [RFC5176] Chiba, M, et. al., "Dynamic Authorization Extensions to Remote 2481 Authentication Dial In User Service (RADIUS)", RFC 5176, 2482 January 2008. 2484 [RFC5226] Narten, T. and Alvestrand, H, "Guidelines for Writing an IANA 2485 Considerations Section in RFCs", RFC 5226, May 2008. 2487 [RFC6158] DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC 2488 6158, March 2011. 2490 [PEN] http://www.iana.org/assignments/enterprise-numbers 2492 12.2. Informative references 2494 [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, 2495 April, 1992 2497 [RFC2868] Zorn, G., et al, " RADIUS Attributes for Tunnel Protocol 2498 Support", RFC 2868, June 2000. 2500 [RFC4270] Hoffman, P, and Schneier, B, "Attacks on Cryptographic Hashes 2501 in Internet Protocols", RFC 4270, November 2005. 2503 [RFC5234] Crocker, D. (Ed.), and Overell, P., "Augmented BNF for Syntax 2504 Specifications: ABNF", RFC 5234, October 2005. 2506 [RFC6151] Turner. S. and Chen, L., "Updated Security Considerations for 2507 the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, 2508 March 2011. 2510 [EDUROAM] Internal Eduroam testing page, data retrieved 04 August 2010. 2512 [ATTR] http://github.com/alandekok/freeradius- 2513 server/tree/master/share/, data retrieved September 2010. 2515 Acknowledgments 2517 This document is the result of long discussions in the IETF RADEXT 2518 working group. The authors would like to thank all of the 2519 participants who contributed various ideas over the years. Their 2520 feedback has been invaluable, and has helped to make this 2521 specification better. 2523 Appendix A - Extended Attribute Generator Program 2525 This section contains "C" program source which can be used for 2526 testing. It reads a line-oriented text file, parses it to create 2527 RADIUS formatted attributes, and prints the hex version of those 2528 attributes to standard output. 2530 The input accepts a grammar similar to that given in Section 9, with 2531 some modifications for usability. For example, blank lines are 2532 allowed, lines beginning with a '#' character are interpreted as 2533 comments, numbers (RADIUS Types, etc.) are checked for minimum / 2534 maximum values, and RADIUS Attribute lengths are enforced. 2536 The program is included here for demonstration purposes only, and 2537 does not define a standard of any kind. 2539 ------------------------------------------------------------ 2540 /* 2541 * Copyright (c) 2010 IETF Trust and the persons identified as 2542 * authors of the code. All rights reserved. 2543 * 2544 * Redistribution and use in source and binary forms, with or without 2545 * modification, are permitted provided that the following conditions 2546 * are met: 2547 * 2548 * Redistributions of source code must retain the above copyright 2549 * notice, this list of conditions and the following disclaimer. 2550 * 2551 * Redistributions in binary form must reproduce the above copyright 2552 * notice, this list of conditions and the following disclaimer in 2553 * the documentation and/or other materials provided with the 2554 * distribution. 2555 * 2556 * Neither the name of Internet Society, IETF or IETF Trust, nor the 2557 * names of specific contributors, may be used to endorse or promote 2558 * products derived from this software without specific prior written 2559 * permission. 2560 * 2561 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 2562 * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, 2563 * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 2564 * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 2565 * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS 2566 * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 2567 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED 2568 * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 2569 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON 2570 * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 2571 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT 2572 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 2573 * SUCH DAMAGE. 2574 * 2575 * Author: Alan DeKok 2576 */ 2577 #include 2578 #include 2579 #include 2580 #include 2581 #include 2582 #include 2584 static int encode_tlv(char *buffer, uint8_t *output, size_t outlen); 2586 static const char *hextab = "0123456789abcdef"; 2588 static int encode_data_string(char *buffer, 2589 uint8_t *output, size_t outlen) 2590 { 2591 int length = 0; 2592 char *p; 2594 p = buffer + 1; 2596 while (*p && (outlen > 0)) { 2597 if (*p == '"') { 2598 return length; 2599 } 2601 if (*p != '\\') { 2602 *(output++) = *(p++); 2603 outlen--; 2604 length++; 2605 continue; 2606 } 2608 switch (p[1]) { 2609 default: 2610 *(output++) = p[1]; 2611 break; 2613 case 'n': 2614 *(output++) = '\n'; 2615 break; 2617 case 'r': 2618 *(output++) = '\r'; 2619 break; 2621 case 't': 2622 *(output++) = '\t'; 2623 break; 2624 } 2626 outlen--; 2627 length++; 2628 } 2630 fprintf(stderr, "String is not terminated\n"); 2631 return 0; 2632 } 2634 static int encode_data_tlv(char *buffer, char **endptr, 2635 uint8_t *output, size_t outlen) 2636 { 2637 int depth = 0; 2638 int length; 2639 char *p; 2641 for (p = buffer; *p != '\0'; p++) { 2642 if (*p == '{') depth++; 2643 if (*p == '}') { 2644 depth--; 2645 if (depth == 0) break; 2646 } 2647 } 2649 if (*p != '}') { 2650 fprintf(stderr, "No trailing '}' in string starting " 2651 "with \"%s\"\n", 2652 buffer); 2653 return 0; 2654 } 2656 *endptr = p + 1; 2657 *p = '\0'; 2659 p = buffer + 1; 2660 while (isspace((int) *p)) p++; 2662 length = encode_tlv(p, output, outlen); 2663 if (length == 0) return 0; 2665 return length; 2666 } 2667 static int encode_data(char *p, uint8_t *output, size_t outlen) 2668 { 2669 int length; 2671 if (!isspace((int) *p)) { 2672 fprintf(stderr, "Invalid character following attribute " 2673 "definition\n"); 2674 return 0; 2675 } 2677 while (isspace((int) *p)) p++; 2679 if (*p == '{') { 2680 int sublen; 2681 char *q; 2683 length = 0; 2685 do { 2686 while (isspace((int) *p)) p++; 2687 if (!*p) { 2688 if (length == 0) { 2689 fprintf(stderr, "No data\n"); 2690 return 0; 2691 } 2693 break; 2694 } 2696 sublen = encode_data_tlv(p, &q, output, outlen); 2697 if (sublen == 0) return 0; 2699 length += sublen; 2700 output += sublen; 2701 outlen -= sublen; 2702 p = q; 2703 } while (*q); 2705 return length; 2706 } 2708 if (*p == '"') { 2709 length = encode_data_string(p, output, outlen); 2710 return length; 2711 } 2713 length = 0; 2714 while (*p) { 2715 char *c1, *c2; 2717 while (isspace((int) *p)) p++; 2719 if (!*p) break; 2721 if(!(c1 = memchr(hextab, tolower((int) p[0]), 16)) || 2722 !(c2 = memchr(hextab, tolower((int) p[1]), 16))) { 2723 fprintf(stderr, "Invalid data starting at " 2724 "\"%s\"\n", p); 2725 return 0; 2726 } 2728 *output = ((c1 - hextab) << 4) + (c2 - hextab); 2729 output++; 2730 length++; 2731 p += 2; 2733 outlen--; 2734 if (outlen == 0) { 2735 fprintf(stderr, "Too much data\n"); 2736 return 0; 2737 } 2738 } 2740 if (length == 0) { 2741 fprintf(stderr, "Empty string\n"); 2742 return 0; 2743 } 2745 return length; 2746 } 2748 static int decode_attr(char *buffer, char **endptr) 2749 { 2750 long attr; 2752 attr = strtol(buffer, endptr, 10); 2753 if (*endptr == buffer) { 2754 fprintf(stderr, "No valid number found in string " 2755 "starting with \"%s\"\n", buffer); 2756 return 0; 2757 } 2759 if (!**endptr) { 2760 fprintf(stderr, "Nothing follows attribute number\n"); 2761 return 0; 2762 } 2763 if ((attr <= 0) || (attr > 256)) { 2764 fprintf(stderr, "Attribute number is out of valid " 2765 "range\n"); 2766 return 0; 2767 } 2769 return (int) attr; 2770 } 2772 static int decode_vendor(char *buffer, char **endptr) 2773 { 2774 long vendor; 2776 if (*buffer != '.') { 2777 fprintf(stderr, "Invalid separator before vendor id\n"); 2778 return 0; 2779 } 2781 vendor = strtol(buffer + 1, endptr, 10); 2782 if (*endptr == (buffer + 1)) { 2783 fprintf(stderr, "No valid vendor number found\n"); 2784 return 0; 2785 } 2787 if (!**endptr) { 2788 fprintf(stderr, "Nothing follows vendor number\n"); 2789 return 0; 2790 } 2792 if ((vendor <= 0) || (vendor > (1 << 24))) { 2793 fprintf(stderr, "Vendor number is out of valid range\n"); 2794 return 0; 2795 } 2797 if (**endptr != '.') { 2798 fprintf(stderr, "Invalid data following vendor number\n"); 2799 return 0; 2800 } 2801 (*endptr)++; 2803 return (int) vendor; 2804 } 2806 static int encode_tlv(char *buffer, uint8_t *output, size_t outlen) 2807 { 2808 int attr; 2809 int length; 2810 char *p; 2811 attr = decode_attr(buffer, &p); 2812 if (attr == 0) return 0; 2814 output[0] = attr; 2815 output[1] = 2; 2817 if (*p == '.') { 2818 p++; 2819 length = encode_tlv(p, output + 2, outlen - 2); 2821 } else { 2822 length = encode_data(p, output + 2, outlen - 2); 2823 } 2825 if (length == 0) return 0; 2826 if (length > (255 - 2)) { 2827 fprintf(stderr, "TLV data is too long\n"); 2828 return 0; 2829 } 2831 output[1] += length; 2833 return length + 2; 2834 } 2836 static int encode_vsa(char *buffer, uint8_t *output, size_t outlen) 2837 { 2838 int vendor; 2839 int attr; 2840 int length; 2841 char *p; 2843 vendor = decode_vendor(buffer, &p); 2844 if (vendor == 0) return 0; 2846 output[0] = 0; 2847 output[1] = (vendor >> 16) & 0xff; 2848 output[2] = (vendor >> 8) & 0xff; 2849 output[3] = vendor & 0xff; 2851 length = encode_tlv(p, output + 4, outlen - 4); 2852 if (length == 0) return 0; 2853 if (length > (255 - 6)) { 2854 fprintf(stderr, "VSA data is too long\n"); 2855 return 0; 2856 } 2857 return length + 4; 2858 } 2860 static int encode_evs(char *buffer, uint8_t *output, size_t outlen) 2861 { 2862 int vendor; 2863 int attr; 2864 int length; 2865 char *p; 2867 vendor = decode_vendor(buffer, &p); 2868 if (vendor == 0) return 0; 2870 attr = decode_attr(p, &p); 2871 if (attr == 0) return 0; 2873 output[0] = 0; 2874 output[1] = (vendor >> 16) & 0xff; 2875 output[2] = (vendor >> 8) & 0xff; 2876 output[3] = vendor & 0xff; 2877 output[4] = attr; 2879 length = encode_data(p, output + 5, outlen - 5); 2880 if (length == 0) return 0; 2882 return length + 5; 2883 } 2885 static int encode_extended(char *buffer, 2886 uint8_t *output, size_t outlen) 2887 { 2888 int attr; 2889 int length; 2890 char *p; 2892 attr = decode_attr(buffer, &p); 2893 if (attr == 0) return 0; 2895 output[0] = attr; 2897 if (attr == 26) { 2898 length = encode_evs(p, output + 1, outlen - 1); 2899 } else { 2900 length = encode_data(p, output + 1, outlen - 1); 2901 } 2902 if (length == 0) return 0; 2903 if (length > (255 - 3)) { 2904 fprintf(stderr, "Extended Attr data is too long\n"); 2905 return 0; 2906 } 2908 return length + 1; 2909 } 2911 static int encode_extended_flags(char *buffer, 2912 uint8_t *output, size_t outlen) 2913 { 2914 int attr; 2915 int length, total; 2916 char *p; 2918 attr = decode_attr(buffer, &p); 2919 if (attr == 0) return 0; 2921 /* output[0] is the extended attribute */ 2922 output[1] = 4; 2923 output[2] = attr; 2924 output[3] = 0; 2926 if (attr == 26) { 2927 length = encode_evs(p, output + 4, outlen - 4); 2928 if (length == 0) return 0; 2930 output[1] += 5; 2931 length -= 5; 2932 } else { 2933 length = encode_data(p, output + 4, outlen - 4); 2934 } 2935 if (length == 0) return 0; 2937 total = 0; 2938 while (1) { 2939 int sublen = 255 - output[1]; 2941 if (length <= sublen) { 2942 output[1] += length; 2943 total += output[1]; 2944 break; 2945 } 2947 length -= sublen; 2949 memmove(output + 255 + 4, output + 255, length); 2950 memcpy(output + 255, output, 4); 2952 output[1] = 255; 2953 output[3] |= 0x80; 2955 output += 255; 2956 output[1] = 4; 2957 total += 255; 2958 } 2960 return total; 2961 } 2963 static int encode_rfc(char *buffer, uint8_t *output, size_t outlen) 2964 { 2965 int attr; 2966 int length, sublen; 2967 char *p; 2969 attr = decode_attr(buffer, &p); 2970 if (attr == 0) return 0; 2972 length = 2; 2973 output[0] = attr; 2974 output[1] = 2; 2976 if (attr == 26) { 2977 sublen = encode_vsa(p, output + 2, outlen - 2); 2979 } else if ((*p == ' ') || ((attr < 241) || (attr > 246))) { 2980 sublen = encode_data(p, output + 2, outlen - 2); 2982 } else { 2983 if (*p != '.') { 2984 fprintf(stderr, "Invalid data following " 2985 "attribute number\n"); 2986 return 0; 2987 } 2989 if (attr < 245) { 2990 sublen = encode_extended(p + 1, 2991 output + 2, outlen - 2); 2992 } else { 2994 /* 2995 * Not like the others! 2996 */ 2997 return encode_extended_flags(p + 1, output, outlen); 2998 } 2999 } 3000 if (sublen == 0) return 0; 3001 if (sublen > (255 -2)) { 3002 fprintf(stderr, "RFC Data is too long\n"); 3003 return 0; 3004 } 3006 output[1] += sublen; 3007 return length + sublen; 3008 } 3010 int main(int argc, char *argv[]) 3011 { 3012 int lineno; 3013 size_t i, outlen; 3014 FILE *fp; 3015 char input[8192], buffer[8192]; 3016 uint8_t output[4096]; 3018 if ((argc < 2) || (strcmp(argv[1], "-") == 0)) { 3019 fp = stdin; 3020 } else { 3021 fp = fopen(argv[1], "r"); 3022 if (!fp) { 3023 fprintf(stderr, "Error opening %s: %s\n", 3024 argv[1], strerror(errno)); 3025 exit(1); 3026 } 3027 } 3029 lineno = 0; 3030 while (fgets(buffer, sizeof(buffer), fp) != NULL) { 3031 char *p = strchr(buffer, '\n'); 3033 lineno++; 3035 if (!p) { 3036 if (!feof(fp)) { 3037 fprintf(stderr, "Line %d too long in %s\n", 3038 lineno, argv[1]); 3039 exit(1); 3040 } 3041 } else { 3042 *p = '\0'; 3043 } 3045 p = strchr(buffer, '#'); 3046 if (p) *p = '\0'; 3048 p = buffer; 3049 while (isspace((int) *p)) p++; 3050 if (!*p) continue; 3052 strcpy(input, p); 3053 outlen = encode_rfc(input, output, sizeof(output)); 3054 if (outlen == 0) { 3055 fprintf(stderr, "Parse error in line %d of %s\n", 3056 lineno, input); 3057 exit(1); 3058 } 3060 printf("%s -> ", buffer); 3061 for (i = 0; i < outlen; i++) { 3062 printf("%02x ", output[i]); 3063 } 3064 printf("\n"); 3065 } 3067 if (fp != stdin) fclose(fp); 3069 return 0; 3070 } 3071 ------------------------------------------------------------ 3073 Author's Address 3075 Alan DeKok 3076 Network RADIUS SARL 3077 57bis blvd des Alpes 3078 38240 Meylan 3079 France 3081 Email: aland@networkradius.com 3082 URI: http://networkradius.com 3084 Avi Lior 3085 Email: avi.ietf@lior.org