idnits 2.17.1 draft-ietf-radext-radius-extensions-13.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 (25 February 2013) is 4077 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC1311' is mentioned on line 2446, but not defined -- Looks like a reference, but probably isn't: '1' on line 3033 -- Looks like a reference, but probably isn't: '0' on line 2968 -- Looks like a reference, but probably isn't: '2' on line 2918 -- Looks like a reference, but probably isn't: '3' on line 2948 -- Looks like a reference, but probably isn't: '4' on line 2872 -- Looks like a reference, but probably isn't: '8192' on line 3010 -- Looks like a reference, but probably isn't: '4096' on line 3011 == Unused Reference: 'RFC5176' is defined on line 2475, but no explicit reference was found in the text == Unused Reference: 'RFC1321' is defined on line 2489, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2866 ** Downref: Normative reference to an Informational RFC: RFC 5176 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'PEN' Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Alan DeKok 3 INTERNET-DRAFT Network RADIUS 4 Category: Proposed Standard Avi Lior 5 Updates: 2865, 2866, 3575, 5176, 6158 6 7 Expires: August 25, 2013 8 25 February 2013 10 Remote Authentication Dial In User Service (RADIUS) Protocol 11 Extensions 12 draft-ietf-radext-radius-extensions-13.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 ..................... 19 79 2.7.3. TLV Identifiers ................................ 20 80 2.7.4. VSA Identifiers ................................ 20 81 2.8. Invalid Attributes .................................. 21 82 3. Attribute Definitions .................................... 22 83 3.1. Extended-Type-1 ..................................... 23 84 3.2. Extended-Type-2 ..................................... 23 85 3.3. Extended-Type-3 ..................................... 24 86 3.4. Extended-Type-4 ..................................... 25 87 3.5. Long-Extended-Type-1 ................................ 26 88 3.6. Long-Extended-Type-2 ................................ 27 89 4. Vendor Specific Attributes ............................... 28 90 4.1. Extended-Vendor-Specific-1 .......................... 29 91 4.2. Extended-Vendor-Specific-2 .......................... 30 92 4.3. Extended-Vendor-Specific-3 .......................... 31 93 4.4. Extended-Vendor-Specific-4 .......................... 32 94 4.5. Extended-Vendor-Specific-5 .......................... 33 95 4.6. Extended-Vendor-Specific-6 .......................... 35 96 5. Compatibility with traditional RADIUS .................... 36 97 5.1. Attribute Allocation ................................ 36 98 5.2. Proxy Servers ....................................... 37 99 6. Guidelines ............................................... 38 100 6.1. Updates to RFC 6158 ................................. 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 ...................................... 41 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 ..................................... 44 111 8. Diameter Considerations .................................. 45 112 9. Examples ................................................. 45 113 9.1. Extended Type ....................................... 46 114 9.2. Long Extended Type .................................. 47 115 10. IANA Considerations ..................................... 50 116 10.1. Attribute Allocations .............................. 50 117 10.2. RADIUS Attribute Type Tree ......................... 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 incentive is 216 being provided by the exhaustion of the standard space. 218 1.1.2. Implementation Recommendations 220 It is RECOMMENDED that implementations support this specification. 221 It is RECOMMENDED that new specifications use the formats defined in 222 this specification. 224 The alternative to the above recommendations is a circular argument 225 of not implementing this specification because no other standards 226 reference it, and also not defining new standards referencing this 227 specification because no implementations exist. 229 As noted earlier, the "standard space" is almost entirely allocated. 230 Ignoring the looming crisis benefits no one. 232 1.2. Terminology 234 This document uses the following terms: 236 Silently discard 237 This means the implementation discards the packet without further 238 processing. The implementation MAY provide the capability of 239 logging the error, including the contents of the silently discarded 240 packet, and SHOULD record the event in a statistics counter. 242 Invalid attribute 243 This means that the Length field of an Attribute is valid (as per 244 [RFC2865], Section 5, top of page 25), but the contents of the 245 Attribute do not follow the correct format. For example, an 246 Attribute of type "address" which encapsulates more than four, or 247 less than four, octets of data. See Section 2.8 for a more 248 complete definition. 250 Standard space 251 Codes in the RADIUS Attribute Type Space that are allocated by IANA 252 and that follow the format defined in Section 5 of [RFC2865]. 254 Extended space 255 Codes in the RADIUS Attribute Type Space that require the 256 extensions defined in this document, and are an extension of the 257 standard space, but which cannot be represented within the standard 258 space. 260 Short extended space 261 Codes in the extended space which use the "Extended Type" format. 263 Long extended space 264 Codes in the extended space which use the "Long Extended Type" 265 format. 267 The following terms are used here with the meanings defined in BCP 268 26 [RFC5226]: "name space", "assigned value", "registration", 269 "Private Use", "Reserved", "Unassigned", "IETF Review", and 270 "Standards Action". 272 1.3. Requirements Language 274 In this document, several words are used to signify the requirements 275 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 276 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 277 and "OPTIONAL" in this document are to be interpreted as described in 278 [RFC2119]. 280 2. Extensions to RADIUS 282 This section defines two new attribute formats; "Extended Type"; and 283 "Long Extended Type". It defines a new Type-Length-Value (TLV) data 284 type, an Extended-Vendor-Specific (EVS) data type, and an Integer64 285 data type. It defines a new method for naming attributes and 286 identifying Attributes using the new attribute formats. It finally 287 defines the new term "invalid attribute", and describes how it 288 affects implementations. 290 The new attribute formats are designed to be compatible with the 291 attribute format given in [RFC2865] Section 5. The meaning and 292 interpretation of the Type and Length fields is unchanged from that 293 specification. This reuse allows the new formats to be compatible 294 with RADIUS implementations which do not implement this 295 specification. Those implementations can simply ignore the Value 296 field of an attribute, or forward it verbatim. 298 The changes to the attribute format come about by "stealing" one or 299 more octets from the Value field. This change has the effect that 300 the Value field of [RFC2865] Section 5 contains both the new octets 301 given here, and any attribute-specific Value. The result is that 302 Values in this specification are limited to less than 253 octets in 303 size. This limitation is overcome through the use of the "Long 304 Extended Type" format. 306 We reiterate that the formats given in this document do not insert 307 new data into an attribute. Instead, we "steal" one octet of Value, 308 so that the definition of the Length field remains unchanged. The 309 new attribute formats are designed to be compatible with the 310 attribute format given in [RFC2865] Section 5. The meaning and 311 interpretation of the Type and Length fields is unchanged from that 312 specification. This reuse allows the new formats to be compatible 313 RADIUS implementations which do not implement this specification. 314 Those implementations can simply ignore the Value field of an 315 attribute, or forward it verbatim. 317 The changes to the attribute format come about by "stealing" one or 318 more octets from the Value field. This change has the effect that 319 the Value field of [RFC2865] Section 5 contains both the new octets 320 given here, and any attribute-specific Value. The result is that 321 Values in this specification are limited to less than 253 octets in 322 size. This limitation is overcome through the use of the "Long 323 Extended Type" format. 325 2.1. Extended Type 327 This section defines a new attribute format, called "Extended Type". 328 A summary of the Attribute format is shown below. The fields are 329 transmitted from left to right. 331 0 1 2 3 332 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Type | Length | Extended-Type | Value ... 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Type 339 This field is identical to the Type field of the Attribute format 340 defined in [RFC2865] Section 5. 342 Length 344 The Length field is one octet, and indicates the length of this 345 Attribute including the Type, Length, Extended-Type, and Value 346 fields. Permitted values are between 4 and 255. If a client or 347 server receives an Extended Attribute with a Length of 2 or 3, 348 then that Attribute MUST be considered to be an "invalid 349 attribute", and handled as per Section 2.8, below. 351 Extended-Type 353 The Extended-Type field is one octet. Up-to-date values of this 354 field are specified according to the policies and rules described 355 in Section 10. Unlike the Type field defined in [RFC2865] Section 356 5, no values are allocated for experimental or implementation- 357 specific use. Values 241-255 are reserved and MUST NOT be used. 359 The Extended-Type is meaningful only within a context defined by 360 the Type field. That is, this field may be thought of as defining 361 a new type space of the form "Type.Extended-Type". See Section 362 2.5, below, for additional discussion. 364 A RADIUS server MAY ignore Attributes with an unknown 365 "Type.Extended-Type". 367 A RADIUS client MAY ignore Attributes with an unknown 368 "Type.Extended-Type". 370 Value 372 This field is similar to the Value field of the Attribute format 373 defined in [RFC2865] Section 5. The format of the data MUST be a 374 valid RADIUS data type. 376 The Value field is one or more octets. 378 Implementations supporting this specification MUST use the 379 Identifier of "Type.Extended-Type" to determine the interpretation 380 of the Value field. 382 The addition of the Extended-Type field decreases the maximum 383 length for attributes of type "text" or "string" from 253 to 252 384 octets. Where an Attribute needs to carry more than 252 octets of 385 data, the "Long Extended Type" format MUST be used. 387 Experience has shown that the "experimental" and "implementation 388 specific" attributes defined in [RFC2865] Section 5 have had little 389 practical value. We therefore do not continue that practice here 390 with the Extended-Type field. 392 2.2. Long Extended Type 394 This section defines a new attribute format, called "Long Extended 395 Type". It leverages the "Extended Type" format in order to permit 396 the transport of attributes encapsulating more than 253 octets of 397 data. A summary of the Attribute format is shown below. The fields 398 are transmitted from left to right. 400 0 1 2 3 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Type | Length | Extended-Type |M| Reserved | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Value ... 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 Type 410 This field is identical to the Type field of the Attribute format 411 defined in [RFC2865] Section 5. 413 Length 415 The Length field is one octet, and indicates the length of this 416 Attribute including the Type, Length, Extended-Type, and Value 417 fields. Permitted values are between 5 and 255. If a client or 418 server receives a "Long Extended Type" with a Length of 2, 3, or 419 4, then that Attribute MUST be considered to be an "invalid 420 attribute", and be handled as per Section 2.8, below. 422 Note that this Length is limited to the length of this fragment. 423 There is no field which gives an explicit value for the total size 424 of the fragmented attribute. 426 Extended-Type 428 This field is identical to the Extended-Type field defined above 429 in Section 2.1. 431 M (More) 433 The More field is one (1) bit in length, and indicates whether or 434 not the current attribute contains "more" than 251 octets of data. 435 The More field MUST be clear (0) if the Length field has value 436 less than 255. The More field MAY be set (1) if the Length field 437 has value of 255. 439 If the More field is set (1), it indicates that the Value field 440 has been fragmented across multiple RADIUS attributes. When the 441 More field is set (1), the attribute MUST have a Length field of 442 value 255; there MUST be an attribute following this one; and the 443 next attribute MUST have both the same Type and Extended Type. 444 That is, multiple fragments of the same value MUST be in order and 445 MUST be consecutive attributes in the packet, and the last 446 attribute in a packet MUST NOT have the More field set (1). 448 That is, a packet containing a fragmented attribute needs to 449 contain all fragments of the attribute, and those fragments need 450 to be contiguous in the packet. RADIUS does not support inter- 451 packet fragmentation, which means that fragmenting an attribute 452 across multiple packets is impossible. 454 If a client or server receives an attribute fragment with the 455 "More" field set (1), but for which no subsequent fragment can be 456 found, then the fragmented attribute is considered to be an 457 "invalid attribute", and handled as per Section 2.8, below. 459 Reserved 461 This field is 7 bits long, and is reserved for future use. 462 Implementations MUST set it to zero (0) when encoding an attribute 463 for sending in a packet. The contents SHOULD be ignored on 464 reception. 466 Future specifications may define additional meaning for this 467 field. Implementations therefore MUST NOT treat this field as 468 invalid if it is non-zero. 470 Value 472 This field is similar to the Value field of the Attribute format 473 defined in [RFC2865] Section 5. It may contain a complete set of 474 data (when the Length field has value less than 255), or it may 475 contain a fragment of data. 477 The Value field is one or more octets. 479 Implementations supporting this specification MUST use the 480 Identifier of "Type.Extended-Type" to determine the interpretation 481 of the Value field. 483 Any interpretation of the resulting data MUST occur after the 484 fragments have been reassembled. The length of the data MUST be 485 taken as the sum of the lengths of the fragments (i.e. Value 486 fields) from which it is constructed. The format of the data 487 SHOULD be a valid RADIUS data type. If the reassembled data does 488 not match the expected format, all fragments MUST be treated as 489 "invalid attributes", and the reassembled data MUST be discarded. 491 We note that the maximum size of a fragmented attribute is limited 492 only by the RADIUS packet length limitation (i.e. 4096 octets, not 493 counting various headers and overhead). Implementations MUST be 494 able to handle the case where one fragmented attribute completely 495 fills the packet. 497 This definition increases the RADIUS Attribute Type space as above, 498 but also provides for transport of Attributes which could contain 499 more than 253 octets of data. 501 Note that [RFC2865] Section 5 says: 503 If multiple Attributes with the same Type are present, the order 504 of Attributes with the same Type MUST be preserved by any proxies. 505 The order of Attributes of different Types is not required to be 506 preserved. A RADIUS server or client MUST NOT have any 507 dependencies on the order of attributes of different types. A 508 RADIUS server or client MUST NOT require attributes of the same 509 type to be contiguous. 511 These requirements also apply to the "Long Extended Type" attribute, 512 including fragments. Implementations MUST be able to process non- 513 contiguous fragments -- that is, fragments which are mixed together 514 with other attributes of a different Type. This will allow them to 515 accept packets, so long as the attributes can be correctly decoded. 517 2.3. TLV Data Type 519 We define a new data type in RADIUS, called "tlv". The "tlv" data 520 type is an encapsulation layer which permits the "Value" field of an 521 Attribute to contain new sub-Attributes. These sub-Attributes can in 522 turn contain "Value"s of data type TLV. This capability both extends 523 the attribute space, and permits "nested" attributes to be used. 524 This nesting can be used to encapsulate or group data into one or 525 more logical containers. 527 The "tlv" data type re-uses the RADIUS attribute format, as given 528 below: 530 0 1 2 3 531 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 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | TLV-Type | TLV-Length | TLV-Value ... 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 TLV-Type 538 The Type field is one octet. Up-to-date values of this field are 539 specified according to the policies and rules described in Section 540 10. Values 254-255 are "Reserved" for use by future extensions to 541 RADIUS. The value 26 has no special meaning, and MUST NOT be 542 treated as a Vendor Specific attribute. 544 As with Extended-Type above, the TLV-Type is meaningful only 545 within the context defined by "Type" fields of the encapsulating 546 Attributes. That is, the field may be thought of as defining a 547 new type space of the form "Type.Extended-Type.TLV-Type". Where 548 TLVs are nested, the type space is of the form "Type.Extended- 549 Type.TLV-Type.TLV-Type", etc. 551 A RADIUS server MAY ignore Attributes with an unknown "TLV-Type". 553 A RADIUS client MAY ignore Attributes with an unknown "TLV-Type". 555 A RADIUS proxy SHOULD forward Attributes with an unknown "TLV- 556 Type" verbatim. 558 TLV-Length 560 The TLV-Length field is one octet, and indicates the length of 561 this TLV including the TLV-Type, TLV-Length and TLV-Value fields. 562 It MUST have a value between 3 and 255. If a client or server 563 receives a TLV with an invalid TLV-Length, then the attribute 564 which encapsulates that TLV MUST be considered to be an "invalid 565 attribute", and handled as per Section 2.8, below. 567 TLV-Value 569 The TLV-Value field is one or more octets and contains information 570 specific to the Attribute. The format and length of the TLV-Value 571 field is determined by the TLV-Type and TLV-Length fields. 573 The TLV-Value field SHOULD encapsulate a standard RADIUS data 574 type. Non-standard data types SHOULD NOT be used within TLV-Value 575 fields. We note that the TLV-Value field MAY also contain one or 576 more attributes of data type "tlv", which allows for simple 577 grouping and multiple layers of nesting. 579 The TLV-Value field is limited to containing 253 or fewer octets 580 of data. Specifications which require a TLV to contain more than 581 253 octets of data are incompatible with RADIUS, and need to be 582 redesigned. Specifications which require the transport of empty 583 Values (i.e. Length = 2) are incompatible with RADIUS, and need to 584 be redesigned. 586 The TLV-Value field MUST NOT contain data using the "Extended 587 Type" formats defined in this document. The base Extended 588 Attributes format allows for sufficient flexibility that nesting 589 them inside of a TLV offers little additional value. 591 This TLV definition is compatible with the suggested format of the 592 "String" field of the Vendor-Specific attribute, as defined in 593 [RFC2865] Section 5.26, though that specification does not discuss 594 nesting. 596 Vendors MAY use attributes of type "tlv" in any Vendor Specific 597 Attribute. It is RECOMMENDED to use type "tlv" for VSAs, in 598 preference to any other format. 600 If multiple TLVs with the same TLV-Type are present, the order of 601 TLVs with the same TLV-Type MUST be preserved by any proxies. The 602 order of TLVs of different TLV-Types is not required to be preserved. 603 A RADIUS server or client MUST NOT have any dependencies on the order 604 of TLVs of different TLV-Types. A RADIUS server or client MUST NOT 605 require TLVs of the same TLV-type to be contiguous. 607 The interpretation of multiple TLVs of the same TLV-Type MUST be that 608 of a logical "and", unless otherwise specified. That is, multiple 609 TLVs are interpreted as specifying an unordered set of values. 610 Specifications SHOULD NOT define TLVs to be interpreted as a logical 611 "or". Doing so would mean that a RADIUS client or server would make 612 an arbitrary, and non-deterministic choice among the values. 614 2.3.1. TLV Nesting 616 TLVs may contain other TLVs. When this occurs, the "container" TLV 617 MUST be completely filled by the "contained" TLVs. That is, the 618 "container" TLV-Length field MUST be exactly two (2) more than the 619 sum of the "contained" TLV-Length fields. If the "contained" TLVs 620 over-fill the "container" TLV, the "container" TLV MUST be considered 621 to be an "invalid attribute", and handled as described in Section 622 2.8, below. 624 The depth of TLV nesting is limited only by the restrictions on the 625 TLV-Length field. The limit of 253 octets of data results in a limit 626 of 126 levels of nesting. However, nesting depths of more than 4 are 627 NOT RECOMMENDED. They have not been demonstrated to be necessary in 628 practice, and they appear to make implementations more complex. 629 Reception of packets with such deeply nest TLVs may indicate 630 implementation errors or deliberate attacks. Where implementations 631 do not support deep nesting of TLVs, it is RECOMMENDED that the 632 unsupported layers are treated as "invalid attributes". 634 2.4. EVS Data Type 636 We define a new data type in RADIUS, called "evs", for "Extended 637 Vendor-Specific". The "evs" data type is an encapsulation layer 638 which permits the "Value" field of an Attribute to contain a Vendor- 639 Id, followed by a Vendor-Type, and then vendor-defined data. This 640 data can in turn contain valid RADIUS data types, or any other data 641 as determined by the vendor. 643 This data type is intended use in attributes which carry Vendor- 644 Specific information, as is done with the Vendor-Specific Attribute 645 (26). It is RECOMMENDED that this data type be used by a vendor only 646 when the Vendor-Specific Attribute Type space has been fully 647 allocated. 649 Where [RFC2865] Section 5.26 makes a recommendation for the format of 650 the data following the Vendor-Id, we give a strict definition. 651 Experience has shown that many vendors have not followed the 652 [RFC2865] recommendations, leading to interoperability issues. We 653 hope here to give vendors sufficient flexibility as to meet their 654 needs, while minimizing the use of non-standard VSA formats. 656 The "evs" data type MAY be used in Attributes having the format of 657 "Extended Type" or "Long Extended Type". It MUST NOT be used in any 658 other Attribute definition, including standard RADIUS Attributes, 659 TLVs, and VSAs. 661 A summary of the "evs" data type format is shown below. The fields 662 are transmitted from left to right. 664 0 1 2 3 665 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 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Vendor-Id | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Vendor-Type | Vendor-Value .... 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 Vendor-Id 674 The 4 octets are the Network Management Private Enterprise Code 675 [PEN] of the Vendor in network byte order. 677 Vendor-Type 679 The Vendor-Type field is one octet. Values are assigned at the 680 sole discretion of the Vendor. 682 Vendor-Value 684 The Vendor-Value field is one or more octets. It SHOULD 685 encapsulate a standard RADIUS data type. Using non-standard data 686 types is NOT RECOMMENDED. We note that the Value field may be of 687 data type "tlv". However, it MUST NOT be of data type "evs", as 688 the use cases are unclear for one vendor delegating Attribute Type 689 space to another vendor. 691 The actual format of the information is site or application 692 specific, and a robust implementation SHOULD support the field as 693 undistinguished octets. We recognise that Vendors have complete 694 control over the contents and format of the Value field, while at 695 the same time recommending that good practices be followed. 697 Further codification of the range of allowed usage of this field 698 is outside the scope of this specification. 700 Note that unlike the format described in [RFC2865] Section 5.26, this 701 data type has no "Vendor length" field. The length of the Vendor- 702 Value field is implicit, and is determined by taking the "Length" of 703 the encapsulating RADIUS Attribute, and subtracting the length of the 704 attribute header (2 octets), the extended type (1 octet), the Vendor- 705 Id (4 octets), and the Vendor-type (1 octet). i.e. For "Extended 706 Type" attributes, the length of the Vendor-Value field is eight (8) 707 less than the value of the Length field. For "Long Extended Type" 708 attributes, the length of the Vendor-Value field is nine (9) less 709 than the value of the Length field. 711 2.5. Integer64 Data Type 713 We define a new data type in RADIUS, called "integer64", which 714 carries a 64-bit unsigned integer in network byte order. 716 This data type is intended to be used in any situation where there is 717 a need to have counters which can count past 2^32. The expected use 718 of this data type is within Accounting-Request packets, but this data 719 type SHOULD be used in any packet where 32-bit integers are expected 720 to be insufficient. 722 The "integer64" data type can be used in Attributes of any format, 723 standard space, extended attributes, TLVs, and VSAs. 725 A summary of the "integer64" data type format is shown below. The 726 fields are transmitted from left to right. 728 0 1 2 3 729 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 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Value ... 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 Attributes having data type "integer64" MUST have the relevant Length 737 field set to eight more than the length of the Attribute header. For 738 standard space Attributes and TLVs, this means that the Length field 739 MUST be set to ten (10). For "Extended Type" Attributes, the Length 740 field MUST be set to eleven (11). For "Long Extended Type" 741 Attributes, the Length field MUST be set to twelve (12). 743 2.6. Vendor-ID Field 745 We define the Vendor-ID field of Vendor-Specific Attributes to 746 encompass the entire 4 octets of the Vendor field. [RFC2865] Section 747 5.26 defined it to be 3 octets, with the high octet being zero. This 748 change has no immediate impact on RADIUS, as the maximum Private 749 Enterprise Code defined is still within 16 bits. 751 However, it is best to make advance preparations for changes in the 752 protocol. As such, it is RECOMMENDED that all implementations 753 support four (4) octets for the Vendor-ID field, instead of three 754 (3). 756 2.7. Attribute Naming and Type Identifiers 758 Attributes have traditionally been identified by a unique name and 759 number. For example, the attribute named "User-Name" has been 760 allocated number one (1). This scheme needs to be extended in order 761 to be able to refer to attributes of Extended Type, and to TLVs. It 762 will also be used by IANA for allocating RADIUS Attribute Type 763 values. 765 The names and identifiers given here are intended to be used only in 766 specifications. The system presented here may not be useful when 767 referring to the contents of a RADIUS packet. It imposes no 768 requirements on implementations, as implementations are free to 769 reference RADIUS Attributes via any method they choose. 771 2.7.1. Attribute and TLV Naming 773 RADIUS specifications traditionally use names consisting of one or 774 more words, separated by hyphens, e.g. "User-Name". However, these 775 names are not allocated from a registry, and there is no restriction 776 other than convention on their global uniqueness. 778 Similarly, vendors have often used their company name as the prefix 779 for VSA names, though this practice is not universal. For example, 780 for a vendor named "Example", the name "Example-Attribute-Name" 781 SHOULD be used instead of "Attribute-Name". The second form can 782 conflict with attributes from other vendors, whereas the first form 783 cannot. 785 It is therefore RECOMMENDED that specifications give names to 786 Attributes which attempt to be globally unique across all RADIUS 787 Attributes. It is RECOMMENDED that vendors use their name as a 788 unique prefix for attribute names, e.g. Livingston-IP-Pool instead of 789 IP-Pool. It is RECOMMENDED that implementations enforce uniqueness 790 on names, which would otherwise lead to ambiguity and problems. 792 We recognise that these suggestions may sometimes be difficult to 793 implement in practice. 795 TLVs SHOULD be named with a unique prefix that is shared among 796 related attributes. For example, a specification that defines a set 797 of TLVs related to time could create attributes named "Time-Zone", 798 "Time-Day", "Time-Hour", "Time-Minute", etc. 800 2.7.2. Attribute Type Identifiers 802 The RADIUS Attribute Type space defines a context for a particular 803 "Extended-Type" field. The "Extended-Type" field allows for 256 804 possible type code values, with values 1 through 240 available for 805 allocation. We define here an identification method that uses a 806 "dotted number" notation similar to that used for Object Identifiers 807 (OIDs), formatted as "Type.Extended-Type". 809 For example, an attribute within the Type space of 241, having 810 Extended-Type of one (1), is uniquely identified as "241.1". 811 Similarly, an attribute within the Type space of 246, having 812 Extended-Type of ten (10), is uniquely identified as "246.10". 814 2.7.3. TLV Identifiers 816 We can extend the Attribute reference scheme defined above for TLVs. 817 This is done by leveraging the "dotted number" notation. As above, 818 we define an additional TLV type space, within the "Extended Type" 819 space, by appending another "dotted number" in order to identify the 820 TLV. This method can be repeated in sequence for nested TLVs. 822 For example, let us say that "245.1" identifies RADIUS Attribute Type 823 245, containing an "Extended Type" of one (1), which is of type 824 "tlv". That attribute will contain 256 possible TLVs, one for each 825 value of the TLV-Type field. The first TLV-Type value of one (1) can 826 then be identified by appending a ".1" to the number of the 827 encapsulating attribute ("241.1"), to yield "241.1.1". Similarly, 828 the sequence "245.2.3.4" identifies RADIUS attribute 245, containing 829 an "Extended Type" of two (2) which is of type "tlv", which in turn 830 contains a TLV with TLV-Type number three (3), which in turn contains 831 another TLV, with TLV-Type number four (4). 833 2.7.4. VSA Identifiers 835 There has historically been no method for numerically addressing 836 VSAs. The "dotted number" method defined here can also be leveraged 837 to create such an addressing scheme. However, as the VSAs are 838 completely under the control of each individual vendor, this section 839 provides a suggested practice, but does not define a standard of any 840 kind. 842 The Vendor-Specific Attribute has been assigned the Attribute number 843 26. It in turn carries a 24-bit Vendor-Id, and possibly additional 844 VSAs. Where the VSAs follow the [RFC2865] Section 5.26 recommended 845 format, a VSA can be identified as "26.Vendor-Id.Vendor-Type". 847 For example, Livingston has Vendor-Id 307, and has defined an 848 attribute "IP-Pool" as number 6. This VSA can be uniquely identified 849 as 26.307.6, but it cannot be uniquely identified by name, as other 850 vendors may have used the same name. 852 Note that there are few restrictions on the size of the numerical 853 values in this notation. The Vendor-Id is a 24-bit number, and the 854 VSA may have been assigned from a 16-bit vendor-specific Attribute 855 Type space. Implementations SHOULD be capable of handling 32-bit 856 numbers at each level of the "dotted number" notation. 858 For example, the company USR has been allocated Vendor-Id 429, and 859 has defined a "Version-Id" attribute as number 32768. This VSA can 860 be uniquely identified as 26.429.32768, and again cannot be uniquely 861 identified by name. 863 Where a VSA is a TLV, the "dotted number" notation can be used as 864 above: 26.Vendor-Id.Vendor-Type.TLV1.TLV2.TLV3 where "TLVn" are the 865 numerical values assigned by the vendor to the different nested TLVs. 867 2.8. Invalid Attributes 869 The term "invalid attribute" is new to this specification. It is 870 defined to mean that the Length field of an Attribute permits the 871 packet to be accepted as not being "malformed". However, the Value 872 field of the attribute does not follow the format required by the 873 data type defined for that Attribute, and therefore the attribute is 874 "malformed". In order to distinguish the two cases, we refer to 875 "malformed" packets, and "invalid attributes". 877 For example, an implementation receives a packet which is well- 878 formed. That packet contains an Attribute allegedly of data type 879 "address", but which has Length not equal to four. In that 880 situation, the packet is well formed, but the attribute is not. 881 Therefore, it is an "invalid attribute". 883 A similar analysis can be performed when an attribute carries TLVs. 884 The encapsulating attribute may be well formed, but the TLV may be an 885 "invalid attribute". The existence of an "invalid attribute" in a 886 packet or attribute MUST NOT result in the implementation discarding 887 the entire packet, or treating the packet as a negative 888 acknowledgment. Instead, only the "invalid attribute" is treated 889 specially. 891 When an implementation receives an "invalid attribute", it SHOULD be 892 silently discarded, except when the implementation is acting as a 893 proxy (see Section 5.2 for discussion of proxy servers). If it is 894 not discarded, it MUST NOT be handled in the same manner as a well- 895 formed attribute. For example, receiving an Attribute of data type 896 "address" containing less than four octets, or more than four octets 897 of data means that the Attribute MUST NOT be treated as being of data 898 type "address". The reason here is that if the attribute does not 899 carry an IPv4 address, the receiver has no idea what format the data 900 is in, and it is therefore not an IPv4 address. 902 For Attributes of type "Long Extended Type", an Attribute is 903 considered to be an "invalid attribute" when it does not match the 904 criteria set out in Section 2.2, above. 906 For Attributes of type "TLV", an Attribute is considered to be an 907 "invalid attribute" when the TLV-Length field allows the 908 encapsulating Attribute to be parsed, but the TLV-Value field does 909 not match the criteria for that TLV. Implementations SHOULD NOT 910 treat the "invalid attribute" property as being transitive. That is, 911 the Attribute encapsulating the "invalid attribute" SHOULD NOT be 912 treated as an "invalid attribute". That encapsulating Attribute 913 might contain multiple TLVs, only one of which is an "invalid 914 attribute". 916 However, a TLV definition may require particular sub-TLVs to be 917 present, and/or to have specific values. If a sub-TLV is missing, or 918 contains incorrect value(s), or is an "invalid attribute", then the 919 encapsulating TLV SHOULD be treated as an "invalid attribute". This 920 requirement ensures that strongly connected TLVs are handled either 921 as a coherent whole, or are ignored entirely. 923 It is RECOMMENDED that Attributes with unknown Type, Ext-Type, TLV- 924 Type, or VSA-Type are treated as "invalid attributes". This 925 recommendation is compatible with the suggestion in [RFC2865] Section 926 5, that implementations "MAY ignore Attributes with an unknown Type". 928 3. Attribute Definitions 930 We define four (4) attributes of "Extended Type", which are allocated 931 from the "Reserved" Attribute Type codes of 241, 242, 243, and 244. 932 We also define two (2) attributes of "Long Extended Type", which are 933 allocated from the "Reserved" Attribute Type codes of 245 and 246. 935 Type Name 936 ---- ---- 937 241 Extended-Type-1 938 242 Extended-Type-2 939 243 Extended-Type-3 940 244 Extended-Type-4 941 245 Long-Extended-Type-1 942 246 Long-Extended-Type-2 944 The rest of this section gives a detailed definition for each 945 Attribute based on the above summary. 947 3.1. Extended-Type-1 949 Description 951 This attribute encapsulates attributes of the "Extended Type" 952 format, in the RADIUS Attribute Type Space of 241.{1-255}. 954 A summary of the Extended-Type-1 Attribute format is shown below. 955 The fields are transmitted from left to right. 957 0 1 2 3 958 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 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | Type | Length | Extended-Type | Value ... 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 Type 965 241 for Extended-Type-1. 967 Length 969 >= 4 971 Extended-Type 973 The Extended-Type field is one octet. Up-to-date values of this 974 field are specified in the 241.{1-255} RADIUS Attribute Type 975 Space, according to the policies and rules described in Section 976 10. Further definition of this field is given in Section 2.1, 977 above. 979 Value 981 The Value field is one or more octets. 983 Implementations supporting this specification MUST use the 984 Identifier of "Type.Extended-Type" to determine the interpretation 985 of the Value field. 987 3.2. Extended-Type-2 989 Description 991 This attribute encapsulates attributes of the "Extended Type" 992 format, in the RADIUS Attribute Type Space of 242.{1-255}. 994 A summary of the Extended-Type-2 Attribute format is shown below. 995 The fields are transmitted from left to right. 997 0 1 2 3 998 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 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | Type | Length | Extended-Type | Value ... 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 Type 1005 242 for Extended-Type-2. 1007 Length 1009 >= 4 1011 Extended-Type 1013 The Extended-Type field is one octet. Up-to-date values of this 1014 field are specified in the 242.{1-255} RADIUS Attribute Type 1015 Space, according to the policies and rules described in Section 1016 10. Further definition of this field is given in Section 2.1, 1017 above. 1019 Value 1021 The Value field is one or more octets. 1023 Implementations supporting this specification MUST use the 1024 Identifier of "Type.Extended-Type" to determine the interpretation 1025 of the Value field 1027 3.3. Extended-Type-3 1029 Description 1031 This attribute encapsulates attributes of the "Extended Type" 1032 format, in the RADIUS Attribute Type Space of 243.{1-255}. 1034 A summary of the Extended-Type-3 Attribute format is shown below. 1035 The fields are transmitted from left to right. 1037 0 1 2 3 1038 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 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | Type | Length | Extended-Type | Value ... 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 Type 1046 243 for Extended-Type-3. 1048 Length 1050 >= 4 1052 Extended-Type 1054 The Extended-Type field is one octet. Up-to-date values of this 1055 field are specified in the 243.{1-255} RADIUS Attribute Type 1056 Space, according to the policies and rules described in Section 1057 10. Further definition of this field is given in Section 2.1, 1058 above. 1060 Value 1062 The Value field is one or more octets. 1064 Implementations supporting this specification MUST use the 1065 Identifier of "Type.Extended-Type" to determine the interpretation 1066 of the Value field. 1068 3.4. Extended-Type-4 1070 Description 1072 This attribute encapsulates attributes of the "Extended Type" 1073 format, in the RADIUS Attribute Type Space of 244.{1-255}. 1075 A summary of the Extended-Type-4 Attribute format is shown below. 1076 The fields are transmitted from left to right. 1078 0 1 2 3 1079 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 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | Type | Length | Extended-Type | Value ... 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 Type 1086 244 for Extended-Type-4. 1088 Length 1089 >= 4 1091 Extended-Type 1093 The Extended-Type field is one octet. Up-to-date values of this 1094 field are specified in the 244.{1-255} RADIUS Attribute Type 1095 Space, according to the policies and rules described in Section 1096 10. Further definition of this field is given in Section 2.1, 1097 above. 1099 Value 1101 The Value field is one or more octets. 1103 Implementations supporting this specification MUST use the 1104 Identifier of "Type.Extended-Type" to determine the interpretation 1105 of the Value Field. 1107 3.5. Long-Extended-Type-1 1109 Description 1111 This attribute encapsulates attributes of the "Long Extended Type" 1112 format, in the RADIUS Attribute Type Space of 245.{1-255}. 1114 A summary of the Long-Extended-Type-1 Attribute format is shown 1115 below. The fields are transmitted from left to right. 1117 0 1 2 3 1118 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 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | Type | Length | Extended-Type |M| Reserved | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | Value ... 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 Type 1127 245 for Long-Extended-Type-1 1129 Length 1131 >= 5 1133 Extended-Type 1135 The Extended-Type field is one octet. Up-to-date values of this 1136 field are specified in the 245.{1-255} RADIUS Attribute Type 1137 Space, according to the policies and rules described in Section 1138 10. Further definition of this field is given in Section 2.1, 1139 above. 1141 M (More) 1143 The More field is one (1) bit in length, and indicates whether or 1144 not the current attribute contains "more" than 251 octets of data. 1145 Further definition of this field is given in Section 2.2, above. 1147 Reserved 1149 This field is 7 bits long, and is reserved for future use. 1150 Implementations MUST set it to zero (0) when encoding an attribute 1151 for sending in a packet. The contents SHOULD be ignored on 1152 reception. 1154 Value 1156 The Value field is one or more 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. 1213 Implementations supporting this specification MUST use the 1214 Identifier of "Type.Extended-Type" to determine the interpretation 1215 of the Value field. 1217 4. Vendor Specific Attributes 1219 We define six new attributes which can carry Vendor Specific 1220 information. We define four (4) attributes of the "Extended Type" 1221 format, with Type codes (241.26, 242.26, 243.26, 244.26), using the 1222 "evs" data type. We also define two (2) attributes using "Long 1223 Extended Type" format, with Type codes (245.26, 246.26), which are of 1224 the "evs" data type. 1226 Type.Extended-Type Name 1227 ------------------ ---- 1228 241.26 Extended-Vendor-Specific-1 1229 242.26 Extended-Vendor-Specific-2 1230 243.26 Extended-Vendor-Specific-3 1231 244.26 Extended-Vendor-Specific-4 1232 245.26 Extended-Vendor-Specific-5 1233 246.26 Extended-Vendor-Specific-6 1235 The rest of this section gives a detailed definition for each 1236 Attribute based on the above summary. 1238 4.1. Extended-Vendor-Specific-1 1240 Description 1242 This attribute defines a RADIUS Type Code of 241.26, using the 1243 "evs" data type. 1245 A summary of the Extended-Vendor-Specific-1 Attribute format is shown 1246 below. The fields are transmitted from left to right. 1248 0 1 2 3 1249 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 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 | Type | Length | Extended-Type | Vendor-Id ... 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 ... Vendor-Id (cont) | Vendor-Type | 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 | Value .... 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 Type.Extended-Type 1260 241.26 for Extended-Vendor-Specific-1 1262 Length 1264 >= 9 1266 Vendor-Id 1268 The 4 octets are the Network Management Private Enterprise Code 1269 [PEN] of the Vendor in network byte order. 1271 Vendor-Type 1273 The Vendor-Type field is one octet. Values are assigned at the 1274 sole discretion of the Vendor. 1276 Value 1278 The Value field is one or more octets. The actual format of the 1279 information is site or application specific, and a robust 1280 implementation SHOULD support the field as undistinguished octets. 1282 The codification of the range of allowed usage of this field is 1283 outside the scope of this specification. 1285 The length of the Value field is eight (8) less than the value of 1286 the Length field. 1288 Implementations supporting this specification MUST use the 1289 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1290 determine the interpretation of the Value field. 1292 4.2. Extended-Vendor-Specific-2 1294 Description 1296 This attribute defines a RADIUS Type Code of 242.26, using the 1297 "evs" data type. 1299 A summary of the Extended-Vendor-Specific-2 Attribute format is shown 1300 below. The fields are transmitted from left to right. 1302 0 1 2 3 1303 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 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 | Type | Length | Extended-Type | Vendor-Id ... 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 ... Vendor-Id (cont) | Vendor-Type | 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 | Value .... 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 Type.Extended-Type 1314 242.26 for Extended-Vendor-Specific-2 1316 Length 1318 >= 9 1320 Vendor-Id 1322 The 4 octets are the Network Management Private Enterprise Code 1323 [PEN] of the Vendor in network byte order. 1325 Vendor-Type 1327 The Vendor-Type field is one octet. Values are assigned at the 1328 sole discretion of the Vendor. 1330 Value 1332 The Value field is one or more octets. The actual format of the 1333 information is site or application specific, and a robust 1334 implementation SHOULD support the field as undistinguished octets. 1336 The codification of the range of allowed usage of this field is 1337 outside the scope of this specification. 1339 The length of the Value field is eight (8) less than the value of 1340 the Length field. 1342 Implementations supporting this specification MUST use the 1343 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1344 determine the interpretation of the Value field. 1346 4.3. Extended-Vendor-Specific-3 1348 Description 1350 This attribute defines a RADIUS Type Code of 243.26, using the 1351 "evs" data type. 1353 A summary of the Extended-Vendor-Specific-3 Attribute format is shown 1354 below. The fields are transmitted from left to right. 1356 0 1 2 3 1357 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 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 | Type | Length | Extended-Type | Vendor-Id ... 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 ... Vendor-Id (cont) | Vendor-Type | 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 | Value .... 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 Type.Extended-Type 1368 243.26 for Extended-Vendor-Specific-3 1370 Length 1372 >= 9 1374 Vendor-Id 1375 The 4 octets are the Network Management Private Enterprise Code 1376 [PEN] of the Vendor in network byte order. 1378 Vendor-Type 1380 The Vendor-Type field is one octet. Values are assigned at the 1381 sole discretion of the Vendor. 1383 Value 1385 The Value field is one or more octets. The actual format of the 1386 information is site or application specific, and a robust 1387 implementation SHOULD support the field as undistinguished octets. 1389 The codification of the range of allowed usage of this field is 1390 outside the scope of this specification. 1392 The length of the Value field is eight (8) less than the value of 1393 the Length field. 1395 Implementations supporting this specification MUST use the 1396 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1397 determine the interpretation of the Value field. 1399 4.4. Extended-Vendor-Specific-4 1401 Description 1403 This attribute defines a RADIUS Type Code of 244.26, using the 1404 "evs" data type. 1406 A summary of the Extended-Vendor-Specific-3 Attribute format is shown 1407 below. The fields are transmitted from left to right. 1409 0 1 2 3 1410 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 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 | Type | Length | Extended-Type | Vendor-Id ... 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 ... Vendor-Id (cont) | Vendor-Type | 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 | Value .... 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 Type.Extended-Type 1421 244.26 for Extended-Vendor-Specific-4 1423 Length 1425 >= 9 1427 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 .... 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 Type.Extended-Type 1476 245.26 for Extended-Vendor-Specific-5 1478 Length 1480 >= 10 (first fragment) 1481 >= 5 (subsequent fragments) 1483 When a VSA is fragmented across multiple Attributes, only the 1484 first Attribute contains the Vendor-Id and Vendor-Type fields. 1485 Subsequent Attributes contain fragments of the Value field only. 1487 M (More) 1489 The More field is one (1) bit in length, and indicates whether or 1490 not the current attribute contains "more" than 251 octets of data. 1491 Further definition of this field is given in Section 2.2, above. 1493 Reserved 1495 This field is 7 bits long, and is reserved for future use. 1496 Implementations MUST set it to zero (0) when encoding an attribute 1497 for sending in a packet. The contents SHOULD be ignored on 1498 reception. 1500 Vendor-Id 1502 The 4 octets are the Network Management Private Enterprise Code 1503 [PEN] of the Vendor in network byte order. 1505 Vendor-Type 1507 The Vendor-Type field is one octet. Values are assigned at the 1508 sole discretion of the Vendor. 1510 Value 1512 The Value field is one or more octets. The actual format of the 1513 information is site or application specific, and a robust 1514 implementation SHOULD support the field as undistinguished octets. 1516 The codification of the range of allowed usage of this field is 1517 outside the scope of this specification. 1519 Implementations supporting this specification MUST use the 1520 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1521 determine the interpretation of the Value field. 1523 4.6. Extended-Vendor-Specific-6 1525 Description 1527 This attribute defines a RADIUS Type Code of 246.26, using the 1528 "evs" data type. 1530 A summary of the Extended-Vendor-Specific-6 Attribute format is shown 1531 below. The fields are transmitted from left to right. 1533 0 1 2 3 1534 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 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 | Type | Length | Extended-Type |M| Reserved | 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 | Vendor-Id | 1539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1540 | Vendor-Type | Value .... 1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 Type.Extended-Type 1545 246.26 for Extended-Vendor-Specific-6 1547 Length 1549 >= 10 (first fragment) 1550 >= 5 (subsequent fragments) 1552 When a VSA is fragmented across multiple Attributes, only the 1553 first Attribute contains the Vendor-Id and Vendor-Type fields. 1554 Subsequent Attributes contain fragments of the Value field only. 1556 M (More) 1558 The More field is one (1) bit in length, and indicates whether or 1559 not the current attribute contains "more" than 251 octets of data. 1560 Further definition of this field is given in Section 2.2, above. 1562 Reserved 1564 This field is 7 bits long, and is reserved for future use. 1565 Implementations MUST set it to zero (0) when encoding an attribute 1566 for sending in a packet. The contents SHOULD be ignored on 1567 reception. 1569 Vendor-Id 1571 The 4 octets are the Network Management Private Enterprise Code 1572 [PEN] of the Vendor in network byte order. 1574 Vendor-Type 1576 The Vendor-Type field is one octet. Values are assigned at the 1577 sole discretion of the Vendor. 1579 Value 1581 The Value field is one or more octets. The actual format of the 1582 information is site or application specific, and a robust 1583 implementation SHOULD support the field as undistinguished octets. 1585 The codification of the range of allowed usage of this field is 1586 outside the scope of this specification. 1588 Implementations supporting this specification MUST use the 1589 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1590 determine the interpretation of the Value field. 1592 5. Compatibility with traditional RADIUS 1594 There are a number of potential compatibility issues with traditional 1595 RADIUS, as defined in [RFC6158] and earlier. This section describes 1596 them. 1598 5.1. Attribute Allocation 1600 Some vendors have used Attribute Type codes from the "Reserved" 1601 space, as part of vendor-defined dictionaries. This practice is 1602 considered anti-social behavior, as noted in [RFC6158]. These vendor 1603 definitions conflict with the attributes in the RADIUS Attribute Type 1604 space. The conflicting definitions may make it difficult for 1605 implementations to support both those Vendor Attributes, and the new 1606 Extended Attribute formats. 1608 We RECOMMEND that RADIUS client and server implementations delete all 1609 references to these improperly defined attributes. Failing that, we 1610 RECOMMEND that RADIUS server implementations have a per-client 1611 configurable flag which indicates which type of attributes are being 1612 sent from the client. If the flag is set to "Non-Standard 1613 Attributes", the conflicting attributes can be interpreted as being 1614 improperly defined Vendor Specific Attributes. If the flag is set the 1615 "IETF Attributes", the attributes MUST be interpreted as being of the 1616 Extended Attributes format. The default SHOULD be to interpret the 1617 attributes as being of the Extended Attributes format. 1619 Other methods of determining how to decode the attributes into a 1620 "correct" form are NOT RECOMMENDED. Those methods are likely to be 1621 fragile and prone to error. 1623 We RECOMMEND that RADIUS server implementations re-use the above flag 1624 to determine which type of attributes to send in a reply message. If 1625 the request is expected to contain the improperly defined attributes, 1626 the reply SHOULD NOT contain Extended Attributes. If the request is 1627 expected to contain Extended Attributes, the reply MUST NOT contain 1628 the improper Attributes. 1630 RADIUS clients will have fewer issues than servers. Clients MUST NOT 1631 send improperly defined Attributes in a request. For replies, 1632 clients MUST interpret attributes as being of the Extended Attributes 1633 format, instead of the improper definitions. These requirements 1634 impose no change in the RADIUS specifications, as such usage by 1635 vendors has always been in conflict with the standard requirements 1636 and the standards process. 1638 Existing clients that send these improperly defined attributes 1639 usually have a configuration setting which can disable this behavior. 1640 We RECOMMEND that vendors ship products with the default set to 1641 "disabled". We RECOMMEND that administrators set this flag to 1642 "disabled" on all equipment that they manage. 1644 5.2. Proxy Servers 1646 RADIUS Proxy servers will need to forward Attributes having the new 1647 format, even if they do not implement support for the encoding and 1648 decoding of those attributes. We remind implementers of the 1649 following text in [RFC2865] Section 2.3: 1651 The forwarding server MUST NOT change the order of any attributes 1652 of the same type, including Proxy-State. 1654 This requirement solves some of the issues related to proxying of the 1655 new format, but not all. The reason is that proxy servers are 1656 permitted to examine the contents of the packets that they forward. 1657 Many proxy implementations not only examine the attributes, but they 1658 refuse to forward attributes which they do not understand (i.e. 1659 attributes for which they have no local dictionary definitions). 1661 This practice is NOT RECOMMENDED. Proxy servers SHOULD forward 1662 attributes, even ones which they do not understand, or which are not 1663 in a local dictionary. When forwarded, these attributes SHOULD be 1664 sent verbatim, with no modifications or changes. This requirement 1665 includes "invalid attributes", as there may be some other system in 1666 the network which understands them. 1668 The only exception to this recommendation is when local site policy 1669 dictates that filtering of attributes has to occur. For example, a 1670 filter at a visited network may require removal of certain 1671 authorization rules which apply to the home network, but not to the 1672 visited network. This filtering can sometimes be done even when the 1673 contents of the attributes are unknown, such as when all Vendor- 1674 Specific Attributes are designated for removal. 1676 As seen in [EDUROAM] many proxies do not follow these practices for 1677 unknown Attributes. Some proxies filter out unknown attributes or 1678 attributes which have unexpected lengths (24%, 17/70), some truncate 1679 the attributes to the "expected" length (11%, 8/70), some discard the 1680 request entirely (1%, 1/70), with the rest (63%, 44/70) following the 1681 recommended practice of passing the attributes verbatim. It will be 1682 difficult to widely use the Extended Attributes format until all non- 1683 conformant proxies are fixed. We therefore RECOMMEND that all 1684 proxies which do not support the Extended Attributes (241 through 1685 246) define them as being of data type "string", and delete all other 1686 local definitions for those attributes. 1688 This last change should enable wider usage of the Extended Attributes 1689 format. 1691 6. Guidelines 1693 This specification proposes a number of changes to RADIUS, and 1694 therefore requires a set of guidelines, as has been done in 1695 [RFC6158]. These guidelines include suggestions around design, 1696 interaction with IANA, usage, and implementation of attributes using 1697 the new formats. 1699 6.1. Updates to RFC 6158 1701 This specification updates [RFC6158] by adding the data types "evs", 1702 "tlv" and "integer64"; defining them to be "basic" data types; and 1703 permitting their use subject to the restrictions outlined below. 1705 The recommendations for the use of the new data types and attribute 1706 formats are given below. 1708 6.2. Guidelines for Simple Data Types 1710 [RFC6158] Section A.2.1 says in part: 1712 * Unsigned integers of size other than 32 bits. 1714 SHOULD be replaced by an unsigned integer of 32 bits. There is 1715 insufficient justification to define a new size of integer. 1717 We update that specification to permit unsigned integers of 64 bits, 1718 for the reasons defined above in Section 2.5. The updated text is as 1719 follows: 1721 * Unsigned integers of size other than 32 or 64 bits. 1722 SHOULD be replaced by an unsigned integer of 32 or 64 bits. 1723 There is insufficient justification to define a new size 1724 of integer. 1726 That section later continues with the following list item: 1728 * Nested attribute-value pairs (AVPs). 1729 Attributes should be defined in a flat typespace. 1731 We update that specification to permit nested TLVs, as defined in 1732 this document: 1734 * Nested attribute-value pairs (AVPs) using the extended 1735 attribute format MAY be used. All other nested AVP or TLV 1736 formats MUST NOT be used. 1738 The [RFC6158] recommendations for "basic" data types apply to the 1739 three types listed above. All other recommendations given in 1740 [RFC6158] for "basic" data types remain unchanged. 1742 6.3. Guidelines for Complex Data Types 1744 [RFC6158] Section 2.1 says: 1746 Complex data types MAY be used in situations where they reduce 1747 complexity in non-RADIUS systems or where using the basic data 1748 types 1749 would be awkward (such as where grouping would be required in 1750 order 1751 to link related attributes). 1753 Since the extended attribute format allows for grouping of complex 1754 types via TLVs, the guidelines for complex data types need to be 1755 updated as follows: 1757 [RFC6158], Section 3.2.4, describes situations in which complex 1758 data types might be appropriate. They SHOULD NOT be used even in 1759 those situations, without careful consideration of the described 1760 limitations. In all other cases not covered by the complex data 1761 type exceptions, complex data types MUST NOT be used. Instead, 1762 complex data types MUST be decomposed into TLVs. 1764 The checklist in Appendix A.2.2 is similarly updated to add a new 1765 requirement at the top of that section, 1767 Does the attribute: 1769 * define a complex type which can be represented via TLVs? 1771 If so, this data type MUST be represented via TLVs. 1773 Note that this requirement does not over-ride Section A.1, which 1774 permits the transport of complex types in certain situations. 1776 All other recommendations given in [RFC6158] for "complex" data types 1777 remain unchanged. 1779 6.4. Design Guidelines For the New Types 1781 This section gives design guidelines for specifications defining 1782 attributes using the new format. The items listed below are not 1783 exhaustive. As experience is gained with the new formats, later 1784 specifications may define additional guidelines. 1786 * The data type "evs" MUST NOT be used for standard RADIUS 1787 Attributes, or for TLVs, or for VSAs. 1789 * The data type "tlv" SHOULD NOT be used for standard RADIUS 1790 attributes. 1792 * [RFC2866] "tagged" attributes MUST NOT be defined in the 1793 Extended-Type space. The "tlv" data type should be used instead 1794 to group attributes. 1796 * The "integer64" data type MAY be used in any RADIUS attribute. 1797 The use of 64-bit integers was not recommended in [RFC6158], 1798 but their utility is now evident. 1800 * Any attribute which is allocated from the "long extended space" of 1801 data type "text", "string", or "tlv" can potentially carry more 1802 than 251 octets of data. Specifications defining such attributes 1803 SHOULD define a maximum length to guide implementations. 1805 All other recommendations given in [RFC6158] for attribute design 1806 guidelines apply to attributes using the "short extended space" and 1807 "long extended space". 1809 6.5. TLV Guidelines 1811 The following items give design guidelines for specifications using 1812 TLVs. 1814 * when multiple attributes are intended to be grouped or managed 1815 together, the use of TLVs to group related attributes is 1816 RECOMMENDED. 1818 * more than 4 layers (depth) of TLV nesting is NOT RECOMMENDED. 1820 * Interpretation of an attribute depends only on its type 1821 definition (e.g. Type.Extended-Type.TLV-Type), and 1822 not on its encoding or location in the RADIUS packet. 1824 * Where a group of TLVs is strictly defined, and not expected to 1825 change, and totals less than 247 octets of data, they SHOULD 1826 request allocation from the "short extended space". 1828 * Where a group of TLVs is loosely defined, or is expected to change, 1829 they SHOULD request allocation from the "long extended space". 1831 All other recommendations given in [RFC6158] for attribute design 1832 guidelines apply to attributes using the TLV format. 1834 6.6. Allocation Request Guidelines 1836 The following items give guidelines for allocation requests made in a 1837 RADIUS specification. 1839 * Discretion is recommended when requesting allocation of attributes. 1840 The new space is much larger than the old one, but it is not 1841 infinite. 1843 * Specifications which allocate many attributes MUST NOT request that 1844 allocation be made from the standard space. That space is under 1845 allocation pressure, and the extended space is more suitable for 1846 large allocations. As a guideline, we suggest that one 1847 specification allocating twenty percent (20%) or more of the 1848 standard space would meet the above criteria. 1850 * Specifications which allocate many related attributes SHOULD define 1851 one or more TLVs to contain related attributes. 1853 * Specifications SHOULD request allocation from a specific space. 1854 The IANA considerations given in Section 9, below, give instruction 1855 to IANA, but authors should assist IANA where possible. 1857 * Specifications of an attribute which encodes 252 octets or less of 1858 data MAY request allocation from the "short extended space". 1860 * Specifications of an attribute which always encode less than 253 1861 octets of data MUST NOT request allocation from the long extended 1862 space. The standard space, or the short extended space MUST be 1863 used instead. 1865 * Specifications of an attribute which encodes 253 octets or more of 1866 data MUST request allocation from the "long extended space". 1868 * When the extended space is nearing exhaustion, a new specification 1869 will have to be written which requests allocation of one or more 1870 RADIUS Attributes from the "Reserved" portion of the standard 1871 space, values 247-255, using an appropriate format ("Short 1872 Extended Type", or "Long Extended Type") 1874 An allocation request made in a specification SHOULD use one of the 1875 following formats when allocating an attribute type code: 1877 * TBDn - request allocation of an attribute from the "standard 1878 space". The value "n" should be "1" or more, to track individual 1879 attributes which are to be allocated. 1881 * SHORT-TBDn - request allocation of an attribute from the "short 1882 extended space". The value "n" should be "1" or more, to track 1883 individual attributes which are to be allocated. 1885 * LONG-TBDn - request allocation of an attribute from the "long 1886 extended space". The value "n" should be "1" or more, to track 1887 individual attributes which are to be allocated. 1889 These guidelines should help specification authors and IANA 1890 communicate effectively and clearly. 1892 6.7. Allocation Requests Guidelines for TLVs 1894 Specifications may allocate a new attribute of type TLV, and at the 1895 same time, allocate sub-attributes within that TLV. These 1896 specifications SHOULD request allocation of specific values for the 1897 sub-TLV. The "dotted number" notation MUST be used. 1899 For example, a specification may request allocation of a TLV as 1900 SHORT-TBD1. Within that attribute, it could request allocation of 1901 three sub-TLVs, as SHORT-TBD1.1, SHORT-TBD1.2, and SHORT-TBD1.3. 1903 Specifications may request allocation of additional sub-TLVs within 1904 an existing attribute of type TLV. Those specifications SHOULD use 1905 the "TBDn" format for every entry in the "dotted number" notation. 1907 For example, a specification may request allocation within an 1908 existing TLV, with "dotted number" notation MM.NN. Within that 1909 attribute, the specification could request allocation of three sub- 1910 TLVs, as MM.NN.TBD1, MM.NN.TBD2, and MM.NN.TBD3. 1912 6.8. Implementation Guidelines 1914 * RADIUS client implementations SHOULD support this specification, 1915 in order to permit the easy deployment of specifications using 1916 the changes defined herein. 1918 * RADIUS server implementations SHOULD support this specification, 1919 in order to permit the easy deployment of specifications using 1920 the changes defined herein. 1922 * RADIUS proxy servers MUST follow the specifications in section 5.2 1924 6.9. Vendor Guidelines 1926 * Vendors SHOULD use the existing Vendor-Specific Attribute Type 1927 space in preference to the new Extended-Vendor-Specific 1928 attributes, as this specification may take time to become widely 1929 deployed. 1931 * Vendors SHOULD implement this specification. The changes to 1932 RADIUS are relatively small, and are likely to quickly be used 1933 in new specifications. 1935 7. Rationale for This Design 1937 The path to extending the RADIUS protocol has been long and arduous. 1938 A number of proposals have been made and discarded by the RADEXT 1939 working group. These proposals have been judged to be either too 1940 bulky, too complex, too simple, or to be unworkable in practice. We 1941 do not otherwise explain here why earlier proposals did not obtain 1942 working group consensus. 1944 The changes outlined here have the benefit of being simple, as the 1945 "Extended Type" format requires only a one octet change to the 1946 Attribute format. The downside is that the "Long Extended Type" 1947 format is awkward, and the 7 Reserved bits will likely never be used 1948 for anything. 1950 7.1. Attribute Audit 1952 An audit of almost five thousand publicly available attributes [ATTR] 1953 (2010), shows the statistics summarized below. The attributes include 1954 over 100 Vendor dictionaries, along with the IANA assigned 1955 attributes: 1957 Count Data Type 1958 ----- --------- 1959 2257 integer 1960 1762 text 1961 273 IPv4 Address 1962 225 string 1963 96 other data types 1964 35 IPv6 Address 1965 18 date 1966 10 integer64 1967 4 Interface Id 1968 3 IPv6 Prefix 1970 4683 Total 1972 The entries in the "Data Type" column are data types recommended by 1973 [RFC6158], along with "integer64". The "other data types" row 1974 encompasses all other data types, including complex data types and 1975 data types transporting opaque data. 1977 We see that over half of the attributes encode less than 16 octets of 1978 data. It is therefore important to have an extension mechanism which 1979 adds as little as possible to the size of these attributes. Another 1980 result is that the overwhelming majority of attributes use simple 1981 data types. 1983 Of the attributes defined above, 177 were declared as being inside of 1984 a TLV. This is approximately 4% of the total. We did not 1985 investigate whether additional attributes were defined in a flat name 1986 space, but could have been defined as being inside of a TLV. We 1987 expect that the number could be as high as 10% of attributes. 1989 Manual inspection of the dictionaries shows that approximately 20 (or 1990 0.5%) attributes have the ability to transport more than 253 octets 1991 of data. These attributes are divided between VSAs, and a small 1992 number of standard Attributes such as EAP-Message. 1994 The results of this audit and analysis is reflected in the design of 1995 the extended attributes. The extended format has minimal overhead, 1996 it permits TLVs, and it has support for "long" attributes. 1998 8. Diameter Considerations 2000 The attribute formats defined in this specification need to be 2001 transported in Diameter. While Diameter supports attributes longer 2002 than 253 octets and grouped attributes, we do not use that 2003 functionality here. Instead, we define the simplest possible 2004 encapsulation method. 2006 The new formats MUST be treated the same as traditional RADIUS 2007 attributes when converting from RADIUS to Diameter, or vice versa. 2008 That is, the new attribute space is not converted to any "extended" 2009 Diameter attribute space. Fragmented attributes are not converted to 2010 a single long Diameter attribute. The new EVS data types are not 2011 converted to Diameter attributes with the "V" bit set. 2013 In short, this document mandates no changes for existing RADIUS to 2014 Diameter, or Diameter to RADIUS gateways. 2016 9. Examples 2018 A few examples are presented here in order to illustrate the encoding 2019 of the new attribute formats. These examples are not intended to be 2020 exhaustive, as many others are possible. For simplicity, we do not 2021 show complete packets, only attributes. 2023 The examples are given using a domain-specific language implemented 2024 by the program given in Appendix A. The language is line oriented, 2025 and composed of a sequence of lines matching the grammar ([RFC5234]) 2026 given below: 2028 Identifier = 1*DIGIT *( "." 1*DIGIT ) 2030 HEXCHAR = HEXDIG HEXDIG 2032 STRING = DQUOTE 1*CHAR DQUOTE 2034 TLV = "{" SP 1*DIGIT SP DATA SP "}" 2036 DATA = (HEXCHAR *(SP HEXCHAR)) / (TLV *(SP TLV)) / STRING 2038 LINE = Identifier SP DATA 2040 The program has additional restrictions on its input that are not 2041 reflected in the above grammar. For example, the portions of the 2042 Identifier which refer to Type and Extended-Type are limited to 2043 values between 1 and 255. We trust that the source code in Appendix 2044 A is clear, and that these restrictions do not negatively affect the 2045 comprehensibility of the examples. 2047 The program reads the input text, and interprets it as a set of 2048 instructions to create RADIUS Attributes. It then prints the hex 2049 encoding of those attributes. It implements the minimum set of 2050 functionality which achieves that goal. This minimalism means that 2051 it does not use attribute dictionaries; it does not implement support 2052 for RADIUS data types; it can be used to encode attributes with 2053 invalid data fields; and there is no requirement for consistency from 2054 one example to the next. For example, it can be used to encode a 2055 User-Name attribute which contains non-UTF8 data, or a Framed-IP- 2056 Address which contains 253 octets of ASCII data. As a result, it 2057 MUST NOT be used to create RADIUS Attributes for transport in a 2058 RADIUS message. 2060 However, the program correctly encodes the RADIUS attribute fields of 2061 "Type", "Length", "Extended-Type", "More", "Reserved", "Vendor-Id", 2062 "Vendor-Type", and "Vendor-Length". It encodes RADIUS attribute data 2063 types "evs" and TLV. It can therefore be used to encode example 2064 attributes from inputs which are humanly readable. 2066 We do not give examples of "malformed" or "invalid attributes". We 2067 also note that the examples show format, rather than consistent 2068 meaning. A particular Attribute Type code may be used to demonstrate 2069 two different formats. In real specifications, attributes have a 2070 static definitions based on their type code. 2072 The examples given below are strictly for demonstration purposes 2073 only, and do not provide a standard of any kind. 2075 9.1. Extended Type 2077 The following are a series of examples of the "Extended Type" format. 2079 Attribute encapsulating textual data. 2081 241.1 "bob" 2082 -> f1 06 01 62 6f 62 2084 Attribute encapsulating a TLV with TLV-Type of one (1). 2086 241.2 { 1 23 45 } 2087 -> f1 07 02 01 04 23 45 2089 Attribute encapsulating two TLVs, one after the other. 2091 241.2 { 1 23 45 } { 2 67 89 } 2092 -> f1 0b 02 01 04 23 45 02 04 67 89 2094 Attribute encapsulating two TLVs, where the second TLV is itself 2095 encapsulating a TLV. 2097 241.2 { 1 23 45 } { 3 { 1 ab cd } } 2098 -> f1 0d 02 01 04 23 45 03 06 01 04 ab cd 2100 Attribute encapsulating two TLVs, where the second TLV is itself 2101 encapsulating two TLVs. 2103 241.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } 2104 -> f1 12 02 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f 2106 Attribute encapsulating a TLV, which in turn encapsulates a TLV, 2107 to a depth of 5 nestings. 2109 241.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } 2110 -> f1 0f 01 01 0c 02 0a 03 08 04 06 05 04 cd ef 2112 Attribute encapsulating an extended Vendor Specific attribute, 2113 with Vendor-Id of 1, and Vendor-Type of 4, which in turn 2114 encapsulates textual data. 2116 241.26.1.4 "test" 2117 -> f1 0c 1a 00 00 00 01 04 74 65 73 74 2119 Attribute encapsulating an extended Vendor Specific attribute, with 2120 Vendor-Id of 1, and Vendor-Type of 5, which in turn encapsulates 2121 a TLV with TLV-Type of 3, which encapsulates textual data. 2123 241.26.1.5 { 3 "test" } 2124 -> f1 0e 1a 00 00 00 01 05 03 06 74 65 73 74 2126 9.2. Long Extended Type 2128 The following are a series of examples of the "Long Extended Type" 2129 format. 2131 Attribute encapsulating textual data. 2133 245.1 "bob" 2134 -> f5 07 01 00 62 6f 62 2136 Attribute encapsulating a TLV with TLV-Type of one (1). 2138 245.2 { 1 23 45 } 2139 -> f5 08 02 00 01 04 23 45 2141 Attribute encapsulating two TLVs, one after the other. 2143 245.2 { 1 23 45 } { 2 67 89 } 2144 -> f5 0c 02 00 01 04 23 45 02 04 67 89 2146 Attribute encapsulating two TLVs, where the second TLV is itself 2147 encapsulating a TLV. 2149 245.2 { 1 23 45 } { 3 { 1 ab cd } } 2150 -> f5 0e 02 00 01 04 23 45 03 06 01 04 ab cd 2152 Attribute encapsulating two TLVs, where the second TLV is itself 2153 encapsulating two TLVs. 2155 245.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } 2156 -> f5 13 02 00 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f 2158 Attribute encapsulating a TLV, which in turn encapsulates a TLV, 2159 to a depth of 5 nestings. 2161 245.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } 2162 -> f5 10 01 00 01 0c 02 0a 03 08 04 06 05 04 cd ef 2164 Attribute encapsulating an extended Vendor Specific attribute, 2165 with Vendor-Id of 1, and Vendor-Type of 4, which in turn 2166 encapsulates textual data. 2168 245.26.1.4 "test" 2169 -> f5 0d 1a 00 00 00 00 01 04 74 65 73 74 2171 Attribute encapsulating an extended Vendor Specific attribute, 2172 with Vendor-Id of 1, and Vendor-Type of 5, which in turn 2173 encapsulates a TLV with TLV-Type of 3, which encapsulates 2174 textual data. 2176 245.26.1.5 { 3 "test" } 2177 -> f5 0f 1a 00 00 00 00 01 05 03 06 74 65 73 74 2179 Attribute encapsulating more than 251 octets of data. The "Data" 2180 portions are indented for readability. 2182 245.4 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2183 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2184 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2185 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2186 aaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2187 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2188 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2189 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2190 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbcccccccccccccccccccc 2191 ccccccccccc" 2192 -> f5 ff 04 80 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 aa aa aa aa aa aa aa aa aa aa aa 2195 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2196 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2197 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2198 aa aa aa aa aa aa aa aa aa ab 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 bb bb bb bb bb 2201 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2202 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2203 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2204 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 13 04 00 cc 2205 cc cc cc cc cc cc cc cc cc cc cc cc cc cc 2207 Attribute encapsulating an extended Vendor Specific attribute, 2208 with Vendor-Id of 1, and Vendor-Type of 6, which in turn 2209 encapsulates more than 251 octets of data. 2211 As the VSA encapsulates more than 251 octets of data, it is 2212 split into two RADIUS attributes. The first attribute has the 2213 More field set, and carries the Vendor-Id and Vendor-Type. 2214 The second attribute has the More field clear, and carries 2215 the rest of the data portion of the VSA. Note that the second 2216 attribute does not include the Vendor-Id ad Vendor-Type fields. 2218 The "Data" portions are indented for readability. 2220 245.26.1.6 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2221 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2222 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2223 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2224 aaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2225 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2226 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2227 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2228 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbccccccccccccc 2229 ccccccccccccccccc" 2230 -> f5 ff 1a 80 00 00 00 01 06 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 aa aa aa aa aa aa 2233 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2234 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2235 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2236 aa aa aa aa aa aa aa aa aa aa aa aa aa aa ab 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 bb bb bb bb bb 2239 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2240 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2241 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2242 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 18 1a 00 bb 2243 bb bb bb bb cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 2245 10. IANA Considerations 2247 This document updates [RFC3575] in that it adds new IANA 2248 considerations for RADIUS Attributes. These considerations modify 2249 and extend the IANA considerations for RADIUS, rather than replacing 2250 them. 2252 The IANA considerations of this document are limited to the "RADIUS 2253 Attribute Types" registry. Some Attribute Type values which were 2254 previously marked "Reserved" are now allocated, and the registry is 2255 extended from a simple 8-bit array to a tree-like structure, up to a 2256 maximum depth of 125 nodes. Detailed instructions are given below. 2258 10.1. Attribute Allocations 2260 IANA is requested to move the following Attribute Type values from 2261 "Reserved", to "Allocated", with the corresponding names: 2263 * 241 Extended-Type-1 2264 * 242 Extended-Type-2 2265 * 243 Extended-Type-3 2266 * 244 Extended-Type-4 2267 * 245 Long-Extended-Type-1 2268 * 246 Long-Extended-Type-2 2270 These values serve as an encapsulation layer for the new RADIUS 2271 Attribute Type tree. 2273 10.2. RADIUS Attribute Type Tree 2275 Each of the Attribute Type values allocated above extends the "RADIUS 2276 Attribute Types" to an N-ary tree, via a "dotted number" notation. 2277 Allocation of an Attribute Type value "TYPE" using the new Extended 2278 type format results in allocation of 255 new Attribute Type values, 2279 of format "TYPE.1" through "TYPE.255". Value twenty-six (26) is 2280 assigned as "Extended-Vendor-Specific-*". Values "TYPE.241" through 2281 "TYPE.255" are marked "Reserved". All other values are "Unassigned". 2283 The initial set of Attribute Type values and names assigned by this 2284 document is given below. 2286 * 241 Extended-Attribute-1 2287 * 241.{1-25} Unassigned 2288 * 241.26 Extended-Vendor-Specific-1 2289 * 241.{27-240} Unassigned 2290 * 241.{241-255} Reserved 2291 * 242 Extended-Attribute-2 2292 * 242.{1-25} Unassigned 2293 * 242.26 Extended-Vendor-Specific-2 2294 * 242.{27-240} Unassigned 2295 * 243 Extended-Attribute-3 2296 * 242.{241-255} Reserved 2297 * 243.{1-25} Unassigned 2298 * 243.26 Extended-Vendor-Specific-3 2299 * 243.{27-240} Unassigned 2300 * 243.{241-255} Reserved 2301 * 244 Extended-Attribute-4 2302 * 244.{1-25} Unassigned 2303 * 244.26 Extended-Vendor-Specific-4 2304 * 244.{27-240} Unassigned 2305 * 244.{241-255} Reserved 2306 * 245 Extended-Attribute-5 2307 * 245.{1-25} Unassigned 2308 * 245.26 Extended-Vendor-Specific-5 2309 * 245.{27-240} Unassigned 2310 * 245.{241-255} Reserved 2311 * 246 Extended-Attribute-6 2312 * 246.{1-25} Unassigned 2313 * 245.26 Extended-Vendor-Specific-6 2314 * 246.{27-240} Unassigned 2315 * 246.{241-255} Reserved 2317 As per [RFC5226], the values marked "Unassigned" above are available 2318 via for assignment by IANA in future RADIUS specifications. The 2319 values marked "Reserved" are reserved for future use. 2321 The Extended-Vendor-Specific spaces (TYPE.26) are for Private Use, 2322 and allocations are not managed by IANA. 2324 Allocation of Reserved entries in the extended space requires 2325 Standards Action. 2327 All other allocations in the extended space require IETF Review. 2329 10.3. Allocation Instructions 2331 This section defines what actions IANA needs to take when allocating 2332 new attributes. Different actions are required when allocating 2333 attributes from the standard space, attributes of Extended Type 2334 format, attributes of the "Long Extended Type" format, preferential 2335 allocations, attributes of data type TLV, attributes within a TLV, 2336 and attributes of other data types. 2338 10.3.1. Requested Allocation from the Standard Space 2340 Specifications can request allocation of an Attribute from within the 2341 standard space (e.g. Attribute Type Codes 1 through 255), subject to 2342 the considerations of [RFC3575] and this document. 2344 10.3.2. Requested Allocation from the short extended space 2346 Specifications can request allocation of an Attribute which requires 2347 the format Extended Type, by specifying the short extended space In 2348 that case, IANA should assign the lowest Unassigned number from the 2349 Attribute Type space with the relevant format. 2351 10.3.3. Requested Allocation from the long extended space 2353 Specifications can request allocation of an Attribute which requires 2354 the format "Long Extended Type", by specifying the extended space 2355 (long). In that case, IANA should assign the lowest Unassigned 2356 number from the Attribute Type space with the relevant format. 2358 10.3.4. Allocation Preferences 2360 Specifications which make no request for allocation from a specific 2361 Type Space should have Attributes allocated using the following 2362 criteria: 2364 * when the standard space has no more Unassigned attributes, 2365 all allocations should be performed from the extended space. 2367 * specifications which allocate a small number of attributes 2368 (i.e. less than ten) should have all allocations made from 2369 the standard space. 2371 * specifications which would allocate a more than twenty percent 2372 of 2373 the remaining standard space attributes should have all 2374 allocations made from the extended space. 2376 * specifications which request allocation of an attribute of 2377 data type TLV should have that attribute allocated from the 2378 extended space. 2380 * specifications which request allocation of an attribute 2381 which can transport 253 or more octets of data should have 2382 that attribute allocated from within the long extended space, 2383 We note that Section 6.5, above requires specifications to 2384 request this allocation. 2386 There is otherwise no requirement that all attributes within a 2387 specification be allocated from one type space or another. 2388 Specifications can simultaneously allocate attributes from both the 2389 standard space and the extended space. 2391 10.3.5. Extending the Type Space via TLV Data Type 2393 When specifications request allocation of an attribute of data type 2394 "tlv", that allocation extends the Attribute Type Tree by one more 2395 level. Allocation of an Attribute Type value "TYPE.TLV", with Data 2396 Type TLV, results in allocation of 255 new Attribute Type values, of 2397 format "TYPE.TLV.1" through "TYPE.TLV.255". Values 254-255 are 2398 marked "Reserved". All other values are "Unassigned". Value 26 has 2399 no special meaning. 2401 For example, if a new attribute "Example-TLV" of data type "tlv" is 2402 assigned the identifier "245.1", then the extended tree will be 2403 allocated as below: 2405 * 245.1 Example-TLV 2406 * 245.1.{1-253} Unassigned 2407 * 245.1.{254-255} Reserved 2409 Note that this example does not define an "Example-TLV" attribute. 2411 The Attribute Type Tree can be extended multiple levels in one 2412 specification when the specification requests allocation of nested 2413 TLVs, as discussed below. 2415 10.3.6. Allocation within a TLV 2417 Specifications can request allocation of Attribute Type values within 2418 an Attribute of Data Type TLV. The encapsulating TLV can be 2419 allocated in the same specification, or it can have been previously 2420 allocated. 2422 Specifications need to request allocation within a specific Attribute 2423 Type value (e.g. "TYPE.TLV.*"). Allocations are performed from the 2424 smallest Unassigned value, proceeding to the largest Unassigned 2425 value. 2427 Where the Attribute being allocated is of Data Type TLV, the 2428 Attribute Type tree is extended by one level, as given in the 2429 previous section. Allocations can then be made within that level. 2431 10.3.7. Allocation of Other Data Types 2433 Attribute Type value allocations are otherwise allocated from the 2434 smallest Unassigned value, proceeding to the largest Unassigned 2435 value. e.g. Starting from 241.1, proceeding through 241.255, then to 2436 242.1, through 242.255, etc. 2438 11. Security Considerations 2440 This document defines new formats for data carried inside of RADIUS, 2441 but otherwise makes no changes to the security of the RADIUS 2442 protocol. 2444 Attacks on cryptographic hashes are well known, and are getting 2445 better with time, as discussed in [RFC4270]. The security of the 2446 RADIUS protocol is dependent on MD5 [RFC1311], which has security 2447 issues as discussed in [RFC6151]. It is not known if the issues 2448 described in [RFC6151] apply to RADIUS. For other issues, we 2449 incorporate by reference the security considerations of [RFC6158] 2450 Section 5. 2452 As with any protocol change, code changes are required in order to 2453 implement the new features. These code changes have the potential to 2454 introduce new vulnerabilities in the software. Since the RADIUS 2455 server performs network authentication, it is an inviting target for 2456 attackers. We RECOMMEND that access to RADIUS servers be kept to a 2457 minimum. 2459 12. References 2461 12.1. Normative references 2463 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2464 Requirement Levels", RFC 2119, March, 1997. 2466 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 2467 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2468 2000. 2470 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 2472 [RFC3575] Aboba, B, "IANA Considerations for RADIUS (Remote 2473 Authentication Dial In User Service)", RFC 3575, July 2003. 2475 [RFC5176] Chiba, M, et. al., "Dynamic Authorization Extensions to Remote 2476 Authentication Dial In User Service (RADIUS)", RFC 5176, 2477 January 2008. 2479 [RFC5226] Narten, T. and Alvestrand, H, "Guidelines for Writing an IANA 2480 Considerations Section in RFCs", RFC 5226, May 2008. 2482 [RFC6158] DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC 2483 6158, March 2011. 2485 [PEN] http://www.iana.org/assignments/enterprise-numbers 2487 12.2. Informative references 2489 [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, 2490 April, 1992 2492 [RFC2868] Zorn, G., et al, " RADIUS Attributes for Tunnel Protocol 2493 Support", RFC 2868, June 2000. 2495 [RFC4270] Hoffman, P, and Schneier, B, "Attacks on Cryptographic Hashes 2496 in Internet Protocols", RFC 4270, November 2005. 2498 [RFC5234] Crocker, D. (Ed.), and Overell, P., "Augmented BNF for Syntax 2499 Specifications: ABNF", RFC 5234, October 2005. 2501 [RFC6151] Turner. S. and Chen, L., "Updated Security Considerations for 2502 the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, 2503 March 2011. 2505 [EDUROAM] Internal Eduroam testing page, data retrieved 04 August 2010. 2507 [ATTR] http://github.com/alandekok/freeradius- 2508 server/tree/master/share/, data retrieved September 2010. 2510 Acknowledgments 2512 This document is the result of long discussions in the IETF RADEXT 2513 working group. The authors would like to thank all of the 2514 participants who contributed various ideas over the years. Their 2515 feedback has been invaluable, and has helped to make this 2516 specification better. 2518 Appendix A - Extended Attribute Generator Program 2520 This section contains "C" program source which can be used for 2521 testing. It reads a line-oriented text file, parses it to create 2522 RADIUS formatted attributes, and prints the hex version of those 2523 attributes to standard output. 2525 The input accepts a grammar similar to that given in Section 9, with 2526 some modifications for usability. For example, blank lines are 2527 allowed, lines beginning with a '#' character are interpreted as 2528 comments, numbers (RADIUS Types, etc.) are checked for minimum / 2529 maximum values, and RADIUS Attribute lengths are enforced. 2531 The program is included here for demonstration purposes only, and 2532 does not define a standard of any kind. 2534 ------------------------------------------------------------ 2535 /* 2536 * Copyright (c) 2010 IETF Trust and the persons identified as 2537 * authors of the code. All rights reserved. 2538 * 2539 * Redistribution and use in source and binary forms, with or without 2540 * modification, are permitted provided that the following conditions 2541 * are met: 2542 * 2543 * Redistributions of source code must retain the above copyright 2544 * notice, this list of conditions and the following disclaimer. 2545 * 2546 * Redistributions in binary form must reproduce the above copyright 2547 * notice, this list of conditions and the following disclaimer in 2548 * the documentation and/or other materials provided with the 2549 * distribution. 2550 * 2551 * Neither the name of Internet Society, IETF or IETF Trust, nor the 2552 * names of specific contributors, may be used to endorse or promote 2553 * products derived from this software without specific prior written 2554 * permission. 2555 * 2556 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 2557 * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, 2558 * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 2559 * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 2560 * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS 2561 * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 2562 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED 2563 * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 2564 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON 2565 * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 2566 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT 2567 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 2568 * SUCH DAMAGE. 2569 * 2570 * Author: Alan DeKok 2571 */ 2572 #include 2573 #include 2574 #include 2575 #include 2576 #include 2577 #include 2579 static int encode_tlv(char *buffer, uint8_t *output, size_t outlen); 2581 static const char *hextab = "0123456789abcdef"; 2583 static int encode_data_string(char *buffer, 2584 uint8_t *output, size_t outlen) 2585 { 2586 int length = 0; 2587 char *p; 2589 p = buffer + 1; 2591 while (*p && (outlen > 0)) { 2592 if (*p == '"') { 2593 return length; 2594 } 2596 if (*p != '\\') { 2597 *(output++) = *(p++); 2598 outlen--; 2599 length++; 2600 continue; 2601 } 2603 switch (p[1]) { 2604 default: 2605 *(output++) = p[1]; 2606 break; 2608 case 'n': 2609 *(output++) = '\n'; 2610 break; 2612 case 'r': 2613 *(output++) = '\r'; 2614 break; 2616 case 't': 2617 *(output++) = '\t'; 2618 break; 2619 } 2621 outlen--; 2622 length++; 2623 } 2625 fprintf(stderr, "String is not terminated\n"); 2626 return 0; 2627 } 2629 static int encode_data_tlv(char *buffer, char **endptr, 2630 uint8_t *output, size_t outlen) 2631 { 2632 int depth = 0; 2633 int length; 2634 char *p; 2636 for (p = buffer; *p != '\0'; p++) { 2637 if (*p == '{') depth++; 2638 if (*p == '}') { 2639 depth--; 2640 if (depth == 0) break; 2641 } 2642 } 2644 if (*p != '}') { 2645 fprintf(stderr, "No trailing '}' in string starting " 2646 "with \"%s\"\n", 2647 buffer); 2648 return 0; 2649 } 2651 *endptr = p + 1; 2652 *p = '\0'; 2654 p = buffer + 1; 2655 while (isspace((int) *p)) p++; 2657 length = encode_tlv(p, output, outlen); 2658 if (length == 0) return 0; 2660 return length; 2661 } 2662 static int encode_data(char *p, uint8_t *output, size_t outlen) 2663 { 2664 int length; 2666 if (!isspace((int) *p)) { 2667 fprintf(stderr, "Invalid character following attribute " 2668 "definition\n"); 2669 return 0; 2670 } 2672 while (isspace((int) *p)) p++; 2674 if (*p == '{') { 2675 int sublen; 2676 char *q; 2678 length = 0; 2680 do { 2681 while (isspace((int) *p)) p++; 2682 if (!*p) { 2683 if (length == 0) { 2684 fprintf(stderr, "No data\n"); 2685 return 0; 2686 } 2688 break; 2689 } 2691 sublen = encode_data_tlv(p, &q, output, outlen); 2692 if (sublen == 0) return 0; 2694 length += sublen; 2695 output += sublen; 2696 outlen -= sublen; 2697 p = q; 2698 } while (*q); 2700 return length; 2701 } 2703 if (*p == '"') { 2704 length = encode_data_string(p, output, outlen); 2705 return length; 2706 } 2708 length = 0; 2709 while (*p) { 2710 char *c1, *c2; 2712 while (isspace((int) *p)) p++; 2714 if (!*p) break; 2716 if(!(c1 = memchr(hextab, tolower((int) p[0]), 16)) || 2717 !(c2 = memchr(hextab, tolower((int) p[1]), 16))) { 2718 fprintf(stderr, "Invalid data starting at " 2719 "\"%s\"\n", p); 2720 return 0; 2721 } 2723 *output = ((c1 - hextab) << 4) + (c2 - hextab); 2724 output++; 2725 length++; 2726 p += 2; 2728 outlen--; 2729 if (outlen == 0) { 2730 fprintf(stderr, "Too much data\n"); 2731 return 0; 2732 } 2733 } 2735 if (length == 0) { 2736 fprintf(stderr, "Empty string\n"); 2737 return 0; 2738 } 2740 return length; 2741 } 2743 static int decode_attr(char *buffer, char **endptr) 2744 { 2745 long attr; 2747 attr = strtol(buffer, endptr, 10); 2748 if (*endptr == buffer) { 2749 fprintf(stderr, "No valid number found in string " 2750 "starting with \"%s\"\n", buffer); 2751 return 0; 2752 } 2754 if (!**endptr) { 2755 fprintf(stderr, "Nothing follows attribute number\n"); 2756 return 0; 2757 } 2758 if ((attr <= 0) || (attr > 256)) { 2759 fprintf(stderr, "Attribute number is out of valid " 2760 "range\n"); 2761 return 0; 2762 } 2764 return (int) attr; 2765 } 2767 static int decode_vendor(char *buffer, char **endptr) 2768 { 2769 long vendor; 2771 if (*buffer != '.') { 2772 fprintf(stderr, "Invalid separator before vendor id\n"); 2773 return 0; 2774 } 2776 vendor = strtol(buffer + 1, endptr, 10); 2777 if (*endptr == (buffer + 1)) { 2778 fprintf(stderr, "No valid vendor number found\n"); 2779 return 0; 2780 } 2782 if (!**endptr) { 2783 fprintf(stderr, "Nothing follows vendor number\n"); 2784 return 0; 2785 } 2787 if ((vendor <= 0) || (vendor > (1 << 24))) { 2788 fprintf(stderr, "Vendor number is out of valid range\n"); 2789 return 0; 2790 } 2792 if (**endptr != '.') { 2793 fprintf(stderr, "Invalid data following vendor number\n"); 2794 return 0; 2795 } 2796 (*endptr)++; 2798 return (int) vendor; 2799 } 2801 static int encode_tlv(char *buffer, uint8_t *output, size_t outlen) 2802 { 2803 int attr; 2804 int length; 2805 char *p; 2806 attr = decode_attr(buffer, &p); 2807 if (attr == 0) return 0; 2809 output[0] = attr; 2810 output[1] = 2; 2812 if (*p == '.') { 2813 p++; 2814 length = encode_tlv(p, output + 2, outlen - 2); 2816 } else { 2817 length = encode_data(p, output + 2, outlen - 2); 2818 } 2820 if (length == 0) return 0; 2821 if (length > (255 - 2)) { 2822 fprintf(stderr, "TLV data is too long\n"); 2823 return 0; 2824 } 2826 output[1] += length; 2828 return length + 2; 2829 } 2831 static int encode_vsa(char *buffer, uint8_t *output, size_t outlen) 2832 { 2833 int vendor; 2834 int attr; 2835 int length; 2836 char *p; 2838 vendor = decode_vendor(buffer, &p); 2839 if (vendor == 0) return 0; 2841 output[0] = 0; 2842 output[1] = (vendor >> 16) & 0xff; 2843 output[2] = (vendor >> 8) & 0xff; 2844 output[3] = vendor & 0xff; 2846 length = encode_tlv(p, output + 4, outlen - 4); 2847 if (length == 0) return 0; 2848 if (length > (255 - 6)) { 2849 fprintf(stderr, "VSA data is too long\n"); 2850 return 0; 2851 } 2852 return length + 4; 2853 } 2855 static int encode_evs(char *buffer, uint8_t *output, size_t outlen) 2856 { 2857 int vendor; 2858 int attr; 2859 int length; 2860 char *p; 2862 vendor = decode_vendor(buffer, &p); 2863 if (vendor == 0) return 0; 2865 attr = decode_attr(p, &p); 2866 if (attr == 0) return 0; 2868 output[0] = 0; 2869 output[1] = (vendor >> 16) & 0xff; 2870 output[2] = (vendor >> 8) & 0xff; 2871 output[3] = vendor & 0xff; 2872 output[4] = attr; 2874 length = encode_data(p, output + 5, outlen - 5); 2875 if (length == 0) return 0; 2877 return length + 5; 2878 } 2880 static int encode_extended(char *buffer, 2881 uint8_t *output, size_t outlen) 2882 { 2883 int attr; 2884 int length; 2885 char *p; 2887 attr = decode_attr(buffer, &p); 2888 if (attr == 0) return 0; 2890 output[0] = attr; 2892 if (attr == 26) { 2893 length = encode_evs(p, output + 1, outlen - 1); 2894 } else { 2895 length = encode_data(p, output + 1, outlen - 1); 2896 } 2897 if (length == 0) return 0; 2898 if (length > (255 - 3)) { 2899 fprintf(stderr, "Extended Attr data is too long\n"); 2900 return 0; 2901 } 2903 return length + 1; 2904 } 2906 static int encode_extended_flags(char *buffer, 2907 uint8_t *output, size_t outlen) 2908 { 2909 int attr; 2910 int length, total; 2911 char *p; 2913 attr = decode_attr(buffer, &p); 2914 if (attr == 0) return 0; 2916 /* output[0] is the extended attribute */ 2917 output[1] = 4; 2918 output[2] = attr; 2919 output[3] = 0; 2921 if (attr == 26) { 2922 length = encode_evs(p, output + 4, outlen - 4); 2923 if (length == 0) return 0; 2925 output[1] += 5; 2926 length -= 5; 2927 } else { 2928 length = encode_data(p, output + 4, outlen - 4); 2929 } 2930 if (length == 0) return 0; 2932 total = 0; 2933 while (1) { 2934 int sublen = 255 - output[1]; 2936 if (length <= sublen) { 2937 output[1] += length; 2938 total += output[1]; 2939 break; 2940 } 2942 length -= sublen; 2944 memmove(output + 255 + 4, output + 255, length); 2945 memcpy(output + 255, output, 4); 2947 output[1] = 255; 2948 output[3] |= 0x80; 2950 output += 255; 2951 output[1] = 4; 2952 total += 255; 2953 } 2955 return total; 2956 } 2958 static int encode_rfc(char *buffer, uint8_t *output, size_t outlen) 2959 { 2960 int attr; 2961 int length, sublen; 2962 char *p; 2964 attr = decode_attr(buffer, &p); 2965 if (attr == 0) return 0; 2967 length = 2; 2968 output[0] = attr; 2969 output[1] = 2; 2971 if (attr == 26) { 2972 sublen = encode_vsa(p, output + 2, outlen - 2); 2974 } else if ((*p == ' ') || ((attr < 241) || (attr > 246))) { 2975 sublen = encode_data(p, output + 2, outlen - 2); 2977 } else { 2978 if (*p != '.') { 2979 fprintf(stderr, "Invalid data following " 2980 "attribute number\n"); 2981 return 0; 2982 } 2984 if (attr < 245) { 2985 sublen = encode_extended(p + 1, 2986 output + 2, outlen - 2); 2987 } else { 2989 /* 2990 * Not like the others! 2991 */ 2992 return encode_extended_flags(p + 1, output, outlen); 2993 } 2994 } 2995 if (sublen == 0) return 0; 2996 if (sublen > (255 -2)) { 2997 fprintf(stderr, "RFC Data is too long\n"); 2998 return 0; 2999 } 3001 output[1] += sublen; 3002 return length + sublen; 3003 } 3005 int main(int argc, char *argv[]) 3006 { 3007 int lineno; 3008 size_t i, outlen; 3009 FILE *fp; 3010 char input[8192], buffer[8192]; 3011 uint8_t output[4096]; 3013 if ((argc < 2) || (strcmp(argv[1], "-") == 0)) { 3014 fp = stdin; 3015 } else { 3016 fp = fopen(argv[1], "r"); 3017 if (!fp) { 3018 fprintf(stderr, "Error opening %s: %s\n", 3019 argv[1], strerror(errno)); 3020 exit(1); 3021 } 3022 } 3024 lineno = 0; 3025 while (fgets(buffer, sizeof(buffer), fp) != NULL) { 3026 char *p = strchr(buffer, '\n'); 3028 lineno++; 3030 if (!p) { 3031 if (!feof(fp)) { 3032 fprintf(stderr, "Line %d too long in %s\n", 3033 lineno, argv[1]); 3034 exit(1); 3035 } 3036 } else { 3037 *p = '\0'; 3038 } 3040 p = strchr(buffer, '#'); 3041 if (p) *p = '\0'; 3043 p = buffer; 3044 while (isspace((int) *p)) p++; 3045 if (!*p) continue; 3047 strcpy(input, p); 3048 outlen = encode_rfc(input, output, sizeof(output)); 3049 if (outlen == 0) { 3050 fprintf(stderr, "Parse error in line %d of %s\n", 3051 lineno, input); 3052 exit(1); 3053 } 3055 printf("%s -> ", buffer); 3056 for (i = 0; i < outlen; i++) { 3057 printf("%02x ", output[i]); 3058 } 3059 printf("\n"); 3060 } 3062 if (fp != stdin) fclose(fp); 3064 return 0; 3065 } 3066 ------------------------------------------------------------ 3068 Author's Address 3070 Alan DeKok 3071 Network RADIUS SARL 3072 57bis blvd des Alpes 3073 38240 Meylan 3074 France 3076 Email: aland@networkradius.com 3077 URI: http://networkradius.com 3079 Avi Lior 3080 Email: avi.ietf@lior.org