idnits 2.17.1 draft-ietf-radext-radius-extensions-02.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 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 October 2011) is 4572 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 2535 -- Looks like a reference, but probably isn't: '0' on line 2470 -- Looks like a reference, but probably isn't: '2' on line 2420 -- Looks like a reference, but probably isn't: '3' on line 2450 -- Looks like a reference, but probably isn't: '4' on line 2374 -- Looks like a reference, but probably isn't: '8192' on line 2512 -- Looks like a reference, but probably isn't: '4096' on line 2513 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 13 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, 5176 BWS 6 7 Expires: January 6, 2012 8 25 October 2011 10 Remote Authentication Dial In User Service (RADIUS) Protocol 11 Extensions 12 draft-ietf-radext-radius-extensions-02.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 January 6, 2012. 46 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info/) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction ............................................. 5 63 1.1. Terminology ......................................... 6 64 1.2. Requirements Language ............................... 6 65 2. Extensions to RADIUS ..................................... 8 66 2.1. Extended Type ....................................... 8 67 2.2. Extended Type with Flags ............................ 9 68 2.3. TLV Data Type ....................................... 11 69 2.3.1. TLV Nesting .................................... 13 70 2.4. EVS Data Type ....................................... 13 71 2.5. Integer64 Data Type ................................. 15 72 2.6. Attribute Naming and Type Identifiers ............... 15 73 2.6.1. Attribute and TLV Naming ....................... 16 74 2.6.2. Attribute Type Identifiers ..................... 16 75 2.6.3. TLV Identifiers ................................ 16 76 2.6.4. VSA Identifiers ................................ 17 77 3. Attribute Definitions .................................... 18 78 3.1. Extended-Type-1 ..................................... 18 79 3.2. Extended-Type-2 ..................................... 19 80 3.3. Extended-Type-3 ..................................... 20 81 3.4. Extended-Type-4 ..................................... 21 82 3.5. Extended-Type-Flagged-1 ............................. 21 83 3.6. Extended-Type-Flagged-2 ............................. 23 84 4. Vendor Specific Attributes ............................... 24 85 4.1. Extended-Vendor-Specific-1 .......................... 24 86 4.2. Extended-Vendor-Specific-2 .......................... 25 87 4.3. Extended-Vendor-Specific-3 .......................... 26 88 4.4. Extended-Vendor-Specific-4 .......................... 28 89 4.5. Extended-Vendor-Specific-5 .......................... 29 90 4.6. Extended-Vendor-Specific-6 .......................... 30 91 5. Compatibility with traditional RADIUS .................... 32 92 5.1. Attribute Allocation ................................ 32 93 5.2. Proxy Servers ....................................... 33 94 6. Guidelines ............................................... 34 95 6.1. Updates to RFC 6158 ................................. 34 96 6.2. Guidelines For the New Types ........................ 34 97 6.3. Allocation Request Guidelines ....................... 34 98 6.4. TLV Guidelines ...................................... 35 99 6.5. Implementation Guidelines ........................... 36 100 6.6. Vendor Guidelines ................................... 36 101 7. Rationale ................................................ 36 102 7.1. Attribute Audit ..................................... 37 103 8. Examples ................................................. 37 104 8.1. Extended Type ....................................... 38 105 8.2. Extended Type with Flags ............................ 40 106 9. IANA Considerations ...................................... 42 107 9.1. Attribute Allocations ............................... 42 108 9.2. RADIUS Attribute Type Tree .......................... 43 109 9.3. Extending the Attribute Type Tree ................... 44 110 10. Security Considerations ................................. 44 111 11. References .............................................. 44 112 11.1. Normative references ............................... 44 113 11.2. Informative references ............................. 45 114 Appendix A - Extended Attribute Generator Program ............ 46 115 1. Introduction 117 Under current allocation pressure, we expect that the RADIUS 118 Attribute Type space will be exhausted by 2014 or 2015. We therefore 119 need a way to extend the type space, so that new specifications may 120 continue to be developed. Other issues have also been shown with 121 RADIUS. The attribute grouping method defined in [RFC2868] has been 122 shown to be imnpractical, and a more powerful mechanism is needed. 123 Multiple attributes have been defined which transport more than the 124 253 octets of data originally envisioned with the protocol. Each of 125 these attributes is handled as a "special case" inside of RADIUS 126 implementations, instead of as a general method. We therefore also 127 need a standardized method of transporting large quantities of data. 128 Finally, some vendors are close to allocating all of the Attributes 129 within their Vendor-Specific Attribute space. It would be useful to 130 leverage changes to the base protocol for extending the Vendor- 131 Specific Attribute space. 133 We satisfy all of these requirements through the following 134 modifications to RADIUS: 136 * defining an "Extended Type" format, which adds 8 bits of "Extended 137 Type" to the RADIUS Attribute Type space, by using one octet of the 138 "Value" field. This method gives us a general way of extending 139 the Attribute Type Space. 141 * allocating 4 attributes as using the format of "Extended Type". 142 This allocation extends the RADIUS Attribute Type Space by 143 approximately 1000 values. 145 * defining an "Extended Type with Flags" format, which inserts 146 an additional "Flags" octet between the "Extended Type" octet, 147 and the "Value" field. This method gives us a general way of 148 adding additional functionality to the protocol. 150 * defining a method which uses the "Flags" field to indicate data 151 fragmentation across multiple Attributes. This method provides a 152 standard way for an Attribute to carry more than 253 octets of 153 data. 155 * allocating 2 attributes as using the format of "Extended Type with 156 Flags". This allocation extends the RADIUS Attribute Type Space 157 by an additional 500 values. 159 * defining a new "Type Length Value" (TLV) data type. The data type 160 allows an attribute to carry TLVs as "sub-attributes", which can in 161 turn encapsulate other TLVs as "sub-sub-attributes." This change 162 creates a standard way to group a set of Attributes. 164 * defining a new "extended Vendor-Specific" (EVS) data type. The 165 data type allows an attribute to carry Vendor-Specific Attributes 166 (VSAs) inside of the new attribute formats. 168 * defining a new "integer64" data type. The data type allows 169 counters which track more than 2^32 octets of data. 171 * allocating 6 attributes using the new EVS data type. This 172 allocation extends the Vendor-Specific Attribute type space by 173 over 1500 values. 175 As with any protocol change, the changes defined here are the result 176 of a series of compromises. We have tried to find a balance between 177 flexibility, space in the RADIUS message, compatibility with existing 178 deployments, and implementation difficulty. 180 1.1. Terminology 182 This document uses the following terms: 184 silently discard 185 This means the implementation discards the packet without further 186 processing. The implementation MAY provide the capability of 187 logging the error, including the contents of the silently discarded 188 packet, and SHOULD record the event in a statistics counter. 190 invalid attribute 191 This means that the Length field of an Attribute is valid (as per 192 [RFC2865], Section 5, top of page 25). However, the Value field of 193 the attribute does not follow the format required by the data type 194 defined for that Attribute. e.g. an Attribute of type "address" 195 which encapsulates more than four, or less than four, octets of 196 data. 198 1.2. Requirements Language 200 In this document, several words are used to signify the requirements 201 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 202 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 203 and "OPTIONAL" in this document are to be interpreted as described in 204 [RFC2119]. 206 An implementation is not compliant if it fails to satisfy one or more 207 of the must or must not requirements for the protocols it implements. 208 An implementation that satisfies all the MUST, MUST NOT, SHOULD, and 209 SHOULD NOT requirements for its protocols is said to be 210 "unconditionally compliant"; one that satisfies all the MUST and MUST 211 NOT requirements but not all the SHOULD or SHOULD NOT requirements 212 for its protocols is said to be "conditionally compliant". 214 2. Extensions to RADIUS 216 This section defines two new attribute formats; "Extended Type"; and 217 "Extended Type with Flags". The formats are defined below. 219 2.1. Extended Type 221 This section defines a new attribute format, called "Extended Type". 222 A summary of the Attribute format is shown below. The fields are 223 transmitted from left to right. 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Type | Length | Extended-Type | Value ... 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Type 233 This field is identical to the Type field of the Attribute format 234 defined in [RFC2865] Section 5. 236 Length 238 This field is identical to the Length field of the Attribute 239 format defined in [RFC2865] Section 5. Permitted values are 240 between 4 and 255. If a client or server receives an Extended 241 Attribute with a Length of 2 or 3, then that Attribute MUST be 242 deemed to be an "invalid attribute", it SHOULD be silently 243 discarded. If it is not discarded, it MUST NOT be handled in the 244 same manner as a well-formed attribute. 246 Note that an "invalid attribute" does not cause the entire packet 247 to be discarded, or to be treated as a negative acknowledgement. 248 Instead, only the "invalid attribute" is discarded. 250 Extended-Type 252 The Extended-Type field is one octet. Up-to-date values of this 253 field are specified by IANA. Unlike the Type field defined in 254 [RFC2865] Section 5, no values are allocated for experimental or 255 implementation-specific use. Values 241-255 are reserved and 256 SHOULD NOT be used. 258 The Extended-Type is meaningful only within a context defined by 259 the Type field. That is, this field may be thought of as defining 260 a new type space of the form "Type.Extended-Type". See Section 261 2.5, below, for additional discussion. 263 A RADIUS server MAY ignore Attributes with an unknown 264 "Type.Extended-Type". 266 A RADIUS client MAY ignore Attributes with an unknown 267 "Type.Extended-Type". 269 Value 271 This field is similar to the Value field of the Attribute format 272 defined in [RFC2865] Section 5. The format of the data SHOULD be 273 a valid RADIUS data type. 275 The addition of the Extended-Type field decreases the maximum 276 length for attributes of type "text" or "string" from 253 to 252 277 octets. Where an Attribute needs to carry more than 252 octets of 278 data, the "Extended Type with flags" format should be used. 280 Experience has shown that the "experimental" and "implementation 281 specific" attributes defined in [RFC2865] Section 5 have had little 282 practical value. We therefore do not continue that practice here 283 with the Extended-Type field. 285 2.2. Extended Type with Flags 287 This section defines a new attribute format, called "Extended Type 288 with Flags". It leverages the "Extended Type" format in order to 289 permit the transport of attributes encapsulating more than 253 octets 290 of data. A summary of the Attribute format is shown below. The 291 fields are transmitted from left to right. 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Type | Length | Extended-Type |M| Flags | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Value ... 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Type 303 This field is identical to the Type field of the Attribute format 304 defined in [RFC2865] Section 5. 306 Length 308 This field is identical to the Length field of the Attribute 309 format defined in [RFC2865] Section 5. Permitted values are 310 between 5 and 255. If a client or server receives an "Extended 311 Attribute with Flags" with a Length of 2, 3, or 4, then that 312 Attribute MUST be deemed to be an "invalid attribute", it SHOULD 313 be silently discarded. If it is not discarded, it MUST NOT be 314 handled in the same manner as a well-formed attribute. 316 Note that an "invalid attribute" does not cause the entire packet 317 to be discarded, or to be treated as a negative acknowledgement. 318 Instead, only the "invalid attribute" is discarded. 320 Extended-Type 322 This field is identical to the Extended-Type field defined above 323 in Section 2.1. 325 M (More) 327 The More Flag is one (1) bit in length, and indicates whether or 328 not the current attribute contains "more" than 251 octets of data. 329 The More flag MUST be clear (0) if the Length field has value less 330 than 255. The More flag MAY be set (1) if the Length field has 331 value of 255. 333 If the More flag is set (1), it indicates that the Value field has 334 been fragmented across multiple RADIUS attributes. When the More 335 flag is set (1), the attribute SHOULD have a Length field of value 336 255; it MUST NOT have a length Field of of value 4; there MUST be 337 an attribute following this one; and the next attribute MUST have 338 both the same Type and Extended Type. That is, multiple fragments 339 of the same value MUST be in order and MUST be consecutive 340 attributes in the packet, and the last attribute in a packet MUST 341 NOT have the More flag set (1). 343 When the Length field of an attribute has value less than 255, the 344 More flag SHOULD be clear (0). 346 If a client or server receives an attribute fragment with the 347 "More" flag set (1), but for which no subsequent fragment can be 348 found, then the fragmented attribute is deemed to be an "invalid 349 attribute" and the entire set of fragments SHOULD be silently 350 discarded. If the fragmented attribute is not discarded, it MUST 351 NOT be handled in the same manner as a well-formed attribute. 353 Flags 355 This field is 7 bits long, and is reserved for future use. 356 Implementations MUST set it to zero (0) when encoding an attribute 357 for sending in a packet. The contents SHOULD be ignored on 358 reception. 360 Value 362 This field is similar to the Value field of the Attribute format 363 defined in [RFC2865] Section 5. It may contain a complete set of 364 data (when the Length field has value less than 255), or it may 365 contain a fragment of data (when the More field is set). 367 Any interpretation of the resulting data MUST occur after the 368 fragments have been reassembled. The length of the data MUST be 369 taken as the sum of the lengths of the fragments (i.e. Value 370 fields) from which it is constructed. The format of the data 371 SHOULD be a valid RADIUS data type. 373 This definition increases the RADIUS Attribute Type space as above, 374 but also provides for transport of Attributes which could contain 375 more than 253 octets of data. 377 2.3. TLV Data Type 379 We define a new data type in RADIUS, called "tlv". The "tlv" data 380 type is an encapsulation layer which which permits the "Value" field 381 of an Attribute to contain new sub-Attributes. These sub-Attributes 382 can in turn contain "Value"s of data type TLV. This capability both 383 extends the attribute space, and permits "nested" attributes to be 384 used. This nesting can be used to encapsulate or group data into one 385 or more logical containers. 387 The "tlv" data type re-uses the RADIUS attribute format, as given 388 below: 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | TLV-Type | TLV-Length | TLV-Value ... 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 TLV-Type 398 The Type field is one octet. Up-to-date values of this field are 399 specified by IANA. Values of zero (0) MUST NOT be used. Values 400 254-255 are "Reserved" for use by future extensions to RADIUS. 401 The value 26 has no special meaning. 403 As with Extended-Type above, the TLV-Type is meaningful only 404 within a context defined by "Type" fields of the encapsulating 405 Attributes. That is, the field may be thought of as defining a 406 new type space of the form "Type.Extended-Type.TLV-Type". Where 407 TLVs are nested, the type space is of the form "Type.Extended- 408 Type.TLV-Type.TLV-Type", etc. 410 A RADIUS server MAY ignore Attributes with an unknown "TLV-Type". 412 A RADIUS client MAY ignore Attributes with an unknown "TLV-Type". 414 TLV-Length 416 The TLV-Length field is one octet, and indicates the length of 417 this TLV including the TLV-Type, TLV-Length and TLV-Value fields. 418 It MUST have a value between 3 and 255. If a client or server 419 receives a TLV with an invalid TLV-Length, then the attribute 420 which encapsulates that TLV MUST be deemed to be an "invalid 421 attribute", it SHOULD be silently discarded. If the encapsulating 422 attribute is not discarded, it MUST NOT be handled in the same 423 manner as a well-formed attribute. 425 Note that an "invalid attribute" does not cause the entire packet 426 to be discarded, or to be treated as a negative acknowledgement. 427 Instead, only the "invalid attribute" is discarded. 429 TLV-Value 431 The Value field is one or more octets and contains information 432 specific to the Attribute. The format and length of the TLV-Value 433 field is determined by the TLV-Type and TLV-Length fields. 435 The TLV-Value field SHOULD encapsulate a previously defined RADIUS 436 data type. Using non-standard data types is NOT RECOMMENDED. We 437 note that the TLV-Value field MAY also contain one or more 438 attributes of data type "tlv", which allows for simple grouping 439 and multiple layers of nesting. 441 The TLV-Value field is limited to containing 253 or fewer octets 442 of data. Specifications which require a TLV to contain more than 443 253 octets of data are incompatible with RADIUS, and need to be 444 redesigned. Specifications which require the transport of empty 445 Values (i.e. Length = 2) are incompatible with RADIUS, and need to 446 be redesigned. 448 The TLV-Value field MUST NOT contain data using the "Extended 449 Type" formats defined in this document. The base Extended 450 Attributes format allows for sufficient flexibility that nesting 451 them inside of a TLV offers little additional value. 453 This TLV definition is compatible with the suggested format of the 454 "String" field of the Vendor-Specific attribute, as defined in 455 [RFC2865] Section 5.26, though that specification does not discuss 456 nesting. 458 Vendors MAY use attributes of type "tlv" in any Vendor Specific 459 Attribute. We RECOMMEND using type "tlv" for VSAs, in preference to 460 any other format. 462 2.3.1. TLV Nesting 464 TLVs may contain other TLVs. When this occurs, the "container" TLV 465 MUST be completely filled by the "contained" TLVs. That is, the 466 "container" TLV-Length field MUST be exactly two (2) more than the 467 sum of the "contained" TLV-Length fields. If the "contained" TLVs 468 over-fill the "container" TLV, the "container" TLV MUST be considered 469 to be an "invalid attribute", and handled as described above. 471 The depth of TLV nesting is limited only by the restrictions on the 472 TLV-Length field. The limit of 253 octets of data results in a limit 473 of 126 levels of nesting. However, nesting depths of more than 4 are 474 NOT RECOMMENDED. 476 2.4. EVS Data Type 478 We define a new data type in RADIUS, called "evs", for "Extended 479 Vendor-Specific". The "evs" data type is an encapsulation layer 480 which which permits the "Value" field of an Attribute to contain a 481 Vendor-Id, followed by a Vendor-Type, and then vendor-defined data. 482 This data can in turn contain valid RADIUS data types, or any other 483 data as determined by the vendor. 485 This data type is intended use in attributes which carry Vendor- 486 Specific information, as is done with the Vendor-Specific Attribute 487 (26). It is RECOMMENDED that this data type be used by a vendor only 488 when the Vendor-Specific Attribute Type space has been fully 489 allocated. 491 Where [RFC2865] Section 5.26 makes a recommendation for the format of 492 the data following the Vendor-Id, we give a strict definition. 493 Experience has shown that many vendors have not followed the 494 [RFC2865] recommendations, leading to interoperability issues. We 495 hope here to give vendors sufficient flexibility as to meet their 496 needs, while minimizing the use of non-standard VSA formats. 498 The "evs" data type MAY be used in Attributes having the format of 499 "Extended Type" or "Extended Type with Flags". It MUST NOT be used 500 in any other Attribute definition, including standard RADIUS 501 Attributes, TLVs, and VSAs. 503 A summary of the "evs" data type format is shown below. The fields 504 are transmitted from left to right. 506 0 1 2 3 507 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 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Vendor-Id | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Vendor-Type | String .... 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 Vendor-Id 516 The high-order octet is 0 and the low-order 3 octets are the SMI 517 Network Management Private Enterprise Code of the Vendor in 518 network byte order. 520 Vendor-Type 522 The Vendor-Type field is one octet. Values are assigned at the 523 sole discretion of the Vendor. 525 String 527 The String field is one or more octets. It SHOULD encapsulate a 528 previously defined RADIUS data type. Using non-standard data 529 types is NOT RECOMMENDED. We note that the String field may be of 530 data type "tlv". However, it MUST NOT be of data type "evs", as 531 the use cases are unclear for one vendor delegating attribute type 532 space to another vendor. 534 The actual format of the information is site or application 535 specific, and a robust implementation SHOULD support the field as 536 undistinguished octets. We recognise that Vendors have complete 537 control over the contents and format of the String field, while at 538 the same time recommending that good practices be followed. 540 Further codification of the range of allowed usage of this field 541 is outside the scope of this specification. 543 Note that unlike the format described in [RFC2865] Section 5.26, this 544 data type has no "Vendor length" field. The length of the "String" 545 field is implicit, and is determined by taking the "Length" of the 546 encapsulating RADIUS Attribute, and subtracting the length of the 547 attribute header including the 4 octets of Vendor-Id. i.e. For 548 "Extended Type" attributes, the length of the String field is seven 549 (7) less than the value of the Length field. For "Extended Type with 550 Flags" attributes, the length of the String field is eight (8) less 551 than the value of the Length field. 553 2.5. Integer64 Data Type 555 We define a new data type in RADIUS, called "integer64", which 556 carries a 64-bit unsigned integer in network byte order. 558 This data type is intended to be used in any situation where there is 559 a need to have counters which can count past 2^32. The expected use 560 og this data type is within Accounting-Request packets, but this data 561 type SHOULD be used in any packet where 32-bit integers are expected 562 to be insufficient. 564 The "integer64" data type MAY be used in Attributes of any format, 565 standard space, extended attributes, TLVs, and VSAs. 567 A summary of the "integer64" data type format is shown below. The 568 fields are transmitted from left to right. 570 0 1 2 3 571 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 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Value ... 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 Attributes having data type "integer64" MUST have the relevant Length 579 field set to eight more than the length of the Attribute header. For 580 standard space Attributes and TLVs, this means that the Length field 581 MUST be set to ten (10). For "Extended Type" Attributes, the Length 582 field MUST be set to eleven (11). For "Extended Type with Flags" 583 Attributes, the Length field MUST be set to twelve (12). 585 2.6. Attribute Naming and Type Identifiers 587 Attributes have traditionally been identified by a unique name and 588 number. For example, the attribute named "User-Name" has been 589 allocated number one (1). This scheme needs to be extended in order 590 to be able to refer to attributes of Extended Type, and to TLVs. It 591 will also be used by IANA for allocating RADIUS Attribute Type 592 values. 594 The names and identifiers given here are intended to be used only in 595 specifications. The system presented here may not be useful when 596 referring to the contents of a RADIUS packet. It imposes no 597 requirements on implementations, as implementations are free to 598 reference RADIUS Attributes via any method they choose. 600 2.6.1. Attribute and TLV Naming 602 RADIUS specifications traditionally use names consisting of one or 603 more words, separated by hyphens, e.g. "User-Name". However, these 604 names are not allocated from a registry, and there is no restriction 605 other than convention on their global uniqueness. 607 Similarly, vendors have often used their company name as the prefix 608 for VSA names, though this practice is not universal. For example, 609 for a vendor named "Example", the name "Example-Attribute-Name" 610 SHOULD be used instead of "Attribute-Name". The second form can 611 conflict with attributes from other vendors, whereas the first form 612 cannot. 614 We therefore RECOMMEND that specifications give names to Attributes 615 which attempt to be globally unique across all RADIUS Attributes. We 616 RECOMMEND that vendors use their name as a unique prefix for 617 attribute names. We recognise that these suggestion may sometimes be 618 difficult to implement in practice. 620 TLVs SHOULD be named with a unique prefix that is shared among 621 related attributes. For example, a specification that defines a set 622 of TLVs related to time could create attributes named "Time-Zone", 623 "Time-Day", "Time-Hour", "Time-Minute", etc. 625 2.6.2. Attribute Type Identifiers 627 The RADIUS Attribute Type space defines a context for a particular 628 "Extended-Type" field. The "Extended-Type" field allows for 256 629 possible type code values, with values 1 through 240 available for 630 allocation. We define here an identification method that uses a 631 "dotted number" notation similar to that used for Object Identifiers 632 (OIDs), formatted as "Type.Extended-Type". 634 For example, and attribute within the Type space of 241, having 635 Extended-Type of one (1), is uniquely identified as "241.1". 636 Similarly, an attribute within the Type space of 246, having 637 Extended-Type of ten (10), is uniquely identified as "246.10". 639 The algorithm used to create the Attribute Identifier is simply to 640 concatenate all of the various identification fields (e.g. Type, 641 Extended-Type, etc.), starting from the encapsulating attribute, down 642 to the final encapsulated TLV, separated by a '.' character. 644 2.6.3. TLV Identifiers 646 We can extend the Attribute reference scheme defined above for TLVs. 647 This is done by leveraging the "dotted number" notation. As above, 648 we define an additional TLV type space, within the "Extended Type" 649 space, by appending another "dotted number" in order to identify the 650 TLV. This method can be replied in sequence for nested TLVs. 652 For example, let us say that "245.1" identifies RADIUS Attribute Type 653 245, containing an "Extended Type" of one (1), which is of type 654 "tlv". That attribute will contain 256 possible TLVs, one for each 655 value of the TLV-Type field. The first TLV-Type value of one (1) can 656 then be identified by appending a ".1" to the number of the 657 encapsulating attribute ("241.1"), to yield "241.1.1". Similarly, 658 the sequence "245.2.3.4" identifies RADIUS attribute 245, containing 659 an "Extended Type" of two (2) which is of type "tlv", which in turn 660 contains a TLV with TLV-Type number three (3), which in turn contains 661 another TLV, wth TLV-Type number four (4). 663 2.6.4. VSA Identifiers 665 There has historically been no method for numerically addressing 666 VSAs. The "dotted number" method defined here can also be leveraged 667 to create such an addressing scheme. However, as the VSAs are 668 completely under the control of each individual vendor, this section 669 provides a suggested practice, but does not define a standard of any 670 kind. 672 The Vendor-Specific Attribute has been assigned the Attribute number 673 26. It in turn carries a 24-bit Vendor-Id, and possibly additional 674 VSAs. Where the VSAs follow the [RFC2865] Section 5.26 recommended 675 format, a VSA can be identified as "26.Vendor-Id"."Vendor-Type". 677 For example, Livingston has Vendor-Id 307, and has defined an 678 attribute "IP-Pool" as number 6. This VSA can be uniquely identified 679 as 26.307.6. 681 Note that there is no restriction on the size of the numerical values 682 in this notation. The Vendor-Id is a 24-bit number, and the VSA may 683 have been assigned from a 16-bit vendor-specific Attribute type 684 space. 686 For example, the company USR has been allocated Vendor-Id 429, and 687 has defined a "Version-Id" attribute as number 32768. This VSA can 688 be uniquely identified as 26.429.32768. 690 Where a VSA is a TLV, the "dotted number" notation can be used as 691 above: 26.VID.VSA.TLV1.TLV2.TLV3 where "TLVn" are the numerical 692 values assigned by the vendor to the different nested TLVs. 694 3. Attribute Definitions 696 We define four (4) attributes of "Extended Type", which are allocated 697 from the "Reserved" Attribute Type codes of 241, 242, 243, and 244. 698 We also define two (2) attributes of "Extended Type with Flags", 699 which are allocated from the "Reserved" Attribute Type codes of 245 700 and 246. 702 Type Name 703 ---- ---- 704 241 Extended-Type-1 705 242 Extended-Type-2 706 243 Extended-Type-3 707 244 Extended-Type-4 708 245 Extended-Type-Flagged-1 709 246 Extended-Type-Flagged-2 711 The rest of this section gives a detailed definition for each 712 Attribute based on the above summary. 714 3.1. Extended-Type-1 716 Description 718 This attribute encapsulates attributes of the "Extended Type" 719 format, in the RADIUS Attribute Type Space of 241.{1-255}. 721 A summary of the Extended-Type-1 Attribute format is shown below. 722 The fields are transmitted from left to right. 724 0 1 2 3 725 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 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Type | Length | Extended-Type | Value ... 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 Type 732 241 for Extended-Type-1. 734 Length 736 >= 4 738 Extended-Type 740 The Extended-Type field is one octet. Up-to-date values of this 741 field are specified by IANA, in the 241.{1-255} RADIUS Attribute 742 Type Space. Further definition of this field is given in Section 743 2.1, above. 745 String 747 The String field is one or more octets. Implementations not 748 supporting this specification SHOULD support the field as 749 undistinguished octets. 751 Implementations supporting this specification MUST use the 752 Identifier of "Type.Extended-Type" to determine the interpretation 753 of the String field. 755 3.2. Extended-Type-2 757 Description 759 This attribute encapsulates attributes of the "Extended Type" 760 format, in the RADIUS Attribute Type Space of 242.{1-255}. 762 A summary of the Extended-Type-2 Attribute format is shown below. 763 The fields are transmitted from left to right. 765 0 1 2 3 766 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 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Type | Length | Extended-Type | Value ... 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 Type 773 242 for Extended-Type-2. 775 Length 777 >= 4 779 Extended-Type 781 The Extended-Type field is one octet. Up-to-date values of this 782 field are specified by IANA, in the 242.{1-255} RADIUS Attribute 783 Type Space. Further definition of this field is given in Section 784 2.1, above. 786 String 788 The String field is one or more octets. Implementations not 789 supporting this specification SHOULD support the field as 790 undistinguished octets. 792 Implementations supporting this specification MUST use the 793 Identifier of "Type.Extended-Type" to determine the interpretation 794 of the String field 796 3.3. Extended-Type-3 798 Description 800 This attribute encapsulates attributes of the "Extended Type" 801 format, in the RADIUS Attribute Type Space of 243.{1-255}. 803 A summary of the Extended-Type-3 Attribute format is shown below. 804 The fields are transmitted from left to right. 806 0 1 2 3 807 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 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Type | Length | Extended-Type | Value ... 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 Type 814 243 for Extended-Type-3. 816 Length 818 >= 4 820 Extended-Type 822 The Extended-Type field is one octet. Up-to-date values of this 823 field are specified by IANA, in the 243.{1-255} RADIUS Attribute 824 Type Space. Further definition of this field is given in Section 825 2.1, above. 827 String 829 The String field is one or more octets. Implementations not 830 supporting this specification SHOULD support the field as 831 undistinguished octets. 833 Implementations supporting this specification MUST use the 834 Identifier of "Type.Extended-Type" to determine the interpretation 835 of the String field. 837 3.4. Extended-Type-4 839 Description 841 This attribute encapsulates attributes of the "Extended Type" 842 format, in the RADIUS Attribute Type Space of 244.{1-255}. 844 A summary of the Extended-Type-4 Attribute format is shown below. 845 The fields are transmitted from left to right. 847 0 1 2 3 848 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 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Type | Length | Extended-Type | Value ... 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 Type 855 244 for Extended-Type-4. 857 Length 859 >= 4 861 Extended-Type 863 The Extended-Type field is one octet. Up-to-date values of this 864 field are specified by IANA, in the 244.{1-255} RADIUS Attribute 865 Type Space. Further definition of this field is given in Section 866 2.1, above. 868 String 870 The String field is one or more octets. Implementations not 871 supporting this specification SHOULD support the field as 872 undistinguished octets. 874 Implementations supporting this specification MUST use the 875 Identifier of "Type.Extended-Type" to determine the interpretation 876 of the String Field. 878 3.5. Extended-Type-Flagged-1 880 Description 882 This attribute encapsulates attributes of the "Extended Type with 883 Flags" format, in the RADIUS Attribute Type Space of 245.{1-255}. 885 A summary of the Extended-Type-Flagged-1 Attribute format is shown 886 below. The fields are transmitted from left to right. 888 0 1 2 3 889 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 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | Type | Length | Extended-Type |M| Flags | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Value ... 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 Type 898 245 for Extended-Type-Flagged-1 900 Length 902 >= 4 904 Extended-Type 906 The Extended-Type field is one octet. Up-to-date values of this 907 field are specified by IANA, in the 245.{1-255} RADIUS Attribute 908 Type Space. Further definition of this field is given in Section 909 2.1, above. 911 M (More) 913 The More Flag is one (1) bit in length, and indicates whether or 914 not the current attribute contains "more" than 251 octets of data. 915 Further definition of this field is given in Section 2.2, above. 917 Flags 919 This field is 7 bits long, and is reserved for future use. 920 Implementations MUST set it to zero (0) when encoding an attribute 921 for sending in a packet. The contents SHOULD be ignored on 922 reception. 924 String 926 The String field is one or more octets. Implementations not 927 supporting this specification SHOULD support the field as 928 undistinguished octets. 930 Implementations supporting this specification MUST use the 931 Identifier of "Type.Extended-Type" to determine the interpretation 932 of the String field. 934 3.6. Extended-Type-Flagged-2 936 Description 938 This attribute encapsulates attributes of the "Extended Type with 939 Flags" format, in the RADIUS Attribute Type Space of 246.{1-255}. 941 A summary of the Extended-Type-Flagged-2 Attribute format is shown 942 below. The fields are transmitted from left to right. 944 0 1 2 3 945 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 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | Type | Length | Extended-Type |M| Flags | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | Value ... 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 Type 954 246 for Extended-Type-Flagged-2 956 Length 958 >= 4 960 Extended-Type 962 The Extended-Type field is one octet. Up-to-date values of this 963 field are specified by IANA, in the 246.{1-255} RADIUS Attribute 964 Type Space. Further definition of this field is given in Section 965 2.1, above. 967 M (More) 969 The More Flag is one (1) bit in length, and indicates whether or 970 not the current attribute contains "more" than 251 octets of data. 971 Further definition of this field is given in Section 2.2, above. 973 Flags 975 This field is 7 bits long, and is reserved for future use. 976 Implementations MUST set it to zero (0) when encoding an attribute 977 for sending in a packet. The contents SHOULD be ignored on 978 reception. 980 String 981 The String field is one or more octets. Implementations not 982 supporting this specification SHOULD support the field as 983 undistinguished octets. 985 Implementations supporting this specification MUST use the 986 Identifier of "Type.Extended-Type" to determine the interpretation 987 of the String field. 989 4. Vendor Specific Attributes 991 We define six new attributes which can carry Vendor Specific 992 information. We define four (4) attributes of the "Extended Type" 993 format, with Type codes (241.26, 242.26, 243.26, 244.26), using the 994 "evs" data type. We also define two (2) attributes of "Extended Type 995 with Flags" format, with Type codes (245.26, 246.26), using the "evs" 996 data type. 998 Type.Extended-Type Name 999 ------------------ ---- 1000 241.26 Extended-Vendor-Specific-1 1001 242.26 Extended-Vendor-Specific-2 1002 243.26 Extended-Vendor-Specific-3 1003 244.26 Extended-Vendor-Specific-4 1004 245.26 Extended-Vendor-Specific-5 1005 246.26 Extended-Vendor-Specific-6 1007 The rest of this section gives a detailed definition for each 1008 Attribute based on the above summary. 1010 4.1. Extended-Vendor-Specific-1 1012 Description 1014 This attribute defines a RADIUS Type Code of 241.26, using the 1015 "evs" data type. 1017 A summary of the Extended-Vendor-Specific-1 Attribute format is shown 1018 below. The fields are transmitted from left to right. 1020 0 1 2 3 1021 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 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | Type | Length | Extended-Type | Vendor-Id ... 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 ... Vendor-Id (cont) | Vendor-Type | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | String .... 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 Type.Extended-Type 1031 241.26 for Extended-Vendor-Specific-1 1033 Length 1035 >= 9 1037 Vendor-Id 1039 The high-order octet is 0 and the low-order 3 octets are the SMI 1040 Network Management Private Enterprise Code of the Vendor in 1041 network byte order. 1043 Vendor-Type 1045 The Vendor-Type field is one octet. Values are assigned at the 1046 sole discretion of the Vendor. 1048 String 1050 The String field is one or more octets. The actual format of the 1051 information is site or application specific, and a robust 1052 implementation SHOULD support the field as undistinguished octets. 1054 The codification of the range of allowed usage of this field is 1055 outside the scope of this specification. 1057 The length of the String field is eight (8) less then the value of 1058 the Length field. 1060 Implementations supporting this specification MUST use the 1061 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1062 determine the interpretation of the String field. 1064 4.2. Extended-Vendor-Specific-2 1066 Description 1068 This attribute defines a RADIUS Type Code of 242.26, using the 1069 "evs" data type. 1071 A summary of the Extended-Vendor-Specific-2 Attribute format is shown 1072 below. The fields are transmitted from left to right. 1074 0 1 2 3 1075 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 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | Type | Length | Extended-Type | Vendor-Id ... 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 ... Vendor-Id (cont) | Vendor-Type | 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | String .... 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 Type.Extended-Type 1086 242.26 for Extended-Vendor-Specific-2 1088 Length 1090 >= 9 1092 Vendor-Id 1094 The high-order octet is 0 and the low-order 3 octets are the SMI 1095 Network Management Private Enterprise Code of the Vendor in 1096 network byte order. 1098 Vendor-Type 1100 The Vendor-Type field is one octet. Values are assigned at the 1101 sole discretion of the Vendor. 1103 String 1105 The String field is one or more octets. The actual format of the 1106 information is site or application specific, and a robust 1107 implementation SHOULD support the field as undistinguished octets. 1109 The codification of the range of allowed usage of this field is 1110 outside the scope of this specification. 1112 The length of the String field is eight (8) less then the value of 1113 the Length field. 1115 Implementations supporting this specification MUST use the 1116 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1117 determine the interpretation of the String field. 1119 4.3. Extended-Vendor-Specific-3 1121 Description 1123 This attribute defines a RADIUS Type Code of 243.26, using the 1124 "evs" data type. 1126 A summary of the Extended-Vendor-Specific-3 Attribute format is shown 1127 below. The fields are transmitted from left to right. 1129 0 1 2 3 1130 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 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | Type | Length | Extended-Type | Vendor-Id ... 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 ... Vendor-Id (cont) | Vendor-Type | 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | String .... 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 Type.Extended-Type 1141 243.26 for Extended-Vendor-Specific-3 1143 Length 1145 >= 9 1147 Vendor-Id 1149 The high-order octet is 0 and the low-order 3 octets are the SMI 1150 Network Management Private Enterprise Code of the Vendor in 1151 network byte order. 1153 Vendor-Type 1155 The Vendor-Type field is one octet. Values are assigned at the 1156 sole discretion of the Vendor. 1158 String 1160 The String field is one or more octets. The actual format of the 1161 information is site or application specific, and a robust 1162 implementation SHOULD support the field as undistinguished octets. 1164 The codification of the range of allowed usage of this field is 1165 outside the scope of this specification. 1167 The length of the String field is eight (8) less then the value of 1168 the Length field. 1170 Implementations supporting this specification MUST use the 1171 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1172 determine the interpretation of the String field. 1174 4.4. Extended-Vendor-Specific-4 1176 Description 1178 This attribute defines a RADIUS Type Code of 244.26, using the 1179 "evs" data type. 1181 A summary of the Extended-Vendor-Specific-3 Attribute format is shown 1182 below. The fields are transmitted from left to right. 1184 0 1 2 3 1185 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 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | Type | Length | Extended-Type | Vendor-Id ... 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 ... Vendor-Id (cont) | Vendor-Type | 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | String .... 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 Type.Extended-Type 1196 244.26 for Extended-Vendor-Specific-4 1198 Length 1200 >= 9 1202 Vendor-Id 1204 The high-order octet is 0 and the low-order 3 octets are the SMI 1205 Network Management Private Enterprise Code of the Vendor in 1206 network byte order. 1208 Vendor-Type 1210 The Vendor-Type field is one octet. Values are assigned at the 1211 sole discretion of the Vendor. 1213 String 1215 The String field is one or more octets. The actual format of the 1216 information is site or application specific, and a robust 1217 implementation SHOULD support the field as undistinguished octets. 1219 The codification of the range of allowed usage of this field is 1220 outside the scope of this specification. 1222 The length of the String field is eight (8) less then the value of 1223 the Length field. 1225 Implementations supporting this specification MUST use the 1226 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1227 determine the interpretation of the String field. 1229 4.5. Extended-Vendor-Specific-5 1231 Description 1233 This attribute defines a RADIUS Type Code of 245.26, using the 1234 "evs" data type. 1236 A summary of the Extended-Vendor-Specific-5 Attribute format is shown 1237 below. The fields are transmitted from left to right. 1239 0 1 2 3 1240 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 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 | Type | Length | Extended-Type |M| Flags | 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 | Vendor-Id | 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 | Vendor-Type | String .... 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 Type.Extended-Type 1251 245.26 for Extended-Vendor-Specific-5 1253 Length 1255 >= 10 (first fragment) 1256 >= 5 (subsequent fragments) 1258 When a VSA is fragmented across multiple Attributes, only the 1259 first Attribute contains the Vendor-Id and Vendor-Type fields. 1260 Subsequent Attributes contain fragments of the String field only. 1262 M (More) 1264 The More Flag is one (1) bit in length, and indicates whether or 1265 not the current attribute contains "more" than 251 octets of data. 1266 Further definition of this field is given in Section 2.2, above. 1268 Flags 1269 This field is 7 bits long, and is reserved for future use. 1270 Implementations MUST set it to zero (0) when encoding an attribute 1271 for sending in a packet. The contents SHOULD be ignored on 1272 reception. 1274 Vendor-Id 1276 The high-order octet is 0 and the low-order 3 octets are the SMI 1277 Network Management Private Enterprise Code of the Vendor in 1278 network byte order. 1280 Vendor-Type 1282 The Vendor-Type field is one octet. Values are assigned at the 1283 sole discretion of the Vendor. 1285 String 1287 The String field is one or more octets. The actual format of the 1288 information is site or application specific, and a robust 1289 implementation SHOULD support the field as undistinguished octets. 1291 The codification of the range of allowed usage of this field is 1292 outside the scope of this specification. 1294 Implementations supporting this specification MUST use the 1295 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1296 determine the interpretation of the String field. 1298 4.6. Extended-Vendor-Specific-6 1300 Description 1302 This attribute defines a RADIUS Type Code of 246.26, using the 1303 "evs" data type. 1305 A summary of the Extended-Vendor-Specific-6 Attribute format is shown 1306 below. The fields are transmitted from left to right. 1308 0 1 2 3 1309 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 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 | Type | Length | Extended-Type |M| Flags | 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | Vendor-Id | 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 | Vendor-Type | String .... 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1317 Type.Extended-Type 1319 246.26 for Extended-Vendor-Specific-6 1321 Length 1323 >= 10 (first fragment) 1324 >= 5 (subsequent fragments) 1326 When a VSA is fragmented across multiple Attributes, only the 1327 first Attribute contains the Vendor-Id and Vendor-Type fields. 1328 Subsequent Attributes contain fragments of the String field only. 1330 M (More) 1332 The More Flag is one (1) bit in length, and indicates whether or 1333 not the current attribute contains "more" than 251 octets of data. 1334 Further definition of this field is given in Section 2.2, above. 1336 Flags 1338 This field is 7 bits long, and is reserved for future use. 1339 Implementations MUST set it to zero (0) when encoding an attribute 1340 for sending in a packet. The contents SHOULD be ignored on 1341 reception. 1343 Vendor-Id 1345 The high-order octet is 0 and the low-order 3 octets are the SMI 1346 Network Management Private Enterprise Code of the Vendor in 1347 network byte order. 1349 Vendor-Type 1351 The Vendor-Type field is one octet. Values are assigned at the 1352 sole discretion of the Vendor. 1354 String 1356 The String field is one or more octets. The actual format of the 1357 information is site or application specific, and a robust 1358 implementation SHOULD support the field as undistinguished octets. 1360 The codification of the range of allowed usage of this field is 1361 outside the scope of this specification. 1363 Implementations supporting this specification MUST use the 1364 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1365 determine the interpretation of the String field. 1367 5. Compatibility with traditional RADIUS 1369 There are a number of potential compatibility issues with traditional 1370 RADIUS. This section describes them. 1372 5.1. Attribute Allocation 1374 Some vendors have used Attribute Type codes from the "Reserved" 1375 space, as part of vendor-defined dictionaries. This practice is 1376 considered anti-social behavior, as noted in [RFC6158]. These vendor 1377 definitions conflict with the attributes in the RADIUS Attribute Type 1378 space. The conflicting definitions may make it difficult for 1379 implementations to support both those Vendor Attributes, and the new 1380 Extended Attribute formats. 1382 We RECOMMEND that RADIUS client and server implementations delete all 1383 references to these improperly defined attributes. Failing that, we 1384 RECOMMEND that RADIUS server implementations have a per-client 1385 configurable flag which indicates which type of attributes are being 1386 sent from the client. If the flag is set one way, the conflicting 1387 attributes can be interpreted as being improperly defined Vendor 1388 Specific Attributes. If the flag is set the other way, the attributes 1389 MUST be interpreted as being of the Extended Attributes format. The 1390 default SHOULD be to interpret the attributes as being of the 1391 Extended Attributes format. 1393 Other methods of determining how to decode the attributes into a 1394 "correct" form are NOT RECOMMENDED. Those methods are likely to be 1395 fragile and prone to error. 1397 We RECOMMEND that RADIUS server implementations re-use the above flag 1398 to determine which type of attributes to send in a reply message. If 1399 the request is expected to contain the improperly defined attributes, 1400 the reply SHOULD NOT contain Extended Attributes. If the request is 1401 expected to contain Extended Attributes, the reply MUST NOT contain 1402 the improper Attributes. 1404 RADIUS clients will have fewer issues than servers. Clients MUST NOT 1405 send improperly defined Attributes in a request. For replies, 1406 clients MUST interpret attributes as being of the Extended Attributes 1407 format, instead of the improper definitions. These requirements 1408 impose no change in the RADIUS specifications, as such usage by 1409 vendors has always been in conflict with the standard requirements 1410 and the standards process. 1412 Existing clients that send these improperly defined attributes 1413 usually have a configuration setting which can disable this behavior. 1414 We RECOMMEND that vendors ship products with the default set to 1415 "disabled". We RECOMMEND that administrators set this flag to 1416 "disabled" on all equipment that they manage. 1418 5.2. Proxy Servers 1420 RADIUS Proxy servers will need to forward Attributes having the new 1421 format, even if they do not implement support for the encoding and 1422 decoding of those attributes. We remind implementors of the 1423 following text in [RFC2865] Section 2.3: 1425 The forwarding server MUST NOT change the order of any attributes 1426 of the same type, including Proxy-State. 1428 This requirement solves some of the issues related to proxying of the 1429 new format, but not all. The reason is that proxy servers are 1430 permitted to examine the contents of the packets that they forward. 1431 Many proxy implementations not only examine the attributes, but they 1432 refuse to forward attributes which they do not understand (i.e. 1433 attributes for which they have no local dictionary definitions). 1435 This practice is NOT RECOMMENDED. Proxy servers SHOULD forward 1436 attributes, even ones which they do not understand, or which are not 1437 in a local dictionary. When forwarded, these attributes SHOULD be 1438 sent verbatim, with no modifications or changes. The only exception 1439 to this recommendation is when local site policy dictates that 1440 filtering of attributes has to occur. For example, a filter at a 1441 visited network may require removal of certain authorization rules 1442 which apply to the home network, but not to the visited network. 1443 This filtering can sometimes be done even when the contents of the 1444 attributes are unknown, such as when all Vendor-Specific Attributes 1445 are designated for removal. 1447 As seen in [EDUROAM] many proxies do not follow these practices for 1448 unknown Attributes. Some proxies filter out unknown attributes or 1449 attributes which have unexpected lengths (24%, 17/70), some truncate 1450 the attributes to the "expected" length (11%, 8/70), some discard the 1451 request entirely (1%, 1/70), with the rest (63%, 44/70) following the 1452 recommended practice of passing the attributes verbatim. It will be 1453 difficult to widely use the Extended Attributes format until all non- 1454 conformant proxies are fixed. We therefore RECOMMEND that all 1455 proxies which do not support the Extended Attributes (241 through 1456 246) define them as being of data type "string", and delete all other 1457 local definitions for those attributes. 1459 This last change should enable wider usage of the Extended Attributes 1460 format. 1462 6. Guidelines 1464 This specification proposes a number of changes to RADIUS, and 1465 therefore requires a set of guidelines, as has been done in 1466 [RFC6158]. 1468 6.1. Updates to RFC 6158 1470 This specification updates [RFC6158] by adding the data types "evs", 1471 "tlv" and "integer64"; defining them to be "basic" data types; and 1472 permitting their use subject to the restrictions outlined below. 1474 All other recommendations given in [RFC6158] are unchanged. New 1475 recommendations for the use of the new data types and attribute 1476 formats are given below. 1478 6.2. Guidelines For the New Types 1480 We recommend the following guidelines when designing attributes using 1481 the new format. The items listed below are not exhaustive. As 1482 experience is gained with the new formats, later specifications may 1483 define additional guidelines. 1485 * The data type "evs" MUST NOT be used for standard RADIUS 1486 Attributes, or for TLVs, or for VSAs. 1488 * The data type "tlv" SHOULD NOT be used for standard RADIUS 1489 attributes. While its use is NOT RECOMMENDED by [RFC6158], this 1490 specification updates [RFC6158] to permit the "tlv" data type in 1491 attributes using the Extended-Type format. 1493 * [RFC2866] "tagged" attributes MUST NOT be defined in the 1494 Extended-Type space. The "tlv" data type should be used instead to 1495 group attributes. 1497 * The "integer64" data type MAY be used in any RADIUS attribute. 1498 The use of 64-bit integers is NOT RECOMMENDED by [RFC6158], but 1499 their utility is now evident. 1501 * For all other circumstances, the guidelines in [RFC6158] MUST 1502 be followed. 1504 6.3. Allocation Request Guidelines 1506 The following items give guidelines for allocation requests made in a 1507 RADIUS specification. 1509 * Discretion is RECOMMENDED when requesting allocation of attributes. 1510 The new space is much larger than the old one, but it is not 1511 infinite. 1513 * When the Type spaces of 241.*, 242.*, 243.*, or 244.* are nearing 1514 exhaustion, a new specification SHOULD be written which requests 1515 allocation of one or more RADIUS Attributes from the "Reserved" 1516 space, using the "Extended Type" format. This process is 1517 preferable to allocating "small" attributes from the 256.* and 1518 246.* Type spaces. 1520 * When the Type spaces of 245.* or 246.* are nearing exhaustion, a 1521 new specification SHOULD be written which requests allocation of 1522 one or more RADIUS Attributes from the "Reserved" space, using the 1523 "Extended Type with flags" format. 1525 * All other specifications SHOULD NOT request allocation from the 1526 standard Attribute Type Space (i.e. Attributes 1 through 255). 1527 That space is deprecated, and is not to be used. 1529 * Attributes which encode 252 octets or less of data SHOULD 1530 request allocation from the Type spaces of 241.*, 242.*, 243.*, 1531 or 244.*. 1533 * Attributes which encode 253 octets or more of data MUST request 1534 allocation from the Type spaces of 245.* or 246.*. 1536 6.4. TLV Guidelines 1538 The following items give guidelines for specifications using TLVs. 1540 * when multiple attributes are intended to be grouped or managed 1541 together, the use of TLVs to group related attributes is 1542 RECOMMENDED. 1544 * more than 4 layers (depth) of TLV nesting is NOT RECOMMENDED. 1546 * Interpretation of an attribute depends only on its type 1547 definition (e.g. Type.Extended-Type.TLV-Type, etc.), and 1548 not on its encoding or location in the RADIUS packet. 1550 * Where a group of TLVs is strictly defined, and not expected to 1551 change, and and totals less than 247 octets of data, they SHOULD 1552 request allocation from the Type spaces of 241.*, 242.*, 243.*, or 1553 244.*. 1555 * Where a group of TLVs is loosely defined, or is expected to change, 1556 they SHOULD request allocation from the Type spaces of 245.* or 1557 246.*. 1559 6.5. Implementation Guidelines 1561 * RADIUS client implementations SHOULD support this specification 1562 as soon as possible. 1564 * RADIUS server implementations SHOULD support this specification 1565 as soon as possible. 1567 * RADIUS proxy servers SHOULD forward all attributes, even ones 1568 which they do not understand, or which are not in a local 1569 dictionary. These attributes SHOULD be forwarded verbatim, with 1570 no modifications or changes. 1572 * Any attribute which is allocated from the Type spaces of 245.* or 1573 246.*, of data type "text", "string", or "tlv" can end up carrying 1574 more than 251 octets of data, up to the maximum RADIUS packet 1575 length (~4096 octets). Specifications defining such attributes 1576 SHOULD define a maximum length. 1578 6.6. Vendor Guidelines 1580 * Vendors SHOULD use the existing Vendor-Specific Attribute Type 1581 space in preference to the new Extended-Vendor-Specific 1582 attributes, as this specification may take time to become widely 1583 deployed. 1585 * Vendors SHOULD implement this specification as soon as 1586 possible. The changes to RADIUS are relatively small, and are 1587 likely to quickly be used in new specifications. 1589 7. Rationale 1591 The path to extending the RADIUS protocol has been long and arduous. 1592 A number of proposals have been made and discarded by the RADEXT 1593 working group. These proposals have been judged to be either too 1594 bulky, too complex, too simple, or to be unworkable in practice. We 1595 do not otherwise explain here why earlier proposals did not obtain 1596 working group consensus. 1598 The changes outlined here have the benefit of being simple, as the 1599 "Extended Type" format requires only a one octet change to the 1600 Attribute format. The downside is that the "Extended Type with 1601 Flags" format is awkward, and the 7 bits of Flags will likey never be 1602 used for anything. 1604 7.1. Attribute Audit 1606 An audit of almost five thousand publicly available attributes 1607 [ATTR], shows the statistics summarized below. The attributes include 1608 over 100 Vendor dictionaries, along with the IANA assigned 1609 attributes: 1611 Count Data Type 1612 ----- --------- 1613 2257 integer 1614 1762 text 1615 273 IPv4 Address 1616 225 string 1617 96 other data types 1618 35 IPv6 Address 1619 18 date 1620 10 integer64 1621 4 Interface Id 1622 3 IPv6 Prefix 1624 4683 Total 1626 The entries in the "Data Type" column are data types recommended by 1627 [RFC6158], along with "integer64". The "other data types" row 1628 encompasses other data types. 1630 Manual inspection of the dictionaries shows that approximately 20 (or 1631 0.5%) attributes have the ability to transport more than 253 octets 1632 of data. These attributes are divided between VSAs, and a small 1633 number of standard Attributes. While the "Extended Type with Flags" 1634 format is therefore important, "long" attributes have had limited 1635 deployment 1637 8. Examples 1639 A few examples are presented here, in order to illustrate the 1640 encoding of the new attribute formats. These examples are not 1641 intended to be exhaustive, as many others are possible. For 1642 simplicity, we do not show complete packets, only attributes. 1644 The examples are given using a domain-specific language implemented 1645 by the program given in Appendix A. The language is line oriented, 1646 and composed of a sequence of lines matching the grammar ([RFC5234]) 1647 given below: 1649 Identifier = 1*DIGIT *( "." 1*DIGIT ) 1651 HEXCHAR = HEXDIG HEXDIG 1652 STRING = DQUOTE 1*CHAR DQUOTE 1654 TLV = "{" 1*DIGIT DATA "}" 1656 DATA = 1*HEXCHAR / 1*TLV / STRING 1658 LINE = Identifier DATA 1660 The progam has additional restrictions on its input that are not 1661 reflected in the above grammar. For example, the portions of the 1662 Identifier which refer to Type and Extended-Type are limited to 1663 values between 1 and 255. We trust that the source code in Appendix 1664 A is clear, and that these restrictions do not negatively affect the 1665 comprehensability of the examples. 1667 The program reads the input text, and interprets it as a set of 1668 instructions to create RADIUS Attributes. It then prints the hex 1669 encoding of those attributes. It implements the minimum set of 1670 functionality which achieves that goal. This minimalism means that 1671 it does not use attribute dictionaries; it does not implement support 1672 for RADIUS data types; it can be used to encode attributes with 1673 invalid data field(s); and there is no requirement for consistency 1674 from one example to the next. For example, it can be used to encode 1675 a User-Name attribute which contains non-UTF8 data, or a Framed-IP- 1676 Address which contains 253 octets of ASCII data. As a result, it 1677 MUST NOT be used to create RADIUS Attributes for transport in a 1678 RADIUS message. 1680 However, the program correctly encodes the RADIUS attribute fields of 1681 "Type", "Length", "Extended-Type", "More", "Flags", "Vendor-Id", 1682 "Vendor-Type", and "Vendor-Length". It can therefore be used to 1683 encode example attributes from input which is humanly readable. 1685 We do not give examples of "malformed" or "invalid attributes". We 1686 also note that the examples show format, and not consistent meaning. 1687 A particular attribute type code may be used to demonstrate two 1688 different formats. In real specifications, attributes have a static 1689 definitions based on their type code. 1691 The examples given below are strictly for demonstration purposes 1692 only, and do not provide a standard of any kind. 1694 8.1. Extended Type 1696 The following are a series of examples of the "Extended Type" format. 1698 Attribute encapsulating textual data. 1700 241.1 "bob" 1701 -> f1 06 01 62 6f 62 1703 Attribute encapsulating a TLV with TLV-Type of one (1). 1705 241.2 { 1 23 45 } 1706 -> f1 07 02 01 04 23 45 1708 Attribute encapsulating two TLVs, one after the other. 1710 241.2 { 1 23 45 } { 2 67 89 } 1711 -> f1 0b 02 01 04 23 45 02 04 67 89 1713 Attribute encapsulating two TLVs, where the second TLV is itself 1714 encapsulating a TLV. 1716 241.2 { 1 23 45 } { 3 { 1 ab cd } } 1717 -> f1 0d 02 01 04 23 45 03 06 01 04 ab cd 1719 Attribute encapsulating two TLVs, where the second TLV is itself 1720 encapsulating two TLVs. 1722 241.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } 1723 -> f1 12 02 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f 1725 Attribute encapsulating a TLV, which in turn encapsulates a TLV, 1726 to a depth of 5 nestings. 1728 241.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } 1729 -> f1 0f 01 01 0c 02 0a 03 08 04 06 05 04 cd ef 1731 Attribute encapsulating an extended Vendor Specific attribute, 1732 with Vendor-Id of 1, and Vendor-Type of 4, which in turn 1733 encapsulates textual data. 1735 241.26.1.4 "test" 1736 -> f1 0c 1a 00 00 00 01 04 74 65 73 74 1738 Attribute encapsulating an extended Vendor Specific attribute, with 1739 Vendor-Id of 1, and Vendor-Type of 5, which in turn encapsulates 1740 a TLV with TLV-Type of 3, which encapsulates textual data. 1742 241.26.1.5 { 3 "test" } 1743 -> f1 0e 1a 00 00 00 01 05 03 06 74 65 73 74 1745 8.2. Extended Type with Flags 1747 The following are a series of examples of the "Extended Type with 1748 flags" format. 1750 Attribute encapsulating textual data. 1752 245.1 "bob" 1753 -> f5 07 01 00 62 6f 62 1755 Attribute encapsulating a TLV with TLV-Type of one (1). 1757 245.2 { 1 23 45 } 1758 -> f5 08 02 00 01 04 23 45 1760 Attribute encapsulating two TLVs, one after the other. 1762 245.2 { 1 23 45 } { 2 67 89 } 1763 -> f5 0c 02 00 01 04 23 45 02 04 67 89 1765 Attribute encapsulating two TLVs, where the second TLV is itself 1766 encapsulating a TLV. 1768 245.2 { 1 23 45 } { 3 { 1 ab cd } } 1769 -> f5 0e 02 00 01 04 23 45 03 06 01 04 ab cd 1771 Attribute encapsulating two TLVs, where the second TLV is itself 1772 encapsulating two TLVs. 1774 245.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } 1775 -> f5 13 02 00 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f 1777 Attribute encapsulating a TLV, which in turn encapsulates a TLV, 1778 to a depth of 5 nestings. 1780 245.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } 1781 -> f5 10 01 00 01 0c 02 0a 03 08 04 06 05 04 cd ef 1783 Attribute encapsulating an extended Vendor Specific attribute, 1784 with Vendor-Id of 1, and Vendor-Type of 4, which in turn 1785 encapsulates textual data. 1787 245.26.1.4 "test" 1788 -> f5 0d 1a 00 00 00 00 01 04 74 65 73 74 1790 Attribute encapsulating an extended Vendor Specific attribute, 1791 with Vendor-Id of 1, and Vendor-Type of 5, which in turn 1792 encapsulates a TLV with TLV-Type of 3, which encapsulates 1793 textual data. 1795 245.26.1.5 { 3 "test" } 1796 -> f5 0f 1a 00 00 00 00 01 05 03 06 74 65 73 74 1798 Attribute encapsulating more than 251 octets of data. The "Data" 1799 portions are indented for readability. 1801 245.4 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1802 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1803 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1804 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1805 aaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1806 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1807 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1808 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1809 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbcccccccccccccccccccc 1810 cccccccccc 1811 -> f5 ff 04 80 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1812 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1813 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1814 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1815 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1816 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1817 aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb bb bb bb bb bb 1818 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1819 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1820 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1821 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1822 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1823 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 13 04 00 cc 1824 cc cc cc cc cc cc cc cc cc cc cc cc cc cc 1826 Attribute encapsulating an extended Vendor Specific attribute, 1827 with Vendor-Id of 1, and Vendor-Type of 6, which in turn 1828 encapsulates more than 251 octets of data. 1830 As the VSA encapsulates more than 251 octets of data, it is 1831 split into two RADIUS attributes. The first attribute has the 1832 More flag set, and carries the Vendor-Id and Vendor-Type. 1833 The second attribute has the More flag clear, and carries 1834 the rest of the data portion of the VSA. Note that the second 1835 attribute does not include the Vendor-Id ad Vendor-Type fields. 1837 The "Data" portions are indented for readability. 1839 245.26.1.6 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1840 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1841 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1842 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1843 aaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1844 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1845 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1846 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1847 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbccccccccccccc 1848 ccccccccccccccccc 1849 -> f5 ff 1a 80 00 00 00 01 06 aa aa aa aa aa aa aa aa aa aa aa 1850 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1851 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1852 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1853 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1854 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1855 aa aa aa aa aa aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb 1856 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1857 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1858 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1859 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1860 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1861 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 17 1a 00 bb 1862 bb bb bb bb cc cc cc cc cc cc cc cc cc cc 13 45 67 89 1864 9. IANA Considerations 1866 This document has multiple impacts on IANA, in the "RADIUS Attribute 1867 Types" registry. Attribute types which were previously reserved are 1868 now allocated, previously free attributes are marked deprecated, and 1869 the registry is extended from a simple 8-bit array to a tree-like 1870 structure, up to a maximum depth of 125 nodes. 1872 9.1. Attribute Allocations 1874 IANA is requested to move the "Unassigned" numbers in the range 1875 144-191 from "Unassigned" to "Deprecated". New allocations are 1876 normally taken from the Extended Type space, starting with lower 1877 numbered attributes. However, allocation from the "Deprecated" space 1878 can still be performed by publication of an IETF specification, where 1879 that specification requests allocation from the "Deprecated" space, 1880 and gives reasons why use of the Extended Type space is impossible. 1882 IANA is requested to move the following numbers from "Reserved", to 1883 allocated, with the following names: 1885 * 241 Extended-Type-1 1886 * 242 Extended-Type-2 1887 * 243 Extended-Type-3 1888 * 244 Extended-Type-4 1889 * 245 Extended-Type-Flagged-1 1890 * 246 Extended-Type-Flagged-2 1892 These attributes serve as an encapsulation layer for the new RADIUS 1893 Attribute Type tree. 1895 9.2. RADIUS Attribute Type Tree 1897 Each of the attributes allocated above extends the "RADIUS Attribute 1898 Types" to an N-ary tree, via a "dotted number" notation. Each number 1899 in the tree is an 8-bit value (1 to 255). The value zero (0) is not 1900 used. Currently, only one level of the tree is defined: 1902 * 241 Extended-Attribute-1 1903 * 241.{1-25} Unassigned 1904 * 241.26 Extended-Vendor-Specific-1 1905 * 241.{27-240} Unassigned 1906 * 241.{241-255} Reserved 1907 * 242 Extended-Attribute-2 1908 * 242.{1-25} Unassigned 1909 * 242.26 Extended-Vendor-Specific-2 1910 * 242.{27-240} Unassigned 1911 * 243 Extended-Attribute-3 1912 * 242.{241-255} Reserved 1913 * 243.{1-25} Unassigned 1914 * 243.26 Extended-Vendor-Specific-3 1915 * 243.{27-240} Unassigned 1916 * 243.{241-255} Reserved 1917 * 244 Extended-Attribute-4 1918 * 244.{1-25} Unassigned 1919 * 244.26 Extended-Vendor-Specific-4 1920 * 244.{27-240} Unassigned 1921 * 244.{241-255} Reserved 1922 * 245 Extended-Attribute-5 1923 * 245.{1-25} Unassigned 1924 * 245.26 Extended-Vendor-Specific-5 1925 * 245.{27-240} Unassigned 1926 * 245.{241-255} Reserved 1927 * 246 Extended-Attribute-6 1928 * 246.{1-25} Unassigned 1929 * 245.26 Extended-Vendor-Specific-6 1930 * 246.{27-240} Unassigned 1931 * 246.{241-255} Reserved 1933 The values marked "Unassigned" above are available for assignment by 1934 IANA in future RADIUS specifications. The values marked "Reserved" 1935 are reserved for future use. 1937 9.3. Extending the Attribute Type Tree 1939 When specifications request allocation of an attribute of data type 1940 "tlv", that allocation extends the Attribute Type Tree by one more 1941 level. The value zero (0) is not used. Values 254 and 255 are 1942 Reserved. All other values are available for allocation. 1944 For example, if a new attribute "Example-TLV" of data type "tlv" is 1945 assigned the identifier "245.1", then the extended tree will be 1946 allocation as below: 1948 * 245.1 Example-TLV 1949 * 245.1.{1-253} Unassigned 1950 * 245.1.{254-255} Reserved 1952 Note that this example does not define an "Example-TLV" attribute. 1954 The Attribute Type Tree can be extended multiple levels in one 1955 specification when the specification requests allocation of nested 1956 TLVs. 1958 10. Security Considerations 1960 This document defines new formats for data carried inside of RADIUS, 1961 but otherwise makes no changes to the security of the RADIUS 1962 protocol. 1964 Attacks on cryptographic hashes are well known, and are getting 1965 better with time, as discussed in[RFC4270]. RADIUS uses the MD5 hash 1966 [RFC1321] for packet authentication and attribute obfuscation. There 1967 are ongoing efforts in the IETF to analyze and address these issues 1968 for the RADIUS protocol. 1970 As with any protocol change, code changes are required in order to 1971 implement the new features. These code changes have the potential to 1972 introduce new vulnerabilities in the software. Since the RADIUS 1973 server performs network authentication, it is an inviting target for 1974 attackers. We RECOMMEND that access to RADIUS servers be kept to a 1975 minimum. 1977 11. References 1979 11.1. Normative references 1981 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1982 Requirement Levels", RFC 2119, March, 1997. 1984 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 1985 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1986 2000. 1988 11.2. Informative references 1990 [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, 1991 April, 1992 1993 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1995 [RFC2868] Zorn, G., et al, " RADIUS Attributes for Tunnel Protocol 1996 Support", RFC 2868, June 2000. 1998 [RFC4270] Hoffman, P, and Schneier, B, "Attacks on Cryptographic Hashes 1999 in Internet Protocols", RFC 4270, November 2005. 2001 [RFC5234] Crocker, D. (Ed.), and Overell, P., "Augmented BNF for Syntax 2002 Specifications: ABNF", RFC 5234, October 2005. 2004 [RFC6158] DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC 2005 6158, March 2011. 2007 [EDUROAM] Internal Eduroam testing page, data retrieved 04 August 2010. 2009 [ATTR] http://github.com/alandekok/freeradius- 2010 server/tree/master/share/, data retrieved September 2010. 2012 Acknowledgments 2014 This document is the result of long discussions in the IETF RADEXT 2015 working group. The authors would like to thank all of the 2016 participants who contributed various ideas over the years. Their 2017 feedback has been invaluable, and has helped to make this 2018 specification better. 2020 Appendix A - Extended Attribute Generator Program 2022 This section contains "C" program source which can be used for 2023 testing. It reads a line-oriented text file, parses it to create 2024 RADIUS formatted attributes, and prints the hex version of those 2025 attributes to standard output. 2027 The input accepts a grammar similar to that given in Section 8, with 2028 some modifications for usability. For example, blank lines are 2029 allowed, lines beginning with a '#' character are interpreted as 2030 comments, numbers (RADIUS Types, etc.) are checked for minimum / 2031 maximum values, and RADIUS Attribute lengths are enforced. 2033 The program is included here for demonstration purposes only, and 2034 does not define a standard of any kind. 2036 ------------------------------------------------------------ 2037 /* 2038 * Copyright (c) 2010 IETF Trust and the persons identified as 2039 * authors of the code. All rights reserved. 2040 * 2041 * Redistribution and use in source and binary forms, with or without 2042 * modification, are permitted provided that the following conditions 2043 * are met: 2044 * 2045 * Redistributions of source code must retain the above copyright 2046 * notice, this list of conditions and the following disclaimer. 2047 * 2048 * Redistributions in binary form must reproduce the above copyright 2049 * notice, this list of conditions and the following disclaimer in 2050 * the documentation and/or other materials provided with the 2051 * distribution. 2052 * 2053 * Neither the name of Internet Society, IETF or IETF Trust, nor the 2054 * names of specific contributors, may be used to endorse or promote 2055 * products derived from this software without specific prior written 2056 * permission. 2057 * 2058 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 2059 * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, 2060 * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 2061 * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 2062 * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS 2063 * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 2064 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED 2065 * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 2066 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON 2067 * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 2068 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT 2069 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 2070 * SUCH DAMAGE. 2071 * 2072 * Author: Alan DeKok 2073 */ 2074 #include 2075 #include 2076 #include 2077 #include 2078 #include 2079 #include 2081 static int encode_tlv(char *buffer, uint8_t *output, size_t outlen); 2083 static const char *hextab = "0123456789abcdef"; 2085 static int encode_data_string(char *buffer, 2086 uint8_t *output, size_t outlen) 2087 { 2088 int length = 0; 2089 char *p; 2091 p = buffer + 1; 2093 while (*p && (outlen > 0)) { 2094 if (*p == '"') { 2095 return length; 2096 } 2098 if (*p != '\\') { 2099 *(output++) = *(p++); 2100 outlen--; 2101 length++; 2102 continue; 2103 } 2105 switch (p[1]) { 2106 default: 2107 *(output++) = p[1]; 2108 break; 2110 case 'n': 2111 *(output++) = '\n'; 2112 break; 2114 case 'r': 2115 *(output++) = '\r'; 2116 break; 2118 case 't': 2119 *(output++) = '\t'; 2120 break; 2121 } 2123 outlen--; 2124 length++; 2125 } 2127 fprintf(stderr, "String is not terminated\n"); 2128 return 0; 2129 } 2131 static int encode_data_tlv(char *buffer, char **endptr, 2132 uint8_t *output, size_t outlen) 2133 { 2134 int depth = 0; 2135 int length; 2136 char *p; 2138 for (p = buffer; *p != '\0'; p++) { 2139 if (*p == '{') depth++; 2140 if (*p == '}') { 2141 depth--; 2142 if (depth == 0) break; 2143 } 2144 } 2146 if (*p != '}') { 2147 fprintf(stderr, "No trailing '}' in string starting " 2148 "with \"%s\"\n", 2149 buffer); 2150 return 0; 2151 } 2153 *endptr = p + 1; 2154 *p = '\0'; 2156 p = buffer + 1; 2157 while (isspace((int) *p)) p++; 2159 length = encode_tlv(p, output, outlen); 2160 if (length == 0) return 0; 2162 return length; 2163 } 2164 static int encode_data(char *p, uint8_t *output, size_t outlen) 2165 { 2166 int length; 2168 if (!isspace((int) *p)) { 2169 fprintf(stderr, "Invalid character following attribute " 2170 "definition\n"); 2171 return 0; 2172 } 2174 while (isspace((int) *p)) p++; 2176 if (*p == '{') { 2177 int sublen; 2178 char *q; 2180 length = 0; 2182 do { 2183 while (isspace((int) *p)) p++; 2184 if (!*p) { 2185 if (length == 0) { 2186 fprintf(stderr, "No data\n"); 2187 return 0; 2188 } 2190 break; 2191 } 2193 sublen = encode_data_tlv(p, &q, output, outlen); 2194 if (sublen == 0) return 0; 2196 length += sublen; 2197 output += sublen; 2198 outlen -= sublen; 2199 p = q; 2200 } while (*q); 2202 return length; 2203 } 2205 if (*p == '"') { 2206 length = encode_data_string(p, output, outlen); 2207 return length; 2208 } 2210 length = 0; 2211 while (*p) { 2212 char *c1, *c2; 2214 while (isspace((int) *p)) p++; 2216 if (!*p) break; 2218 if(!(c1 = memchr(hextab, tolower((int) p[0]), 16)) || 2219 !(c2 = memchr(hextab, tolower((int) p[1]), 16))) { 2220 fprintf(stderr, "Invalid data starting at " 2221 "\"%s\"\n", p); 2222 return 0; 2223 } 2225 *output = ((c1 - hextab) << 4) + (c2 - hextab); 2226 output++; 2227 length++; 2228 p += 2; 2230 outlen--; 2231 if (outlen == 0) { 2232 fprintf(stderr, "Too much data\n"); 2233 return 0; 2234 } 2235 } 2237 if (length == 0) { 2238 fprintf(stderr, "Empty string\n"); 2239 return 0; 2240 } 2242 return length; 2243 } 2245 static int decode_attr(char *buffer, char **endptr) 2246 { 2247 long attr; 2249 attr = strtol(buffer, endptr, 10); 2250 if (*endptr == buffer) { 2251 fprintf(stderr, "No valid number found in string " 2252 "starting with \"%s\"\n", buffer); 2253 return 0; 2254 } 2256 if (!**endptr) { 2257 fprintf(stderr, "Nothing follows attribute number\n"); 2258 return 0; 2259 } 2260 if ((attr <= 0) || (attr > 256)) { 2261 fprintf(stderr, "Attribute number is out of valid " 2262 "range\n"); 2263 return 0; 2264 } 2266 return (int) attr; 2267 } 2269 static int decode_vendor(char *buffer, char **endptr) 2270 { 2271 long vendor; 2273 if (*buffer != '.') { 2274 fprintf(stderr, "Invalid separator before vendor id\n"); 2275 return 0; 2276 } 2278 vendor = strtol(buffer + 1, endptr, 10); 2279 if (*endptr == (buffer + 1)) { 2280 fprintf(stderr, "No valid vendor number found\n"); 2281 return 0; 2282 } 2284 if (!**endptr) { 2285 fprintf(stderr, "Nothing follows vendor number\n"); 2286 return 0; 2287 } 2289 if ((vendor <= 0) || (vendor > (1 << 24))) { 2290 fprintf(stderr, "Vendor number is out of valid range\n"); 2291 return 0; 2292 } 2294 if (**endptr != '.') { 2295 fprintf(stderr, "Invalid data following vendor number\n"); 2296 return 0; 2297 } 2298 (*endptr)++; 2300 return (int) vendor; 2301 } 2303 static int encode_tlv(char *buffer, uint8_t *output, size_t outlen) 2304 { 2305 int attr; 2306 int length; 2307 char *p; 2308 attr = decode_attr(buffer, &p); 2309 if (attr == 0) return 0; 2311 output[0] = attr; 2312 output[1] = 2; 2314 if (*p == '.') { 2315 p++; 2316 length = encode_tlv(p, output + 2, outlen - 2); 2318 } else { 2319 length = encode_data(p, output + 2, outlen - 2); 2320 } 2322 if (length == 0) return 0; 2323 if (length > (255 - 2)) { 2324 fprintf(stderr, "TLV data is too long\n"); 2325 return 0; 2326 } 2328 output[1] += length; 2330 return length + 2; 2331 } 2333 static int encode_vsa(char *buffer, uint8_t *output, size_t outlen) 2334 { 2335 int vendor; 2336 int attr; 2337 int length; 2338 char *p; 2340 vendor = decode_vendor(buffer, &p); 2341 if (vendor == 0) return 0; 2343 output[0] = 0; 2344 output[1] = (vendor >> 16) & 0xff; 2345 output[2] = (vendor >> 8) & 0xff; 2346 output[3] = vendor & 0xff; 2348 length = encode_tlv(p, output + 4, outlen - 4); 2349 if (length == 0) return 0; 2350 if (length > (255 - 6)) { 2351 fprintf(stderr, "VSA data is too long\n"); 2352 return 0; 2353 } 2354 return length + 4; 2355 } 2357 static int encode_evs(char *buffer, uint8_t *output, size_t outlen) 2358 { 2359 int vendor; 2360 int attr; 2361 int length; 2362 char *p; 2364 vendor = decode_vendor(buffer, &p); 2365 if (vendor == 0) return 0; 2367 attr = decode_attr(p, &p); 2368 if (attr == 0) return 0; 2370 output[0] = 0; 2371 output[1] = (vendor >> 16) & 0xff; 2372 output[2] = (vendor >> 8) & 0xff; 2373 output[3] = vendor & 0xff; 2374 output[4] = attr; 2376 length = encode_data(p, output + 5, outlen - 5); 2377 if (length == 0) return 0; 2379 return length + 5; 2380 } 2382 static int encode_extended(char *buffer, 2383 uint8_t *output, size_t outlen) 2384 { 2385 int attr; 2386 int length; 2387 char *p; 2389 attr = decode_attr(buffer, &p); 2390 if (attr == 0) return 0; 2392 output[0] = attr; 2394 if (attr == 26) { 2395 length = encode_evs(p, output + 1, outlen - 1); 2396 } else { 2397 length = encode_data(p, output + 1, outlen - 1); 2398 } 2399 if (length == 0) return 0; 2400 if (length > (255 - 3)) { 2401 fprintf(stderr, "Extended Attr data is too long\n"); 2402 return 0; 2403 } 2405 return length + 1; 2406 } 2408 static int encode_extended_flags(char *buffer, 2409 uint8_t *output, size_t outlen) 2410 { 2411 int attr; 2412 int length, total; 2413 char *p; 2415 attr = decode_attr(buffer, &p); 2416 if (attr == 0) return 0; 2418 /* output[0] is the extended attribute */ 2419 output[1] = 4; 2420 output[2] = attr; 2421 output[3] = 0; 2423 if (attr == 26) { 2424 length = encode_evs(p, output + 4, outlen - 4); 2425 if (length == 0) return 0; 2427 output[1] += 5; 2428 length -= 5; 2429 } else { 2430 length = encode_data(p, output + 4, outlen - 4); 2431 } 2432 if (length == 0) return 0; 2434 total = 0; 2435 while (1) { 2436 int sublen = 255 - output[1]; 2438 if (length <= sublen) { 2439 output[1] += length; 2440 total += output[1]; 2441 break; 2442 } 2444 length -= sublen; 2446 memmove(output + 255 + 4, output + 255, length); 2447 memcpy(output + 255, output, 4); 2449 output[1] = 255; 2450 output[3] |= 0x80; 2452 output += 255; 2453 output[1] = 4; 2454 total += 255; 2455 } 2457 return total; 2458 } 2460 static int encode_rfc(char *buffer, uint8_t *output, size_t outlen) 2461 { 2462 int attr; 2463 int length, sublen; 2464 char *p; 2466 attr = decode_attr(buffer, &p); 2467 if (attr == 0) return 0; 2469 length = 2; 2470 output[0] = attr; 2471 output[1] = 2; 2473 if (attr == 26) { 2474 sublen = encode_vsa(p, output + 2, outlen - 2); 2476 } else if ((*p == ' ') || ((attr < 241) || (attr > 246))) { 2477 sublen = encode_data(p, output + 2, outlen - 2); 2479 } else { 2480 if (*p != '.') { 2481 fprintf(stderr, "Invalid data following " 2482 "attribute number\n"); 2483 return 0; 2484 } 2486 if (attr < 245) { 2487 sublen = encode_extended(p + 1, 2488 output + 2, outlen - 2); 2489 } else { 2491 /* 2492 * Not like the others! 2493 */ 2494 return encode_extended_flags(p + 1, output, outlen); 2495 } 2496 } 2497 if (sublen == 0) return 0; 2498 if (sublen > (255 -2)) { 2499 fprintf(stderr, "RFC Data is too long\n"); 2500 return 0; 2501 } 2503 output[1] += sublen; 2504 return length + sublen; 2505 } 2507 int main(int argc, char *argv[]) 2508 { 2509 int lineno; 2510 size_t i, outlen; 2511 FILE *fp; 2512 char input[8192], buffer[8192]; 2513 uint8_t output[4096]; 2515 if ((argc < 2) || (strcmp(argv[1], "-") == 0)) { 2516 fp = stdin; 2517 } else { 2518 fp = fopen(argv[1], "r"); 2519 if (!fp) { 2520 fprintf(stderr, "Error opening %s: %s\n", 2521 argv[1], strerror(errno)); 2522 exit(1); 2523 } 2524 } 2526 lineno = 0; 2527 while (fgets(buffer, sizeof(buffer), fp) != NULL) { 2528 char *p = strchr(buffer, '\n'); 2530 lineno++; 2532 if (!p) { 2533 if (!feof(fp)) { 2534 fprintf(stderr, "Line %d too long in %s\n", 2535 lineno, argv[1]); 2536 exit(1); 2537 } 2538 } else { 2539 *p = '\0'; 2540 } 2542 p = strchr(buffer, '#'); 2543 if (p) *p = '\0'; 2545 p = buffer; 2546 while (isspace((int) *p)) p++; 2547 if (!*p) continue; 2549 strcpy(input, p); 2550 outlen = encode_rfc(input, output, sizeof(output)); 2551 if (outlen == 0) { 2552 fprintf(stderr, "Parse error in line %d of %s\n", 2553 lineno, input); 2554 exit(1); 2555 } 2557 printf("%s -> ", buffer); 2558 for (i = 0; i < outlen; i++) { 2559 printf("%02x ", output[i]); 2560 } 2561 printf("\n"); 2562 } 2564 if (fp != stdin) fclose(fp); 2566 return 0; 2567 } 2568 ------------------------------------------------------------ 2570 Author's Address 2572 Alan DeKok 2573 Network RADIUS SARL 2574 15 av du Granier 2575 38240 Meylan 2576 France 2578 Email: aland@networkradius.com 2579 URI: http://networkradius.com 2581 Avi Lior 2582 Bridgewater Systems Corporation 2583 303 Terry Fox Drive 2584 Suite 100 2585 Ottawa, Ontario K2K 3J1 2586 Canada 2588 Phone: +1 (613) 591-6655 2589 Email: avi@bridgewatersystems.com 2590 URI: http://www.bridgewatersystems.com/