idnits 2.17.1 draft-ietf-radext-radius-extensions-01.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 (6 June 2011) is 4707 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 2578 -- Looks like a reference, but probably isn't: '0' on line 2513 -- Looks like a reference, but probably isn't: '2' on line 2463 -- Looks like a reference, but probably isn't: '3' on line 2493 -- Looks like a reference, but probably isn't: '4' on line 2417 -- Looks like a reference, but probably isn't: '8192' on line 2555 -- Looks like a reference, but probably isn't: '4096' on line 2556 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 6 June 2011 10 Remote Authentication Dial In User Service (RADIUS) Protocol 11 Extensions 12 draft-ietf-radext-radius-extensions-01.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 November 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 ............................................... 33 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 ..................................... 36 103 8. Examples ................................................. 37 104 8.1. Extended Type ....................................... 38 105 8.2. Extended Type with Flags ............................ 39 106 9. IANA Considerations ...................................... 42 107 9.1. Attribute Allocations ............................... 42 108 9.2. RADIUS Attribute Type Tree .......................... 42 109 9.3. Assignment Policy ................................... 43 110 9.4. Extending the Attribute Type Tree ................... 44 111 9.5. Extending the RADIUS Attribute Type Space ........... 44 112 10. Security Considerations ................................. 45 113 11. References .............................................. 45 114 11.1. Normative references ............................... 45 115 11.2. Informative references ............................. 46 116 Appendix A - Extended Attribute Generator Program ............ 47 117 1. Introduction 119 Under current allocation pressure, we expect that the RADIUS 120 Attribute Type space will be exhausted by 2014 or 2015. We therefore 121 need a way to extend the type space, so that new specifications may 122 continue to be developed. Other issues have also been shown with 123 RADIUS. The attribute grouping method defined in [RFC2868] has been 124 shown to be imnpractical, and a more powerful mechanism is needed. 125 Multiple attributes have been defined which transport more than the 126 253 octets of data originally envisioned with the protocol. Each of 127 these attributes is handled as a "special case" inside of RADIUS 128 implementations, instead of as a general method. We therefore also 129 need a standardized method of transporting large quantities of data. 130 Finally, some vendors are close to allocating all of the Attributes 131 within their Vendor-Specific Attribute space. It would be useful to 132 leverage changes to the base protocol for extending the Vendor- 133 Specific Attribute space. 135 We satisfy all of these requirements through the following 136 modifications to RADIUS: 138 * defining an "Extended Type" format, which adds 8 bits of "Extended 139 Type" to the RADIUS Attribute Type space, by using one octet of the 140 "Value" field. This method gives us a general way of extending 141 the Attribute Type Space. 143 * allocating 4 attributes as using the format of "Extended Type". 144 This allocation extends the RADIUS Attribute Type Space by 145 approximately 1000 values. 147 * defining an "Extended Type with Flags" format, which inserts 148 an additional "Flags" octet between the "Extended Type" octet, 149 and the "Value" field. This method gives us a general way of 150 adding additional functionality to the protocol. 152 * defining method which uses the "Flags" field to indicate data 153 fragmentation across multiple Attributes. This method provides a 154 standard way for an Attribute to carry more than 253 octets of 155 data. 157 * allocating 2 attributes as using the format of "Extended Type with 158 Flags". This allocation extends the RADIUS Attribute Type Space 159 by an additional 500 values. 161 * defining a new "Type Length Value" (TLV) data type. The data type 162 allows an attribute to carry TLVs as "sub-attributes", which can in 163 turn encapsulate other TLVs as "sub-sub-attributes." This change 164 creates a standard way to group a set of Attributes. 166 * defining a new "extended Vendor-Specific" (EVS) data type. The 167 data type allows an attribute to carry Vendor-Specific Attributes 168 (VSAs) inside of the new attribute formats. 170 * defining a new "integer64" data type. The data type allows 171 counters which track more than 2^32 octets of data. 173 * allocating 6 attributes using the new EVS data type. This 174 allocation extends the Vendor-Specific Attribute type space by 175 over 1500 values. 177 As with any protocol change, the changes defined here are the result 178 of a series of compromises. We have tried to find a balance between 179 flexibility, space in the RADIUS message, compatibility with existing 180 deployments, and implementation difficulty. 182 1.1. Terminology 184 This document uses the following terms: 186 silently discard 187 This means the implementation discards the packet without further 188 processing. The implementation MAY provide the capability of 189 logging the error, including the contents of the silently discarded 190 packet, and SHOULD record the event in a statistics counter. 192 invalid attribute 193 This means that the Length field of an Attribute is valid (as per 194 [RFC2865], Section 5, top of page 25). However, the Value field of 195 the attribute does not follow the format required by the data type 196 defined for that Attribute. e.g. an Attribute of type "address" 197 which encapsulates more than four, or less than four, octets of 198 data. 200 1.2. Requirements Language 202 In this document, several words are used to signify the requirements 203 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 204 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 205 and "OPTIONAL" in this document are to be interpreted as described in 206 [RFC2119]. 208 An implementation is not compliant if it fails to satisfy one or more 209 of the must or must not requirements for the protocols it implements. 210 An implementation that satisfies all the MUST, MUST NOT, SHOULD, and 211 SHOULD NOT requirements for its protocols is said to be 212 "unconditionally compliant"; one that satisfies all the MUST and MUST 213 NOT requirements but not all the SHOULD or SHOULD NOT requirements 214 for its protocols is said to be "conditionally compliant". 216 2. Extensions to RADIUS 218 This section defines two new attribute formats; "Extended Type"; and 219 "Extended Type with Flags". The formats are defined below. 221 2.1. Extended Type 223 This section defines a new attribute format, called "Extended Type". 224 A summary of the Attribute format is shown below. The fields are 225 transmitted from left to right. 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Type | Length | Extended-Type | Value ... 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Type 235 This field is identical to the Type field of the Attribute format 236 defined in [RFC2865] Section 5. 238 Length 240 This field is identical to the Length field of the Attribute 241 format defined in [RFC2865] Section 5. Permitted values are 242 between 4 and 255. If a client or server receives an Extended 243 Attribute with a Length of 2 or 3, then that Attribute MUST be 244 deemed to be an "invalid attribute", it SHOULD be silently 245 discarded. If it is not discarded, it MUST NOT be handled in the 246 same manner as a well-formed attribute. 248 Note that an "invalid attribute" does not cause the entire packet 249 to be discarded, or to be treated as a negative acknowledgement. 250 Instead, only the "invalid attribute" is discarded. 252 Extended-Type 254 The Extended-Type field is one octet. Up-to-date values of this 255 field are specified by IANA. Unlike the Type field defined in 256 [RFC2865] Section 5, no values are allocated for experimental or 257 implementation-specific use. Values 241-255 are reserved and 258 SHOULD NOT be used. 260 The Extended-Type is meaningful only within a context defined by 261 the Type field. That is, this field may be thought of as defining 262 a new type space of the form "Type.Extended-Type". See Section 263 2.5, below, for additional discussion. 265 A RADIUS server MAY ignore Attributes with an unknown 266 "Type.Extended-Type". 268 A RADIUS client MAY ignore Attributes with an unknown 269 "Type.Extended-Type". 271 Value 273 This field is similar to the Value field of the Attribute format 274 defined in [RFC2865] Section 5. The format of the data SHOULD be 275 a valid RADIUS data type. 277 The addition of the Extended-Type field decreases the maximum 278 length for attributes of type "text" or "string" from 253 to 252 279 octets. Where an Attribute needs to carry more than 252 octets of 280 data, the "Extended Type with flags" format should be used. 282 Experience has shown that the "experimental" and "implementation 283 specific" attributes defined in [RFC2865] Section 5 have had little 284 practical value. We therefore do not continue that practice here 285 with the Extended-Type field. 287 2.2. Extended Type with Flags 289 This section defines a new attribute format, called "Extended Type 290 with Flags". It leverages the "Extended Type" format in order to 291 permit the transport of attributes encapsulating more than 253 octets 292 of data. A summary of the Attribute format is shown below. The 293 fields are transmitted from left to right. 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Type | Length | Extended-Type |M| Flags | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Value ... 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Type 305 This field is identical to the Type field of the Attribute format 306 defined in [RFC2865] Section 5. 308 Length 310 This field is identical to the Length field of the Attribute 311 format defined in [RFC2865] Section 5. Permitted values are 312 between 5 and 255. If a client or server receives an "Extended 313 Attribute with Flags" with a Length of 2, 3, or 4, then that 314 Attribute MUST be deemed to be an "invalid attribute", it SHOULD 315 be silently discarded. If it is not discarded, it MUST NOT be 316 handled in the same manner as a well-formed attribute. 318 Note that an "invalid attribute" does not cause the entire packet 319 to be discarded, or to be treated as a negative acknowledgement. 320 Instead, only the "invalid attribute" is discarded. 322 Extended-Type 324 This field is identical to the Extended-Type field defined above 325 in Section 2.1. 327 M (More) 329 The More Flag is one (1) bit in length, and indicates whether or 330 not the current attribute contains "more" than 251 octets of data. 331 The More flag MUST be clear (0) if the Length field has value less 332 than 255. The More flag MAY be set (1) if the Length field has 333 value of 255. 335 If the More flag is set (1), it indicates that the Value field has 336 been fragmented across multiple RADIUS attributes. When the More 337 flag is set (1), the attribute SHOULD have a Length field of value 338 255; it MUST NOT have a length Field of of value 4; there MUST be 339 an attribute following this one; and the next attribute MUST have 340 both the same Type and Extended Type. That is, multiple fragments 341 of the same value MUST be in order and MUST be consecutive 342 attributes in the packet, and the last attribute in a packet MUST 343 NOT have the More flag set (1). 345 When the Length field of an attribute has value less than 255, the 346 More flag SHOULD be clear (0). 348 If a client or server receives an attribute fragment with the 349 "More" flag set (1), but for which no subsequent fragment can be 350 found, then the fragmented attribute is deemed to be an "invalid 351 attribute" and the entire set of fragments SHOULD be silently 352 discarded. If the fragmented attribute is not discarded, it MUST 353 NOT be handled in the same manner as a well-formed attribute. 355 Flags 357 This field is 7 bits long, and is reserved for future use. 358 Implementations MUST set it to zero (0) when encoding an attribute 359 for sending in a packet. The contents SHOULD be ignored on 360 reception. 362 Value 364 This field is similar to the Value field of the Attribute format 365 defined in [RFC2865] Section 5. It may contain a complete set of 366 data (when the Length field has value less than 255), or it may 367 contain a fragment of data (when the More field is set). 369 Any interpretation of the resulting data MUST occur after the 370 fragments have been reassembled. The length of the data MUST be 371 taken as the sum of the lengths of the fragments (i.e. Value 372 fields) from which it is constructed. The format of the data 373 SHOULD be a valid RADIUS data type. 375 This definition increases the RADIUS Attribute Type space as above, 376 but also provides for transport of Attributes which could contain 377 more than 253 octets of data. 379 2.3. TLV Data Type 381 We define a new data type in RADIUS, called "tlv". The "tlv" data 382 type is an encapsulation layer which which permits the "Value" field 383 of an Attribute to contain new sub-Attributes. These sub-Attributes 384 can in turn contain "Value"s of data type TLV. This capability both 385 extends the attribute space, and permits "nested" attributes to be 386 used. This nesting can be used to encapsulate or group data into one 387 or more logical containers. 389 The "tlv" data type re-uses the RADIUS attribute format, as given 390 below: 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | TLV-Type | TLV-Length | TLV-Value ... 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 TLV-Type 400 The Type field is one octet. Up-to-date values of this field are 401 specified by IANA. Values of zero (0) MUST NOT be used. Values 402 254-255 are "Reserved" for use by future extensions to RADIUS. 403 The value 26 has no special meaning. 405 As with Extended-Type above, the TLV-Type is meaningful only 406 within a context defined by "Type" fields of the encapsulating 407 Attributes. That is, the field may be thought of as defining a 408 new type space of the form "Type.Extended-Type.TLV-Type". Where 409 TLVs are nested, the type space is of the form "Type.Extended- 410 Type.TLV-Type.TLV-Type", etc. 412 A RADIUS server MAY ignore Attributes with an unknown "TLV-Type". 414 A RADIUS client MAY ignore Attributes with an unknown "TLV-Type". 416 TLV-Length 418 The TLV-Length field is one octet, and indicates the length of 419 this TLV including the TLV-Type, TLV-Length and TLV-Value fields. 420 It MUST have a value between 3 and 255. If a client or server 421 receives a TLV with an invalid TLV-Length, then the attribute 422 which encapsulates that TLV MUST be deemed to be an "invalid 423 attribute", it SHOULD be silently discarded. If the encapsulating 424 attribute is not discarded, it MUST NOT be handled in the same 425 manner as a well-formed attribute. 427 Note that an "invalid attribute" does not cause the entire packet 428 to be discarded, or to be treated as a negative acknowledgement. 429 Instead, only the "invalid attribute" is discarded. 431 TLV-Value 433 The Value field is one or more octets and contains information 434 specific to the Attribute. The format and length of the TLV-Value 435 field is determined by the TLV-Type and TLV-Length fields. 437 The TLV-Value field SHOULD encapsulate a previously defined RADIUS 438 data type. Using non-standard data types is NOT RECOMMENDED. We 439 note that the TLV-Value field MAY also contain one or more 440 attributes of data type "tlv", which allows for simple grouping 441 and multiple layers of nesting. 443 The TLV-Value field is limited to containing 253 or fewer octets 444 of data. Specifications which require a TLV to contain more than 445 253 octets of data are incompatible with RADIUS, and need to be 446 redesigned. Specifications which require the transport of empty 447 Values (i.e. Length = 2) are incomaptible with RADIUS, and need to 448 be redesigned. 450 The TLV-Value field MUST NOT contain data using the "Extended 451 Type" formats defined in this document. The base Extended 452 Attributes format allows for sufficient flexibility that nesting 453 them inside of a TLV offers little additional value. 455 This TLV definition is compatible with the suggested format of the 456 "String" field of the Vendor-Specific attribute, as defined in 457 [RFC2865] Section 5.26, though that specification does not discuss 458 nesting. 460 Vendors MAY use attributes of type "tlv" in any Vendor Specific 461 Attribute. We RECOMMEND using type "tlv" for VSAs, in preference to 462 any other format. 464 2.3.1. TLV Nesting 466 TLVs may contain other TLVs. When this occurs, the "container" TLV 467 MUST be completely filled by the "contained" TLVs. That is, the 468 "container" TLV-Length field MUST be exactly two (2) more than the 469 sum of the "contained" TLV-Length fields. If the "contained" TLVs 470 over-fill the "container" TLV, the "container" TLV MUST be considered 471 to be an "invalid attribute", and handled as described above. 473 The depth of TLV nesting is limited only by the restrictions on the 474 TLV-Length field. The limit of 253 octets of data results in a limit 475 of 126 levels of nesting. However, nesting depths of more than 4 are 476 NOT RECOMMENDED. 478 2.4. EVS Data Type 480 We define a new data type in RADIUS, called "evs", for "Extended 481 Vendor-Specific". The "evs" data type is an encapsulation layer 482 which which permits the "Value" field of an Attribute to contain a 483 Vendor-Id, followed by a Vendor-Type, and then vendor-defined data. 484 This data can in turn contain valid RADIUS data types, or any other 485 data as determined by the vendor. 487 This data type is intended use in attributes which carry Vendor- 488 Specific information, as is done with the Vendor-Specific Attribute 489 (26). It is RECOMMENDED that this data type be used by a vendor only 490 when the Vendor-Specific Attribute Type space has been fully 491 allocated. 493 Where [RFC2865] Section 5.26 makes a recommendation for the format of 494 the data following the Vendor-Id, we give a strict definition. 495 Experience has shown that many vendors have not followed the 496 [RFC2865] recommendations, leading to interoperability issues. We 497 hope here to give vendors sufficient flexibility as to meet their 498 needs, while minimizing the use of non-standard VSA formats. 500 The "evs" data type MAY be used in Attributes having the format of 501 "Extended Type" or "Extended Type with Flags". It MUST NOT be used 502 in any other Attribute definition, including standard RADIUS 503 Attributes, TLVs, and VSAs. 505 A summary of the "evs" data type format is shown below. The fields 506 are transmitted from left to right. 508 0 1 2 3 509 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 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Vendor-Id | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Vendor-Type | String .... 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Vendor-Id 518 The high-order octet is 0 and the low-order 3 octets are the SMI 519 Network Management Private Enterprise Code of the Vendor in 520 network byte order. 522 Vendor-Type 524 The Vendor-Type field is one octet. Values are assigned at the 525 sole discretion of the Vendor. 527 String 529 The String field is one or more octets. It SHOULD encapsulate a 530 previously defined RADIUS data type. Using non-standard data 531 types is NOT RECOMMENDED. We note that the String field may be of 532 data type "tlv". However, it MUST NOT be of data type "evs", as 533 the use cases are unclear for one vendor delegating attribute type 534 space to another vendor. 536 The actual format of the information is site or application 537 specific, and a robust implementation SHOULD support the field as 538 undistinguished octets. We recognise that Vendors have complete 539 control over the contents and format of the String field, while at 540 the same time recommending that good practices be followed. 542 Further codification of the range of allowed usage of this field 543 is outside the scope of this specification. 545 Note that unlike the format described in [RFC2865] Section 5.26, this 546 data type has no "Vendor length" field. The length of the "String" 547 field is implicit, and is determined by taking the "Length" of the 548 encapsulating RADIUS Attribute, and subtracting the length of the 549 attribute header including the 4 octets of Vendor-Id. i.e. For 550 "Extended Type" attributes, the length of the String field is seven 551 (7) less than the value of the Length field. For "Extended Type with 552 Flags" attributes, the length of the String field is eight (8) less 553 than the value of the Length field. 555 2.5. Integer64 Data Type 557 We define a new data type in RADIUS, called "integer64", which 558 carries a 64-bit unsigned integer in network byte order. 560 This data type is intended to be used in any situation where there is 561 a need to have counters which can count past 2^32. The expected use 562 og this data type is within Accounting-Request packets, but this data 563 type SHOULD be used in any packet where 32-bit integers are expected 564 to be insufficient. 566 The "integer64" data type MAY be used in Attributes of any format, 567 standard space, extended attributes, TLVs, and VSAs. 569 A summary of the "integer64" data type format is shown below. The 570 fields are transmitted from left to right. 572 0 1 2 3 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Value ... 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 Attributes having data type "integer64" MUST have the relevant Length 581 field set to eight more than the length of the Attribute header. For 582 standard space Attributes and TLVs, this means that the Length field 583 MUST be set to ten (10). For "Extended Type" Attributes, the Length 584 field MUST be set to eleven (11). For "Extended Type with Flags" 585 Attributes, the Length field MUST be set to twelve (12). 587 2.6. Attribute Naming and Type Identifiers 589 Attributes have traditionally been identified by a unique name and 590 number. For example, the attribute named "User-Name" has been 591 allocated number one (1). This scheme needs to be extended in order 592 to be able to refer to attributes of Extended Type, and to TLVs. It 593 will also be used by IANA for allocating RADIUS Attribute Type 594 values. 596 The names and identifiers given here are intended to be used only in 597 specifications. The system presented here may not be useful when 598 referring to the contents of a RADIUS packet. It imposes no 599 requirements on implementations, as implementations are free to 600 reference RADIUS Attributes via any method they choose. 602 2.6.1. Attribute and TLV Naming 604 RADIUS specifications traditionally use names consisting of one or 605 more words, separated by hyphens, e.g. "User-Name". However, these 606 names are not allocated from a registry, and there is no restriction 607 other than convention on their global uniqueness. 609 Similarly, vendors have often used their company name as the prefix 610 for VSA names, though this practice is not universal. For example, 611 for a vendor named "Example", the name "Example-Attribute-Name" 612 SHOULD be used instead of "Attribute-Name". The second form can 613 conflict with attributes from other vendors, whereas the first form 614 cannot. 616 We therefore RECOMMEND that specifications give names to Attributes 617 which attempt to be globally unique across all RADIUS Attributes. We 618 RECOMMEND that vendors use their name as a unique prefix for 619 attribute names. We recognise that these suggestion may sometimes be 620 difficult to implement in practice. 622 TLVs SHOULD be named with a unique prefix that is shared among 623 related attributes. For example, a specification that defines a set 624 of TLVs related to time could create attributes named "Time-Zone", 625 "Time-Day", "Time-Hour", "Time-Minute", etc. 627 2.6.2. Attribute Type Identifiers 629 The RADIUS Attribute Type space defines a context for a particular 630 "Extended-Type" field. The "Extended-Type" field allows for 256 631 possible type code values, with values 1 through 240 available for 632 allocation. We define here an identification method that uses a 633 "dotted number" notation similar to that used for Object Identifiers 634 (OIDs), formatted as "Type.Extended-Type". 636 For example, and attribute within the Type space of 241, having 637 Extended-Type of one (1), is uniquely identified as "241.1". 638 Similarly, an attribute within the Type space of 246, having 639 Extended-Type of ten (10), is uniquely identified as "246.10". 641 The algorithm used to create the Attribute Identifier is simply to 642 concatenate all of the various identification fields (e.g. Type, 643 Extended-Type, etc.), starting from the encapsulating attribute, down 644 to the final encapsulated TLV, separated by a '.' character. 646 2.6.3. TLV Identifiers 648 We can extend the Attribute reference scheme defined above for TLVs. 649 This is done by leveraging the "dotted number" notation. As above, 650 we define an additional TLV type space, within the "Extended Type" 651 space, by appending another "dotted number" in order to identify the 652 TLV. This method can be replied in sequence for nested TLVs. 654 For example, let us say that "245.1" identifies RADIUS Attribute Type 655 245, containing an "Extended Type" of one (1), which is of type 656 "tlv". That attribute will contain 256 possible TLVs, one for each 657 value of the TLV-Type field. The first TLV-Type value of one (1) can 658 then be identified by appending a ".1" to the number of the 659 encapsulating attribute ("241.1"), to yield "241.1.1". Similarly, 660 the sequence "245.2.3.4" identifies RADIUS attribute 245, containing 661 an "Extended Type" of two (2) which is of type "tlv", which in turn 662 contains a TLV with TLV-Type number three (3), which in turn contains 663 another TLV, wth TLV-Type number four (4). 665 2.6.4. VSA Identifiers 667 There has historically been no method for numerically addressing 668 VSAs. The "dotted number" method defined here can also be leveraged 669 to create such an addressing scheme. However, as the VSAs are 670 completely under the control of each individual vendor, this section 671 provides a suggested practice, but does not define a standard of any 672 kind. 674 The Vendor-Specific Attribute has been assigned the Attribute number 675 26. It in turn carries a 24-bit Vendor-Id, and possibly additional 676 VSAs. Where the VSAs follow the [RFC2865] Section 5.26 recommended 677 format, a VSA can be identified as "26.Vendor-Id"."Vendor-Type". 679 For example, Livingston has Vendor-Id 307, and has defined an 680 attribute "IP-Pool" as number 6. This VSA can be uniquely identified 681 as 26.307.6. 683 Note that there is no restriction on the size of the numerical values 684 in this notation. The Vendor-Id is a 24-bit number, and the VSA may 685 have been assigned from a 16-bit vendor-specific Attribute type 686 space. 688 For example, the company USR has been allocated Vendor-Id 429, and 689 has defined a "Version-Id" attribute as number 32768. This VSA can 690 be uniquely identified as 26.429.32768. 692 Where a VSA is a TLV, the "dotted number" notation can be used as 693 above: 26.VID.VSA.TLV1.TLV2.TLV3 where "TLVn" are the numerical 694 values assigned by the vendor to the different nested TLVs. 696 3. Attribute Definitions 698 We define four (4) attributes of "Extended Type", which are allocated 699 from the "Reserved" Attribute Type codes of 241, 242, 243, and 244. 700 We also define two (2) attributes of "Extended Type with Flags", 701 which are allocated from the "Reserved" Attribute Type codes of 245 702 and 246. 704 Type Name 705 ---- ---- 706 241 Extended-Type-1 707 242 Extended-Type-2 708 243 Extended-Type-3 709 244 Extended-Type-4 710 245 Extended-Type-Flagged-1 711 246 Extended-Type-Flagged-2 713 The rest of this section gives a detailed definition for each 714 Attribute based on the above summary. 716 3.1. Extended-Type-1 718 Description 720 This attribute encapsulates attributes of the "Extended Type" 721 format, in the RADIUS Attribute Type Space of 241.{1-255}. 723 A summary of the Extended-Type-1 Attribute format is shown below. 724 The fields are transmitted from left to right. 726 0 1 2 3 727 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 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Type | Length | Extended-Type | Value ... 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 Type 734 241 for Extended-Type-1. 736 Length 738 >= 4 740 Extended-Type 742 The Extended-Type field is one octet. Up-to-date values of this 743 field are specified by IANA, in the 241.{1-255} RADIUS Attribute 744 Type Space. Further definition of this field is given in Section 745 2.1, above. 747 String 749 The String field is one or more octets. Implementations not 750 supporting this specification SHOULD support the field as 751 undistinguished octets. 753 Implementations supporting this specification MUST use the 754 Identifier of "Type.Extended-Type" to determine the interpretation 755 of the String field. 757 3.2. Extended-Type-2 759 Description 761 This attribute encapsulates attributes of the "Extended Type" 762 format, in the RADIUS Attribute Type Space of 242.{1-255}. 764 A summary of the Extended-Type-2 Attribute format is shown below. 765 The fields are transmitted from left to right. 767 0 1 2 3 768 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 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Type | Length | Extended-Type | Value ... 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 Type 775 242 for Extended-Type-2. 777 Length 779 >= 4 781 Extended-Type 783 The Extended-Type field is one octet. Up-to-date values of this 784 field are specified by IANA, in the 242.{1-255} RADIUS Attribute 785 Type Space. Further definition of this field is given in Section 786 2.1, above. 788 String 790 The String field is one or more octets. Implementations not 791 supporting this specification SHOULD support the field as 792 undistinguished octets. 794 Implementations supporting this specification MUST use the 795 Identifier of "Type.Extended-Type" to determine the interpretation 796 of the String field 798 3.3. Extended-Type-3 800 Description 802 This attribute encapsulates attributes of the "Extended Type" 803 format, in the RADIUS Attribute Type Space of 243.{1-255}. 805 A summary of the Extended-Type-3 Attribute format is shown below. 806 The fields are transmitted from left to right. 808 0 1 2 3 809 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 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Type | Length | Extended-Type | Value ... 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 Type 816 243 for Extended-Type-3. 818 Length 820 >= 4 822 Extended-Type 824 The Extended-Type field is one octet. Up-to-date values of this 825 field are specified by IANA, in the 243.{1-255} RADIUS Attribute 826 Type Space. Further definition of this field is given in Section 827 2.1, above. 829 String 831 The String field is one or more octets. Implementations not 832 supporting this specification SHOULD support the field as 833 undistinguished octets. 835 Implementations supporting this specification MUST use the 836 Identifier of "Type.Extended-Type" to determine the interpretation 837 of the String field. 839 3.4. Extended-Type-4 841 Description 843 This attribute encapsulates attributes of the "Extended Type" 844 format, in the RADIUS Attribute Type Space of 244.{1-255}. 846 A summary of the Extended-Type-4 Attribute format is shown below. 847 The fields are transmitted from left to right. 849 0 1 2 3 850 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 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Type | Length | Extended-Type | Value ... 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 Type 857 244 for Extended-Type-4. 859 Length 861 >= 4 863 Extended-Type 865 The Extended-Type field is one octet. Up-to-date values of this 866 field are specified by IANA, in the 244.{1-255} RADIUS Attribute 867 Type Space. Further definition of this field is given in Section 868 2.1, above. 870 String 872 The String field is one or more octets. Implementations not 873 supporting this specification SHOULD support the field as 874 undistinguished octets. 876 Implementations supporting this specification MUST use the 877 Identifier of "Type.Extended-Type" to determine the interpretation 878 of the String Field. 880 3.5. Extended-Type-Flagged-1 882 Description 884 This attribute encapsulates attributes of the "Extended Type with 885 Flags" format, in the RADIUS Attribute Type Space of 245.{1-255}. 887 A summary of the Extended-Type-Flagged-1 Attribute format is shown 888 below. The fields are transmitted from left to right. 890 0 1 2 3 891 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 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Type | Length | Extended-Type |M| Flags | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | Value ... 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 Type 900 245 for Extended-Type-Flagged-1 902 Length 904 >= 4 906 Extended-Type 908 The Extended-Type field is one octet. Up-to-date values of this 909 field are specified by IANA, in the 245.{1-255} RADIUS Attribute 910 Type Space. Further definition of this field is given in Section 911 2.1, above. 913 M (More) 915 The More Flag is one (1) bit in length, and indicates whether or 916 not the current attribute contains "more" than 251 octets of data. 917 Further definition of this field is given in Section 2.2, above. 919 Flags 921 This field is 7 bits long, and is reserved for future use. 922 Implementations MUST set it to zero (0) when encoding an attribute 923 for sending in a packet. The contents SHOULD be ignored on 924 reception. 926 String 928 The String field is one or more octets. Implementations not 929 supporting this specification SHOULD support the field as 930 undistinguished octets. 932 Implementations supporting this specification MUST use the 933 Identifier of "Type.Extended-Type" to determine the interpretation 934 of the String field. 936 3.6. Extended-Type-Flagged-2 938 Description 940 This attribute encapsulates attributes of the "Extended Type with 941 Flags" format, in the RADIUS Attribute Type Space of 246.{1-255}. 943 A summary of the Extended-Type-Flagged-2 Attribute format is shown 944 below. The fields are transmitted from left to right. 946 0 1 2 3 947 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 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | Type | Length | Extended-Type |M| Flags | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | Value ... 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 Type 956 246 for Extended-Type-Flagged-2 958 Length 960 >= 4 962 Extended-Type 964 The Extended-Type field is one octet. Up-to-date values of this 965 field are specified by IANA, in the 246.{1-255} RADIUS Attribute 966 Type Space. Further definition of this field is given in Section 967 2.1, above. 969 M (More) 971 The More Flag is one (1) bit in length, and indicates whether or 972 not the current attribute contains "more" than 251 octets of data. 973 Further definition of this field is given in Section 2.2, above. 975 Flags 977 This field is 7 bits long, and is reserved for future use. 978 Implementations MUST set it to zero (0) when encoding an attribute 979 for sending in a packet. The contents SHOULD be ignored on 980 reception. 982 String 983 The String field is one or more octets. Implementations not 984 supporting this specification SHOULD support the field as 985 undistinguished octets. 987 Implementations supporting this specification MUST use the 988 Identifier of "Type.Extended-Type" to determine the interpretation 989 of the String field. 991 4. Vendor Specific Attributes 993 We define six new attributes which can carry Vendor Specific 994 information. We define four (4) attributes of the "Extended Type" 995 format, with Type codes (241.26, 242.26, 243.26, 244.26), using the 996 "evs" data type. We also define two (2) attributes of "Extended Type 997 with Flags" format, with Type codes (245.26, 246.26), using the "evs" 998 data type. 1000 Type.Extended-Type Name 1001 ------------------ ---- 1002 241.26 Extended-Vendor-Specific-1 1003 242.26 Extended-Vendor-Specific-2 1004 243.26 Extended-Vendor-Specific-3 1005 244.26 Extended-Vendor-Specific-4 1006 245.26 Extended-Vendor-Specific-5 1007 246.26 Extended-Vendor-Specific-6 1009 The rest of this section gives a detailed definition for each 1010 Attribute based on the above summary. 1012 4.1. Extended-Vendor-Specific-1 1014 Description 1016 This attribute defines a RADIUS Type Code of 241.26, using the 1017 "evs" data type. 1019 A summary of the Extended-Vendor-Specific-1 Attribute format is shown 1020 below. The fields are transmitted from left to right. 1022 0 1 2 3 1023 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 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | Type | Length | Extended-Type | Vendor-Id ... 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 ... Vendor-Id (cont) | Vendor-Type | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | String .... 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 Type.Extended-Type 1033 241.26 for Extended-Vendor-Specific-1 1035 Length 1037 >= 9 1039 Vendor-Id 1041 The high-order octet is 0 and the low-order 3 octets are the SMI 1042 Network Management Private Enterprise Code of the Vendor in 1043 network byte order. 1045 Vendor-Type 1047 The Vendor-Type field is one octet. Values are assigned at the 1048 sole discretion of the Vendor. 1050 String 1052 The String field is one or more octets. The actual format of the 1053 information is site or application specific, and a robust 1054 implementation SHOULD support the field as undistinguished octets. 1056 The codification of the range of allowed usage of this field is 1057 outside the scope of this specification. 1059 The length of the String field is eight (8) less then the value of 1060 the Length field. 1062 Implementations supporting this specification MUST use the 1063 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1064 determine the interpretation of the String field. 1066 4.2. Extended-Vendor-Specific-2 1068 Description 1070 This attribute defines a RADIUS Type Code of 242.26, using the 1071 "evs" data type. 1073 A summary of the Extended-Vendor-Specific-2 Attribute format is shown 1074 below. The fields are transmitted from left to right. 1076 0 1 2 3 1077 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 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | Type | Length | Extended-Type | Vendor-Id ... 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 ... Vendor-Id (cont) | Vendor-Type | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | String .... 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 Type.Extended-Type 1088 242.26 for Extended-Vendor-Specific-2 1090 Length 1092 >= 9 1094 Vendor-Id 1096 The high-order octet is 0 and the low-order 3 octets are the SMI 1097 Network Management Private Enterprise Code of the Vendor in 1098 network byte order. 1100 Vendor-Type 1102 The Vendor-Type field is one octet. Values are assigned at the 1103 sole discretion of the Vendor. 1105 String 1107 The String field is one or more octets. The actual format of the 1108 information is site or application specific, and a robust 1109 implementation SHOULD support the field as undistinguished octets. 1111 The codification of the range of allowed usage of this field is 1112 outside the scope of this specification. 1114 The length of the String field is eight (8) less then the value of 1115 the Length field. 1117 Implementations supporting this specification MUST use the 1118 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1119 determine the interpretation of the String field. 1121 4.3. Extended-Vendor-Specific-3 1123 Description 1125 This attribute defines a RADIUS Type Code of 243.26, using the 1126 "evs" data type. 1128 A summary of the Extended-Vendor-Specific-3 Attribute format is shown 1129 below. The fields are transmitted from left to right. 1131 0 1 2 3 1132 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 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 | Type | Length | Extended-Type | Vendor-Id ... 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 ... Vendor-Id (cont) | Vendor-Type | 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | String .... 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 Type.Extended-Type 1143 243.26 for Extended-Vendor-Specific-3 1145 Length 1147 >= 9 1149 Vendor-Id 1151 The high-order octet is 0 and the low-order 3 octets are the SMI 1152 Network Management Private Enterprise Code of the Vendor in 1153 network byte order. 1155 Vendor-Type 1157 The Vendor-Type field is one octet. Values are assigned at the 1158 sole discretion of the Vendor. 1160 String 1162 The String field is one or more octets. The actual format of the 1163 information is site or application specific, and a robust 1164 implementation SHOULD support the field as undistinguished octets. 1166 The codification of the range of allowed usage of this field is 1167 outside the scope of this specification. 1169 The length of the String field is eight (8) less then the value of 1170 the Length field. 1172 Implementations supporting this specification MUST use the 1173 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1174 determine the interpretation of the String field. 1176 4.4. Extended-Vendor-Specific-4 1178 Description 1180 This attribute defines a RADIUS Type Code of 244.26, using the 1181 "evs" data type. 1183 A summary of the Extended-Vendor-Specific-3 Attribute format is shown 1184 below. The fields are transmitted from left to right. 1186 0 1 2 3 1187 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 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 | Type | Length | Extended-Type | Vendor-Id ... 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 ... Vendor-Id (cont) | Vendor-Type | 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 | String .... 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 Type.Extended-Type 1198 244.26 for Extended-Vendor-Specific-4 1200 Length 1202 >= 9 1204 Vendor-Id 1206 The high-order octet is 0 and the low-order 3 octets are the SMI 1207 Network Management Private Enterprise Code of the Vendor in 1208 network byte order. 1210 Vendor-Type 1212 The Vendor-Type field is one octet. Values are assigned at the 1213 sole discretion of the Vendor. 1215 String 1217 The String field is one or more octets. The actual format of the 1218 information is site or application specific, and a robust 1219 implementation SHOULD support the field as undistinguished octets. 1221 The codification of the range of allowed usage of this field is 1222 outside the scope of this specification. 1224 The length of the String field is eight (8) less then the value of 1225 the Length field. 1227 Implementations supporting this specification MUST use the 1228 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1229 determine the interpretation of the String field. 1231 4.5. Extended-Vendor-Specific-5 1233 Description 1235 This attribute defines a RADIUS Type Code of 245.26, using the 1236 "evs" data type. 1238 A summary of the Extended-Vendor-Specific-5 Attribute format is shown 1239 below. The fields are transmitted from left to right. 1241 0 1 2 3 1242 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 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 | Type | Length | Extended-Type |M| Flags | 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 | Vendor-Id | 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 | Vendor-Type | String .... 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 Type.Extended-Type 1253 245.26 for Extended-Vendor-Specific-5 1255 Length 1257 >= 10 (first fragment) 1258 >= 5 (subsequent fragments) 1260 When a VSA is fragmented across multiple Attributes, only the 1261 first Attribute contains the Vendor-Id and Vendor-Type fields. 1262 Subsequent Attributes contain fragments of the String field only. 1264 M (More) 1266 The More Flag is one (1) bit in length, and indicates whether or 1267 not the current attribute contains "more" than 251 octets of data. 1268 Further definition of this field is given in Section 2.2, above. 1270 Flags 1271 This field is 7 bits long, and is reserved for future use. 1272 Implementations MUST set it to zero (0) when encoding an attribute 1273 for sending in a packet. The contents SHOULD be ignored on 1274 reception. 1276 Vendor-Id 1278 The high-order octet is 0 and the low-order 3 octets are the SMI 1279 Network Management Private Enterprise Code of the Vendor in 1280 network byte order. 1282 Vendor-Type 1284 The Vendor-Type field is one octet. Values are assigned at the 1285 sole discretion of the Vendor. 1287 String 1289 The String field is one or more octets. The actual format of the 1290 information is site or application specific, and a robust 1291 implementation SHOULD support the field as undistinguished octets. 1293 The codification of the range of allowed usage of this field is 1294 outside the scope of this specification. 1296 Implementations supporting this specification MUST use the 1297 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1298 determine the interpretation of the String field. 1300 4.6. Extended-Vendor-Specific-6 1302 Description 1304 This attribute defines a RADIUS Type Code of 246.26, using the 1305 "evs" data type. 1307 A summary of the Extended-Vendor-Specific-6 Attribute format is shown 1308 below. The fields are transmitted from left to right. 1310 0 1 2 3 1311 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 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | Type | Length | Extended-Type |M| Flags | 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 | Vendor-Id | 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1317 | Vendor-Type | String .... 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1319 Type.Extended-Type 1321 246.26 for Extended-Vendor-Specific-6 1323 Length 1325 >= 10 (first fragment) 1326 >= 5 (subsequent fragments) 1328 When a VSA is fragmented across multiple Attributes, only the 1329 first Attribute contains the Vendor-Id and Vendor-Type fields. 1330 Subsequent Attributes contain fragments of the String field only. 1332 M (More) 1334 The More Flag is one (1) bit in length, and indicates whether or 1335 not the current attribute contains "more" than 251 octets of data. 1336 Further definition of this field is given in Section 2.2, above. 1338 Flags 1340 This field is 7 bits long, and is reserved for future use. 1341 Implementations MUST set it to zero (0) when encoding an attribute 1342 for sending in a packet. The contents SHOULD be ignored on 1343 reception. 1345 Vendor-Id 1347 The high-order octet is 0 and the low-order 3 octets are the SMI 1348 Network Management Private Enterprise Code of the Vendor in 1349 network byte order. 1351 Vendor-Type 1353 The Vendor-Type field is one octet. Values are assigned at the 1354 sole discretion of the Vendor. 1356 String 1358 The String field is one or more octets. The actual format of the 1359 information is site or application specific, and a robust 1360 implementation SHOULD support the field as undistinguished octets. 1362 The codification of the range of allowed usage of this field is 1363 outside the scope of this specification. 1365 Implementations supporting this specification MUST use the 1366 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1367 determine the interpretation of the String field. 1369 5. Compatibility with traditional RADIUS 1371 There are a number of potential compatibility issues with traditional 1372 RADIUS. This section describes them. 1374 5.1. Attribute Allocation 1376 Some vendors have used Attribute Type codes from the "Reserved" 1377 space, as Vendor Specific Attributes. This practice is considered 1378 anti-social behavior, as noted in [RFC6158]. These vendor 1379 definitions conflict with the attributes in the RADIUS Attribute Type 1380 space. The conflicting definitions may make it difficult for 1381 implementations to support both those Vendor Attributes, and the new 1382 Extended Attribute formats. 1384 We RECOMMEND that RADIUS client and server implementations delete all 1385 references to these improperly defined attributes. Failing that, we 1386 RECOMMEND that RADIUS server implementations have a per-client 1387 configurable flag which indicates which type of attributes are being 1388 sent from the client. If the flag is set one way, the conflicting 1389 attributes can be interpreted as being improperly defined Vendor 1390 Specific Attributes. If the flag is set the other way, the attributes 1391 MUST be interpreted as being of the Extended Attributes format. The 1392 default SHOULD be to interpret the attributes as being of the 1393 Extended Attributes format. 1395 Other methods of determining how to decode the attributes into a 1396 "correct" form are NOT RECOMMENDED. Those methods are likely to be 1397 fragile and prone to error. 1399 We RECOMMEND that RADIUS server implementations re-use the above flag 1400 to determine which type of attributes to send in a reply message. If 1401 the request is expected to contain the improperly defined attributes, 1402 the reply SHOULD NOT contain Extended Attributes. If the request is 1403 expected to contain Extended Attributes, the reply MUST NOT contain 1404 the improper Attributes. 1406 RADIUS clients will have fewer issues than servers. Clients MUST NOT 1407 send improperly defined Attributes in a request. For replies, 1408 clients MUST interpret attributes as being of the Extended Attributes 1409 format, instead of the improper definitions. These requirements 1410 impose no change in the RADIUS specifications, as such usage by 1411 vendors has always been in conflict with the standard requirements 1412 and the standards process. 1414 5.2. Proxy Servers 1416 RADIUS Proxy servers will need to forward Attributes having the new 1417 format, even if they do not implement support for the encoding and 1418 decoding of those attributes. We remind implementors of the 1419 following text in [RFC2865] Section 2.3: 1421 The forwarding server MUST NOT change the order of any attributes 1422 of the same type, including Proxy-State. 1424 This requirement solves some of the issues related to proxying of the 1425 new format, but not all. The reason is that proxy servers are 1426 permitted to examine the contents of the packets that they forward. 1427 Many proxy implementations not only examine the attributes, but they 1428 refuse to forward attributes which they do not understand (i.e. 1429 attributes for which they have no local dictionary definitions). 1431 This practice is NOT RECOMMENDED. Proxy servers SHOULD forward 1432 attributes, even ones which they do not understand, or which are not 1433 in a local dictionary. When forwarded, these attributes SHOULD be 1434 sent verbatim, with no modifications or changes. The only exception 1435 to this recommendation is when local site policy dictates that 1436 filtering of attributes has to occur. For example, a filter at a 1437 visited network may require removal of certain authorization rules 1438 which apply to the home network, but not to the visited network. 1439 This filtering can sometimes be done even when the contents of the 1440 attributes are unknown, such as when all Vendor-Specific Attributes 1441 are designated for removal. 1443 As seen in [EDUROAM] many proxies do not follow these practices for 1444 unknown Attributes. Some proxies filter out unknown attributes or 1445 attributes which have unexpected lengths (24%, 17/70), some truncate 1446 the attributes to the "expected" length (11%, 8/70), some discard the 1447 request entirely (1%, 1/70), with the rest (63%, 44/70) following the 1448 recommended practice of passing the attributes verbatim. It will be 1449 difficult to widely use the Extended Attributes format until all non- 1450 conformant proxies are fixed. We therefore RECOMMEND that all 1451 proxies which do not support the Extended Attributes (241 through 1452 246) define them as being of data type "string", and delete all other 1453 local definitions for those attributes. 1455 This last change should enable wider usage of the Extended Attributes 1456 format. 1458 6. Guidelines 1460 This specification proposes a number of changes to RADIUS, and 1461 therefore requires a set of guidelines, as has been done in 1463 [RFC6158]. 1465 6.1. Updates to RFC 6158 1467 This specification updates [RFC6158] by adding the data types "evs", 1468 "tlv" and "integer64"; defining them to be "basic" data types; and 1469 permitting their use subject to the restrictions outlined below. 1471 All other recommendations given in [RFC6158] are unchanged. New 1472 recommendations for the use of the new data types and attribute 1473 formats are given below. 1475 6.2. Guidelines For the New Types 1477 We recommend the following guidelines when designing attributes using 1478 the new format. The items listed below are not exhaustive. As 1479 experience is gained with the new formats, later specifications may 1480 define additional guidelines. 1482 * The data type "evs" MUST NOT be used for standard RADIUS 1483 Attributes, or for TLVs, or for VSAs. 1485 * The data type "tlv" SHOULD NOT be used for standard RADIUS 1486 attributes. While its use is NOT RECOMMENDED by [RFC6158], this 1487 specification updates [RFC6158] to permit the "tlv" data type in 1488 attributes using the Extended-Type format. 1490 * [RFC2866] "tagged" attributes MUST NOT be defined in the 1491 Extended-Type space. The "tlv" data type should be used instead to 1492 group attributes. 1494 * The "integer64" data type MAY be used in any RADIUS attribute. 1495 The use of 64-bit integers is NOT RECOMMENDED by [RFC6158], but 1496 their utility is now evident. 1498 * For all other circumstances, the guidelines in [RFC6158] MUST 1499 be followed. 1501 6.3. Allocation Request Guidelines 1503 The following items give guidelines for allocation requests made in a 1504 RADIUS specification. 1506 * Discretion is RECOMMENDED when requesting allocation of attributes. 1507 The new space is much larger than the old one, but it is not 1508 infinite. 1510 * When the Type spaces of 241.*, 242.*, 243.*, or 244.* are nearing 1511 exhaustion, a new specification SHOULD be written which requests 1512 allocation of one or more RADIUS Attributes from the "Reserved" 1513 space, using the "Extended Type" format. This process is 1514 preferable to allocating "small" attributes from the 256.* and 1515 246.* Type spaces. 1517 * When the Type spaces of 245.* or 246.* are nearing exhaustion, a 1518 new specification SHOULD be written which requests allocation of 1519 one or more RADIUS Attributes from the "Reserved" space, using the 1520 "Extended Type with flags" format. 1522 * All other specifications SHOULD NOT request allocation from the 1523 standard Attribute Type Space (i.e. Attributes 1 through 255). 1524 That space is deprecated, and is not to be used. 1526 * Attributes which encode 252 octets or less of data SHOULD 1527 request allocation from the Type spaces of 241.*, 242.*, 243.*, 1528 or 244.*. 1530 * Attributes which encode 253 octets or more of data MUST request 1531 allocation from the Type spaces of 245.* or 246.*. 1533 * Where a group of TLVs is strictly defined, and not expected to 1534 change, and and totals less than 247 octets of data, they SHOULD 1535 request allocation from the Type spaces of 241.*, 242.*, 243.*, or 1536 244.*. 1538 * Where a group of TLVs is loosely defined, or is expected to change, 1539 they SHOULD request allocation from the Type spaces of 245.* or 1540 246.*. 1542 6.4. TLV Guidelines 1544 The following items give guidelines for specifications using TLVs. 1546 * when multiple attributes are intended to be grouped or managed 1547 together, the use of TLVs to group related attributes is 1548 RECOMMENDED. 1550 * more than 4 layers (depth) of TLV nesting is NOT RECOMMENDED. 1552 * Specifications SHOULD that the interpretation of an attribute 1553 depends only on its OID, and not on its encoding in the RADIUS 1554 packet. 1556 6.5. Implementation Guidelines 1558 * RADIUS Server implementations SHOULD support this specification 1559 as soon as possible. 1561 * RADIUS Proxy servers SHOULD forward all attributes, even ones 1562 which they do not understand, or which are not in a local 1563 dictionary. These attributes SHOULD be forwarded verbatim, with 1564 no modifications or changes. 1566 * Any attribute which is allocated from the Type spaces of 245.* or 1567 246.*, of data type "text", "string", or "tlv" can end up carrying 1568 more than 251 octets of data, up to the maximum RADIUS packet 1569 length (~4096 octets). Specifications defining such attributes 1570 SHOULD define a maximum length. 1572 6.6. Vendor Guidelines 1574 * Vendors SHOULD use the existing Vendor-Specific Attribute Type 1575 space in preference to the new Extended-Vendor-Specific 1576 attributes, as this specification may take time to be widely 1577 deployed. 1579 7. Rationale 1581 The path to extending the RADIUS protocol has been long and arduous. 1582 A number of proposals have been made and discarded by the RADEXT 1583 working group. These proposals have been judged to be either too 1584 bulky, too complex, too simple, or to be unworkable in practice. We 1585 do not otherwise explain here why earlier proposals did not obtain 1586 working group consensus. 1588 This proposal has the benefit of being simple, as the "Extended Type" 1589 format requires only a one octet change to the Attribute format. 1591 7.1. Attribute Audit 1593 An audit of almost five thousand publicly available attributes 1594 [ATTR], shows the statistics summarized below. The attributes include 1595 over 100 Vendor dictionaries, along with the IANA assigned 1596 attributes: 1598 Count Data Type 1599 ----- --------- 1600 2257 integer 1601 1762 text 1602 273 IPv4 Address 1603 235 string 1604 96 other data types 1605 35 IPv6 Address 1606 18 date 1607 4 Interface Id 1608 3 IPv6 Prefix 1610 4683 Total 1612 The entries in the "Data Type" column are data types recommended by 1613 [RFC6158]. The "other data types" row encompasses data types not 1614 recommended by that document. 1616 Manual inspection of the dictionaries shows that approximately 20 (or 1617 0.5%) attributes have the ability to transport more than 253 octets 1618 of data. These attributes are divided between VSAs, and a small 1619 number of standard Attributes. The "Extended Type with Flags" 1620 formats is therefore important, but "long" attributes have had 1621 limited deployment. 1623 8. Examples 1625 A few examples are presented here, in order to illustrate the 1626 encoding of the new attribute formats. These examples are not 1627 intended to be exhaustive, as many others are possible. For 1628 simplicity, we do not show complete packets, only attributes. 1630 The examples are given using a domain-specific language implemented 1631 by the program given in Appendix A. The language is line oriented, 1632 and composed of a sequence of lines matching the grammar ([RFC5234]) 1633 given below: 1635 Identifier = 1*DIGIT *( "." 1*DIGIT ) 1637 HEXCHAR = HEXDIG HEXDIG 1639 STRING = DQUOTE 1*CHAR DQUOTE 1641 TLV = "{" 1*DIGIT DATA "}" 1643 DATA = 1*HEXCHAR / 1*TLV / STRING 1645 LINE = Identifier DATA 1647 The progam has additional restrictions on its input that are not 1648 reflected in the above grammar. For example, the portions of the 1649 Identifier which refer to Type and Extended-Type are limited to 1650 values between 1 and 255. We trust that the source code in Appendix 1651 A is clear, and that these restrictions do not negatively affect the 1652 comprehensability of the examples. 1654 The program reads the input text, and interprets it as a set of 1655 instructions to create RADIUS Attributes. It then prints the hex 1656 encoding of those attributes. It implements the minimum set of 1657 functionality which achieves that goal. This minimalism means that 1658 it does not use attribute dictionaries; it does not implement support 1659 for RADIUS data types; it can be used to encode attributes with 1660 invalid data field(s); and there is no requirement for consistency 1661 from one example to the next. For example, it can be used to encode 1662 a User-Name attribute which contains non-UTF8 data, or a Framed-IP- 1663 Address which contains 253 octets of ASCII data. As a result, it 1664 cannot be used to create RADIUS Attributes for transport in a RADIUS 1665 message. 1667 However, the program correctly encodes the RADIUS attribute fields of 1668 "Type", "Length", "Extended-Type", "More", "Flags", "Vendor-Id", 1669 "Vendor-Type", and "Vendor-Length". It can therefore be used to 1670 encode example attributes from input which is humanly readable. 1672 We do not give examples of "malformed" or "invalid attributes". We 1673 also note that the examples show format, and not consistent meaning. 1674 A particular attribute type code may be used to demonstrate two 1675 different formats. In real specifications, attributes have a static 1676 definitions based on their type code. 1678 The examples given below are strictly for demonstration purposes 1679 only, and do not provide a standard of any kind. 1681 8.1. Extended Type 1683 The following are a series of examples of the "Extended Type" format. 1685 Attribute encapsulating textual data. 1687 241.1 "bob" 1688 -> f1 06 01 62 6f 62 1690 Attribute encapsulating a TLV with TLV-Type of one (1). 1692 241.2 { 1 23 45 } 1693 -> f1 07 02 01 04 23 45 1695 Attribute encapsulating two TLVs, one after the other. 1697 241.2 { 1 23 45 } { 2 67 89 } 1698 -> f1 0b 02 01 04 23 45 02 04 67 89 1700 Attribute encapsulating two TLVs, where the second TLV is itself 1701 encapsulating a TLV. 1703 241.2 { 1 23 45 } { 3 { 1 ab cd } } 1704 -> f1 0d 02 01 04 23 45 03 06 01 04 ab cd 1706 Attribute encapsulating two TLVs, where the second TLV is itself 1707 encapsulating two TLVs. 1709 241.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } 1710 -> f1 12 02 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f 1712 Attribute encapsulating a TLV, which in turn encapsulates a TLV, 1713 to a depth of 5 nestings. 1715 241.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } 1716 -> f1 0f 01 01 0c 02 0a 03 08 04 06 05 04 cd ef 1718 Attribute encapsulating an extended Vendor Specific attribute, 1719 with Vendor-Id of 1, and Vendor-Type of 4, which in turn 1720 encapsulates textual data. 1722 241.26.1.4 "test" 1723 -> f1 0c 1a 00 00 00 01 04 74 65 73 74 1725 Attribute encapsulating an extended Vendor Specific attribute, with 1726 Vendor-Id of 1, and Vendor-Type of 5, which in turn encapsulates 1727 a TLV with TLV-Type of 3, which encapsulates textual data. 1729 241.26.1.5 { 3 "test" } 1730 -> f1 0e 1a 00 00 00 01 05 03 06 74 65 73 74 1732 8.2. Extended Type with Flags 1734 The following are a series of examples of the "Extended Type with 1735 flags" format. 1737 Attribute encapsulating textual data. 1739 245.1 "bob" 1740 -> f5 07 01 00 62 6f 62 1742 Attribute encapsulating a TLV with TLV-Type of one (1). 1744 245.2 { 1 23 45 } 1745 -> f5 08 02 00 01 04 23 45 1747 Attribute encapsulating two TLVs, one after the other. 1749 245.2 { 1 23 45 } { 2 67 89 } 1750 -> f5 0c 02 00 01 04 23 45 02 04 67 89 1752 Attribute encapsulating two TLVs, where the second TLV is itself 1753 encapsulating a TLV. 1755 245.2 { 1 23 45 } { 3 { 1 ab cd } } 1756 -> f5 0e 02 00 01 04 23 45 03 06 01 04 ab cd 1758 Attribute encapsulating two TLVs, where the second TLV is itself 1759 encapsulating two TLVs. 1761 245.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } 1762 -> f5 13 02 00 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f 1764 Attribute encapsulating a TLV, which in turn encapsulates a TLV, 1765 to a depth of 5 nestings. 1767 245.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } 1768 -> f5 10 01 00 01 0c 02 0a 03 08 04 06 05 04 cd ef 1770 Attribute encapsulating an extended Vendor Specific attribute, 1771 with Vendor-Id of 1, and Vendor-Type of 4, which in turn 1772 encapsulates textual data. 1774 245.26.1.4 "test" 1775 -> f5 0d 1a 00 00 00 00 01 04 74 65 73 74 1777 Attribute encapsulating an extended Vendor Specific attribute, 1778 with Vendor-Id of 1, and Vendor-Type of 5, which in turn 1779 encapsulates a TLV with TLV-Type of 3, which encapsulates 1780 textual data. 1782 245.26.1.5 { 3 "test" } 1783 -> f5 0f 1a 00 00 00 00 01 05 03 06 74 65 73 74 1785 Attribute encapsulating more than 251 octets of data. The "Data" 1786 portions are indented for readability. 1788 245.4 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1789 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1790 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1791 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1792 aaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1793 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1794 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1795 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1796 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbcccccccccccccccccccc 1797 cccccccccc 1798 -> f5 ff 04 80 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1799 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1800 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1801 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1802 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1803 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1804 aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb bb bb bb bb bb 1805 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1806 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1807 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1808 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1809 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1810 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 13 04 00 cc 1811 cc cc cc cc cc cc cc cc cc cc cc cc cc cc 1813 Attribute encapsulating an extended Vendor Specific attribute, 1814 with Vendor-Id of 1, and Vendor-Type of 6, which in turn 1815 encapsulates more than 251 octets of data. 1817 As the VSA encapsulates more than 251 octets of data, it is 1818 split into two RADIUS attributes. The first attribute has the 1819 More flag set, and carries the Vendor-Id and Vendor-Type. 1820 The second attribute has the More flag clear, and carries 1821 the rest of the data portion of the VSA. Note that the second 1822 attribute does not include the Vendor-Id ad Vendor-Type fields. 1824 The "Data" portions are indented for readability. 1826 245.26.1.6 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1827 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1828 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1829 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1830 aaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1831 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1832 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1833 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1834 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbccccccccccccc 1835 ccccccccccccccccc 1836 -> f5 ff 1a 80 00 00 00 01 06 aa aa aa aa aa aa aa aa aa aa aa 1837 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1838 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1839 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1840 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1841 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1842 aa aa aa aa aa aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb 1843 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1844 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1845 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1846 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1847 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1848 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 17 1a 00 bb 1849 bb bb bb bb cc cc cc cc cc cc cc cc cc cc 13 45 67 89 1851 9. IANA Considerations 1853 This document has multiple impacts on IANA, in the "RADIUS Attribute 1854 Types" registry. Attribute types which were previously reserved are 1855 now allocated, previously free attributes are marked deprecated, and 1856 the registry is extended from a simple 8-bit array to a tree-like 1857 structure, up to a maximum depth of 125 nodes. 1859 9.1. Attribute Allocations 1861 IANA is requested to move the "Unassigned" numbers in the range 1862 144-191 from "Unassigned" to "Deprecated". This status means that 1863 allocations SHOULD NOT be made from this space. Instead, allocations 1864 SHOULD be taken from the Extended Type space, starting with lower 1865 numbered attributes. However, allocation from the "Deprecated" space 1866 MAY still be performed by publication of an IETF specification, where 1867 that specification requests allocation from the "Deprecated" space, 1868 and gives reasons why use of the Extended Type space is impossible. 1870 IANA is requested to move the following numbers from "Reserved", to 1871 allocated, with the following names: 1873 * 241 Extended-Type-1 1874 * 242 Extended-Type-2 1875 * 243 Extended-Type-3 1876 * 244 Extended-Type-4 1877 * 245 Extended-Type-Flagged-1 1878 * 246 Extended-Type-Flagged-2 1880 These attributes serve as an encapsulation layer for the new RADIUS 1881 Attribute Type tree. 1883 9.2. RADIUS Attribute Type Tree 1885 Each of the attributes allocated above extends the "RADIUS Attribute 1886 Types" to an N-ary tree, via a "dotted number" notation. Each number 1887 in the tree is an 8-bit value (1 to 255). The value zero (0) MUST 1888 NOT be used. Currently, only one level of the tree is defined: 1890 * 241 Extended-Attribute-1 1891 * 241.{1-25} Unassigned 1892 * 241.26 Extended-Vendor-Specific-1 1893 * 241.{27-240} Unassigned 1894 * 241.{241-255} Reserved 1895 * 242 Extended-Attribute-2 1896 * 242.{1-25} Unassigned 1897 * 242.26 Extended-Vendor-Specific-2 1898 * 242.{27-240} Unassigned 1899 * 243 Extended-Attribute-3 1900 * 242.{241-255} Reserved 1901 * 243.{1-25} Unassigned 1902 * 243.26 Extended-Vendor-Specific-3 1903 * 243.{27-240} Unassigned 1904 * 243.{241-255} Reserved 1905 * 244 Extended-Attribute-4 1906 * 244.{1-25} Unassigned 1907 * 244.26 Extended-Vendor-Specific-4 1908 * 244.{27-240} Unassigned 1909 * 244.{241-255} Reserved 1910 * 245 Extended-Attribute-5 1911 * 245.{1-25} Unassigned 1912 * 245.26 Extended-Vendor-Specific-5 1913 * 245.{27-240} Unassigned 1914 * 245.{241-255} Reserved 1915 * 246 Extended-Attribute-6 1916 * 246.{1-25} Unassigned 1917 * 245.26 Extended-Vendor-Specific-6 1918 * 246.{27-240} Unassigned 1919 * 246.{241-255} Reserved 1921 The values marked "Unassigned" above are available for assignment by 1922 IANA in future RADIUS specifications. The values marked "Reserved" 1923 are reserved for future use. 1925 9.3. Assignment Policy 1927 Attributes which are known to always require 252 octets or less of 1928 data MUST be assigned from the lowest unassigned number, e.g. 241.1, 1929 241.2, 241.3, etc. Attributes have the potential to transport more 1930 than 252 octets of data MUST be assigned from the 245.* or 246.* 1931 spaces, again using the lowest unassigned number, and MUST request 1932 assignment from the appropriate Attribute Type Space. 1934 The above policy can be difficult to enforce in the case of TLVs. 1935 For exaple, a set of TLVs may define a logical structure which totals 1936 less than 252 octets of data. Later extensions could assign 1937 additional sub-TLVs, and extend the structure to more than 252 octets 1938 of data. This capability means that TLV definitions SHOULD generally 1939 request assignment from the 245.* or 246.* space. 1941 9.4. Extending the Attribute Type Tree 1943 New specifications may request that the tree be extended to an 1944 additional level or levels. The attribute MUST be of type "tlv". 1946 For example, a specification may request that an "Example-TLV" 1947 attribute be assigned, of data type "tlv". If it is assigned the 1948 number 245.1, then it will define an extension to the registry as 1949 follows: 1951 * 245.1 Example-TLV 1952 * 245.1.{1-253} Unassigned 1953 * 245.1.{254-255} Reserved 1955 Note that this example does not define an "Example-TLV" attribute. 1957 The number zero (0) MUST NOT be used. The last two numbers (254 and 1958 255) MUST be reserved for future use. All other numbers are 1959 available for assignment by IANA. 1961 The Attribute Type Tree can be extended multiple levels in one 1962 specification. For example, the "Example-TLV" above could contain 1963 another attribute, "Example-Nested-TLV", of type "tlv". It would 1964 define an additional extension to the registry as follows: 1966 * 245.1.1 Example-Nested-TLV 1967 * 245.1.1.{1-253} Unassigned 1968 * 245.1.1.{254-255} Reserved 1969 This process may be continued to additional levels of nesting. 1971 Again, this example does not define an "Example-Nested-TLV" 1972 attribute. 1974 9.5. Extending the RADIUS Attribute Type Space 1976 The extended RADIUS Attribute Type space may eventually approach 1977 exhaustion. When necessary, the space SHOULD be extended by 1978 publication of a specification which allocates new attributes of 1979 either the "Extended Type", or the "Extended Type with flags" format. 1980 The specification SHOULD request allocation of a specific number from 1981 the "Reserved" RADIUS Attribute type space, such as 247. The 1982 attribute(s) SHOULD be given a name which follows the naming 1983 convention used in this document. The Extended-Type value of 26 MUST 1984 be allocated to a "Vendor Specific" attribute, of data type "esv". 1985 The Extended-Type values of 241 through 255 MUST be marked as 1986 "Reserved". 1988 IANA SHOULD allocate the attribute(s) as requested. For example, if 1989 allocation of attribute 247 is requested, the following definitions 1990 MUST be made in the specification, and allocated by IANA. 1992 * 247.1 Extended-Attribute-7 1993 * 247.{1-25} Unassigned 1994 * 247.26 Extended-Vendor-Specific-7 1995 * 247.{27-240} Unassigned 1996 * 247.{241-255} Reserved 1998 We note,however, that the above list is an example, and we do not 1999 request or perform allocation of attribute 247 in this document. 2001 10. Security Considerations 2003 This document defines new formats for data carried inside of RADIUS, 2004 but otherwise makes no changes to the security of the RADIUS 2005 protocol. 2007 Attacks on cryptographic hashes are well known, and are getting 2008 better with time, as discussed in[RFC4270]. RADIUS uses the MD5 hash 2009 [RFC1321] for packet authentication and attribute obfuscation. There 2010 are ongoing efforts in the IETF to analyze and address these issues 2011 for the RADIUS protocol. 2013 As with any protocol change, code changes are required in order to 2014 implement the new features. These code changes have the potential to 2015 introduce new vulnerabilities in the software. Since the RADIUS 2016 server performs network authentication, it is an inviting target for 2017 attackers. We RECOMMEND that access to RADIUS servers be kept to a 2018 minimum. 2020 11. References 2022 11.1. Normative references 2024 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2025 Requirement Levels", RFC 2119, March, 1997. 2027 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 2028 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2029 2000. 2031 11.2. Informative references 2033 [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, 2034 April, 1992 2036 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 2038 [RFC2868] Zorn, G., et al, " RADIUS Attributes for Tunnel Protocol 2039 Support", RFC 2868, June 2000. 2041 [RFC4270] Hoffman, P, and Schneier, B, "Attacks on Cryptographic Hashes 2042 in Internet Protocols", RFC 4270, November 2005. 2044 [RFC5234] Crocker, D. (Ed.), and Overell, P., "Augmented BNF for Syntax 2045 Specifications: ABNF", RFC 5234, October 2005. 2047 [RFC6158] DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC 2048 6158, March 2011. 2050 [EDUROAM] Internal Eduroam testing page, data retrieved 04 August 2010. 2052 [ATTR] http://github.com/alandekok/freeradius- 2053 server/tree/master/share/, data retrieved September 2010. 2055 Acknowledgments 2057 This document is the result of long discussions in the IETF RADEXT 2058 working group. The authors would like to thank all of the 2059 participants who contributed various ideas over the years. Their 2060 feedback has been invaluable, and has helped to make this 2061 specification better. 2063 Appendix A - Extended Attribute Generator Program 2065 This section contains "C" program source which can be used for 2066 testing. It reads a line-oriented text file, parses it to create 2067 RADIUS formatted attributes, and prints the hex version of those 2068 attributes to standard output. 2070 The input accepts a grammar similar to that given in Section 8, with 2071 some modifications for usability. For example, blank lines are 2072 allowed, lines beginning with a '#' character are interpreted as 2073 comments, numbers (RADIUS Types, etc.) are checked for minimum / 2074 maximum values, and RADIUS Attribute lengths are enforced. 2076 The program is included here for demonstration purposes only, and 2077 does not define a standard of any kind. 2079 ------------------------------------------------------------ 2080 /* 2081 * Copyright (c) 2010 IETF Trust and the persons identified as 2082 * authors of the code. All rights reserved. 2083 * 2084 * Redistribution and use in source and binary forms, with or without 2085 * modification, are permitted provided that the following conditions 2086 * are met: 2087 * 2088 * Redistributions of source code must retain the above copyright 2089 * notice, this list of conditions and the following disclaimer. 2090 * 2091 * Redistributions in binary form must reproduce the above copyright 2092 * notice, this list of conditions and the following disclaimer in 2093 * the documentation and/or other materials provided with the 2094 * distribution. 2095 * 2096 * Neither the name of Internet Society, IETF or IETF Trust, nor the 2097 * names of specific contributors, may be used to endorse or promote 2098 * products derived from this software without specific prior written 2099 * permission. 2100 * 2101 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 2102 * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, 2103 * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 2104 * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 2105 * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS 2106 * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 2107 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED 2108 * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 2109 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON 2110 * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 2111 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT 2112 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 2113 * SUCH DAMAGE. 2114 * 2115 * Author: Alan DeKok 2116 */ 2117 #include 2118 #include 2119 #include 2120 #include 2121 #include 2122 #include 2124 static int encode_tlv(char *buffer, uint8_t *output, size_t outlen); 2126 static const char *hextab = "0123456789abcdef"; 2128 static int encode_data_string(char *buffer, 2129 uint8_t *output, size_t outlen) 2130 { 2131 int length = 0; 2132 char *p; 2134 p = buffer + 1; 2136 while (*p && (outlen > 0)) { 2137 if (*p == '"') { 2138 return length; 2139 } 2141 if (*p != '\\') { 2142 *(output++) = *(p++); 2143 outlen--; 2144 length++; 2145 continue; 2146 } 2148 switch (p[1]) { 2149 default: 2150 *(output++) = p[1]; 2151 break; 2153 case 'n': 2154 *(output++) = '\n'; 2155 break; 2157 case 'r': 2158 *(output++) = '\r'; 2159 break; 2161 case 't': 2162 *(output++) = '\t'; 2163 break; 2164 } 2166 outlen--; 2167 length++; 2168 } 2170 fprintf(stderr, "String is not terminated\n"); 2171 return 0; 2172 } 2174 static int encode_data_tlv(char *buffer, char **endptr, 2175 uint8_t *output, size_t outlen) 2176 { 2177 int depth = 0; 2178 int length; 2179 char *p; 2181 for (p = buffer; *p != '\0'; p++) { 2182 if (*p == '{') depth++; 2183 if (*p == '}') { 2184 depth--; 2185 if (depth == 0) break; 2186 } 2187 } 2189 if (*p != '}') { 2190 fprintf(stderr, "No trailing '}' in string starting " 2191 "with \"%s\"\n", 2192 buffer); 2193 return 0; 2194 } 2196 *endptr = p + 1; 2197 *p = '\0'; 2199 p = buffer + 1; 2200 while (isspace((int) *p)) p++; 2202 length = encode_tlv(p, output, outlen); 2203 if (length == 0) return 0; 2205 return length; 2206 } 2207 static int encode_data(char *p, uint8_t *output, size_t outlen) 2208 { 2209 int length; 2211 if (!isspace((int) *p)) { 2212 fprintf(stderr, "Invalid character following attribute " 2213 "definition\n"); 2214 return 0; 2215 } 2217 while (isspace((int) *p)) p++; 2219 if (*p == '{') { 2220 int sublen; 2221 char *q; 2223 length = 0; 2225 do { 2226 while (isspace((int) *p)) p++; 2227 if (!*p) { 2228 if (length == 0) { 2229 fprintf(stderr, "No data\n"); 2230 return 0; 2231 } 2233 break; 2234 } 2236 sublen = encode_data_tlv(p, &q, output, outlen); 2237 if (sublen == 0) return 0; 2239 length += sublen; 2240 output += sublen; 2241 outlen -= sublen; 2242 p = q; 2243 } while (*q); 2245 return length; 2246 } 2248 if (*p == '"') { 2249 length = encode_data_string(p, output, outlen); 2250 return length; 2251 } 2253 length = 0; 2254 while (*p) { 2255 char *c1, *c2; 2257 while (isspace((int) *p)) p++; 2259 if (!*p) break; 2261 if(!(c1 = memchr(hextab, tolower((int) p[0]), 16)) || 2262 !(c2 = memchr(hextab, tolower((int) p[1]), 16))) { 2263 fprintf(stderr, "Invalid data starting at " 2264 "\"%s\"\n", p); 2265 return 0; 2266 } 2268 *output = ((c1 - hextab) << 4) + (c2 - hextab); 2269 output++; 2270 length++; 2271 p += 2; 2273 outlen--; 2274 if (outlen == 0) { 2275 fprintf(stderr, "Too much data\n"); 2276 return 0; 2277 } 2278 } 2280 if (length == 0) { 2281 fprintf(stderr, "Empty string\n"); 2282 return 0; 2283 } 2285 return length; 2286 } 2288 static int decode_attr(char *buffer, char **endptr) 2289 { 2290 long attr; 2292 attr = strtol(buffer, endptr, 10); 2293 if (*endptr == buffer) { 2294 fprintf(stderr, "No valid number found in string " 2295 "starting with \"%s\"\n", buffer); 2296 return 0; 2297 } 2299 if (!**endptr) { 2300 fprintf(stderr, "Nothing follows attribute number\n"); 2301 return 0; 2302 } 2303 if ((attr <= 0) || (attr > 256)) { 2304 fprintf(stderr, "Attribute number is out of valid " 2305 "range\n"); 2306 return 0; 2307 } 2309 return (int) attr; 2310 } 2312 static int decode_vendor(char *buffer, char **endptr) 2313 { 2314 long vendor; 2316 if (*buffer != '.') { 2317 fprintf(stderr, "Invalid separator before vendor id\n"); 2318 return 0; 2319 } 2321 vendor = strtol(buffer + 1, endptr, 10); 2322 if (*endptr == (buffer + 1)) { 2323 fprintf(stderr, "No valid vendor number found\n"); 2324 return 0; 2325 } 2327 if (!**endptr) { 2328 fprintf(stderr, "Nothing follows vendor number\n"); 2329 return 0; 2330 } 2332 if ((vendor <= 0) || (vendor > (1 << 24))) { 2333 fprintf(stderr, "Vendor number is out of valid range\n"); 2334 return 0; 2335 } 2337 if (**endptr != '.') { 2338 fprintf(stderr, "Invalid data following vendor number\n"); 2339 return 0; 2340 } 2341 (*endptr)++; 2343 return (int) vendor; 2344 } 2346 static int encode_tlv(char *buffer, uint8_t *output, size_t outlen) 2347 { 2348 int attr; 2349 int length; 2350 char *p; 2351 attr = decode_attr(buffer, &p); 2352 if (attr == 0) return 0; 2354 output[0] = attr; 2355 output[1] = 2; 2357 if (*p == '.') { 2358 p++; 2359 length = encode_tlv(p, output + 2, outlen - 2); 2361 } else { 2362 length = encode_data(p, output + 2, outlen - 2); 2363 } 2365 if (length == 0) return 0; 2366 if (length > (255 - 2)) { 2367 fprintf(stderr, "TLV data is too long\n"); 2368 return 0; 2369 } 2371 output[1] += length; 2373 return length + 2; 2374 } 2376 static int encode_vsa(char *buffer, uint8_t *output, size_t outlen) 2377 { 2378 int vendor; 2379 int attr; 2380 int length; 2381 char *p; 2383 vendor = decode_vendor(buffer, &p); 2384 if (vendor == 0) return 0; 2386 output[0] = 0; 2387 output[1] = (vendor >> 16) & 0xff; 2388 output[2] = (vendor >> 8) & 0xff; 2389 output[3] = vendor & 0xff; 2391 length = encode_tlv(p, output + 4, outlen - 4); 2392 if (length == 0) return 0; 2393 if (length > (255 - 6)) { 2394 fprintf(stderr, "VSA data is too long\n"); 2395 return 0; 2396 } 2397 return length + 4; 2398 } 2400 static int encode_evs(char *buffer, uint8_t *output, size_t outlen) 2401 { 2402 int vendor; 2403 int attr; 2404 int length; 2405 char *p; 2407 vendor = decode_vendor(buffer, &p); 2408 if (vendor == 0) return 0; 2410 attr = decode_attr(p, &p); 2411 if (attr == 0) return 0; 2413 output[0] = 0; 2414 output[1] = (vendor >> 16) & 0xff; 2415 output[2] = (vendor >> 8) & 0xff; 2416 output[3] = vendor & 0xff; 2417 output[4] = attr; 2419 length = encode_data(p, output + 5, outlen - 5); 2420 if (length == 0) return 0; 2422 return length + 5; 2423 } 2425 static int encode_extended(char *buffer, 2426 uint8_t *output, size_t outlen) 2427 { 2428 int attr; 2429 int length; 2430 char *p; 2432 attr = decode_attr(buffer, &p); 2433 if (attr == 0) return 0; 2435 output[0] = attr; 2437 if (attr == 26) { 2438 length = encode_evs(p, output + 1, outlen - 1); 2439 } else { 2440 length = encode_data(p, output + 1, outlen - 1); 2441 } 2442 if (length == 0) return 0; 2443 if (length > (255 - 3)) { 2444 fprintf(stderr, "Extended Attr data is too long\n"); 2445 return 0; 2446 } 2448 return length + 1; 2449 } 2451 static int encode_extended_flags(char *buffer, 2452 uint8_t *output, size_t outlen) 2453 { 2454 int attr; 2455 int length, total; 2456 char *p; 2458 attr = decode_attr(buffer, &p); 2459 if (attr == 0) return 0; 2461 /* output[0] is the extended attribute */ 2462 output[1] = 4; 2463 output[2] = attr; 2464 output[3] = 0; 2466 if (attr == 26) { 2467 length = encode_evs(p, output + 4, outlen - 4); 2468 if (length == 0) return 0; 2470 output[1] += 5; 2471 length -= 5; 2472 } else { 2473 length = encode_data(p, output + 4, outlen - 4); 2474 } 2475 if (length == 0) return 0; 2477 total = 0; 2478 while (1) { 2479 int sublen = 255 - output[1]; 2481 if (length <= sublen) { 2482 output[1] += length; 2483 total += output[1]; 2484 break; 2485 } 2487 length -= sublen; 2489 memmove(output + 255 + 4, output + 255, length); 2490 memcpy(output + 255, output, 4); 2492 output[1] = 255; 2493 output[3] |= 0x80; 2495 output += 255; 2496 output[1] = 4; 2497 total += 255; 2498 } 2500 return total; 2501 } 2503 static int encode_rfc(char *buffer, uint8_t *output, size_t outlen) 2504 { 2505 int attr; 2506 int length, sublen; 2507 char *p; 2509 attr = decode_attr(buffer, &p); 2510 if (attr == 0) return 0; 2512 length = 2; 2513 output[0] = attr; 2514 output[1] = 2; 2516 if (attr == 26) { 2517 sublen = encode_vsa(p, output + 2, outlen - 2); 2519 } else if ((*p == ' ') || ((attr < 241) || (attr > 246))) { 2520 sublen = encode_data(p, output + 2, outlen - 2); 2522 } else { 2523 if (*p != '.') { 2524 fprintf(stderr, "Invalid data following " 2525 "attribute number\n"); 2526 return 0; 2527 } 2529 if (attr < 245) { 2530 sublen = encode_extended(p + 1, 2531 output + 2, outlen - 2); 2532 } else { 2534 /* 2535 * Not like the others! 2536 */ 2537 return encode_extended_flags(p + 1, output, outlen); 2538 } 2539 } 2540 if (sublen == 0) return 0; 2541 if (sublen > (255 -2)) { 2542 fprintf(stderr, "RFC Data is too long\n"); 2543 return 0; 2544 } 2546 output[1] += sublen; 2547 return length + sublen; 2548 } 2550 int main(int argc, char *argv[]) 2551 { 2552 int lineno; 2553 size_t i, outlen; 2554 FILE *fp; 2555 char input[8192], buffer[8192]; 2556 uint8_t output[4096]; 2558 if ((argc < 2) || (strcmp(argv[1], "-") == 0)) { 2559 fp = stdin; 2560 } else { 2561 fp = fopen(argv[1], "r"); 2562 if (!fp) { 2563 fprintf(stderr, "Error opening %s: %s\n", 2564 argv[1], strerror(errno)); 2565 exit(1); 2566 } 2567 } 2569 lineno = 0; 2570 while (fgets(buffer, sizeof(buffer), fp) != NULL) { 2571 char *p = strchr(buffer, '\n'); 2573 lineno++; 2575 if (!p) { 2576 if (!feof(fp)) { 2577 fprintf(stderr, "Line %d too long in %s\n", 2578 lineno, argv[1]); 2579 exit(1); 2580 } 2581 } else { 2582 *p = '\0'; 2583 } 2585 p = strchr(buffer, '#'); 2586 if (p) *p = '\0'; 2588 p = buffer; 2589 while (isspace((int) *p)) p++; 2590 if (!*p) continue; 2592 strcpy(input, p); 2593 outlen = encode_rfc(input, output, sizeof(output)); 2594 if (outlen == 0) { 2595 fprintf(stderr, "Parse error in line %d of %s\n", 2596 lineno, input); 2597 exit(1); 2598 } 2600 printf("%s -> ", buffer); 2601 for (i = 0; i < outlen; i++) { 2602 printf("%02x ", output[i]); 2603 } 2604 printf("\n"); 2605 } 2607 if (fp != stdin) fclose(fp); 2609 return 0; 2610 } 2611 ------------------------------------------------------------ 2613 Author's Address 2615 Alan DeKok 2616 Network RADIUS SARL 2617 15 av du Granier 2618 38240 Meylan 2619 France 2621 Email: aland@networkradius.com 2622 URI: http://networkradius.com 2624 Avi Lior 2625 Bridgewater Systems Corporation 2626 303 Terry Fox Drive 2627 Suite 100 2628 Ottawa, Ontario K2K 3J1 2629 Canada 2631 Phone: +1 (613) 591-6655 2632 Email: avi@bridgewatersystems.com 2633 URI: http://www.bridgewatersystems.com/