idnits 2.17.1 draft-ietf-radext-radius-extensions-11.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 (1 February 2013) is 4094 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 3023 -- Looks like a reference, but probably isn't: '0' on line 2958 -- Looks like a reference, but probably isn't: '2' on line 2908 -- Looks like a reference, but probably isn't: '3' on line 2938 -- Looks like a reference, but probably isn't: '4' on line 2862 -- Looks like a reference, but probably isn't: '8192' on line 3000 -- Looks like a reference, but probably isn't: '4096' on line 3001 == Unused Reference: 'RFC5176' is defined on line 2469, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2866 ** Downref: Normative reference to an Informational RFC: RFC 5176 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'PEN' Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 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 1, 2013 8 1 February 2013 10 Remote Authentication Dial In User Service (RADIUS) Protocol 11 Extensions 12 draft-ietf-radext-radius-extensions-11.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 ..................................... 22 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 ................................. 38 101 6.2. Guidelines for Simple Data Types .................... 38 102 6.3. Guidelines for Complex Data Types ................... 39 103 6.4. Design Guidelines For the New Types ................. 40 104 6.5. TLV Guidelines ...................................... 40 105 6.6. Allocation Request Guidelines ....................... 41 106 6.7. Allocation Requests Guidelines for TLVs ............. 42 107 6.8. Implementation Guidelines ........................... 43 108 6.9. Vendor Guidelines ................................... 43 109 7. Rationale for This Design ................................ 43 110 7.1. Attribute Audit ..................................... 43 111 8. Diameter Considerations .................................. 44 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 ......................... 50 118 10.3. Allocation Instructions ............................ 51 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 ....................... 53 125 10.3.7. Allocation of Other Data Types ................ 54 126 11. Security Considerations ................................. 54 127 12. References .............................................. 54 128 12.1. Normative references ............................... 54 129 12.2. Informative references ............................. 55 130 Appendix A - Extended Attribute Generator Program ............ 56 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 incenctive 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 RADIUS implementations which do not implement this specification. 295 Those implementations can simply ignore the Value field of an 296 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 fill 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 previously defined RADIUS 578 data type. Use of non-standard data types SHOULD NOT be done. We 579 note that the TLV-Value field MAY also contain one or more 580 attributes of data type "tlv", which allows for simple grouping 581 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 a set or a list 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 | String .... 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 String 688 The String field is one or more octets. It SHOULD encapsulate a 689 previously defined 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 "String" 706 field is implicit, and is determined by taking the "Length" of the 707 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 String field is eight (8) less 711 than the value of the Length field. For "Long Extended Type" 712 attributes, the length of the String field is nine (9) less than the 713 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 3. Attribute Definitions 922 We define four (4) attributes of "Extended Type", which are allocated 923 from the "Reserved" Attribute Type codes of 241, 242, 243, and 244. 924 We also define two (2) attributes of "Long Extended Type", which are 925 allocated from the "Reserved" Attribute Type codes of 245 and 246. 927 Type Name 928 ---- ---- 929 241 Extended-Type-1 930 242 Extended-Type-2 931 243 Extended-Type-3 932 244 Extended-Type-4 933 245 Long-Extended-Type-1 934 246 Long-Extended-Type-2 936 The rest of this section gives a detailed definition for each 937 Attribute based on the above summary. 939 3.1. Extended-Type-1 941 Description 943 This attribute encapsulates attributes of the "Extended Type" 944 format, in the RADIUS Attribute Type Space of 241.{1-255}. 946 A summary of the Extended-Type-1 Attribute format is shown below. 947 The fields are transmitted from left to right. 949 0 1 2 3 950 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 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | Type | Length | Extended-Type | Value ... 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 Type 957 241 for Extended-Type-1. 959 Length 961 >= 4 963 Extended-Type 965 The Extended-Type field is one octet. Up-to-date values of this 966 field are specified in the 241.{1-255} RADIUS Attribute Type 967 Space, according to the policies and rules described in Section 968 10. Further definition of this field is given in Section 2.1, 969 above. 971 Value 973 The Value field is one or more octets. Implementations not 974 supporting this specification SHOULD support the field as 975 undistinguished octets. 977 Implementations supporting this specification MUST use the 978 Identifier of "Type.Extended-Type" to determine the interpretation 979 of the Value field. 981 3.2. Extended-Type-2 983 Description 985 This attribute encapsulates attributes of the "Extended Type" 986 format, in the RADIUS Attribute Type Space of 242.{1-255}. 988 A summary of the Extended-Type-2 Attribute format is shown below. 989 The fields are transmitted from left to right. 991 0 1 2 3 992 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 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | Type | Length | Extended-Type | Value ... 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 Type 998 242 for Extended-Type-2. 1000 Length 1002 >= 4 1004 Extended-Type 1006 The Extended-Type field is one octet. Up-to-date values of this 1007 field are specified in the 242.{1-255} RADIUS Attribute Type 1008 Space, according to the policies and rules described in Section 1009 10. Further definition of this field is given in Section 2.1, 1010 above. 1012 Value 1014 The Value field is one or more octets. Implementations not 1015 supporting this specification SHOULD support the field as 1016 undistinguished octets. 1018 Implementations supporting this specification MUST use the 1019 Identifier of "Type.Extended-Type" to determine the interpretation 1020 of the Value field 1022 3.3. Extended-Type-3 1024 Description 1026 This attribute encapsulates attributes of the "Extended Type" 1027 format, in the RADIUS Attribute Type Space of 243.{1-255}. 1029 A summary of the Extended-Type-3 Attribute format is shown below. 1030 The fields are transmitted from left to right. 1032 0 1 2 3 1033 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | Type | Length | Extended-Type | Value ... 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 Type 1040 243 for Extended-Type-3. 1042 Length 1043 >= 4 1045 Extended-Type 1047 The Extended-Type field is one octet. Up-to-date values of this 1048 field are specified in the 243.{1-255} RADIUS Attribute Type 1049 Space, according to the policies and rules described in Section 1050 10. Further definition of this field is given in Section 2.1, 1051 above. 1053 Value 1055 The Value field is one or more octets. Implementations not 1056 supporting this specification SHOULD support the field as 1057 undistinguished octets. 1059 Implementations supporting this specification MUST use the 1060 Identifier of "Type.Extended-Type" to determine the interpretation 1061 of the Value field. 1063 3.4. Extended-Type-4 1065 Description 1067 This attribute encapsulates attributes of the "Extended Type" 1068 format, in the RADIUS Attribute Type Space of 244.{1-255}. 1070 A summary of the Extended-Type-4 Attribute format is shown below. 1071 The fields are transmitted from left to right. 1073 0 1 2 3 1074 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 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | Type | Length | Extended-Type | Value ... 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 Type 1081 244 for Extended-Type-4. 1083 Length 1085 >= 4 1087 Extended-Type 1089 The Extended-Type field is one octet. Up-to-date values of this 1090 field are specified in the 244.{1-255} RADIUS Attribute Type 1091 Space, according to the policies and rules described in Section 1092 10. Further definition of this field is given in Section 2.1, 1093 above. 1095 Value 1097 The Value field is one or more octets. Implementations not 1098 supporting this specification SHOULD support the field as 1099 undistinguished octets. 1101 Implementations supporting this specification MUST use the 1102 Identifier of "Type.Extended-Type" to determine the interpretation 1103 of the Value Field. 1105 3.5. Long-Extended-Type-1 1107 Description 1109 This attribute encapsulates attributes of the "Long Extended Type" 1110 format, in the RADIUS Attribute Type Space of 245.{1-255}. 1112 A summary of the Long-Extended-Type-1 Attribute format is shown 1113 below. The fields are transmitted from left to right. 1115 0 1 2 3 1116 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 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 | Type | Length | Extended-Type |M| Reserved | 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | Value ... 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 Type 1125 245 for Long-Extended-Type-1 1127 Length 1129 >= 5 1131 Extended-Type 1133 The Extended-Type field is one octet. Up-to-date values of this 1134 field are specified in the 245.{1-255} RADIUS Attribute Type 1135 Space, according to the policies and rules described in Section 1136 10. Further definition of this field is given in Section 2.1, 1137 above. 1139 M (More) 1141 The More field is one (1) bit in length, and indicates whether or 1142 not the current attribute contains "more" than 251 octets of data. 1143 Further definition of this field is given in Section 2.2, above. 1145 Reserved 1147 This field is 7 bits long, and is reserved for future use. 1148 Implementations MUST set it to zero (0) when encoding an attribute 1149 for sending in a packet. The contents SHOULD be ignored on 1150 reception. 1152 Value 1154 The Value field is one or more octets. Implementations not 1155 supporting this specification SHOULD support the field as 1156 undistinguished octets. 1158 Implementations supporting this specification MUST use the 1159 Identifier of "Type.Extended-Type" to determine the interpretation 1160 of the Value field. 1162 3.6. Long-Extended-Type-2 1164 Description 1166 This attribute encapsulates attributes of the "Long Extended Type" 1167 format, in the RADIUS Attribute Type Space of 246.{1-255}. 1169 A summary of the Long-Extended-Type-2 Attribute format is shown 1170 below. The fields are transmitted from left to right. 1172 0 1 2 3 1173 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 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 | Type | Length | Extended-Type |M| Reserved | 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 | Value ... 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 Type 1182 246 for Long-Extended-Type-2 1184 Length 1186 >= 5 1188 Extended-Type 1190 The Extended-Type field is one octet. Up-to-date values of this 1191 field are specified in the 246.{1-255} RADIUS Attribute Type 1192 Space, according to the policies and rules described in Section 1193 10. Further definition of this field is given in Section 2.1, 1194 above. 1196 M (More) 1198 The More field is one (1) bit in length, and indicates whether or 1199 not the current attribute contains "more" than 251 octets of data. 1200 Further definition of this field is given in Section 2.2, above. 1202 Reserved 1204 This field is 7 bits long, and is reserved for future use. 1205 Implementations MUST set it to zero (0) when encoding an attribute 1206 for sending in a packet. The contents SHOULD be ignored on 1207 reception. 1209 Value 1211 The Value field is one or more octets. Implementations not 1212 supporting this specification SHOULD support the field as 1213 undistinguished octets. 1215 Implementations supporting this specification MUST use the 1216 Identifier of "Type.Extended-Type" to determine the interpretation 1217 of the Value field. 1219 4. Vendor Specific Attributes 1221 We define six new attributes which can carry Vendor Specific 1222 information. We define four (4) attributes of the "Extended Type" 1223 format, with Type codes (241.26, 242.26, 243.26, 244.26), using the 1224 "evs" data type. We also define two (2) attributes using "Long 1225 Extended Type" format, with Type codes (245.26, 246.26), which are of 1226 the "evs" data type. 1228 Type.Extended-Type Name 1229 ------------------ ---- 1230 241.26 Extended-Vendor-Specific-1 1231 242.26 Extended-Vendor-Specific-2 1232 243.26 Extended-Vendor-Specific-3 1233 244.26 Extended-Vendor-Specific-4 1234 245.26 Extended-Vendor-Specific-5 1235 246.26 Extended-Vendor-Specific-6 1237 The rest of this section gives a detailed definition for each 1238 Attribute based on the above summary. 1240 4.1. Extended-Vendor-Specific-1 1242 Description 1244 This attribute defines a RADIUS Type Code of 241.26, using the 1245 "evs" data type. 1247 A summary of the Extended-Vendor-Specific-1 Attribute format is shown 1248 below. The fields are transmitted from left to right. 1250 0 1 2 3 1251 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 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 | Type | Length | Extended-Type | Vendor-Id ... 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 ... Vendor-Id (cont) | Vendor-Type | 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 | Value .... 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 Type.Extended-Type 1262 241.26 for Extended-Vendor-Specific-1 1264 Length 1266 >= 9 1268 Vendor-Id 1270 The 4 octets are the Network Management Private Enterprise Code 1271 [PEN] of the Vendor in network byte order. 1273 Vendor-Type 1275 The Vendor-Type field is one octet. Values are assigned at the 1276 sole discretion of the Vendor. 1278 Value 1280 The Value field is one or more octets. The actual format of the 1281 information is site or application specific, and a robust 1282 implementation SHOULD support the field as undistinguished octets. 1284 The codification of the range of allowed usage of this field is 1285 outside the scope of this specification. 1287 The length of the Value field is eight (8) less than the value of 1288 the Length field. 1290 Implementations supporting this specification MUST use the 1291 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1292 determine the interpretation of the Value field. 1294 4.2. Extended-Vendor-Specific-2 1296 Description 1298 This attribute defines a RADIUS Type Code of 242.26, using the 1299 "evs" data type. 1301 A summary of the Extended-Vendor-Specific-2 Attribute format is shown 1302 below. The fields are transmitted from left to right. 1304 0 1 2 3 1305 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 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 | Type | Length | Extended-Type | Vendor-Id ... 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 ... Vendor-Id (cont) | Vendor-Type | 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 | Value .... 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 Type.Extended-Type 1316 242.26 for Extended-Vendor-Specific-2 1318 Length 1320 >= 9 1322 Vendor-Id 1324 The 4 octets are the Network Management Private Enterprise Code 1325 [PEN] of the Vendor in network byte order. 1327 Vendor-Type 1329 The Vendor-Type field is one octet. Values are assigned at the 1330 sole discretion of the Vendor. 1332 Value 1333 The Value field is one or more octets. The actual format of the 1334 information is site or application specific, and a robust 1335 implementation SHOULD support the field as undistinguished octets. 1337 The codification of the range of allowed usage of this field is 1338 outside the scope of this specification. 1340 The length of the Value field is eight (8) less than the value of 1341 the Length field. 1343 Implementations supporting this specification MUST use the 1344 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1345 determine the interpretation of the Value field. 1347 4.3. Extended-Vendor-Specific-3 1349 Description 1351 This attribute defines a RADIUS Type Code of 243.26, using the 1352 "evs" data type. 1354 A summary of the Extended-Vendor-Specific-3 Attribute format is shown 1355 below. The fields are transmitted from left to right. 1357 0 1 2 3 1358 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 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 | Type | Length | Extended-Type | Vendor-Id ... 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 ... Vendor-Id (cont) | Vendor-Type | 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 | Value .... 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 Type.Extended-Type 1369 243.26 for Extended-Vendor-Specific-3 1371 Length 1373 >= 9 1375 Vendor-Id 1377 The 4 octets are the Network Management Private Enterprise Code 1378 [PEN] of the Vendor in network byte order. 1380 Vendor-Type 1381 The Vendor-Type field is one octet. Values are assigned at the 1382 sole discretion of the Vendor. 1384 Value 1386 The Value field is one or more octets. The actual format of the 1387 information is site or application specific, and a robust 1388 implementation SHOULD support the field as undistinguished octets. 1390 The codification of the range of allowed usage of this field is 1391 outside the scope of this specification. 1393 The length of the Value field is eight (8) less than the value of 1394 the Length field. 1396 Implementations supporting this specification MUST use the 1397 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1398 determine the interpretation of the Value field. 1400 4.4. Extended-Vendor-Specific-4 1402 Description 1404 This attribute defines a RADIUS Type Code of 244.26, using the 1405 "evs" data type. 1407 A summary of the Extended-Vendor-Specific-3 Attribute format is shown 1408 below. The fields are transmitted from left to right. 1410 0 1 2 3 1411 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 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 | Type | Length | Extended-Type | Vendor-Id ... 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 ... Vendor-Id (cont) | Vendor-Type | 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 | Value .... 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 Type.Extended-Type 1422 244.26 for Extended-Vendor-Specific-4 1424 Length 1426 >= 9 1428 Vendor-Id 1429 The 4 octets are the Network Management Private Enterprise Code 1430 [PEN] of the Vendor in network byte order. 1432 Vendor-Type 1434 The Vendor-Type field is one octet. Values are assigned at the 1435 sole discretion of the Vendor. 1437 Value 1439 The Value field is one or more octets. The actual format of the 1440 information is site or application specific, and a robust 1441 implementation SHOULD support the field as undistinguished octets. 1443 The codification of the range of allowed usage of this field is 1444 outside the scope of this specification. 1446 The length of the Value field is eight (8) less than the value of 1447 the Length field. 1449 Implementations supporting this specification MUST use the 1450 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1451 determine the interpretation of the Value field. 1453 4.5. Extended-Vendor-Specific-5 1455 Description 1457 This attribute defines a RADIUS Type Code of 245.26, using the 1458 "evs" data type. 1460 A summary of the Extended-Vendor-Specific-5 Attribute format is shown 1461 below. The fields are transmitted from left to right. 1463 0 1 2 3 1464 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 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 | Type | Length | Extended-Type |M| Reserved | 1467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 | Vendor-Id | 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 | Vendor-Type | Value .... 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 Type.Extended-Type 1475 245.26 for Extended-Vendor-Specific-5 1477 Length 1479 >= 10 (first fragment) 1480 >= 5 (subsequent fragments) 1482 When a VSA is fragmented across multiple Attributes, only the 1483 first Attribute contains the Vendor-Id and Vendor-Type fields. 1484 Subsequent Attributes contain fragments of the Value field only. 1486 M (More) 1488 The More field is one (1) bit in length, and indicates whether or 1489 not the current attribute contains "more" than 251 octets of data. 1490 Further definition of this field is given in Section 2.2, above. 1492 Reserved 1494 This field is 7 bits long, and is reserved for future use. 1495 Implementations MUST set it to zero (0) when encoding an attribute 1496 for sending in a packet. The contents SHOULD be ignored on 1497 reception. 1499 Vendor-Id 1501 The 4 octets are the Network Management Private Enterprise Code 1502 [PEN] of the Vendor in network byte order. 1504 Vendor-Type 1506 The Vendor-Type field is one octet. Values are assigned at the 1507 sole discretion of the Vendor. 1509 Value 1511 The Value field is one or more octets. The actual format of the 1512 information is site or application specific, and a robust 1513 implementation SHOULD support the field as undistinguished octets. 1515 The codification of the range of allowed usage of this field is 1516 outside the scope of this specification. 1518 Implementations supporting this specification MUST use the 1519 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1520 determine the interpretation of the Value field. 1522 4.6. Extended-Vendor-Specific-6 1524 Description 1526 This attribute defines a RADIUS Type Code of 246.26, using the 1527 "evs" data type. 1529 A summary of the Extended-Vendor-Specific-6 Attribute format is shown 1530 below. The fields are transmitted from left to right. 1532 0 1 2 3 1533 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 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 | Type | Length | Extended-Type |M| Reserved | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 | Vendor-Id | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 | Vendor-Type | Value .... 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1542 Type.Extended-Type 1544 246.26 for Extended-Vendor-Specific-6 1546 Length 1548 >= 10 (first fragment) 1549 >= 5 (subsequent fragments) 1551 When a VSA is fragmented across multiple Attributes, only the 1552 first Attribute contains the Vendor-Id and Vendor-Type fields. 1553 Subsequent Attributes contain fragments of the Value field only. 1555 M (More) 1557 The More field is one (1) bit in length, and indicates whether or 1558 not the current attribute contains "more" than 251 octets of data. 1559 Further definition of this field is given in Section 2.2, above. 1561 Reserved 1563 This field is 7 bits long, and is reserved for future use. 1564 Implementations MUST set it to zero (0) when encoding an attribute 1565 for sending in a packet. The contents SHOULD be ignored on 1566 reception. 1568 Vendor-Id 1569 The 4 octets are the Network Management Private Enterprise Code 1570 [PEN] of the Vendor in network byte order. 1572 Vendor-Type 1574 The Vendor-Type field is one octet. Values are assigned at the 1575 sole discretion of the Vendor. 1577 Value 1579 The Value field is one or more octets. The actual format of the 1580 information is site or application specific, and a robust 1581 implementation SHOULD support the field as undistinguished octets. 1583 The codification of the range of allowed usage of this field is 1584 outside the scope of this specification. 1586 Implementations supporting this specification MUST use the 1587 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1588 determine the interpretation of the Value field. 1590 5. Compatibility with traditional RADIUS 1592 There are a number of potential compatibility issues with traditional 1593 RADIUS, as defined in [RFC6158] and earlier. This section describes 1594 them. 1596 5.1. Attribute Allocation 1598 Some vendors have used Attribute Type codes from the "Reserved" 1599 space, as part of vendor-defined dictionaries. This practice is 1600 considered anti-social behavior, as noted in [RFC6158]. These vendor 1601 definitions conflict with the attributes in the RADIUS Attribute Type 1602 space. The conflicting definitions may make it difficult for 1603 implementations to support both those Vendor Attributes, and the new 1604 Extended Attribute formats. 1606 We RECOMMEND that RADIUS client and server implementations delete all 1607 references to these improperly defined attributes. Failing that, we 1608 RECOMMEND that RADIUS server implementations have a per-client 1609 configurable flag which indicates which type of attributes are being 1610 sent from the client. If the flag is set to "Non-Standard 1611 Attributes", the conflicting attributes can be interpreted as being 1612 improperly defined Vendor Specific Attributes. If the flag is set the 1613 "IETF Attributes", the attributes MUST be interpreted as being of the 1614 Extended Attributes format. The default SHOULD be to interpret the 1615 attributes as being of the Extended Attributes format. 1617 Other methods of determining how to decode the attributes into a 1618 "correct" form are NOT RECOMMENDED. Those methods are likely to be 1619 fragile and prone to error. 1621 We RECOMMEND that RADIUS server implementations re-use the above flag 1622 to determine which type of attributes to send in a reply message. If 1623 the request is expected to contain the improperly defined attributes, 1624 the reply SHOULD NOT contain Extended Attributes. If the request is 1625 expected to contain Extended Attributes, the reply MUST NOT contain 1626 the improper Attributes. 1628 RADIUS clients will have fewer issues than servers. Clients MUST NOT 1629 send improperly defined Attributes in a request. For replies, 1630 clients MUST interpret attributes as being of the Extended Attributes 1631 format, instead of the improper definitions. These requirements 1632 impose no change in the RADIUS specifications, as such usage by 1633 vendors has always been in conflict with the standard requirements 1634 and the standards process. 1636 Existing clients that send these improperly defined attributes 1637 usually have a configuration setting which can disable this behavior. 1638 We RECOMMEND that vendors ship products with the default set to 1639 "disabled". We RECOMMEND that administrators set this flag to 1640 "disabled" on all equipment that they manage. 1642 5.2. Proxy Servers 1644 RADIUS Proxy servers will need to forward Attributes having the new 1645 format, even if they do not implement support for the encoding and 1646 decoding of those attributes. We remind implementors of the 1647 following text in [RFC2865] Section 2.3: 1649 The forwarding server MUST NOT change the order of any attributes 1650 of the same type, including Proxy-State. 1652 This requirement solves some of the issues related to proxying of the 1653 new format, but not all. The reason is that proxy servers are 1654 permitted to examine the contents of the packets that they forward. 1655 Many proxy implementations not only examine the attributes, but they 1656 refuse to forward attributes which they do not understand (i.e. 1657 attributes for which they have no local dictionary definitions). 1659 This practice is NOT RECOMMENDED. Proxy servers SHOULD forward 1660 attributes, even ones which they do not understand, or which are not 1661 in a local dictionary. When forwarded, these attributes SHOULD be 1662 sent verbatim, with no modifications or changes. This requirement 1663 includes "invalid attributes", as there may be some other system in 1664 the network which understands them. 1666 The only exception to this recommendation is when local site policy 1667 dictates that filtering of attributes has to occur. For example, a 1668 filter at a visited network may require removal of certain 1669 authorization rules which apply to the home network, but not to the 1670 visited network. This filtering can sometimes be done even when the 1671 contents of the attributes are unknown, such as when all Vendor- 1672 Specific Attributes are designated for removal. 1674 As seen in [EDUROAM] many proxies do not follow these practices for 1675 unknown Attributes. Some proxies filter out unknown attributes or 1676 attributes which have unexpected lengths (24%, 17/70), some truncate 1677 the attributes to the "expected" length (11%, 8/70), some discard the 1678 request entirely (1%, 1/70), with the rest (63%, 44/70) following the 1679 recommended practice of passing the attributes verbatim. It will be 1680 difficult to widely use the Extended Attributes format until all non- 1681 conformant proxies are fixed. We therefore RECOMMEND that all 1682 proxies which do not support the Extended Attributes (241 through 1683 246) define them as being of data type "string", and delete all other 1684 local definitions for those attributes. 1686 This last change should enable wider usage of the Extended Attributes 1687 format. 1689 6. Guidelines 1691 This specification proposes a number of changes to RADIUS, and 1692 therefore requires a set of guidelines, as has been done in 1693 [RFC6158]. These guidelines include suggestions around design, 1694 interaction with IANA, usage, and implementation of attributes using 1695 the new formats. 1697 6.1. Updates to RFC 6158 1699 This specification updates [RFC6158] by adding the data types "evs", 1700 "tlv" and "integer64"; defining them to be "basic" data types; and 1701 permitting their use subject to the restrictions outlined below. 1703 The recommendations for the use of the new data types and attribute 1704 formats are given below. 1706 6.2. Guidelines for Simple Data Types 1708 [RFC6158] Section A.2.1 says in part: 1710 * Unsigned integers of size other than 32 bits. 1711 SHOULD be replaced by an unsigned integer of 32 bits. There is 1712 insufficient justification to define a new size of integer. 1714 We update that specification to permit unsigned integers of 64 bits, 1715 for the reasons defined above in Section 2.5. The updated text is as 1716 follows: 1718 * Unsigned integers of size other than 32 or 64 bits. 1719 SHOULD be replaced by an unsigned integer of 32 or 64 bits. 1720 There is insufficient justification to define a new size 1721 of integer. 1723 That section later continues with the following list item: 1725 * Nested attribute-value pairs (AVPs). 1726 Attributes should be defined in a flat typespace. 1728 We update that specification to permit nested TLVs, as defined in 1729 this document: 1731 * Nested attribute-value pairs (AVPs) using the extended 1732 attribute format MAY be used. All other nested AVP or TLV 1733 formats MUST NOT be used. 1735 The [RFC6158] recommendations for "basic" data types apply to the 1736 three types listed above. All other recommendations given in 1737 [RFC6158] for "basic" data types remain unchanged. 1739 6.3. Guidelines for Complex Data Types 1741 [RFC6158] Section 2.1 says: 1743 Complex data types MAY be used in situations where they reduce 1744 complexity in non-RADIUS systems or where using the basic data 1745 types 1746 would be awkward (such as where grouping would be required in 1747 order 1748 to link related attributes). 1750 Since the extended attribute format allows for grouping of complex 1751 types via TLVs, the guidelines for complex data types need to be 1752 updated as follows: 1754 [RFC6158], Section 3.2.4, describes situations in which complex 1755 data types might be appropriate. They SHOULD NOT be used even in 1756 those situations, without careful consideration of the described 1757 limitations. In all other cases not covered by the complex data 1758 type exceptions, complex data types MUST NOT be used. Instead, 1759 complex data types MUST be decomposed into TLVs. 1761 The checklist in Appendix A.2.2 is similarly updated to add a new 1762 requirement at the top of that section, 1764 Does the attribute: 1766 * define a complex type which can be represented via TLVs? 1768 If so, this data type MUST be represented via TLVs. 1770 Note that this requirement does not over-ride Section A.1, which 1771 permits the transport of complex types in certain situations. 1773 All other recommendations given in [RFC6158] for "complex" data types 1774 remain unchanged. 1776 6.4. Design Guidelines For the New Types 1778 This section gives design guidelines for specifications defining 1779 attributes using the new format. The items listed below are not 1780 exhaustive. As experience is gained with the new formats, later 1781 specifications may define additional guidelines. 1783 * The data type "evs" MUST NOT be used for standard RADIUS 1784 Attributes, or for TLVs, or for VSAs. 1786 * The data type "tlv" SHOULD NOT be used for standard RADIUS 1787 attributes. 1789 * [RFC2866] "tagged" attributes MUST NOT be defined in the 1790 Extended-Type space. The "tlv" data type should be used instead 1791 to group attributes. 1793 * The "integer64" data type MAY be used in any RADIUS attribute. 1794 The use of 64-bit integers is NOT RECOMMENDED by [RFC6158], but 1795 their utility is now evident. 1797 * Any attribute which is allocated from the "long extended space" of 1798 data type "text", "string", or "tlv" can potentially carry more 1799 than 251 octets of data. Specifications defining such attributes 1800 SHOULD define a maximum length to guide implementations. 1802 All other recommendations given in [RFC6158] for attribute design 1803 guidelines apply to attributes using the "short extended space" and 1804 "long extended space". 1806 6.5. TLV Guidelines 1808 The following items give design guidelines for specifications using 1809 TLVs. 1811 * when multiple attributes are intended to be grouped or managed 1812 together, the use of TLVs to group related attributes is 1813 RECOMMENDED. 1815 * more than 4 layers (depth) of TLV nesting is NOT RECOMMENDED. 1817 * Interpretation of an attribute depends only on its type 1818 definition (e.g. Type.Extended-Type.TLV-Type), and 1819 not on its encoding or location in the RADIUS packet. 1821 * Where a group of TLVs is strictly defined, and not expected to 1822 change, and totals less than 247 octets of data, they SHOULD 1823 request allocation from the "short extended space". 1825 * Where a group of TLVs is loosely defined, or is expected to change, 1826 they SHOULD request allocation from the "long extended space". 1828 All other recommendations given in [RFC6158] for attribute design 1829 guidelines apply to attributes using the TLV format. 1831 6.6. Allocation Request Guidelines 1833 The following items give guidelines for allocation requests made in a 1834 RADIUS specification. 1836 * Discretion is RECOMMENDED when requesting allocation of attributes. 1837 The new space is much larger than the old one, but it is not 1838 infinite. 1840 * Specifications which allocate many attributes MUST NOT request that 1841 allocation be made from the standard space. That space is under 1842 allocation pressure, and the extended space is more suitable for 1843 large allocations. 1845 * Specifications which allocate many related attributes SHOULD define 1846 one or more TLVs to contain related attributes. 1848 * Specifications SHOULD request allocation from a specific space. 1849 The IANA considerations given in Section 9, below, give instruction 1850 to IANA, but authors should assist IANA where possible. 1852 * Specifications of an attribute which encodes 252 octets or less of 1853 data MAY request allocation from the "short extended space". 1855 * Specifications of an attribute which always encode less than 253 1856 octets of data MUST NOT request allocation from the long extended 1857 space. The standard space, or the short extended space MUST be 1858 used instead. 1860 * Specifications of an attribute which encodes 253 octets or more of 1861 data MUST request allocation from the "long extended space". 1863 * When the extended space is nearing exhaustion, a new specification 1864 will have to be written which requests allocation of one or more 1865 RADIUS Attributes from the "Reserved" portion of the standard 1866 space, values 247-255, using an appropriate format ("Short 1867 Extended Type", or "Long Extended Type") 1869 An allocation request made in a specification SHOULD use one of the 1870 following formats when allocating an attribute type code: 1872 * TBDn - request allocation of an attribute from the "standard 1873 space". The value "n" should be "1" or more, to track individual 1874 attributes which are to be allocated. 1876 * SHORT-TBDn - request allocation of an attribute from the "short 1877 extended space". The value "n" should be "1" or more, to track 1878 individual attributes which are to be allocated. 1880 * LONG-TBDn - request allocation of an attribute from the "long 1881 extended space". The value "n" should be "1" or more, to track 1882 individual attributes which are to be allocated. 1884 These guidelines should help specification authors and IANA 1885 communicate effectively and clearly. 1887 6.7. Allocation Requests Guidelines for TLVs 1889 Specifications may allocate a new attribute of type TLV, and at the 1890 same time, allocate sub-attributes within that TLV. These 1891 specifications SHOULD request allocation of specific values for the 1892 sub-TLV. The "dotted number" notation MUST be used. 1894 For example, a specification may request allocation of a TLV as 1895 SHORT-TBD1. Within that attribute, it could request allocation of 1896 three sub-TLVs, as SHORT-TBD1.1, SHORT-TBD1.2, and SHORT-TBD1.3. 1898 Specifications may request allocation of additional sub-TLVs within 1899 an existing attribute of type TLV. Those specifications SHOULD use 1900 the "TBDn" format for every entry in the "dotted number" notation. 1902 For example, a specification may request allocation within an 1903 existing TLV, with "dotted number" notation MM.NN. Within that 1904 attribute, the specification could request allocation of three sub- 1905 TLVs, as MM.NN.TBD1, MM.NN.TBD2, and MM.NN.TBD3. 1907 6.8. Implementation Guidelines 1909 * RADIUS client implementations SHOULD support this specification, 1910 in order to permit the easy deployment of specifications using 1911 the changes defined herein. 1913 * RADIUS server implementations SHOULD support this specification, 1914 in order to permit the easy deployment of specifications using 1915 the changes defined herein. 1917 * RADIUS proxy servers MUST follow the specifications in section 5.2 1919 6.9. Vendor Guidelines 1921 * Vendors SHOULD use the existing Vendor-Specific Attribute Type 1922 space in preference to the new Extended-Vendor-Specific 1923 attributes, as this specification may take time to become widely 1924 deployed. 1926 * Vendors SHOULD implement this specification. The changes to 1927 RADIUS are relatively small, and are likely to quickly be used 1928 in new specifications. 1930 7. Rationale for This Design 1932 The path to extending the RADIUS protocol has been long and arduous. 1933 A number of proposals have been made and discarded by the RADEXT 1934 working group. These proposals have been judged to be either too 1935 bulky, too complex, too simple, or to be unworkable in practice. We 1936 do not otherwise explain here why earlier proposals did not obtain 1937 working group consensus. 1939 The changes outlined here have the benefit of being simple, as the 1940 "Extended Type" format requires only a one octet change to the 1941 Attribute format. The downside is that the "Long Extended Type" 1942 format is awkward, and the 7 Reserved bits will likely never be used 1943 for anything. 1945 7.1. Attribute Audit 1947 An audit of almost five thousand publicly available attributes [ATTR] 1948 (2010), shows the statistics summarized below. The attributes include 1949 over 100 Vendor dictionaries, along with the IANA assigned 1950 attributes: 1952 Count Data Type 1953 ----- --------- 1954 2257 integer 1955 1762 text 1956 273 IPv4 Address 1957 225 string 1958 96 other data types 1959 35 IPv6 Address 1960 18 date 1961 10 integer64 1962 4 Interface Id 1963 3 IPv6 Prefix 1965 4683 Total 1967 The entries in the "Data Type" column are data types recommended by 1968 [RFC6158], along with "integer64". The "other data types" row 1969 encompasses all other data types, including complex data types and 1970 data types transporting opaque data. 1972 We see that over half of the attributes encode less than 16 octets of 1973 data. It is therefore important to have an extension mechanism which 1974 adds as little as possible to the size of these attributes. Another 1975 result is that the overwhelming majority of attributes use simple 1976 data types. 1978 Of the attributes defined above, 177 were declared as being inside of 1979 a TLV. This is approximately 4% of the total. We did not 1980 investigate whether additional attributes were defined in a flat name 1981 space, but could have been defined as being inside of a TLV. We 1982 expect that the number could be as high as 10% of attributes. 1984 Manual inspection of the dictionaries shows that approximately 20 (or 1985 0.5%) attributes have the ability to transport more than 253 octets 1986 of data. These attributes are divided between VSAs, and a small 1987 number of standard Attributes such as EAP-Message. 1989 The results of this audit and analysis is reflected in the design of 1990 the extended attributes. The extended format has minimal overhead, 1991 it permits TLVs, and it has support for "long" attributes. 1993 8. Diameter Considerations 1995 The attribute formats defined in this specification need to be 1996 transported in Diameter. While Diameter supports attributes longer 1997 than 253 octets and grouped attributes, we do not use that 1998 functionality here. Instead, we define the simplest possible 1999 encapsulation method. 2001 The new formats MUST be treated the same as traditional RADIUS 2002 attributes when converting from RADIUS to Diameter, or vice versa. 2004 That is, the new attribute space is not converted to any "extended" 2005 Diameter attribute space. Fragmented attributes are not converted to 2006 a single long Diameter attribute. The new EVS data types are not 2007 converted to Diameter attributes with the "V" bit set. 2009 In short, this document mandates no changes for existing RADIUS to 2010 Diameter, or Diameter to RADIUS gateways. 2012 9. Examples 2014 A few examples are presented here in order to illustrate the encoding 2015 of the new attribute formats. These examples are not intended to be 2016 exhaustive, as many others are possible. For simplicity, we do not 2017 show complete packets, only attributes. 2019 The examples are given using a domain-specific language implemented 2020 by the program given in Appendix A. The language is line oriented, 2021 and composed of a sequence of lines matching the grammar ([RFC5234]) 2022 given below: 2024 Identifier = 1*DIGIT *( "." 1*DIGIT ) 2026 HEXCHAR = HEXDIG HEXDIG 2028 STRING = DQUOTE 1*CHAR DQUOTE 2030 TLV = "{" SP 1*DIGIT SP DATA SP "}" 2032 DATA = (HEXCHAR *(SP HEXCHAR)) / (TLV *(SP TLV)) / STRING 2034 LINE = Identifier SP DATA 2036 The program has additional restrictions on its input that are not 2037 reflected in the above grammar. For example, the portions of the 2038 Identifier which refer to Type and Extended-Type are limited to 2039 values between 1 and 255. We trust that the source code in Appendix 2040 A is clear, and that these restrictions do not negatively affect the 2041 comprehensibility of the examples. 2043 The program reads the input text, and interprets it as a set of 2044 instructions to create RADIUS Attributes. It then prints the hex 2045 encoding of those attributes. It implements the minimum set of 2046 functionality which achieves that goal. This minimalism means that 2047 it does not use attribute dictionaries; it does not implement support 2048 for RADIUS data types; it can be used to encode attributes with 2049 invalid data fields; and there is no requirement for consistency from 2050 one example to the next. For example, it can be used to encode a 2051 User-Name attribute which contains non-UTF8 data, or a Framed-IP- 2052 Address which contains 253 octets of ASCII data. As a result, it 2053 MUST NOT be used to create RADIUS Attributes for transport in a 2054 RADIUS message. 2056 However, the program correctly encodes the RADIUS attribute fields of 2057 "Type", "Length", "Extended-Type", "More", "Reserved", "Vendor-Id", 2058 "Vendor-Type", and "Vendor-Length". It encodes RADIUS attribute data 2059 types "evs" and TLV. It can therefore be used to encode example 2060 attributes from inputs which are humanly readable. 2062 We do not give examples of "malformed" or "invalid attributes". We 2063 also note that the examples show format, rather than consistent 2064 meaning. A particular Attribute Type code may be used to demonstrate 2065 two different formats. In real specifications, attributes have a 2066 static definitions based on their type code. 2068 The examples given below are strictly for demonstration purposes 2069 only, and do not provide a standard of any kind. 2071 9.1. Extended Type 2073 The following are a series of examples of the "Extended Type" format. 2075 Attribute encapsulating textual data. 2077 241.1 "bob" 2078 -> f1 06 01 62 6f 62 2080 Attribute encapsulating a TLV with TLV-Type of one (1). 2082 241.2 { 1 23 45 } 2083 -> f1 07 02 01 04 23 45 2085 Attribute encapsulating two TLVs, one after the other. 2087 241.2 { 1 23 45 } { 2 67 89 } 2088 -> f1 0b 02 01 04 23 45 02 04 67 89 2090 Attribute encapsulating two TLVs, where the second TLV is itself 2091 encapsulating a TLV. 2093 241.2 { 1 23 45 } { 3 { 1 ab cd } } 2094 -> f1 0d 02 01 04 23 45 03 06 01 04 ab cd 2096 Attribute encapsulating two TLVs, where the second TLV is itself 2097 encapsulating two TLVs. 2099 241.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } 2100 -> f1 12 02 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f 2102 Attribute encapsulating a TLV, which in turn encapsulates a TLV, 2103 to a depth of 5 nestings. 2105 241.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } 2106 -> f1 0f 01 01 0c 02 0a 03 08 04 06 05 04 cd ef 2108 Attribute encapsulating an extended Vendor Specific attribute, 2109 with Vendor-Id of 1, and Vendor-Type of 4, which in turn 2110 encapsulates textual data. 2112 241.26.1.4 "test" 2113 -> f1 0c 1a 00 00 00 01 04 74 65 73 74 2115 Attribute encapsulating an extended Vendor Specific attribute, with 2116 Vendor-Id of 1, and Vendor-Type of 5, which in turn encapsulates 2117 a TLV with TLV-Type of 3, which encapsulates textual data. 2119 241.26.1.5 { 3 "test" } 2120 -> f1 0e 1a 00 00 00 01 05 03 06 74 65 73 74 2122 9.2. Long Extended Type 2124 The following are a series of examples of the "Long Extended Type" 2125 format. 2127 Attribute encapsulating textual data. 2129 245.1 "bob" 2130 -> f5 07 01 00 62 6f 62 2132 Attribute encapsulating a TLV with TLV-Type of one (1). 2134 245.2 { 1 23 45 } 2135 -> f5 08 02 00 01 04 23 45 2137 Attribute encapsulating two TLVs, one after the other. 2139 245.2 { 1 23 45 } { 2 67 89 } 2140 -> f5 0c 02 00 01 04 23 45 02 04 67 89 2142 Attribute encapsulating two TLVs, where the second TLV is itself 2143 encapsulating a TLV. 2145 245.2 { 1 23 45 } { 3 { 1 ab cd } } 2146 -> f5 0e 02 00 01 04 23 45 03 06 01 04 ab cd 2148 Attribute encapsulating two TLVs, where the second TLV is itself 2149 encapsulating two TLVs. 2151 245.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } 2152 -> f5 13 02 00 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f 2154 Attribute encapsulating a TLV, which in turn encapsulates a TLV, 2155 to a depth of 5 nestings. 2157 245.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } 2158 -> f5 10 01 00 01 0c 02 0a 03 08 04 06 05 04 cd ef 2160 Attribute encapsulating an extended Vendor Specific attribute, 2161 with Vendor-Id of 1, and Vendor-Type of 4, which in turn 2162 encapsulates textual data. 2164 245.26.1.4 "test" 2165 -> f5 0d 1a 00 00 00 00 01 04 74 65 73 74 2167 Attribute encapsulating an extended Vendor Specific attribute, 2168 with Vendor-Id of 1, and Vendor-Type of 5, which in turn 2169 encapsulates a TLV with TLV-Type of 3, which encapsulates 2170 textual data. 2172 245.26.1.5 { 3 "test" } 2173 -> f5 0f 1a 00 00 00 00 01 05 03 06 74 65 73 74 2175 Attribute encapsulating more than 251 octets of data. The "Data" 2176 portions are indented for readability. 2178 245.4 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2179 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2180 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2181 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2182 aaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2183 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2184 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2185 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2186 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbcccccccccccccccccccc 2187 ccccccccccc" 2188 -> f5 ff 04 80 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2189 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2190 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2191 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2192 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2193 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2194 aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb bb bb bb bb bb 2195 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2196 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2197 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2198 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2199 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2200 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 13 04 00 cc 2201 cc cc cc cc cc cc cc cc cc cc cc cc cc cc 2203 Attribute encapsulating an extended Vendor Specific attribute, 2204 with Vendor-Id of 1, and Vendor-Type of 6, which in turn 2205 encapsulates more than 251 octets of data. 2207 As the VSA encapsulates more than 251 octets of data, it is 2208 split into two RADIUS attributes. The first attribute has the 2209 More field set, and carries the Vendor-Id and Vendor-Type. 2210 The second attribute has the More field clear, and carries 2211 the rest of the data portion of the VSA. Note that the second 2212 attribute does not include the Vendor-Id ad Vendor-Type fields. 2214 The "Data" portions are indented for readability. 2216 245.26.1.6 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2217 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2218 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2219 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2220 aaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2221 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2222 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2223 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2224 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbccccccccccccc 2225 ccccccccccccccccc" 2226 -> f5 ff 1a 80 00 00 00 01 06 aa aa aa aa aa aa aa aa aa aa aa 2227 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2228 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2229 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2230 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2231 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2232 aa aa aa aa aa aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb 2233 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2234 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2235 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2236 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2237 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2238 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 18 1a 00 bb 2239 bb bb bb bb cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 2241 10. IANA Considerations 2243 This document updates [RFC3575] in that it adds new IANA 2244 considerations for RADIUS Attributes. These considerations modify 2245 and extend the IANA considerations for RADIUS, rather than replacing 2246 them. 2248 The IANA considerations of this document are limited to the "RADIUS 2249 Attribute Types" registry. Some Attribute Type values which were 2250 previously marked "Reserved" are now allocated, and the registry is 2251 extended from a simple 8-bit array to a tree-like structure, up to a 2252 maximum depth of 125 nodes. Detailed instructions are given below. 2254 10.1. Attribute Allocations 2256 IANA is requested to move the following Attribute Type values from 2257 "Reserved", to "Allocated", with the corresponding names: 2259 * 241 Extended-Type-1 2260 * 242 Extended-Type-2 2261 * 243 Extended-Type-3 2262 * 244 Extended-Type-4 2263 * 245 Long-Extended-Type-1 2264 * 246 Long-Extended-Type-2 2266 These values serve as an encapsulation layer for the new RADIUS 2267 Attribute Type tree. 2269 10.2. RADIUS Attribute Type Tree 2271 Each of the Attribute Type values allocated above extends the "RADIUS 2272 Attribute Types" to an N-ary tree, via a "dotted number" notation. 2273 Allocation of an Attribute Type value "TYPE" using the new Extended 2274 type format results in allocation of 255 new Attribute Type values, 2275 of format "TYPE.1" through "TYPE.255". Value twenty-six (26) is 2276 assigned as "Extended-Vendor-Specific-*". Values "TYPE.241" through 2277 "TYPE.255" are marked "Reserved". All other values are "Unassigned". 2279 The initial set of Attribute Type values and names assigned by this 2280 document is given below. 2282 * 241 Extended-Attribute-1 2283 * 241.{1-25} Unassigned 2284 * 241.26 Extended-Vendor-Specific-1 2285 * 241.{27-240} Unassigned 2286 * 241.{241-255} Reserved 2287 * 242 Extended-Attribute-2 2288 * 242.{1-25} Unassigned 2289 * 242.26 Extended-Vendor-Specific-2 2290 * 242.{27-240} Unassigned 2291 * 243 Extended-Attribute-3 2292 * 242.{241-255} Reserved 2293 * 243.{1-25} Unassigned 2294 * 243.26 Extended-Vendor-Specific-3 2295 * 243.{27-240} Unassigned 2296 * 243.{241-255} Reserved 2297 * 244 Extended-Attribute-4 2298 * 244.{1-25} Unassigned 2299 * 244.26 Extended-Vendor-Specific-4 2300 * 244.{27-240} Unassigned 2301 * 244.{241-255} Reserved 2302 * 245 Extended-Attribute-5 2303 * 245.{1-25} Unassigned 2304 * 245.26 Extended-Vendor-Specific-5 2305 * 245.{27-240} Unassigned 2306 * 245.{241-255} Reserved 2307 * 246 Extended-Attribute-6 2308 * 246.{1-25} Unassigned 2309 * 245.26 Extended-Vendor-Specific-6 2310 * 246.{27-240} Unassigned 2311 * 246.{241-255} Reserved 2313 As per [RFC5226], the values marked "Unassigned" above are available 2314 via for assignment by IANA in future RADIUS specifications. The 2315 values marked "Reserved" are reserved for future use. 2317 The Extended-Vendor-Specific spaces (TYPE.26) are for Private Use, 2318 and allocations are not managed by IANA. 2320 Allocation of Reserved entries in the extended space requires 2321 Standards Action. 2323 All other allocations in the extended space require IETF Review. 2325 10.3. Allocation Instructions 2327 This section defines what actions IANA needs to take when allocating 2328 new attributes. Different actions are required when allocating 2329 attributes from the standard space, attributes of Extended Type 2330 format, attributes of the "Long Extended Type" format, preferential 2331 allocations, attributes of data type TLV, attributes within a TLV, 2332 and attributes of other data types. 2334 10.3.1. Requested Allocation from the Standard Space 2336 Specifications can request allocation of an Attribute from within the 2337 standard space (e.g. Attribute Type Codes 1 through 255), subject to 2338 the considerations of [RFC3575] and this document. 2340 10.3.2. Requested Allocation from the short extended space 2342 Specifications can request allocation of an Attribute which requires 2343 the format Extended Type, by specifying the short extended space In 2344 that case, IANA should assign the lowest Unassigned number from the 2345 Attribute Type space with the relevant format. 2347 10.3.3. Requested Allocation from the long extended space 2349 Specifications can request allocation of an Attribute which requires 2350 the format "Long Extended Type", by specifying the extended space 2351 (long). In that case, IANA should assign the lowest Unassigned 2352 number from the Attribute Type space with the relevant format. 2354 10.3.4. Allocation Preferences 2356 Specifications which make no request for allocation from a specific 2357 Type Space should have Attributes allocated using the following 2358 criteria: 2360 * when the standard space has no more Unassigned attributes, 2361 all allocations should be performed from the extended space. 2363 * specifications which allocate a small number of attributes 2364 (i.e. less than ten) should have all allocations made from 2365 the standard space. 2367 * specifications which would allocate a more than twenty percent 2368 of 2369 the remaining standard space attributes should have all 2370 allocations made from the extended space. 2372 * specifications which request allocation of an attribute of 2373 data type TLV should have that attribute allocated from the 2374 extended space. 2376 * specifications which request allocation of an attribute 2377 which can transport 253 or more octets of data should have 2378 that attribute allocated from within the long extended space, 2379 We note that Section 6.5, above requires specifications to 2380 request this allocation. 2382 There is otherwise no requirement that all attributes within a 2383 specification be allocated from one type space or another. 2384 Specifications can simultaneously allocate attributes from both the 2385 standard space and the extended space. 2387 10.3.5. Extending the Type Space via TLV Data Type 2389 When specifications request allocation of an attribute of data type 2390 "tlv", that allocation extends the Attribute Type Tree by one more 2391 level. Allocation of an Attribute Type value "TYPE.TLV", with Data 2392 Type TLV, results in allocation of 255 new Attribute Type values, of 2393 format "TYPE.TLV.1" through "TYPE.TLV.255". Values 254-255 are 2394 marked "Reserved". All other values are "Unassigned". Value 26 has 2395 no special meaning. 2397 For example, if a new attribute "Example-TLV" of data type "tlv" is 2398 assigned the identifier "245.1", then the extended tree will be 2399 allocated as below: 2401 * 245.1 Example-TLV 2402 * 245.1.{1-253} Unassigned 2403 * 245.1.{254-255} Reserved 2405 Note that this example does not define an "Example-TLV" attribute. 2407 The Attribute Type Tree can be extended multiple levels in one 2408 specification when the specification requests allocation of nested 2409 TLVs, as discussed below. 2411 10.3.6. Allocation within a TLV 2413 Specifications can request allocation of Attribute Type values within 2414 an Attribute of Data Type TLV. The encapsulating TLV can be 2415 allocated in the same specification, or it can have been previously 2416 allocated. 2418 Specifications need to request allocation within a specific Attribute 2419 Type value (e.g. "TYPE.TLV.*"). Allocations are performed from the 2420 smallest Unassigned value, proceeding to the largest Unassigned 2421 value. 2423 Where the Attribute being allocated is of Data Type TLV, the 2424 Attribute Type tree is extended by one level, as given in the 2425 previous section. Allocations can then be made within that level. 2427 10.3.7. Allocation of Other Data Types 2429 Attribute Type value allocations are otherwise allocated from the 2430 smallest Unassigned value, proceeding to the largest Unassigned 2431 value. e.g. Starting from 241.1, proceeding through 241.255, then to 2432 242.1, through 242.255, etc. 2434 11. Security Considerations 2436 This document defines new formats for data carried inside of RADIUS, 2437 but otherwise makes no changes to the security of the RADIUS 2438 protocol. 2440 Attacks on cryptographic hashes are well known, and are getting 2441 better with time, as discussed in[RFC4270]. RADIUS uses the MD5 hash 2442 [RFC1321] for packet authentication and attribute obfuscation. There 2443 are ongoing efforts in the IETF to analyze and address these issues 2444 for the RADIUS protocol. 2446 As with any protocol change, code changes are required in order to 2447 implement the new features. These code changes have the potential to 2448 introduce new vulnerabilities in the software. Since the RADIUS 2449 server performs network authentication, it is an inviting target for 2450 attackers. We RECOMMEND that access to RADIUS servers be kept to a 2451 minimum. 2453 12. References 2455 12.1. Normative references 2457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2458 Requirement Levels", RFC 2119, March, 1997. 2460 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 2461 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2462 2000. 2464 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 2466 [RFC3575] Aboba, B, "IANA Considerations for RADIUS (Remote 2467 Authentication Dial In User Service)", RFC 3575, July 2003. 2469 [RFC5176] Chiba, M, et. al., "Dynamic Authorization Extensions to Remote 2470 Authentication Dial In User Service (RADIUS)", RFC 5176, 2471 January 2008. 2473 [RFC5226] Narten, T. and Alvestrand, H, "Guidelines for Writing an IANA 2474 Considerations Section in RFCs", RFC 5226, May 2008. 2476 [RFC6158] DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC 2477 6158, March 2011. 2479 [PEN] http://www.iana.org/assignments/enterprise-numbers 2481 12.2. Informative references 2483 [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, 2484 April, 1992 2486 [RFC2868] Zorn, G., et al, " RADIUS Attributes for Tunnel Protocol 2487 Support", RFC 2868, June 2000. 2489 [RFC4270] Hoffman, P, and Schneier, B, "Attacks on Cryptographic Hashes 2490 in Internet Protocols", RFC 4270, November 2005. 2492 [RFC5234] Crocker, D. (Ed.), and Overell, P., "Augmented BNF for Syntax 2493 Specifications: ABNF", RFC 5234, October 2005. 2495 [EDUROAM] Internal Eduroam testing page, data retrieved 04 August 2010. 2497 [ATTR] http://github.com/alandekok/freeradius- 2498 server/tree/master/share/, data retrieved September 2010. 2500 Acknowledgments 2502 This document is the result of long discussions in the IETF RADEXT 2503 working group. The authors would like to thank all of the 2504 participants who contributed various ideas over the years. Their 2505 feedback has been invaluable, and has helped to make this 2506 specification better. 2508 Appendix A - Extended Attribute Generator Program 2510 This section contains "C" program source which can be used for 2511 testing. It reads a line-oriented text file, parses it to create 2512 RADIUS formatted attributes, and prints the hex version of those 2513 attributes to standard output. 2515 The input accepts a grammar similar to that given in Section 9, with 2516 some modifications for usability. For example, blank lines are 2517 allowed, lines beginning with a '#' character are interpreted as 2518 comments, numbers (RADIUS Types, etc.) are checked for minimum / 2519 maximum values, and RADIUS Attribute lengths are enforced. 2521 The program is included here for demonstration purposes only, and 2522 does not define a standard of any kind. 2524 ------------------------------------------------------------ 2525 /* 2526 * Copyright (c) 2010 IETF Trust and the persons identified as 2527 * authors of the code. All rights reserved. 2528 * 2529 * Redistribution and use in source and binary forms, with or without 2530 * modification, are permitted provided that the following conditions 2531 * are met: 2532 * 2533 * Redistributions of source code must retain the above copyright 2534 * notice, this list of conditions and the following disclaimer. 2535 * 2536 * Redistributions in binary form must reproduce the above copyright 2537 * notice, this list of conditions and the following disclaimer in 2538 * the documentation and/or other materials provided with the 2539 * distribution. 2540 * 2541 * Neither the name of Internet Society, IETF or IETF Trust, nor the 2542 * names of specific contributors, may be used to endorse or promote 2543 * products derived from this software without specific prior written 2544 * permission. 2545 * 2546 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 2547 * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, 2548 * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 2549 * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 2550 * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS 2551 * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 2552 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED 2553 * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 2554 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON 2555 * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 2556 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT 2557 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 2558 * SUCH DAMAGE. 2559 * 2560 * Author: Alan DeKok 2561 */ 2562 #include 2563 #include 2564 #include 2565 #include 2566 #include 2567 #include 2569 static int encode_tlv(char *buffer, uint8_t *output, size_t outlen); 2571 static const char *hextab = "0123456789abcdef"; 2573 static int encode_data_string(char *buffer, 2574 uint8_t *output, size_t outlen) 2575 { 2576 int length = 0; 2577 char *p; 2579 p = buffer + 1; 2581 while (*p && (outlen > 0)) { 2582 if (*p == '"') { 2583 return length; 2584 } 2586 if (*p != '\\') { 2587 *(output++) = *(p++); 2588 outlen--; 2589 length++; 2590 continue; 2591 } 2593 switch (p[1]) { 2594 default: 2595 *(output++) = p[1]; 2596 break; 2598 case 'n': 2599 *(output++) = '\n'; 2600 break; 2602 case 'r': 2603 *(output++) = '\r'; 2604 break; 2606 case 't': 2607 *(output++) = '\t'; 2608 break; 2609 } 2611 outlen--; 2612 length++; 2613 } 2615 fprintf(stderr, "String is not terminated\n"); 2616 return 0; 2617 } 2619 static int encode_data_tlv(char *buffer, char **endptr, 2620 uint8_t *output, size_t outlen) 2621 { 2622 int depth = 0; 2623 int length; 2624 char *p; 2626 for (p = buffer; *p != '\0'; p++) { 2627 if (*p == '{') depth++; 2628 if (*p == '}') { 2629 depth--; 2630 if (depth == 0) break; 2631 } 2632 } 2634 if (*p != '}') { 2635 fprintf(stderr, "No trailing '}' in string starting " 2636 "with \"%s\"\n", 2637 buffer); 2638 return 0; 2639 } 2641 *endptr = p + 1; 2642 *p = '\0'; 2644 p = buffer + 1; 2645 while (isspace((int) *p)) p++; 2647 length = encode_tlv(p, output, outlen); 2648 if (length == 0) return 0; 2650 return length; 2651 } 2652 static int encode_data(char *p, uint8_t *output, size_t outlen) 2653 { 2654 int length; 2656 if (!isspace((int) *p)) { 2657 fprintf(stderr, "Invalid character following attribute " 2658 "definition\n"); 2659 return 0; 2660 } 2662 while (isspace((int) *p)) p++; 2664 if (*p == '{') { 2665 int sublen; 2666 char *q; 2668 length = 0; 2670 do { 2671 while (isspace((int) *p)) p++; 2672 if (!*p) { 2673 if (length == 0) { 2674 fprintf(stderr, "No data\n"); 2675 return 0; 2676 } 2678 break; 2679 } 2681 sublen = encode_data_tlv(p, &q, output, outlen); 2682 if (sublen == 0) return 0; 2684 length += sublen; 2685 output += sublen; 2686 outlen -= sublen; 2687 p = q; 2688 } while (*q); 2690 return length; 2691 } 2693 if (*p == '"') { 2694 length = encode_data_string(p, output, outlen); 2695 return length; 2696 } 2698 length = 0; 2699 while (*p) { 2700 char *c1, *c2; 2702 while (isspace((int) *p)) p++; 2704 if (!*p) break; 2706 if(!(c1 = memchr(hextab, tolower((int) p[0]), 16)) || 2707 !(c2 = memchr(hextab, tolower((int) p[1]), 16))) { 2708 fprintf(stderr, "Invalid data starting at " 2709 "\"%s\"\n", p); 2710 return 0; 2711 } 2713 *output = ((c1 - hextab) << 4) + (c2 - hextab); 2714 output++; 2715 length++; 2716 p += 2; 2718 outlen--; 2719 if (outlen == 0) { 2720 fprintf(stderr, "Too much data\n"); 2721 return 0; 2722 } 2723 } 2725 if (length == 0) { 2726 fprintf(stderr, "Empty string\n"); 2727 return 0; 2728 } 2730 return length; 2731 } 2733 static int decode_attr(char *buffer, char **endptr) 2734 { 2735 long attr; 2737 attr = strtol(buffer, endptr, 10); 2738 if (*endptr == buffer) { 2739 fprintf(stderr, "No valid number found in string " 2740 "starting with \"%s\"\n", buffer); 2741 return 0; 2742 } 2744 if (!**endptr) { 2745 fprintf(stderr, "Nothing follows attribute number\n"); 2746 return 0; 2747 } 2748 if ((attr <= 0) || (attr > 256)) { 2749 fprintf(stderr, "Attribute number is out of valid " 2750 "range\n"); 2751 return 0; 2752 } 2754 return (int) attr; 2755 } 2757 static int decode_vendor(char *buffer, char **endptr) 2758 { 2759 long vendor; 2761 if (*buffer != '.') { 2762 fprintf(stderr, "Invalid separator before vendor id\n"); 2763 return 0; 2764 } 2766 vendor = strtol(buffer + 1, endptr, 10); 2767 if (*endptr == (buffer + 1)) { 2768 fprintf(stderr, "No valid vendor number found\n"); 2769 return 0; 2770 } 2772 if (!**endptr) { 2773 fprintf(stderr, "Nothing follows vendor number\n"); 2774 return 0; 2775 } 2777 if ((vendor <= 0) || (vendor > (1 << 24))) { 2778 fprintf(stderr, "Vendor number is out of valid range\n"); 2779 return 0; 2780 } 2782 if (**endptr != '.') { 2783 fprintf(stderr, "Invalid data following vendor number\n"); 2784 return 0; 2785 } 2786 (*endptr)++; 2788 return (int) vendor; 2789 } 2791 static int encode_tlv(char *buffer, uint8_t *output, size_t outlen) 2792 { 2793 int attr; 2794 int length; 2795 char *p; 2796 attr = decode_attr(buffer, &p); 2797 if (attr == 0) return 0; 2799 output[0] = attr; 2800 output[1] = 2; 2802 if (*p == '.') { 2803 p++; 2804 length = encode_tlv(p, output + 2, outlen - 2); 2806 } else { 2807 length = encode_data(p, output + 2, outlen - 2); 2808 } 2810 if (length == 0) return 0; 2811 if (length > (255 - 2)) { 2812 fprintf(stderr, "TLV data is too long\n"); 2813 return 0; 2814 } 2816 output[1] += length; 2818 return length + 2; 2819 } 2821 static int encode_vsa(char *buffer, uint8_t *output, size_t outlen) 2822 { 2823 int vendor; 2824 int attr; 2825 int length; 2826 char *p; 2828 vendor = decode_vendor(buffer, &p); 2829 if (vendor == 0) return 0; 2831 output[0] = 0; 2832 output[1] = (vendor >> 16) & 0xff; 2833 output[2] = (vendor >> 8) & 0xff; 2834 output[3] = vendor & 0xff; 2836 length = encode_tlv(p, output + 4, outlen - 4); 2837 if (length == 0) return 0; 2838 if (length > (255 - 6)) { 2839 fprintf(stderr, "VSA data is too long\n"); 2840 return 0; 2841 } 2842 return length + 4; 2843 } 2845 static int encode_evs(char *buffer, uint8_t *output, size_t outlen) 2846 { 2847 int vendor; 2848 int attr; 2849 int length; 2850 char *p; 2852 vendor = decode_vendor(buffer, &p); 2853 if (vendor == 0) return 0; 2855 attr = decode_attr(p, &p); 2856 if (attr == 0) return 0; 2858 output[0] = 0; 2859 output[1] = (vendor >> 16) & 0xff; 2860 output[2] = (vendor >> 8) & 0xff; 2861 output[3] = vendor & 0xff; 2862 output[4] = attr; 2864 length = encode_data(p, output + 5, outlen - 5); 2865 if (length == 0) return 0; 2867 return length + 5; 2868 } 2870 static int encode_extended(char *buffer, 2871 uint8_t *output, size_t outlen) 2872 { 2873 int attr; 2874 int length; 2875 char *p; 2877 attr = decode_attr(buffer, &p); 2878 if (attr == 0) return 0; 2880 output[0] = attr; 2882 if (attr == 26) { 2883 length = encode_evs(p, output + 1, outlen - 1); 2884 } else { 2885 length = encode_data(p, output + 1, outlen - 1); 2886 } 2887 if (length == 0) return 0; 2888 if (length > (255 - 3)) { 2889 fprintf(stderr, "Extended Attr data is too long\n"); 2890 return 0; 2891 } 2893 return length + 1; 2894 } 2896 static int encode_extended_flags(char *buffer, 2897 uint8_t *output, size_t outlen) 2898 { 2899 int attr; 2900 int length, total; 2901 char *p; 2903 attr = decode_attr(buffer, &p); 2904 if (attr == 0) return 0; 2906 /* output[0] is the extended attribute */ 2907 output[1] = 4; 2908 output[2] = attr; 2909 output[3] = 0; 2911 if (attr == 26) { 2912 length = encode_evs(p, output + 4, outlen - 4); 2913 if (length == 0) return 0; 2915 output[1] += 5; 2916 length -= 5; 2917 } else { 2918 length = encode_data(p, output + 4, outlen - 4); 2919 } 2920 if (length == 0) return 0; 2922 total = 0; 2923 while (1) { 2924 int sublen = 255 - output[1]; 2926 if (length <= sublen) { 2927 output[1] += length; 2928 total += output[1]; 2929 break; 2930 } 2932 length -= sublen; 2934 memmove(output + 255 + 4, output + 255, length); 2935 memcpy(output + 255, output, 4); 2937 output[1] = 255; 2938 output[3] |= 0x80; 2940 output += 255; 2941 output[1] = 4; 2942 total += 255; 2943 } 2945 return total; 2946 } 2948 static int encode_rfc(char *buffer, uint8_t *output, size_t outlen) 2949 { 2950 int attr; 2951 int length, sublen; 2952 char *p; 2954 attr = decode_attr(buffer, &p); 2955 if (attr == 0) return 0; 2957 length = 2; 2958 output[0] = attr; 2959 output[1] = 2; 2961 if (attr == 26) { 2962 sublen = encode_vsa(p, output + 2, outlen - 2); 2964 } else if ((*p == ' ') || ((attr < 241) || (attr > 246))) { 2965 sublen = encode_data(p, output + 2, outlen - 2); 2967 } else { 2968 if (*p != '.') { 2969 fprintf(stderr, "Invalid data following " 2970 "attribute number\n"); 2971 return 0; 2972 } 2974 if (attr < 245) { 2975 sublen = encode_extended(p + 1, 2976 output + 2, outlen - 2); 2977 } else { 2979 /* 2980 * Not like the others! 2981 */ 2982 return encode_extended_flags(p + 1, output, outlen); 2983 } 2984 } 2985 if (sublen == 0) return 0; 2986 if (sublen > (255 -2)) { 2987 fprintf(stderr, "RFC Data is too long\n"); 2988 return 0; 2989 } 2991 output[1] += sublen; 2992 return length + sublen; 2993 } 2995 int main(int argc, char *argv[]) 2996 { 2997 int lineno; 2998 size_t i, outlen; 2999 FILE *fp; 3000 char input[8192], buffer[8192]; 3001 uint8_t output[4096]; 3003 if ((argc < 2) || (strcmp(argv[1], "-") == 0)) { 3004 fp = stdin; 3005 } else { 3006 fp = fopen(argv[1], "r"); 3007 if (!fp) { 3008 fprintf(stderr, "Error opening %s: %s\n", 3009 argv[1], strerror(errno)); 3010 exit(1); 3011 } 3012 } 3014 lineno = 0; 3015 while (fgets(buffer, sizeof(buffer), fp) != NULL) { 3016 char *p = strchr(buffer, '\n'); 3018 lineno++; 3020 if (!p) { 3021 if (!feof(fp)) { 3022 fprintf(stderr, "Line %d too long in %s\n", 3023 lineno, argv[1]); 3024 exit(1); 3025 } 3026 } else { 3027 *p = '\0'; 3028 } 3030 p = strchr(buffer, '#'); 3031 if (p) *p = '\0'; 3033 p = buffer; 3034 while (isspace((int) *p)) p++; 3035 if (!*p) continue; 3037 strcpy(input, p); 3038 outlen = encode_rfc(input, output, sizeof(output)); 3039 if (outlen == 0) { 3040 fprintf(stderr, "Parse error in line %d of %s\n", 3041 lineno, input); 3042 exit(1); 3043 } 3045 printf("%s -> ", buffer); 3046 for (i = 0; i < outlen; i++) { 3047 printf("%02x ", output[i]); 3048 } 3049 printf("\n"); 3050 } 3052 if (fp != stdin) fclose(fp); 3054 return 0; 3055 } 3056 ------------------------------------------------------------ 3058 Author's Address 3060 Alan DeKok 3061 Network RADIUS SARL 3062 57bis blvd des Alpes 3063 38240 Meylan 3064 France 3066 Email: aland@networkradius.com 3067 URI: http://networkradius.com 3069 Avi Lior 3070 Email: avi.ietf@lior.org