idnits 2.17.1 draft-ietf-radext-radius-extensions-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC2865, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3575, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2866, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5176, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (Using the creation date from RFC2865, updated by this document, for RFC5378 checks: 1999-03-04) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (15 November 2011) is 4546 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 2590 -- Looks like a reference, but probably isn't: '0' on line 2525 -- Looks like a reference, but probably isn't: '2' on line 2475 -- Looks like a reference, but probably isn't: '3' on line 2505 -- Looks like a reference, but probably isn't: '4' on line 2429 -- Looks like a reference, but probably isn't: '8192' on line 2567 -- Looks like a reference, but probably isn't: '4096' on line 2568 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Alan DeKok 3 INTERNET-DRAFT Network RADIUS 4 Category: Proposed Standard Avi Lior 5 Updates: 2865, 2866, 3575, 5176 BWS 6 7 Expires: May 15, 2012 8 15 November 2011 10 Remote Authentication Dial In User Service (RADIUS) Protocol 11 Extensions 12 draft-ietf-radext-radius-extensions-03.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 May 15, 2012. 46 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info/) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction ............................................. 5 63 1.1. Terminology ......................................... 6 64 1.2. Requirements Language ............................... 6 65 2. Extensions to RADIUS ..................................... 8 66 2.1. Extended Type ....................................... 8 67 2.2. Extended Type with Flags ............................ 9 68 2.3. TLV Data Type ....................................... 11 69 2.3.1. TLV Nesting .................................... 13 70 2.4. EVS Data Type ....................................... 13 71 2.5. Integer64 Data Type ................................. 15 72 2.6. Attribute Naming and Type Identifiers ............... 15 73 2.6.1. Attribute and TLV Naming ....................... 16 74 2.6.2. Attribute Type Identifiers ..................... 16 75 2.6.3. TLV Identifiers ................................ 16 76 2.6.4. VSA Identifiers ................................ 17 77 3. Attribute Definitions .................................... 18 78 3.1. Extended-Type-1 ..................................... 18 79 3.2. Extended-Type-2 ..................................... 19 80 3.3. Extended-Type-3 ..................................... 20 81 3.4. Extended-Type-4 ..................................... 21 82 3.5. Extended-Type-Flagged-1 ............................. 21 83 3.6. Extended-Type-Flagged-2 ............................. 23 84 4. Vendor Specific Attributes ............................... 24 85 4.1. Extended-Vendor-Specific-1 .......................... 24 86 4.2. Extended-Vendor-Specific-2 .......................... 25 87 4.3. Extended-Vendor-Specific-3 .......................... 26 88 4.4. Extended-Vendor-Specific-4 .......................... 28 89 4.5. Extended-Vendor-Specific-5 .......................... 29 90 4.6. Extended-Vendor-Specific-6 .......................... 30 91 5. Compatibility with traditional RADIUS .................... 32 92 5.1. Attribute Allocation ................................ 32 93 5.2. Proxy Servers ....................................... 33 94 6. Guidelines ............................................... 34 95 6.1. Updates to RFC 6158 ................................. 34 96 6.2. Guidelines For the New Types ........................ 34 97 6.3. Allocation Request Guidelines ....................... 34 98 6.4. TLV Guidelines ...................................... 35 99 6.5. Implementation Guidelines ........................... 36 100 6.6. Vendor Guidelines ................................... 36 101 7. Rationale ................................................ 36 102 7.1. Attribute Audit ..................................... 37 103 8. Examples ................................................. 37 104 8.1. Extended Type ....................................... 38 105 8.2. Extended Type with Flags ............................ 40 106 9. IANA Considerations ...................................... 42 107 9.1. Attribute Allocations ............................... 42 108 9.2. RADIUS Attribute Type Tree .......................... 43 109 9.3. Allocation of TLV Data Types ........................ 44 110 9.4. Allocation within a TLV ............................. 44 111 9.5. Allocation of Extended Type with Flags format ....... 45 112 9.6. Allocation of Other Data Types ...................... 45 113 10. Security Considerations ................................. 45 114 11. References .............................................. 45 115 11.1. Normative references ............................... 46 116 11.2. Informative references ............................. 46 117 Appendix A - Extended Attribute Generator Program ............ 47 118 1. Introduction 120 Under current allocation pressure, we expect that the RADIUS 121 Attribute Type space will be exhausted by 2014 or 2015. We therefore 122 need a way to extend the type space, so that new specifications may 123 continue to be developed. Other issues have also been shown with 124 RADIUS. The attribute grouping method defined in [RFC2868] has been 125 shown to be imnpractical, and a more powerful mechanism is needed. 126 Multiple attributes have been defined which transport more than the 127 253 octets of data originally envisioned with the protocol. Each of 128 these attributes is handled as a "special case" inside of RADIUS 129 implementations, instead of as a general method. We therefore also 130 need a standardized method of transporting large quantities of data. 131 Finally, some vendors are close to allocating all of the Attributes 132 within their Vendor-Specific Attribute space. It would be useful to 133 leverage changes to the base protocol for extending the Vendor- 134 Specific Attribute space. 136 We satisfy all of these requirements through the following 137 modifications to RADIUS: 139 * defining an "Extended Type" format, which adds 8 bits of "Extended 140 Type" to the RADIUS Attribute Type space, by using one octet of the 141 "Value" field. This method gives us a general way of extending 142 the Attribute Type Space. 144 * allocating 4 attributes as using the format of "Extended Type". 145 This allocation extends the RADIUS Attribute Type Space by 146 approximately 1000 values. 148 * defining an "Extended Type with Flags" format, which inserts 149 an additional "Flags" octet between the "Extended Type" octet, 150 and the "Value" field. This method gives us a general way of 151 adding additional functionality to the protocol. 153 * defining a method which uses the "Flags" field to indicate data 154 fragmentation across multiple Attributes. This method provides a 155 standard way for an Attribute to carry more than 253 octets of 156 data. 158 * allocating 2 attributes as using the format of "Extended Type with 159 Flags". This allocation extends the RADIUS Attribute Type Space 160 by an additional 500 values. 162 * defining a new "Type Length Value" (TLV) data type. The data type 163 allows an attribute to carry TLVs as "sub-attributes", which can in 164 turn encapsulate other TLVs as "sub-sub-attributes." This change 165 creates a standard way to group a set of Attributes. 167 * defining a new "extended Vendor-Specific" (EVS) data type. The 168 data type allows an attribute to carry Vendor-Specific Attributes 169 (VSAs) inside of the new attribute formats. 171 * defining a new "integer64" data type. The data type allows 172 counters which track more than 2^32 octets of data. 174 * allocating 6 attributes using the new EVS data type. This 175 allocation extends the Vendor-Specific Attribute type space by 176 over 1500 values. 178 As with any protocol change, the changes defined here are the result 179 of a series of compromises. We have tried to find a balance between 180 flexibility, space in the RADIUS message, compatibility with existing 181 deployments, and implementation difficulty. 183 1.1. Terminology 185 This document uses the following terms: 187 silently discard 188 This means the implementation discards the packet without further 189 processing. The implementation MAY provide the capability of 190 logging the error, including the contents of the silently discarded 191 packet, and SHOULD record the event in a statistics counter. 193 invalid attribute 194 This means that the Length field of an Attribute is valid (as per 195 [RFC2865], Section 5, top of page 25). However, the Value field of 196 the attribute does not follow the format required by the data type 197 defined for that Attribute. e.g. an Attribute of type "address" 198 which encapsulates more than four, or less than four, octets of 199 data. 201 1.2. Requirements Language 203 In this document, several words are used to signify the requirements 204 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 205 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 206 and "OPTIONAL" in this document are to be interpreted as described in 207 [RFC2119]. 209 An implementation is not compliant if it fails to satisfy one or more 210 of the must or must not requirements for the protocols it implements. 211 An implementation that satisfies all the MUST, MUST NOT, SHOULD, and 212 SHOULD NOT requirements for its protocols is said to be 213 "unconditionally compliant"; one that satisfies all the MUST and MUST 214 NOT requirements but not all the SHOULD or SHOULD NOT requirements 215 for its protocols is said to be "conditionally compliant". 217 2. Extensions to RADIUS 219 This section defines two new attribute formats; "Extended Type"; and 220 "Extended Type with Flags". The formats are defined below. 222 2.1. Extended Type 224 This section defines a new attribute format, called "Extended Type". 225 A summary of the Attribute format is shown below. The fields are 226 transmitted from left to right. 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Type | Length | Extended-Type | Value ... 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Type 236 This field is identical to the Type field of the Attribute format 237 defined in [RFC2865] Section 5. 239 Length 241 This field is identical to the Length field of the Attribute 242 format defined in [RFC2865] Section 5. Permitted values are 243 between 4 and 255. If a client or server receives an Extended 244 Attribute with a Length of 2 or 3, then that Attribute MUST be 245 deemed to be an "invalid attribute", it SHOULD be silently 246 discarded. If it is not discarded, it MUST NOT be handled in the 247 same manner as a well-formed attribute. 249 Note that an "invalid attribute" does not cause the entire packet 250 to be discarded, or to be treated as a negative acknowledgement. 251 Instead, only the "invalid attribute" is discarded. 253 Extended-Type 255 The Extended-Type field is one octet. Up-to-date values of this 256 field are specified by IANA. Unlike the Type field defined in 257 [RFC2865] Section 5, no values are allocated for experimental or 258 implementation-specific use. Values 241-255 are reserved and 259 SHOULD NOT be used. 261 The Extended-Type is meaningful only within a context defined by 262 the Type field. That is, this field may be thought of as defining 263 a new type space of the form "Type.Extended-Type". See Section 264 2.5, below, for additional discussion. 266 A RADIUS server MAY ignore Attributes with an unknown 267 "Type.Extended-Type". 269 A RADIUS client MAY ignore Attributes with an unknown 270 "Type.Extended-Type". 272 Value 274 This field is similar to the Value field of the Attribute format 275 defined in [RFC2865] Section 5. The format of the data SHOULD be 276 a valid RADIUS data type. 278 The addition of the Extended-Type field decreases the maximum 279 length for attributes of type "text" or "string" from 253 to 252 280 octets. Where an Attribute needs to carry more than 252 octets of 281 data, the "Extended Type with flags" format should be used. 283 Experience has shown that the "experimental" and "implementation 284 specific" attributes defined in [RFC2865] Section 5 have had little 285 practical value. We therefore do not continue that practice here 286 with the Extended-Type field. 288 2.2. Extended Type with Flags 290 This section defines a new attribute format, called "Extended Type 291 with Flags". It leverages the "Extended Type" format in order to 292 permit the transport of attributes encapsulating more than 253 octets 293 of data. A summary of the Attribute format is shown below. The 294 fields are transmitted from left to right. 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Type | Length | Extended-Type |M| Flags | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Value ... 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Type 306 This field is identical to the Type field of the Attribute format 307 defined in [RFC2865] Section 5. 309 Length 311 This field is identical to the Length field of the Attribute 312 format defined in [RFC2865] Section 5. Permitted values are 313 between 5 and 255. If a client or server receives an "Extended 314 Attribute with Flags" with a Length of 2, 3, or 4, then that 315 Attribute MUST be deemed to be an "invalid attribute", it SHOULD 316 be silently discarded. If it is not discarded, it MUST NOT be 317 handled in the same manner as a well-formed attribute. 319 Note that an "invalid attribute" does not cause the entire packet 320 to be discarded, or to be treated as a negative acknowledgement. 321 Instead, only the "invalid attribute" is discarded. 323 Extended-Type 325 This field is identical to the Extended-Type field defined above 326 in Section 2.1. 328 M (More) 330 The More Flag is one (1) bit in length, and indicates whether or 331 not the current attribute contains "more" than 251 octets of data. 332 The More flag MUST be clear (0) if the Length field has value less 333 than 255. The More flag MAY be set (1) if the Length field has 334 value of 255. 336 If the More flag is set (1), it indicates that the Value field has 337 been fragmented across multiple RADIUS attributes. When the More 338 flag is set (1), the attribute SHOULD have a Length field of value 339 255; it MUST NOT have a length Field of value 4; there MUST be an 340 attribute following this one; and the next attribute MUST have 341 both the same Type and Extended Type. That is, multiple fragments 342 of the same value MUST be in order and MUST be consecutive 343 attributes in the packet, and the last attribute in a packet MUST 344 NOT have the More flag set (1). 346 When the Length field of an attribute has value less than 255, the 347 More flag SHOULD be clear (0). 349 If a client or server receives an attribute fragment with the 350 "More" flag set (1), but for which no subsequent fragment can be 351 found, then the fragmented attribute is deemed to be an "invalid 352 attribute" and the entire set of fragments SHOULD be silently 353 discarded. If the fragmented attribute is not discarded, it MUST 354 NOT be handled in the same manner as a well-formed attribute. 356 Flags 358 This field is 7 bits long, and is reserved for future use. 359 Implementations MUST set it to zero (0) when encoding an attribute 360 for sending in a packet. The contents SHOULD be ignored on 361 reception. 363 Value 365 This field is similar to the Value field of the Attribute format 366 defined in [RFC2865] Section 5. It may contain a complete set of 367 data (when the Length field has value less than 255), or it may 368 contain a fragment of data (when the More field is set). 370 Any interpretation of the resulting data MUST occur after the 371 fragments have been reassembled. The length of the data MUST be 372 taken as the sum of the lengths of the fragments (i.e. Value 373 fields) from which it is constructed. The format of the data 374 SHOULD be a valid RADIUS data type. 376 This definition increases the RADIUS Attribute Type space as above, 377 but also provides for transport of Attributes which could contain 378 more than 253 octets of data. 380 2.3. TLV Data Type 382 We define a new data type in RADIUS, called "tlv". The "tlv" data 383 type is an encapsulation layer which permits the "Value" field of an 384 Attribute to contain new sub-Attributes. These sub-Attributes can in 385 turn contain "Value"s of data type TLV. This capability both extends 386 the attribute space, and permits "nested" attributes to be used. 387 This nesting can be used to encapsulate or group data into one or 388 more logical containers. 390 The "tlv" data type re-uses the RADIUS attribute format, as given 391 below: 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | TLV-Type | TLV-Length | TLV-Value ... 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 TLV-Type 401 The Type field is one octet. Up-to-date values of this field are 402 specified by IANA. Values of zero (0) MUST NOT be used. Values 403 254-255 are "Reserved" for use by future extensions to RADIUS. 404 The value 26 has no special meaning. 406 As with Extended-Type above, the TLV-Type is meaningful only 407 within a context defined by "Type" fields of the encapsulating 408 Attributes. That is, the field may be thought of as defining a 409 new type space of the form "Type.Extended-Type.TLV-Type". Where 410 TLVs are nested, the type space is of the form "Type.Extended- 411 Type.TLV-Type.TLV-Type", etc. 413 A RADIUS server MAY ignore Attributes with an unknown "TLV-Type". 415 A RADIUS client MAY ignore Attributes with an unknown "TLV-Type". 417 TLV-Length 419 The TLV-Length field is one octet, and indicates the length of 420 this TLV including the TLV-Type, TLV-Length and TLV-Value fields. 421 It MUST have a value between 3 and 255. If a client or server 422 receives a TLV with an invalid TLV-Length, then the attribute 423 which encapsulates that TLV MUST be deemed to be an "invalid 424 attribute", it SHOULD be silently discarded. If the encapsulating 425 attribute is not discarded, it MUST NOT be handled in the same 426 manner as a well-formed attribute. 428 Note that an "invalid attribute" does not cause the entire packet 429 to be discarded, or to be treated as a negative acknowledgement. 430 Instead, only the "invalid attribute" is discarded. 432 TLV-Value 434 The Value field is one or more octets and contains information 435 specific to the Attribute. The format and length of the TLV-Value 436 field is determined by the TLV-Type and TLV-Length fields. 438 The TLV-Value field SHOULD encapsulate a previously defined RADIUS 439 data type. Using non-standard data types is NOT RECOMMENDED. We 440 note that the TLV-Value field MAY also contain one or more 441 attributes of data type "tlv", which allows for simple grouping 442 and multiple layers of nesting. 444 The TLV-Value field is limited to containing 253 or fewer octets 445 of data. Specifications which require a TLV to contain more than 446 253 octets of data are incompatible with RADIUS, and need to be 447 redesigned. Specifications which require the transport of empty 448 Values (i.e. Length = 2) are incompatible with RADIUS, and need to 449 be redesigned. 451 The TLV-Value field MUST NOT contain data using the "Extended 452 Type" formats defined in this document. The base Extended 453 Attributes format allows for sufficient flexibility that nesting 454 them inside of a TLV offers little additional value. 456 This TLV definition is compatible with the suggested format of the 457 "String" field of the Vendor-Specific attribute, as defined in 458 [RFC2865] Section 5.26, though that specification does not discuss 459 nesting. 461 Vendors MAY use attributes of type "tlv" in any Vendor Specific 462 Attribute. We RECOMMEND using type "tlv" for VSAs, in preference to 463 any other format. 465 2.3.1. TLV Nesting 467 TLVs may contain other TLVs. When this occurs, the "container" TLV 468 MUST be completely filled by the "contained" TLVs. That is, the 469 "container" TLV-Length field MUST be exactly two (2) more than the 470 sum of the "contained" TLV-Length fields. If the "contained" TLVs 471 over-fill the "container" TLV, the "container" TLV MUST be considered 472 to be an "invalid attribute", and handled as described above. 474 The depth of TLV nesting is limited only by the restrictions on the 475 TLV-Length field. The limit of 253 octets of data results in a limit 476 of 126 levels of nesting. However, nesting depths of more than 4 are 477 NOT RECOMMENDED. 479 2.4. EVS Data Type 481 We define a new data type in RADIUS, called "evs", for "Extended 482 Vendor-Specific". The "evs" data type is an encapsulation layer 483 which which permits the "Value" field of an Attribute to contain a 484 Vendor-Id, followed by a Vendor-Type, and then vendor-defined data. 485 This data can in turn contain valid RADIUS data types, or any other 486 data as determined by the vendor. 488 This data type is intended use in attributes which carry Vendor- 489 Specific information, as is done with the Vendor-Specific Attribute 490 (26). It is RECOMMENDED that this data type be used by a vendor only 491 when the Vendor-Specific Attribute Type space has been fully 492 allocated. 494 Where [RFC2865] Section 5.26 makes a recommendation for the format of 495 the data following the Vendor-Id, we give a strict definition. 496 Experience has shown that many vendors have not followed the 497 [RFC2865] recommendations, leading to interoperability issues. We 498 hope here to give vendors sufficient flexibility as to meet their 499 needs, while minimizing the use of non-standard VSA formats. 501 The "evs" data type MAY be used in Attributes having the format of 502 "Extended Type" or "Extended Type with Flags". It MUST NOT be used 503 in any other Attribute definition, including standard RADIUS 504 Attributes, TLVs, and VSAs. 506 A summary of the "evs" data type format is shown below. The fields 507 are transmitted from left to right. 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Vendor-Id | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Vendor-Type | String .... 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 Vendor-Id 519 The high-order octet is 0 and the low-order 3 octets are the SMI 520 Network Management Private Enterprise Code of the Vendor in 521 network byte order. 523 Vendor-Type 525 The Vendor-Type field is one octet. Values are assigned at the 526 sole discretion of the Vendor. 528 Value 530 The Value field is one or more octets. It SHOULD encapsulate a 531 previously defined RADIUS data type. Using non-standard data 532 types is NOT RECOMMENDED. We note that the Value field may be of 533 data type "tlv". However, it MUST NOT be of data type "evs", as 534 the use cases are unclear for one vendor delegating attribute type 535 space to another vendor. 537 The actual format of the information is site or application 538 specific, and a robust implementation SHOULD support the field as 539 undistinguished octets. We recognise that Vendors have complete 540 control over the contents and format of the Value field, while at 541 the same time recommending that good practices be followed. 543 Further codification of the range of allowed usage of this field 544 is outside the scope of this specification. 546 Note that unlike the format described in [RFC2865] Section 5.26, this 547 data type has no "Vendor length" field. The length of the "String" 548 field is implicit, and is determined by taking the "Length" of the 549 encapsulating RADIUS Attribute, and subtracting the length of the 550 attribute header including the 4 octets of Vendor-Id. i.e. For 551 "Extended Type" attributes, the length of the String field is seven 552 (7) less than the value of the Length field. For "Extended Type with 553 Flags" attributes, the length of the String field is eight (8) less 554 than the value of the Length field. 556 2.5. Integer64 Data Type 558 We define a new data type in RADIUS, called "integer64", which 559 carries a 64-bit unsigned integer in network byte order. 561 This data type is intended to be used in any situation where there is 562 a need to have counters which can count past 2^32. The expected use 563 of this data type is within Accounting-Request packets, but this data 564 type SHOULD be used in any packet where 32-bit integers are expected 565 to be insufficient. 567 The "integer64" data type MAY be used in Attributes of any format, 568 standard space, extended attributes, TLVs, and VSAs. 570 A summary of the "integer64" data type format is shown below. The 571 fields are transmitted from left to right. 573 0 1 2 3 574 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 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Value ... 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 Attributes having data type "integer64" MUST have the relevant Length 582 field set to eight more than the length of the Attribute header. For 583 standard space Attributes and TLVs, this means that the Length field 584 MUST be set to ten (10). For "Extended Type" Attributes, the Length 585 field MUST be set to eleven (11). For "Extended Type with Flags" 586 Attributes, the Length field MUST be set to twelve (12). 588 2.6. Attribute Naming and Type Identifiers 590 Attributes have traditionally been identified by a unique name and 591 number. For example, the attribute named "User-Name" has been 592 allocated number one (1). This scheme needs to be extended in order 593 to be able to refer to attributes of Extended Type, and to TLVs. It 594 will also be used by IANA for allocating RADIUS Attribute Type 595 values. 597 The names and identifiers given here are intended to be used only in 598 specifications. The system presented here may not be useful when 599 referring to the contents of a RADIUS packet. It imposes no 600 requirements on implementations, as implementations are free to 601 reference RADIUS Attributes via any method they choose. 603 2.6.1. Attribute and TLV Naming 605 RADIUS specifications traditionally use names consisting of one or 606 more words, separated by hyphens, e.g. "User-Name". However, these 607 names are not allocated from a registry, and there is no restriction 608 other than convention on their global uniqueness. 610 Similarly, vendors have often used their company name as the prefix 611 for VSA names, though this practice is not universal. For example, 612 for a vendor named "Example", the name "Example-Attribute-Name" 613 SHOULD be used instead of "Attribute-Name". The second form can 614 conflict with attributes from other vendors, whereas the first form 615 cannot. 617 We therefore RECOMMEND that specifications give names to Attributes 618 which attempt to be globally unique across all RADIUS Attributes. We 619 RECOMMEND that vendors use their name as a unique prefix for 620 attribute names. We recognise that these suggestion may sometimes be 621 difficult to implement in practice. 623 TLVs SHOULD be named with a unique prefix that is shared among 624 related attributes. For example, a specification that defines a set 625 of TLVs related to time could create attributes named "Time-Zone", 626 "Time-Day", "Time-Hour", "Time-Minute", etc. 628 2.6.2. Attribute Type Identifiers 630 The RADIUS Attribute Type space defines a context for a particular 631 "Extended-Type" field. The "Extended-Type" field allows for 256 632 possible type code values, with values 1 through 240 available for 633 allocation. We define here an identification method that uses a 634 "dotted number" notation similar to that used for Object Identifiers 635 (OIDs), formatted as "Type.Extended-Type". 637 For example, and attribute within the Type space of 241, having 638 Extended-Type of one (1), is uniquely identified as "241.1". 639 Similarly, an attribute within the Type space of 246, having 640 Extended-Type of ten (10), is uniquely identified as "246.10". 642 The algorithm used to create the Attribute Identifier is simply to 643 concatenate all of the various identification fields (e.g. Type, 644 Extended-Type, etc.), starting from the encapsulating attribute, down 645 to the final encapsulated TLV, separated by a '.' character. 647 2.6.3. TLV Identifiers 649 We can extend the Attribute reference scheme defined above for TLVs. 650 This is done by leveraging the "dotted number" notation. As above, 651 we define an additional TLV type space, within the "Extended Type" 652 space, by appending another "dotted number" in order to identify the 653 TLV. This method can be replied in sequence for nested TLVs. 655 For example, let us say that "245.1" identifies RADIUS Attribute Type 656 245, containing an "Extended Type" of one (1), which is of type 657 "tlv". That attribute will contain 256 possible TLVs, one for each 658 value of the TLV-Type field. The first TLV-Type value of one (1) can 659 then be identified by appending a ".1" to the number of the 660 encapsulating attribute ("241.1"), to yield "241.1.1". Similarly, 661 the sequence "245.2.3.4" identifies RADIUS attribute 245, containing 662 an "Extended Type" of two (2) which is of type "tlv", which in turn 663 contains a TLV with TLV-Type number three (3), which in turn contains 664 another TLV, wth TLV-Type number four (4). 666 2.6.4. VSA Identifiers 668 There has historically been no method for numerically addressing 669 VSAs. The "dotted number" method defined here can also be leveraged 670 to create such an addressing scheme. However, as the VSAs are 671 completely under the control of each individual vendor, this section 672 provides a suggested practice, but does not define a standard of any 673 kind. 675 The Vendor-Specific Attribute has been assigned the Attribute number 676 26. It in turn carries a 24-bit Vendor-Id, and possibly additional 677 VSAs. Where the VSAs follow the [RFC2865] Section 5.26 recommended 678 format, a VSA can be identified as "26.Vendor-Id"."Vendor-Type". 680 For example, Livingston has Vendor-Id 307, and has defined an 681 attribute "IP-Pool" as number 6. This VSA can be uniquely identified 682 as 26.307.6. 684 Note that there is no restriction on the size of the numerical values 685 in this notation. The Vendor-Id is a 24-bit number, and the VSA may 686 have been assigned from a 16-bit vendor-specific Attribute type 687 space. 689 For example, the company USR has been allocated Vendor-Id 429, and 690 has defined a "Version-Id" attribute as number 32768. This VSA can 691 be uniquely identified as 26.429.32768. 693 Where a VSA is a TLV, the "dotted number" notation can be used as 694 above: 26.VID.VSA.TLV1.TLV2.TLV3 where "TLVn" are the numerical 695 values assigned by the vendor to the different nested TLVs. 697 3. Attribute Definitions 699 We define four (4) attributes of "Extended Type", which are allocated 700 from the "Reserved" Attribute Type codes of 241, 242, 243, and 244. 701 We also define two (2) attributes of "Extended Type with Flags", 702 which are allocated from the "Reserved" Attribute Type codes of 245 703 and 246. 705 Type Name 706 ---- ---- 707 241 Extended-Type-1 708 242 Extended-Type-2 709 243 Extended-Type-3 710 244 Extended-Type-4 711 245 Extended-Type-Flagged-1 712 246 Extended-Type-Flagged-2 714 The rest of this section gives a detailed definition for each 715 Attribute based on the above summary. 717 3.1. Extended-Type-1 719 Description 721 This attribute encapsulates attributes of the "Extended Type" 722 format, in the RADIUS Attribute Type Space of 241.{1-255}. 724 A summary of the Extended-Type-1 Attribute format is shown below. 725 The fields are transmitted from left to right. 727 0 1 2 3 728 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 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Type | Length | Extended-Type | Value ... 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 Type 735 241 for Extended-Type-1. 737 Length 739 >= 4 741 Extended-Type 743 The Extended-Type field is one octet. Up-to-date values of this 744 field are specified by IANA, in the 241.{1-255} RADIUS Attribute 745 Type Space. Further definition of this field is given in Section 746 2.1, above. 748 Value 750 The Value field is one or more octets. Implementations not 751 supporting this specification SHOULD support the field as 752 undistinguished octets. 754 Implementations supporting this specification MUST use the 755 Identifier of "Type.Extended-Type" to determine the interpretation 756 of the Value field. 758 3.2. Extended-Type-2 760 Description 762 This attribute encapsulates attributes of the "Extended Type" 763 format, in the RADIUS Attribute Type Space of 242.{1-255}. 765 A summary of the Extended-Type-2 Attribute format is shown below. 766 The fields are transmitted from left to right. 768 0 1 2 3 769 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 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Type | Length | Extended-Type | Value ... 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 Type 776 242 for Extended-Type-2. 778 Length 780 >= 4 782 Extended-Type 784 The Extended-Type field is one octet. Up-to-date values of this 785 field are specified by IANA, in the 242.{1-255} RADIUS Attribute 786 Type Space. Further definition of this field is given in Section 787 2.1, above. 789 Value 791 The Value field is one or more octets. Implementations not 792 supporting this specification SHOULD support the field as 793 undistinguished octets. 795 Implementations supporting this specification MUST use the 796 Identifier of "Type.Extended-Type" to determine the interpretation 797 of the Value field 799 3.3. Extended-Type-3 801 Description 803 This attribute encapsulates attributes of the "Extended Type" 804 format, in the RADIUS Attribute Type Space of 243.{1-255}. 806 A summary of the Extended-Type-3 Attribute format is shown below. 807 The fields are transmitted from left to right. 809 0 1 2 3 810 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 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Type | Length | Extended-Type | Value ... 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 Type 817 243 for Extended-Type-3. 819 Length 821 >= 4 823 Extended-Type 825 The Extended-Type field is one octet. Up-to-date values of this 826 field are specified by IANA, in the 243.{1-255} RADIUS Attribute 827 Type Space. Further definition of this field is given in Section 828 2.1, above. 830 Value 832 The Value field is one or more octets. Implementations not 833 supporting this specification SHOULD support the field as 834 undistinguished octets. 836 Implementations supporting this specification MUST use the 837 Identifier of "Type.Extended-Type" to determine the interpretation 838 of the Value field. 840 3.4. Extended-Type-4 842 Description 844 This attribute encapsulates attributes of the "Extended Type" 845 format, in the RADIUS Attribute Type Space of 244.{1-255}. 847 A summary of the Extended-Type-4 Attribute format is shown below. 848 The fields are transmitted from left to right. 850 0 1 2 3 851 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 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Type | Length | Extended-Type | Value ... 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 Type 858 244 for Extended-Type-4. 860 Length 862 >= 4 864 Extended-Type 866 The Extended-Type field is one octet. Up-to-date values of this 867 field are specified by IANA, in the 244.{1-255} RADIUS Attribute 868 Type Space. Further definition of this field is given in Section 869 2.1, above. 871 Value 873 The Value field is one or more octets. Implementations not 874 supporting this specification SHOULD support the field as 875 undistinguished octets. 877 Implementations supporting this specification MUST use the 878 Identifier of "Type.Extended-Type" to determine the interpretation 879 of the Value Field. 881 3.5. Extended-Type-Flagged-1 883 Description 885 This attribute encapsulates attributes of the "Extended Type with 886 Flags" format, in the RADIUS Attribute Type Space of 245.{1-255}. 888 A summary of the Extended-Type-Flagged-1 Attribute format is shown 889 below. The fields are transmitted from left to right. 891 0 1 2 3 892 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 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | Type | Length | Extended-Type |M| Flags | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | Value ... 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 Type 901 245 for Extended-Type-Flagged-1 903 Length 905 >= 5 907 Extended-Type 909 The Extended-Type field is one octet. Up-to-date values of this 910 field are specified by IANA, in the 245.{1-255} RADIUS Attribute 911 Type Space. Further definition of this field is given in Section 912 2.1, above. 914 M (More) 916 The More Flag is one (1) bit in length, and indicates whether or 917 not the current attribute contains "more" than 251 octets of data. 918 Further definition of this field is given in Section 2.2, above. 920 Flags 922 This field is 7 bits long, and is reserved for future use. 923 Implementations MUST set it to zero (0) when encoding an attribute 924 for sending in a packet. The contents SHOULD be ignored on 925 reception. 927 Value 929 The Value field is one or more octets. Implementations not 930 supporting this specification SHOULD support the field as 931 undistinguished octets. 933 Implementations supporting this specification MUST use the 934 Identifier of "Type.Extended-Type" to determine the interpretation 935 of the Value field. 937 3.6. Extended-Type-Flagged-2 939 Description 941 This attribute encapsulates attributes of the "Extended Type with 942 Flags" format, in the RADIUS Attribute Type Space of 246.{1-255}. 944 A summary of the Extended-Type-Flagged-2 Attribute format is shown 945 below. The fields are transmitted from left to right. 947 0 1 2 3 948 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 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Type | Length | Extended-Type |M| Flags | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | Value ... 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 Type 957 246 for Extended-Type-Flagged-2 959 Length 961 >= 5 963 Extended-Type 965 The Extended-Type field is one octet. Up-to-date values of this 966 field are specified by IANA, in the 246.{1-255} RADIUS Attribute 967 Type Space. Further definition of this field is given in Section 968 2.1, above. 970 M (More) 972 The More Flag is one (1) bit in length, and indicates whether or 973 not the current attribute contains "more" than 251 octets of data. 974 Further definition of this field is given in Section 2.2, above. 976 Flags 978 This field is 7 bits long, and is reserved for future use. 979 Implementations MUST set it to zero (0) when encoding an attribute 980 for sending in a packet. The contents SHOULD be ignored on 981 reception. 983 Value 984 The Value field is one or more octets. Implementations not 985 supporting this specification SHOULD support the field as 986 undistinguished octets. 988 Implementations supporting this specification MUST use the 989 Identifier of "Type.Extended-Type" to determine the interpretation 990 of the Value field. 992 4. Vendor Specific Attributes 994 We define six new attributes which can carry Vendor Specific 995 information. We define four (4) attributes of the "Extended Type" 996 format, with Type codes (241.26, 242.26, 243.26, 244.26), using the 997 "evs" data type. We also define two (2) attributes of "Extended Type 998 with Flags" format, with Type codes (245.26, 246.26), using the "evs" 999 data type. 1001 Type.Extended-Type Name 1002 ------------------ ---- 1003 241.26 Extended-Vendor-Specific-1 1004 242.26 Extended-Vendor-Specific-2 1005 243.26 Extended-Vendor-Specific-3 1006 244.26 Extended-Vendor-Specific-4 1007 245.26 Extended-Vendor-Specific-5 1008 246.26 Extended-Vendor-Specific-6 1010 The rest of this section gives a detailed definition for each 1011 Attribute based on the above summary. 1013 4.1. Extended-Vendor-Specific-1 1015 Description 1017 This attribute defines a RADIUS Type Code of 241.26, using the 1018 "evs" data type. 1020 A summary of the Extended-Vendor-Specific-1 Attribute format is shown 1021 below. The fields are transmitted from left to right. 1023 0 1 2 3 1024 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 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | Type | Length | Extended-Type | Vendor-Id ... 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 ... Vendor-Id (cont) | Vendor-Type | 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | Value .... 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 Type.Extended-Type 1034 241.26 for Extended-Vendor-Specific-1 1036 Length 1038 >= 9 1040 Vendor-Id 1042 The high-order octet is 0 and the low-order 3 octets are the SMI 1043 Network Management Private Enterprise Code of the Vendor in 1044 network byte order. 1046 Vendor-Type 1048 The Vendor-Type field is one octet. Values are assigned at the 1049 sole discretion of the Vendor. 1051 Value 1053 The Value field is one or more octets. The actual format of the 1054 information is site or application specific, and a robust 1055 implementation SHOULD support the field as undistinguished octets. 1057 The codification of the range of allowed usage of this field is 1058 outside the scope of this specification. 1060 The length of the Value field is eight (8) less then the value of 1061 the Length field. 1063 Implementations supporting this specification MUST use the 1064 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1065 determine the interpretation of the Value field. 1067 4.2. Extended-Vendor-Specific-2 1069 Description 1071 This attribute defines a RADIUS Type Code of 242.26, using the 1072 "evs" data type. 1074 A summary of the Extended-Vendor-Specific-2 Attribute format is shown 1075 below. The fields are transmitted from left to right. 1077 0 1 2 3 1078 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 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | Type | Length | Extended-Type | Vendor-Id ... 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 ... Vendor-Id (cont) | Vendor-Type | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | Value .... 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 Type.Extended-Type 1089 242.26 for Extended-Vendor-Specific-2 1091 Length 1093 >= 9 1095 Vendor-Id 1097 The high-order octet is 0 and the low-order 3 octets are the SMI 1098 Network Management Private Enterprise Code of the Vendor in 1099 network byte order. 1101 Vendor-Type 1103 The Vendor-Type field is one octet. Values are assigned at the 1104 sole discretion of the Vendor. 1106 Value 1108 The Value field is one or more octets. The actual format of the 1109 information is site or application specific, and a robust 1110 implementation SHOULD support the field as undistinguished octets. 1112 The codification of the range of allowed usage of this field is 1113 outside the scope of this specification. 1115 The length of the Value field is eight (8) less then the value of 1116 the Length field. 1118 Implementations supporting this specification MUST use the 1119 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1120 determine the interpretation of the Value field. 1122 4.3. Extended-Vendor-Specific-3 1124 Description 1126 This attribute defines a RADIUS Type Code of 243.26, using the 1127 "evs" data type. 1129 A summary of the Extended-Vendor-Specific-3 Attribute format is shown 1130 below. The fields are transmitted from left to right. 1132 0 1 2 3 1133 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 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 | Type | Length | Extended-Type | Vendor-Id ... 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 ... Vendor-Id (cont) | Vendor-Type | 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 | Value .... 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 Type.Extended-Type 1144 243.26 for Extended-Vendor-Specific-3 1146 Length 1148 >= 9 1150 Vendor-Id 1152 The high-order octet is 0 and the low-order 3 octets are the SMI 1153 Network Management Private Enterprise Code of the Vendor in 1154 network byte order. 1156 Vendor-Type 1158 The Vendor-Type field is one octet. Values are assigned at the 1159 sole discretion of the Vendor. 1161 Value 1163 The Value field is one or more octets. The actual format of the 1164 information is site or application specific, and a robust 1165 implementation SHOULD support the field as undistinguished octets. 1167 The codification of the range of allowed usage of this field is 1168 outside the scope of this specification. 1170 The length of the Value field is eight (8) less then the value of 1171 the Length field. 1173 Implementations supporting this specification MUST use the 1174 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1175 determine the interpretation of the Value field. 1177 4.4. Extended-Vendor-Specific-4 1179 Description 1181 This attribute defines a RADIUS Type Code of 244.26, using the 1182 "evs" data type. 1184 A summary of the Extended-Vendor-Specific-3 Attribute format is shown 1185 below. The fields are transmitted from left to right. 1187 0 1 2 3 1188 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 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | Type | Length | Extended-Type | Vendor-Id ... 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 ... Vendor-Id (cont) | Vendor-Type | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | Value .... 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 Type.Extended-Type 1199 244.26 for Extended-Vendor-Specific-4 1201 Length 1203 >= 9 1205 Vendor-Id 1207 The high-order octet is 0 and the low-order 3 octets are the SMI 1208 Network Management Private Enterprise Code of the Vendor in 1209 network byte order. 1211 Vendor-Type 1213 The Vendor-Type field is one octet. Values are assigned at the 1214 sole discretion of the Vendor. 1216 Value 1218 The Value field is one or more octets. The actual format of the 1219 information is site or application specific, and a robust 1220 implementation SHOULD support the field as undistinguished octets. 1222 The codification of the range of allowed usage of this field is 1223 outside the scope of this specification. 1225 The length of the Value field is eight (8) less then the value of 1226 the Length field. 1228 Implementations supporting this specification MUST use the 1229 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1230 determine the interpretation of the Value field. 1232 4.5. Extended-Vendor-Specific-5 1234 Description 1236 This attribute defines a RADIUS Type Code of 245.26, using the 1237 "evs" data type. 1239 A summary of the Extended-Vendor-Specific-5 Attribute format is shown 1240 below. The fields are transmitted from left to right. 1242 0 1 2 3 1243 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 1244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 | Type | Length | Extended-Type |M| Flags | 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 | Vendor-Id | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | Vendor-Type | Value .... 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 Type.Extended-Type 1254 245.26 for Extended-Vendor-Specific-5 1256 Length 1258 >= 10 (first fragment) 1259 >= 5 (subsequent fragments) 1261 When a VSA is fragmented across multiple Attributes, only the 1262 first Attribute contains the Vendor-Id and Vendor-Type fields. 1263 Subsequent Attributes contain fragments of the Value field only. 1265 M (More) 1267 The More Flag is one (1) bit in length, and indicates whether or 1268 not the current attribute contains "more" than 251 octets of data. 1269 Further definition of this field is given in Section 2.2, above. 1271 Flags 1272 This field is 7 bits long, and is reserved for future use. 1273 Implementations MUST set it to zero (0) when encoding an attribute 1274 for sending in a packet. The contents SHOULD be ignored on 1275 reception. 1277 Vendor-Id 1279 The high-order octet is 0 and the low-order 3 octets are the SMI 1280 Network Management Private Enterprise Code of the Vendor in 1281 network byte order. 1283 Vendor-Type 1285 The Vendor-Type field is one octet. Values are assigned at the 1286 sole discretion of the Vendor. 1288 Value 1290 The Value field is one or more octets. The actual format of the 1291 information is site or application specific, and a robust 1292 implementation SHOULD support the field as undistinguished octets. 1294 The codification of the range of allowed usage of this field is 1295 outside the scope of this specification. 1297 Implementations supporting this specification MUST use the 1298 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1299 determine the interpretation of the Value field. 1301 4.6. Extended-Vendor-Specific-6 1303 Description 1305 This attribute defines a RADIUS Type Code of 246.26, using the 1306 "evs" data type. 1308 A summary of the Extended-Vendor-Specific-6 Attribute format is shown 1309 below. The fields are transmitted from left to right. 1311 0 1 2 3 1312 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 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 | Type | Length | Extended-Type |M| Flags | 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 | Vendor-Id | 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 | Vendor-Type | Value .... 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 Type.Extended-Type 1322 246.26 for Extended-Vendor-Specific-6 1324 Length 1326 >= 10 (first fragment) 1327 >= 5 (subsequent fragments) 1329 When a VSA is fragmented across multiple Attributes, only the 1330 first Attribute contains the Vendor-Id and Vendor-Type fields. 1331 Subsequent Attributes contain fragments of the Value field only. 1333 M (More) 1335 The More Flag is one (1) bit in length, and indicates whether or 1336 not the current attribute contains "more" than 251 octets of data. 1337 Further definition of this field is given in Section 2.2, above. 1339 Flags 1341 This field is 7 bits long, and is reserved for future use. 1342 Implementations MUST set it to zero (0) when encoding an attribute 1343 for sending in a packet. The contents SHOULD be ignored on 1344 reception. 1346 Vendor-Id 1348 The high-order octet is 0 and the low-order 3 octets are the SMI 1349 Network Management Private Enterprise Code of the Vendor in 1350 network byte order. 1352 Vendor-Type 1354 The Vendor-Type field is one octet. Values are assigned at the 1355 sole discretion of the Vendor. 1357 Value 1359 The Value field is one or more octets. The actual format of the 1360 information is site or application specific, and a robust 1361 implementation SHOULD support the field as undistinguished octets. 1363 The codification of the range of allowed usage of this field is 1364 outside the scope of this specification. 1366 Implementations supporting this specification MUST use the 1367 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1368 determine the interpretation of the Value field. 1370 5. Compatibility with traditional RADIUS 1372 There are a number of potential compatibility issues with traditional 1373 RADIUS. This section describes them. 1375 5.1. Attribute Allocation 1377 Some vendors have used Attribute Type codes from the "Reserved" 1378 space, as part of vendor-defined dictionaries. This practice is 1379 considered anti-social behavior, as noted in [RFC6158]. These vendor 1380 definitions conflict with the attributes in the RADIUS Attribute Type 1381 space. The conflicting definitions may make it difficult for 1382 implementations to support both those Vendor Attributes, and the new 1383 Extended Attribute formats. 1385 We RECOMMEND that RADIUS client and server implementations delete all 1386 references to these improperly defined attributes. Failing that, we 1387 RECOMMEND that RADIUS server implementations have a per-client 1388 configurable flag which indicates which type of attributes are being 1389 sent from the client. If the flag is set one way, the conflicting 1390 attributes can be interpreted as being improperly defined Vendor 1391 Specific Attributes. If the flag is set the other way, the attributes 1392 MUST be interpreted as being of the Extended Attributes format. The 1393 default SHOULD be to interpret the attributes as being of the 1394 Extended Attributes format. 1396 Other methods of determining how to decode the attributes into a 1397 "correct" form are NOT RECOMMENDED. Those methods are likely to be 1398 fragile and prone to error. 1400 We RECOMMEND that RADIUS server implementations re-use the above flag 1401 to determine which type of attributes to send in a reply message. If 1402 the request is expected to contain the improperly defined attributes, 1403 the reply SHOULD NOT contain Extended Attributes. If the request is 1404 expected to contain Extended Attributes, the reply MUST NOT contain 1405 the improper Attributes. 1407 RADIUS clients will have fewer issues than servers. Clients MUST NOT 1408 send improperly defined Attributes in a request. For replies, 1409 clients MUST interpret attributes as being of the Extended Attributes 1410 format, instead of the improper definitions. These requirements 1411 impose no change in the RADIUS specifications, as such usage by 1412 vendors has always been in conflict with the standard requirements 1413 and the standards process. 1415 Existing clients that send these improperly defined attributes 1416 usually have a configuration setting which can disable this behavior. 1417 We RECOMMEND that vendors ship products with the default set to 1418 "disabled". We RECOMMEND that administrators set this flag to 1419 "disabled" on all equipment that they manage. 1421 5.2. Proxy Servers 1423 RADIUS Proxy servers will need to forward Attributes having the new 1424 format, even if they do not implement support for the encoding and 1425 decoding of those attributes. We remind implementors of the 1426 following text in [RFC2865] Section 2.3: 1428 The forwarding server MUST NOT change the order of any attributes 1429 of the same type, including Proxy-State. 1431 This requirement solves some of the issues related to proxying of the 1432 new format, but not all. The reason is that proxy servers are 1433 permitted to examine the contents of the packets that they forward. 1434 Many proxy implementations not only examine the attributes, but they 1435 refuse to forward attributes which they do not understand (i.e. 1436 attributes for which they have no local dictionary definitions). 1438 This practice is NOT RECOMMENDED. Proxy servers SHOULD forward 1439 attributes, even ones which they do not understand, or which are not 1440 in a local dictionary. When forwarded, these attributes SHOULD be 1441 sent verbatim, with no modifications or changes. The only exception 1442 to this recommendation is when local site policy dictates that 1443 filtering of attributes has to occur. For example, a filter at a 1444 visited network may require removal of certain authorization rules 1445 which apply to the home network, but not to the visited network. 1446 This filtering can sometimes be done even when the contents of the 1447 attributes are unknown, such as when all Vendor-Specific Attributes 1448 are designated for removal. 1450 As seen in [EDUROAM] many proxies do not follow these practices for 1451 unknown Attributes. Some proxies filter out unknown attributes or 1452 attributes which have unexpected lengths (24%, 17/70), some truncate 1453 the attributes to the "expected" length (11%, 8/70), some discard the 1454 request entirely (1%, 1/70), with the rest (63%, 44/70) following the 1455 recommended practice of passing the attributes verbatim. It will be 1456 difficult to widely use the Extended Attributes format until all non- 1457 conformant proxies are fixed. We therefore RECOMMEND that all 1458 proxies which do not support the Extended Attributes (241 through 1459 246) define them as being of data type "string", and delete all other 1460 local definitions for those attributes. 1462 This last change should enable wider usage of the Extended Attributes 1463 format. 1465 6. Guidelines 1467 This specification proposes a number of changes to RADIUS, and 1468 therefore requires a set of guidelines, as has been done in 1469 [RFC6158]. 1471 6.1. Updates to RFC 6158 1473 This specification updates [RFC6158] by adding the data types "evs", 1474 "tlv" and "integer64"; defining them to be "basic" data types; and 1475 permitting their use subject to the restrictions outlined below. 1477 All other recommendations given in [RFC6158] are unchanged. New 1478 recommendations for the use of the new data types and attribute 1479 formats are given below. 1481 6.2. Guidelines For the New Types 1483 We recommend the following guidelines when designing attributes using 1484 the new format. The items listed below are not exhaustive. As 1485 experience is gained with the new formats, later specifications may 1486 define additional guidelines. 1488 * The data type "evs" MUST NOT be used for standard RADIUS 1489 Attributes, or for TLVs, or for VSAs. 1491 * The data type "tlv" SHOULD NOT be used for standard RADIUS 1492 attributes. While its use is NOT RECOMMENDED by [RFC6158], this 1493 specification updates [RFC6158] to permit the "tlv" data type in 1494 attributes using the Extended-Type format. 1496 * [RFC2866] "tagged" attributes MUST NOT be defined in the 1497 Extended-Type space. The "tlv" data type should be used instead to 1498 group attributes. 1500 * The "integer64" data type MAY be used in any RADIUS attribute. 1501 The use of 64-bit integers is NOT RECOMMENDED by [RFC6158], but 1502 their utility is now evident. 1504 * For all other circumstances, the guidelines in [RFC6158] MUST 1505 be followed. 1507 6.3. Allocation Request Guidelines 1509 The following items give guidelines for allocation requests made in a 1510 RADIUS specification. 1512 * Discretion is RECOMMENDED when requesting allocation of attributes. 1513 The new space is much larger than the old one, but it is not 1514 infinite. 1516 * When the Type spaces of 241.*, 242.*, 243.*, or 244.* are nearing 1517 exhaustion, a new specification SHOULD be written which requests 1518 allocation of one or more RADIUS Attributes from the "Reserved" 1519 space, using the "Extended Type" format. This process is 1520 preferable to allocating "small" attributes from the 256.* and 1521 246.* Type spaces. 1523 * When the Type spaces of 245.* or 246.* are nearing exhaustion, a 1524 new specification SHOULD be written which requests allocation of 1525 one or more RADIUS Attributes from the "Reserved" space, using the 1526 "Extended Type with flags" format. 1528 * All other specifications SHOULD NOT request allocation from the 1529 standard Attribute Type Space (i.e. Attributes 1 through 255). 1530 That space is deprecated, and is not to be used. 1532 * Attributes which encode 252 octets or less of data SHOULD 1533 request allocation from the Type spaces of 241.*, 242.*, 243.*, 1534 or 244.*. 1536 * Attributes which encode 253 octets or more of data MUST request 1537 allocation from the Type spaces of 245.* or 246.*. 1539 6.4. TLV Guidelines 1541 The following items give guidelines for specifications using TLVs. 1543 * when multiple attributes are intended to be grouped or managed 1544 together, the use of TLVs to group related attributes is 1545 RECOMMENDED. 1547 * more than 4 layers (depth) of TLV nesting is NOT RECOMMENDED. 1549 * Interpretation of an attribute depends only on its type 1550 definition (e.g. Type.Extended-Type.TLV-Type, etc.), and 1551 not on its encoding or location in the RADIUS packet. 1553 * Where a group of TLVs is strictly defined, and not expected to 1554 change, and and totals less than 247 octets of data, they SHOULD 1555 request allocation from the Type spaces of 241.*, 242.*, 243.*, or 1556 244.*. 1558 * Where a group of TLVs is loosely defined, or is expected to change, 1559 they SHOULD request allocation from the Type spaces of 245.* or 1560 246.*. 1562 6.5. Implementation Guidelines 1564 * RADIUS client implementations SHOULD support this specification 1565 as soon as possible. 1567 * RADIUS server implementations SHOULD support this specification 1568 as soon as possible. 1570 * RADIUS proxy servers SHOULD forward all attributes, even ones 1571 which they do not understand, or which are not in a local 1572 dictionary. These attributes SHOULD be forwarded verbatim, with 1573 no modifications or changes. 1575 * Any attribute which is allocated from the Type spaces of 245.* or 1576 246.*, of data type "text", "string", or "tlv" can end up carrying 1577 more than 251 octets of data, up to the maximum RADIUS packet 1578 length (~4096 octets). Specifications defining such attributes 1579 SHOULD define a maximum length. 1581 6.6. Vendor Guidelines 1583 * Vendors SHOULD use the existing Vendor-Specific Attribute Type 1584 space in preference to the new Extended-Vendor-Specific 1585 attributes, as this specification may take time to become widely 1586 deployed. 1588 * Vendors SHOULD implement this specification as soon as 1589 possible. The changes to RADIUS are relatively small, and are 1590 likely to quickly be used in new specifications. 1592 7. Rationale 1594 The path to extending the RADIUS protocol has been long and arduous. 1595 A number of proposals have been made and discarded by the RADEXT 1596 working group. These proposals have been judged to be either too 1597 bulky, too complex, too simple, or to be unworkable in practice. We 1598 do not otherwise explain here why earlier proposals did not obtain 1599 working group consensus. 1601 The changes outlined here have the benefit of being simple, as the 1602 "Extended Type" format requires only a one octet change to the 1603 Attribute format. The downside is that the "Extended Type with 1604 Flags" format is awkward, and the 7 bits of Flags will likey never be 1605 used for anything. 1607 7.1. Attribute Audit 1609 An audit of almost five thousand publicly available attributes 1610 [ATTR], shows the statistics summarized below. The attributes include 1611 over 100 Vendor dictionaries, along with the IANA assigned 1612 attributes: 1614 Count Data Type 1615 ----- --------- 1616 2257 integer 1617 1762 text 1618 273 IPv4 Address 1619 225 string 1620 96 other data types 1621 35 IPv6 Address 1622 18 date 1623 10 integer64 1624 4 Interface Id 1625 3 IPv6 Prefix 1627 4683 Total 1629 The entries in the "Data Type" column are data types recommended by 1630 [RFC6158], along with "integer64". The "other data types" row 1631 encompasses other data types. 1633 Manual inspection of the dictionaries shows that approximately 20 (or 1634 0.5%) attributes have the ability to transport more than 253 octets 1635 of data. These attributes are divided between VSAs, and a small 1636 number of standard Attributes. While the "Extended Type with Flags" 1637 format is therefore important, "long" attributes have had limited 1638 deployment 1640 8. Examples 1642 A few examples are presented here, in order to illustrate the 1643 encoding of the new attribute formats. These examples are not 1644 intended to be exhaustive, as many others are possible. For 1645 simplicity, we do not show complete packets, only attributes. 1647 The examples are given using a domain-specific language implemented 1648 by the program given in Appendix A. The language is line oriented, 1649 and composed of a sequence of lines matching the grammar ([RFC5234]) 1650 given below: 1652 Identifier = 1*DIGIT *( "." 1*DIGIT ) 1654 HEXCHAR = HEXDIG HEXDIG 1655 STRING = DQUOTE 1*CHAR DQUOTE 1657 TLV = "{" 1*DIGIT DATA "}" 1659 DATA = 1*HEXCHAR / 1*TLV / STRING 1661 LINE = Identifier DATA 1663 The progam has additional restrictions on its input that are not 1664 reflected in the above grammar. For example, the portions of the 1665 Identifier which refer to Type and Extended-Type are limited to 1666 values between 1 and 255. We trust that the source code in Appendix 1667 A is clear, and that these restrictions do not negatively affect the 1668 comprehensability of the examples. 1670 The program reads the input text, and interprets it as a set of 1671 instructions to create RADIUS Attributes. It then prints the hex 1672 encoding of those attributes. It implements the minimum set of 1673 functionality which achieves that goal. This minimalism means that 1674 it does not use attribute dictionaries; it does not implement support 1675 for RADIUS data types; it can be used to encode attributes with 1676 invalid data field(s); and there is no requirement for consistency 1677 from one example to the next. For example, it can be used to encode 1678 a User-Name attribute which contains non-UTF8 data, or a Framed-IP- 1679 Address which contains 253 octets of ASCII data. As a result, it 1680 MUST NOT be used to create RADIUS Attributes for transport in a 1681 RADIUS message. 1683 However, the program correctly encodes the RADIUS attribute fields of 1684 "Type", "Length", "Extended-Type", "More", "Flags", "Vendor-Id", 1685 "Vendor-Type", and "Vendor-Length". It can therefore be used to 1686 encode example attributes from input which is humanly readable. 1688 We do not give examples of "malformed" or "invalid attributes". We 1689 also note that the examples show format, and not consistent meaning. 1690 A particular attribute type code may be used to demonstrate two 1691 different formats. In real specifications, attributes have a static 1692 definitions based on their type code. 1694 The examples given below are strictly for demonstration purposes 1695 only, and do not provide a standard of any kind. 1697 8.1. Extended Type 1699 The following are a series of examples of the "Extended Type" format. 1701 Attribute encapsulating textual data. 1703 241.1 "bob" 1704 -> f1 06 01 62 6f 62 1706 Attribute encapsulating a TLV with TLV-Type of one (1). 1708 241.2 { 1 23 45 } 1709 -> f1 07 02 01 04 23 45 1711 Attribute encapsulating two TLVs, one after the other. 1713 241.2 { 1 23 45 } { 2 67 89 } 1714 -> f1 0b 02 01 04 23 45 02 04 67 89 1716 Attribute encapsulating two TLVs, where the second TLV is itself 1717 encapsulating a TLV. 1719 241.2 { 1 23 45 } { 3 { 1 ab cd } } 1720 -> f1 0d 02 01 04 23 45 03 06 01 04 ab cd 1722 Attribute encapsulating two TLVs, where the second TLV is itself 1723 encapsulating two TLVs. 1725 241.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } 1726 -> f1 12 02 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f 1728 Attribute encapsulating a TLV, which in turn encapsulates a TLV, 1729 to a depth of 5 nestings. 1731 241.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } 1732 -> f1 0f 01 01 0c 02 0a 03 08 04 06 05 04 cd ef 1734 Attribute encapsulating an extended Vendor Specific attribute, 1735 with Vendor-Id of 1, and Vendor-Type of 4, which in turn 1736 encapsulates textual data. 1738 241.26.1.4 "test" 1739 -> f1 0c 1a 00 00 00 01 04 74 65 73 74 1741 Attribute encapsulating an extended Vendor Specific attribute, with 1742 Vendor-Id of 1, and Vendor-Type of 5, which in turn encapsulates 1743 a TLV with TLV-Type of 3, which encapsulates textual data. 1745 241.26.1.5 { 3 "test" } 1746 -> f1 0e 1a 00 00 00 01 05 03 06 74 65 73 74 1748 8.2. Extended Type with Flags 1750 The following are a series of examples of the "Extended Type with 1751 flags" format. 1753 Attribute encapsulating textual data. 1755 245.1 "bob" 1756 -> f5 07 01 00 62 6f 62 1758 Attribute encapsulating a TLV with TLV-Type of one (1). 1760 245.2 { 1 23 45 } 1761 -> f5 08 02 00 01 04 23 45 1763 Attribute encapsulating two TLVs, one after the other. 1765 245.2 { 1 23 45 } { 2 67 89 } 1766 -> f5 0c 02 00 01 04 23 45 02 04 67 89 1768 Attribute encapsulating two TLVs, where the second TLV is itself 1769 encapsulating a TLV. 1771 245.2 { 1 23 45 } { 3 { 1 ab cd } } 1772 -> f5 0e 02 00 01 04 23 45 03 06 01 04 ab cd 1774 Attribute encapsulating two TLVs, where the second TLV is itself 1775 encapsulating two TLVs. 1777 245.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } 1778 -> f5 13 02 00 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f 1780 Attribute encapsulating a TLV, which in turn encapsulates a TLV, 1781 to a depth of 5 nestings. 1783 245.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } 1784 -> f5 10 01 00 01 0c 02 0a 03 08 04 06 05 04 cd ef 1786 Attribute encapsulating an extended Vendor Specific attribute, 1787 with Vendor-Id of 1, and Vendor-Type of 4, which in turn 1788 encapsulates textual data. 1790 245.26.1.4 "test" 1791 -> f5 0d 1a 00 00 00 00 01 04 74 65 73 74 1793 Attribute encapsulating an extended Vendor Specific attribute, 1794 with Vendor-Id of 1, and Vendor-Type of 5, which in turn 1795 encapsulates a TLV with TLV-Type of 3, which encapsulates 1796 textual data. 1798 245.26.1.5 { 3 "test" } 1799 -> f5 0f 1a 00 00 00 00 01 05 03 06 74 65 73 74 1801 Attribute encapsulating more than 251 octets of data. The "Data" 1802 portions are indented for readability. 1804 245.4 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1805 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1806 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1807 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1808 aaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1809 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1810 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1811 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1812 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbcccccccccccccccccccc 1813 cccccccccc 1814 -> f5 ff 04 80 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1815 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1816 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1817 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1818 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1819 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1820 aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb bb bb bb bb bb 1821 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1822 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1823 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1824 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1825 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1826 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 13 04 00 cc 1827 cc cc cc cc cc cc cc cc cc cc cc cc cc cc 1829 Attribute encapsulating an extended Vendor Specific attribute, 1830 with Vendor-Id of 1, and Vendor-Type of 6, which in turn 1831 encapsulates more than 251 octets of data. 1833 As the VSA encapsulates more than 251 octets of data, it is 1834 split into two RADIUS attributes. The first attribute has the 1835 More flag set, and carries the Vendor-Id and Vendor-Type. 1836 The second attribute has the More flag clear, and carries 1837 the rest of the data portion of the VSA. Note that the second 1838 attribute does not include the Vendor-Id ad Vendor-Type fields. 1840 The "Data" portions are indented for readability. 1842 245.26.1.6 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1843 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1844 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1845 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1846 aaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1847 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1848 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1849 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1850 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbccccccccccccc 1851 ccccccccccccccccc 1852 -> f5 ff 1a 80 00 00 00 01 06 aa aa aa aa aa aa aa aa aa aa aa 1853 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1854 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1855 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1856 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1857 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1858 aa aa aa aa aa aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb 1859 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1860 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1861 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1862 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1863 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1864 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 17 1a 00 bb 1865 bb bb bb bb cc cc cc cc cc cc cc cc cc cc 13 45 67 89 1867 9. IANA Considerations 1869 This document updates [RFC3575] in that it adds new IANA 1870 considerations for RADIUS Attributes. These considerations extend 1871 the IANA considerations for RADIUS, rather than replacing them. 1872 Specifically, assignment of Attribute Type values 241-255 requires 1873 Standards Action, and allocation of values for existing attributes is 1874 done by the process given in [RFC3575]. 1876 The IANA considerations of this document are limited to the "RADIUS 1877 Attribute Types" registry. Attribute Type values which were 1878 previously marked reserved are now allocated, Attribute Type values 1879 previously marked unassigned are now deprecated, and the registry is 1880 extended from a simple 8-bit array to a tree-like structure, up to a 1881 maximum depth of 125 nodes. Detailed recommendations are given 1882 below. 1884 9.1. Attribute Allocations 1886 IANA is requested to move the "Unassigned" values in the range 1887 144-191 from "Unassigned" to "Deprecated". Allocation from the 1888 "Deprecated" space can still be performed by publication of an IETF 1889 specification, subject to the recommendations of {RFC3575], and where 1890 that specification requests allocation from the "Deprecated" space, 1891 and also gives reasons why use of the Extended Type space is 1892 impossible. 1894 IANA is requested to move the following values from "Reserved", to 1895 "Allocated", with the following names: 1897 * 241 Extended-Type-1 1898 * 242 Extended-Type-2 1899 * 243 Extended-Type-3 1900 * 244 Extended-Type-4 1901 * 245 Extended-Type-Flagged-1 1902 * 246 Extended-Type-Flagged-2 1904 These values serve as an encapsulation layer for the new RADIUS 1905 Attribute Type tree. 1907 9.2. RADIUS Attribute Type Tree 1909 Each of the Attribute Type values allocated above extends the "RADIUS 1910 Attribute Types" to an N-ary tree, via a "dotted number" notation. 1911 Allocation of an Attribute Type value "VALUE" using the new Extended 1912 type format results in allocation of 255 new Attribute Type values, 1913 of format "VALUE.1" through "VALUE.255". The value zero "VALUE.0" is 1914 not used. Value twenty-six (26) is assigned as "Vendor Specific". 1915 Values 241-255 are marked "Reserved". All other values are 1916 "Unassigned". 1918 The initial set of Attribute Type values and names assigned by this 1919 document is given below. 1921 * 241 Extended-Attribute-1 1922 * 241.{1-25} Unassigned 1923 * 241.26 Extended-Vendor-Specific-1 1924 * 241.{27-240} Unassigned 1925 * 241.{241-255} Reserved 1926 * 242 Extended-Attribute-2 1927 * 242.{1-25} Unassigned 1928 * 242.26 Extended-Vendor-Specific-2 1929 * 242.{27-240} Unassigned 1930 * 243 Extended-Attribute-3 1931 * 242.{241-255} Reserved 1932 * 243.{1-25} Unassigned 1933 * 243.26 Extended-Vendor-Specific-3 1934 * 243.{27-240} Unassigned 1935 * 243.{241-255} Reserved 1936 * 244 Extended-Attribute-4 1937 * 244.{1-25} Unassigned 1938 * 244.26 Extended-Vendor-Specific-4 1939 * 244.{27-240} Unassigned 1940 * 244.{241-255} Reserved 1941 * 245 Extended-Attribute-5 1942 * 245.{1-25} Unassigned 1943 * 245.26 Extended-Vendor-Specific-5 1944 * 245.{27-240} Unassigned 1945 * 245.{241-255} Reserved 1946 * 246 Extended-Attribute-6 1947 * 246.{1-25} Unassigned 1948 * 245.26 Extended-Vendor-Specific-6 1949 * 246.{27-240} Unassigned 1950 * 246.{241-255} Reserved 1952 The values marked "Unassigned" above are available for assignment by 1953 IANA in future RADIUS specifications. The values marked "Reserved" 1954 are reserved for future use. 1956 9.3. Allocation of TLV Data Types 1958 When specifications request allocation of an attribute of data type 1959 "tlv", that allocation extends the Attribute Type Tree by one more 1960 level. Allocation of an Attribute Type value "TYPE.TLV", with Data 1961 Type TLV, results in allocation of 255 new Attribute Type values, of 1962 format "TYPE.TLV.1" through "TYPE.TLV.255". The value zero "VALUE.0" 1963 is not used. Values 254-255 are marked "Reserved". All other values 1964 are "Unassigned". 1966 For example, if a new attribute "Example-TLV" of data type "tlv" is 1967 assigned the identifier "245.1", then the extended tree will be 1968 allocation as below: 1970 * 245.1 Example-TLV 1971 * 245.1.{1-253} Unassigned 1972 * 245.1.{254-255} Reserved 1974 Note that this example does not define an "Example-TLV" attribute. 1976 The Attribute Type Tree can be extended multiple levels in one 1977 specification when the specification requests allocation of nested 1978 TLVs, as discussed below. 1980 9.4. Allocation within a TLV 1982 Specifications can request allocation of Attribute Type values within 1983 an Attribute of Data Type TLV. The encapsulating TLV can be 1984 allocated in the same specification, or it can have been previously 1985 allocated. 1987 Specifications need to request allocation within a specific Attribute 1988 Type value (e.g. "TYPE.TLV.*"). Allocations are performed from the 1989 smallest Unassigned value, proceeding to the largest Unassigned 1990 value. 1992 Where the Attribute being allocated is of Data Type TLV, the 1993 Attribute Type tree is extended by one level, as given in the 1994 previous section. Allocations can then be made within that level. 1996 9.5. Allocation of Extended Type with Flags format 1998 Specifications can request allocation of an Attribute which requires 1999 the format Extended Type with Flags. In that case, IANA should 2000 assign the lowest Unassigned number from the 245.* or 246.* Attribute 2001 Type space. If those spaces are full, the specification should 2002 explicitly request allocation from an Attribute Type space of the 2003 relevant format. 2005 9.6. Allocation of Other Data Types 2007 Attribute Type value allocations are otherwise allocated from the 2008 smallest Unassigned value, starting from 241.1, proceeding through 2009 241.255, then to 242.1, through 242.255, etc. 2011 10. Security Considerations 2013 This document defines new formats for data carried inside of RADIUS, 2014 but otherwise makes no changes to the security of the RADIUS 2015 protocol. 2017 Attacks on cryptographic hashes are well known, and are getting 2018 better with time, as discussed in[RFC4270]. RADIUS uses the MD5 hash 2019 [RFC1321] for packet authentication and attribute obfuscation. There 2020 are ongoing efforts in the IETF to analyze and address these issues 2021 for the RADIUS protocol. 2023 As with any protocol change, code changes are required in order to 2024 implement the new features. These code changes have the potential to 2025 introduce new vulnerabilities in the software. Since the RADIUS 2026 server performs network authentication, it is an inviting target for 2027 attackers. We RECOMMEND that access to RADIUS servers be kept to a 2028 minimum. 2030 11. References 2031 11.1. Normative references 2033 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2034 Requirement Levels", RFC 2119, March, 1997. 2036 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 2037 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2038 2000. 2040 11.2. Informative references 2042 [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, 2043 April, 1992 2045 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 2047 [RFC2868] Zorn, G., et al, " RADIUS Attributes for Tunnel Protocol 2048 Support", RFC 2868, June 2000. 2050 [RFC3575] Aboba, B, "IANA Considerations for RADIUS (Remote 2051 Authentication Dial In User Service)", RFC 3575, July 2003. 2053 [RFC4270] Hoffman, P, and Schneier, B, "Attacks on Cryptographic Hashes 2054 in Internet Protocols", RFC 4270, November 2005. 2056 [RFC5234] Crocker, D. (Ed.), and Overell, P., "Augmented BNF for Syntax 2057 Specifications: ABNF", RFC 5234, October 2005. 2059 [RFC6158] DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC 2060 6158, March 2011. 2062 [EDUROAM] Internal Eduroam testing page, data retrieved 04 August 2010. 2064 [ATTR] http://github.com/alandekok/freeradius- 2065 server/tree/master/share/, data retrieved September 2010. 2067 Acknowledgments 2069 This document is the result of long discussions in the IETF RADEXT 2070 working group. The authors would like to thank all of the 2071 participants who contributed various ideas over the years. Their 2072 feedback has been invaluable, and has helped to make this 2073 specification better. 2075 Appendix A - Extended Attribute Generator Program 2077 This section contains "C" program source which can be used for 2078 testing. It reads a line-oriented text file, parses it to create 2079 RADIUS formatted attributes, and prints the hex version of those 2080 attributes to standard output. 2082 The input accepts a grammar similar to that given in Section 8, with 2083 some modifications for usability. For example, blank lines are 2084 allowed, lines beginning with a '#' character are interpreted as 2085 comments, numbers (RADIUS Types, etc.) are checked for minimum / 2086 maximum values, and RADIUS Attribute lengths are enforced. 2088 The program is included here for demonstration purposes only, and 2089 does not define a standard of any kind. 2091 ------------------------------------------------------------ 2092 /* 2093 * Copyright (c) 2010 IETF Trust and the persons identified as 2094 * authors of the code. All rights reserved. 2095 * 2096 * Redistribution and use in source and binary forms, with or without 2097 * modification, are permitted provided that the following conditions 2098 * are met: 2099 * 2100 * Redistributions of source code must retain the above copyright 2101 * notice, this list of conditions and the following disclaimer. 2102 * 2103 * Redistributions in binary form must reproduce the above copyright 2104 * notice, this list of conditions and the following disclaimer in 2105 * the documentation and/or other materials provided with the 2106 * distribution. 2107 * 2108 * Neither the name of Internet Society, IETF or IETF Trust, nor the 2109 * names of specific contributors, may be used to endorse or promote 2110 * products derived from this software without specific prior written 2111 * permission. 2112 * 2113 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 2114 * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, 2115 * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 2116 * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 2117 * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS 2118 * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 2119 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED 2120 * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 2121 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON 2122 * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 2123 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT 2124 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 2125 * SUCH DAMAGE. 2126 * 2127 * Author: Alan DeKok 2128 */ 2129 #include 2130 #include 2131 #include 2132 #include 2133 #include 2134 #include 2136 static int encode_tlv(char *buffer, uint8_t *output, size_t outlen); 2138 static const char *hextab = "0123456789abcdef"; 2140 static int encode_data_string(char *buffer, 2141 uint8_t *output, size_t outlen) 2142 { 2143 int length = 0; 2144 char *p; 2146 p = buffer + 1; 2148 while (*p && (outlen > 0)) { 2149 if (*p == '"') { 2150 return length; 2151 } 2153 if (*p != '\\') { 2154 *(output++) = *(p++); 2155 outlen--; 2156 length++; 2157 continue; 2158 } 2160 switch (p[1]) { 2161 default: 2162 *(output++) = p[1]; 2163 break; 2165 case 'n': 2166 *(output++) = '\n'; 2167 break; 2169 case 'r': 2170 *(output++) = '\r'; 2171 break; 2173 case 't': 2174 *(output++) = '\t'; 2175 break; 2176 } 2178 outlen--; 2179 length++; 2180 } 2182 fprintf(stderr, "String is not terminated\n"); 2183 return 0; 2184 } 2186 static int encode_data_tlv(char *buffer, char **endptr, 2187 uint8_t *output, size_t outlen) 2188 { 2189 int depth = 0; 2190 int length; 2191 char *p; 2193 for (p = buffer; *p != '\0'; p++) { 2194 if (*p == '{') depth++; 2195 if (*p == '}') { 2196 depth--; 2197 if (depth == 0) break; 2198 } 2199 } 2201 if (*p != '}') { 2202 fprintf(stderr, "No trailing '}' in string starting " 2203 "with \"%s\"\n", 2204 buffer); 2205 return 0; 2206 } 2208 *endptr = p + 1; 2209 *p = '\0'; 2211 p = buffer + 1; 2212 while (isspace((int) *p)) p++; 2214 length = encode_tlv(p, output, outlen); 2215 if (length == 0) return 0; 2217 return length; 2218 } 2219 static int encode_data(char *p, uint8_t *output, size_t outlen) 2220 { 2221 int length; 2223 if (!isspace((int) *p)) { 2224 fprintf(stderr, "Invalid character following attribute " 2225 "definition\n"); 2226 return 0; 2227 } 2229 while (isspace((int) *p)) p++; 2231 if (*p == '{') { 2232 int sublen; 2233 char *q; 2235 length = 0; 2237 do { 2238 while (isspace((int) *p)) p++; 2239 if (!*p) { 2240 if (length == 0) { 2241 fprintf(stderr, "No data\n"); 2242 return 0; 2243 } 2245 break; 2246 } 2248 sublen = encode_data_tlv(p, &q, output, outlen); 2249 if (sublen == 0) return 0; 2251 length += sublen; 2252 output += sublen; 2253 outlen -= sublen; 2254 p = q; 2255 } while (*q); 2257 return length; 2258 } 2260 if (*p == '"') { 2261 length = encode_data_string(p, output, outlen); 2262 return length; 2263 } 2265 length = 0; 2266 while (*p) { 2267 char *c1, *c2; 2269 while (isspace((int) *p)) p++; 2271 if (!*p) break; 2273 if(!(c1 = memchr(hextab, tolower((int) p[0]), 16)) || 2274 !(c2 = memchr(hextab, tolower((int) p[1]), 16))) { 2275 fprintf(stderr, "Invalid data starting at " 2276 "\"%s\"\n", p); 2277 return 0; 2278 } 2280 *output = ((c1 - hextab) << 4) + (c2 - hextab); 2281 output++; 2282 length++; 2283 p += 2; 2285 outlen--; 2286 if (outlen == 0) { 2287 fprintf(stderr, "Too much data\n"); 2288 return 0; 2289 } 2290 } 2292 if (length == 0) { 2293 fprintf(stderr, "Empty string\n"); 2294 return 0; 2295 } 2297 return length; 2298 } 2300 static int decode_attr(char *buffer, char **endptr) 2301 { 2302 long attr; 2304 attr = strtol(buffer, endptr, 10); 2305 if (*endptr == buffer) { 2306 fprintf(stderr, "No valid number found in string " 2307 "starting with \"%s\"\n", buffer); 2308 return 0; 2309 } 2311 if (!**endptr) { 2312 fprintf(stderr, "Nothing follows attribute number\n"); 2313 return 0; 2314 } 2315 if ((attr <= 0) || (attr > 256)) { 2316 fprintf(stderr, "Attribute number is out of valid " 2317 "range\n"); 2318 return 0; 2319 } 2321 return (int) attr; 2322 } 2324 static int decode_vendor(char *buffer, char **endptr) 2325 { 2326 long vendor; 2328 if (*buffer != '.') { 2329 fprintf(stderr, "Invalid separator before vendor id\n"); 2330 return 0; 2331 } 2333 vendor = strtol(buffer + 1, endptr, 10); 2334 if (*endptr == (buffer + 1)) { 2335 fprintf(stderr, "No valid vendor number found\n"); 2336 return 0; 2337 } 2339 if (!**endptr) { 2340 fprintf(stderr, "Nothing follows vendor number\n"); 2341 return 0; 2342 } 2344 if ((vendor <= 0) || (vendor > (1 << 24))) { 2345 fprintf(stderr, "Vendor number is out of valid range\n"); 2346 return 0; 2347 } 2349 if (**endptr != '.') { 2350 fprintf(stderr, "Invalid data following vendor number\n"); 2351 return 0; 2352 } 2353 (*endptr)++; 2355 return (int) vendor; 2356 } 2358 static int encode_tlv(char *buffer, uint8_t *output, size_t outlen) 2359 { 2360 int attr; 2361 int length; 2362 char *p; 2363 attr = decode_attr(buffer, &p); 2364 if (attr == 0) return 0; 2366 output[0] = attr; 2367 output[1] = 2; 2369 if (*p == '.') { 2370 p++; 2371 length = encode_tlv(p, output + 2, outlen - 2); 2373 } else { 2374 length = encode_data(p, output + 2, outlen - 2); 2375 } 2377 if (length == 0) return 0; 2378 if (length > (255 - 2)) { 2379 fprintf(stderr, "TLV data is too long\n"); 2380 return 0; 2381 } 2383 output[1] += length; 2385 return length + 2; 2386 } 2388 static int encode_vsa(char *buffer, uint8_t *output, size_t outlen) 2389 { 2390 int vendor; 2391 int attr; 2392 int length; 2393 char *p; 2395 vendor = decode_vendor(buffer, &p); 2396 if (vendor == 0) return 0; 2398 output[0] = 0; 2399 output[1] = (vendor >> 16) & 0xff; 2400 output[2] = (vendor >> 8) & 0xff; 2401 output[3] = vendor & 0xff; 2403 length = encode_tlv(p, output + 4, outlen - 4); 2404 if (length == 0) return 0; 2405 if (length > (255 - 6)) { 2406 fprintf(stderr, "VSA data is too long\n"); 2407 return 0; 2408 } 2409 return length + 4; 2410 } 2412 static int encode_evs(char *buffer, uint8_t *output, size_t outlen) 2413 { 2414 int vendor; 2415 int attr; 2416 int length; 2417 char *p; 2419 vendor = decode_vendor(buffer, &p); 2420 if (vendor == 0) return 0; 2422 attr = decode_attr(p, &p); 2423 if (attr == 0) return 0; 2425 output[0] = 0; 2426 output[1] = (vendor >> 16) & 0xff; 2427 output[2] = (vendor >> 8) & 0xff; 2428 output[3] = vendor & 0xff; 2429 output[4] = attr; 2431 length = encode_data(p, output + 5, outlen - 5); 2432 if (length == 0) return 0; 2434 return length + 5; 2435 } 2437 static int encode_extended(char *buffer, 2438 uint8_t *output, size_t outlen) 2439 { 2440 int attr; 2441 int length; 2442 char *p; 2444 attr = decode_attr(buffer, &p); 2445 if (attr == 0) return 0; 2447 output[0] = attr; 2449 if (attr == 26) { 2450 length = encode_evs(p, output + 1, outlen - 1); 2451 } else { 2452 length = encode_data(p, output + 1, outlen - 1); 2453 } 2454 if (length == 0) return 0; 2455 if (length > (255 - 3)) { 2456 fprintf(stderr, "Extended Attr data is too long\n"); 2457 return 0; 2458 } 2460 return length + 1; 2461 } 2463 static int encode_extended_flags(char *buffer, 2464 uint8_t *output, size_t outlen) 2465 { 2466 int attr; 2467 int length, total; 2468 char *p; 2470 attr = decode_attr(buffer, &p); 2471 if (attr == 0) return 0; 2473 /* output[0] is the extended attribute */ 2474 output[1] = 4; 2475 output[2] = attr; 2476 output[3] = 0; 2478 if (attr == 26) { 2479 length = encode_evs(p, output + 4, outlen - 4); 2480 if (length == 0) return 0; 2482 output[1] += 5; 2483 length -= 5; 2484 } else { 2485 length = encode_data(p, output + 4, outlen - 4); 2486 } 2487 if (length == 0) return 0; 2489 total = 0; 2490 while (1) { 2491 int sublen = 255 - output[1]; 2493 if (length <= sublen) { 2494 output[1] += length; 2495 total += output[1]; 2496 break; 2497 } 2499 length -= sublen; 2501 memmove(output + 255 + 4, output + 255, length); 2502 memcpy(output + 255, output, 4); 2504 output[1] = 255; 2505 output[3] |= 0x80; 2507 output += 255; 2508 output[1] = 4; 2509 total += 255; 2510 } 2512 return total; 2513 } 2515 static int encode_rfc(char *buffer, uint8_t *output, size_t outlen) 2516 { 2517 int attr; 2518 int length, sublen; 2519 char *p; 2521 attr = decode_attr(buffer, &p); 2522 if (attr == 0) return 0; 2524 length = 2; 2525 output[0] = attr; 2526 output[1] = 2; 2528 if (attr == 26) { 2529 sublen = encode_vsa(p, output + 2, outlen - 2); 2531 } else if ((*p == ' ') || ((attr < 241) || (attr > 246))) { 2532 sublen = encode_data(p, output + 2, outlen - 2); 2534 } else { 2535 if (*p != '.') { 2536 fprintf(stderr, "Invalid data following " 2537 "attribute number\n"); 2538 return 0; 2539 } 2541 if (attr < 245) { 2542 sublen = encode_extended(p + 1, 2543 output + 2, outlen - 2); 2544 } else { 2546 /* 2547 * Not like the others! 2548 */ 2549 return encode_extended_flags(p + 1, output, outlen); 2550 } 2551 } 2552 if (sublen == 0) return 0; 2553 if (sublen > (255 -2)) { 2554 fprintf(stderr, "RFC Data is too long\n"); 2555 return 0; 2556 } 2558 output[1] += sublen; 2559 return length + sublen; 2560 } 2562 int main(int argc, char *argv[]) 2563 { 2564 int lineno; 2565 size_t i, outlen; 2566 FILE *fp; 2567 char input[8192], buffer[8192]; 2568 uint8_t output[4096]; 2570 if ((argc < 2) || (strcmp(argv[1], "-") == 0)) { 2571 fp = stdin; 2572 } else { 2573 fp = fopen(argv[1], "r"); 2574 if (!fp) { 2575 fprintf(stderr, "Error opening %s: %s\n", 2576 argv[1], strerror(errno)); 2577 exit(1); 2578 } 2579 } 2581 lineno = 0; 2582 while (fgets(buffer, sizeof(buffer), fp) != NULL) { 2583 char *p = strchr(buffer, '\n'); 2585 lineno++; 2587 if (!p) { 2588 if (!feof(fp)) { 2589 fprintf(stderr, "Line %d too long in %s\n", 2590 lineno, argv[1]); 2591 exit(1); 2592 } 2593 } else { 2594 *p = '\0'; 2595 } 2597 p = strchr(buffer, '#'); 2598 if (p) *p = '\0'; 2600 p = buffer; 2601 while (isspace((int) *p)) p++; 2602 if (!*p) continue; 2604 strcpy(input, p); 2605 outlen = encode_rfc(input, output, sizeof(output)); 2606 if (outlen == 0) { 2607 fprintf(stderr, "Parse error in line %d of %s\n", 2608 lineno, input); 2609 exit(1); 2610 } 2612 printf("%s -> ", buffer); 2613 for (i = 0; i < outlen; i++) { 2614 printf("%02x ", output[i]); 2615 } 2616 printf("\n"); 2617 } 2619 if (fp != stdin) fclose(fp); 2621 return 0; 2622 } 2623 ------------------------------------------------------------ 2625 Author's Address 2627 Alan DeKok 2628 Network RADIUS SARL 2629 15 av du Granier 2630 38240 Meylan 2631 France 2633 Email: aland@networkradius.com 2634 URI: http://networkradius.com 2636 Avi Lior 2637 Bridgewater Systems Corporation 2638 303 Terry Fox Drive 2639 Suite 100 2640 Ottawa, Ontario K2K 3J1 2641 Canada 2643 Phone: +1 (613) 591-6655 2644 Email: avi@bridgewatersystems.com 2645 URI: http://www.bridgewatersystems.com/