idnits 2.17.1 draft-ietf-radext-radius-extensions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC2865, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2866, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5176, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (Using the creation date from RFC2865, updated by this document, for RFC5378 checks: 1999-03-04) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (27 February 2011) is 4807 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 2507 -- Looks like a reference, but probably isn't: '0' on line 2442 -- Looks like a reference, but probably isn't: '2' on line 2392 -- Looks like a reference, but probably isn't: '3' on line 2422 -- Looks like a reference, but probably isn't: '4' on line 2346 -- Looks like a reference, but probably isn't: '8192' on line 2484 -- Looks like a reference, but probably isn't: '4096' on line 2485 == Unused Reference: 'RFC5176' is defined on line 1968, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1321 == Outdated reference: A later version (-19) exists of draft-ietf-radext-design-18 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Alan DeKok 3 INTERNET-DRAFT Network RADIUS 4 Category: Proposed Standard Avi Lior 5 Updates: 2865, 2866, 5176 BWS 6 7 Expires: August 27, 2011 8 27 February 2011 10 Remote Authentication Dial In User Service (RADIUS) Protocol 11 Extensions 12 draft-ietf-radext-radius-extensions-00.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 March 1, 2011. 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 ..................................... 7 66 2.1. Extended Type ....................................... 7 67 2.2. Extended Type with Flags ............................ 8 68 2.3. TLV Data Type ....................................... 10 69 2.3.1. TLV Nesting .................................... 12 70 2.4. EVS Data Type ....................................... 12 71 2.5. Attribute Naming and Type Identifiers ............... 14 72 2.5.1. Attribute and TLV Naming ....................... 14 73 2.5.2. Attribute Type Identifiers ..................... 14 74 2.5.3. TLV Identifiers ................................ 15 75 2.5.4. VSA Identifiers ................................ 15 76 3. Attribute Definitions .................................... 16 77 3.1. Extended-Type-1 ..................................... 16 78 3.2. Extended-Type-2 ..................................... 17 79 3.3. Extended-Type-3 ..................................... 18 80 3.4. Extended-Type-4 ..................................... 19 81 3.5. Extended-Type-Flagged-1 ............................. 20 82 3.6. Extended-Type-Flagged-2 ............................. 21 83 4. Vendor Specific Attributes ............................... 22 84 4.1. Extended-Vendor-Specific-1 .......................... 22 85 4.2. Extended-Vendor-Specific-2 .......................... 24 86 4.3. Extended-Vendor-Specific-3 .......................... 25 87 4.4. Extended-Vendor-Specific-4 .......................... 26 88 4.5. Extended-Vendor-Specific-5 .......................... 27 89 4.6. Extended-Vendor-Specific-6 .......................... 28 90 5. Compatibility with traditional RADIUS .................... 30 91 5.1. Attribute Allocation ................................ 30 92 5.2. Proxy Servers ....................................... 31 93 6. Guidelines ............................................... 32 94 6.1. Allocation Request Guidelines ....................... 32 95 6.2. TLV Guidelines ...................................... 33 96 6.3. Implementation Guidelines ........................... 33 97 6.4. Vendor Guidelines ................................... 34 98 7. Rationale ................................................ 34 99 7.1. Attribute Audit ..................................... 34 100 8. Examples ................................................. 35 101 8.1. Extended Type ....................................... 36 102 8.2. Extended Type with Flags ............................ 37 103 9. IANA Considerations ...................................... 39 104 9.1. Attribute Allocations ............................... 40 105 9.2. RADIUS Attribute Type Tree .......................... 40 106 9.3. Assignment Policy ................................... 41 107 9.4. Extending the Attribute Type Tree ................... 41 108 9.5. Extending the RADIUS Attribute Type Space ........... 42 109 10. Security Considerations ................................. 43 110 11. References .............................................. 43 111 11.1. Normative references ............................... 43 112 11.2. Informative references ............................. 43 113 Appendix A - Extended Attribute Generator Program ............ 45 114 1. Introduction 116 Under current allocation pressure, we expect that the RADIUS 117 Attribute Type space will be exhausted by 2014 or 2015. We therefore 118 need a way to extend the type space, so that new specifications may 119 continue to be developed. Other issues have also been shown with 120 RADIUS. The attribute grouping method defined in [RFC2868] has been 121 shown to be imnpractical, and a more powerful mechanism is needed. 122 Multiple attributes have been defined which transport more than the 123 253 octets of data originally envisioned with the protocol. Each of 124 these attributes is handled as a "special case" inside of RADIUS 125 implementations, instead of as a general method. We therefore also 126 need a standardized method of transporting large quantities of data. 127 Finally, some vendors are close to allocating all of the Attributes 128 within their Vendor-Specific Attribute space. It would be useful to 129 leverage changes to the base protocol for extending the Vendor- 130 Specific Attribute space. 132 We satisfy all of these requirements through the following 133 modifications to RADIUS: 135 * defining an "Extended Type" format, which adds 8 bits of "Extended 136 Type" to the RADIUS Attribute Type space, by using one octet of the 137 "Value" field. This method gives us a general way of extending 138 the Attribute Type Space. 140 * allocating 4 attributes as using the format of "Extended Type". 141 This allocation extends the RADIUS Attribute Type Space by 142 approximately 1000 values. 144 * defining an "Extended Type with Flags" format, which inserts 145 an additional "Flags" octet between the "Extended Type" octet, 146 and the "Value" field. This method gives us a general way of 147 adding additional functionality to the protocol. 149 * defining method which uses the "Flags" field to indicate data 150 fragmentation across multiple Attributes. This method provides a 151 standard way for an Attribute to carry more than 253 octets of 152 data. 154 * allocating 2 attributes as using the format of "Extended Type with 155 Flags". This allocation extends the RADIUS Attribute Type Space 156 by an additional 500 values. 158 * defining a new "Type Length Value" (TLV) data type. The data type 159 allows an attribute to carry TLVs as "sub-attributes", which can in 160 turn encapsulate other TLVs as "sub-sub-attributes." This change 161 creates a standard way to group a set of Attributes. 163 * defining a new "extended Vendor-Specific" (EVS) data type. The 164 data type allows an attribute to carry Vendor-Specific Attributes 165 (VSAs) inside of the new attribute formats. 167 * allocating 6 attributes using the new EVS data type. This 168 allocation extends the Vendor-Specific Attribute type space by 169 over 1500 values. 171 As with any protocol change, the changes defined here are the result 172 of a series of compromises. We have tried to find a balance between 173 flexibility, space in the RADIUS message, compatibility with existing 174 deployments, and implementation difficulty. 176 1.1. Terminology 178 This document uses the following terms: 180 silently discard 181 This means the implementation discards the packet without further 182 processing. The implementation MAY provide the capability of 183 logging the error, including the contents of the silently discarded 184 packet, and SHOULD record the event in a statistics counter. 186 invalid attribute 187 This means that the Length field of an Attribute is valid (as per 188 [RFC2865], Section 5, top of page 25). However, the Value field of 189 the attribute does not follow the format required by the data type 190 defined for that Attribute. e.g. an Attribute of type "address" 191 which encapsulates more than four, or less than four, octets of 192 data. 194 1.2. Requirements Language 196 In this document, several words are used to signify the requirements 197 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 198 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 199 and "OPTIONAL" in this document are to be interpreted as described in 200 [RFC2119]. 202 An implementation is not compliant if it fails to satisfy one or more 203 of the must or must not requirements for the protocols it implements. 204 An implementation that satisfies all the MUST, MUST NOT, SHOULD, and 205 SHOULD NOT requirements for its protocols is said to be 206 "unconditionally compliant"; one that satisfies all the MUST and MUST 207 NOT requirements but not all the SHOULD or SHOULD NOT requirements 208 for its protocols is said to be "conditionally compliant". 210 2. Extensions to RADIUS 212 This section defines two new attribute formats; "Extended Type"; and 213 "Extended Type with Flags". The formats are defined below. 215 2.1. Extended Type 217 This section defines a new attribute format, called "Extended Type". 218 A summary of the Attribute format is shown below. The fields are 219 transmitted from left to right. 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Type | Length | Extended-Type | Value ... 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Type 229 This field is identical to the Type field of the Attribute format 230 defined in [RFC2865] Section 5. 232 Length 234 This field is identical to the Length field of the Attribute 235 format defined in [RFC2865] Section 5. Permitted values are 236 between 4 and 255. If a client or server receives an Extended 237 Attribute with a Length of 2 or 3, then that Attribute MUST be 238 deemed to be an "invalid attribute", it SHOULD be silently 239 discarded. If it is not discarded, it MUST NOT be handled in the 240 same manner as a well-formed attribute. 242 Note that an "invalid attribute" does not cause the entire packet 243 to be discarded, or to be treated as a negative acknowledgement. 244 Instead, only the "invalid attribute" is discarded. 246 Extended-Type 248 The Extended-Type field is one octet. Up-to-date values of this 249 field are specified by IANA. Unlike the Type field defined in 250 [RFC2865] Section 5, no values are allocated for experimental or 251 implementation-specific use. Values 241-255 are reserved and 252 SHOULD NOT be used. 254 The Extended-Type is meaningful only within a context defined by 255 the Type field. That is, this field may be thought of as defining 256 a new type space of the form "Type.Extended-Type". See Section 257 2.5, below, for additional discussion. 259 A RADIUS server MAY ignore Attributes with an unknown 260 "Type.Extended-Type". 262 A RADIUS client MAY ignore Attributes with an unknown 263 "Type.Extended-Type". 265 Value 267 This field is similar to the Value field of the Attribute format 268 defined in [RFC2865] Section 5. The format of the data SHOULD be 269 a valid RADIUS data type. 271 The addition of the Extended-Type field decreases the maximum 272 length for attributes of type "text" or "string" from 253 to 252 273 octets. Where an Attribute needs to carry more than 252 octets of 274 data, the "Extended Type with flags" format should be used. 276 Experience has shown that the "experimental" and "implementation 277 specific" attributes defined in [RFC2865] Section 5 have had little 278 practical value. We therefore do not continue that practice here 279 with the Extended-Type field. 281 2.2. Extended Type with Flags 283 This section defines a new attribute format, called "Extended Type 284 with Flags". It leverages the "Extended Type" format in order to 285 permit the transport of attributes encapsulating more than 253 octets 286 of data. A summary of the Attribute format is shown below. The 287 fields are transmitted from left to right. 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Type | Length | Extended-Type |M| Flags | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Value ... 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Type 299 This field is identical to the Type field of the Attribute format 300 defined in [RFC2865] Section 5. 302 Length 304 This field is identical to the Length field of the Attribute 305 format defined in [RFC2865] Section 5. Permitted values are 306 between 5 and 255. If a client or server receives an "Extended 307 Attribute with Flags" with a Length of 2, 3, or 4, then that 308 Attribute MUST be deemed to be an "invalid attribute", it SHOULD 309 be silently discarded. If it is not discarded, it MUST NOT be 310 handled in the same manner as a well-formed attribute. 312 Note that an "invalid attribute" does not cause the entire packet 313 to be discarded, or to be treated as a negative acknowledgement. 314 Instead, only the "invalid attribute" is discarded. 316 Extended-Type 318 This field is identical to the Extended-Type field defined above 319 in Section 2.1. 321 M (More) 323 The More Flag is one (1) bit in length, and indicates whether or 324 not the current attribute contains "more" than 251 octets of data. 325 The More flag MUST be clear (0) if the Length field has value less 326 than 255. The More flag MAY be set (1) if the Length field has 327 value of 255. 329 If the More flag is set (1), it indicates that the Value field has 330 been fragmented across multiple RADIUS attributes. When the More 331 flag is set (1), the attribute SHOULD have a Length field of value 332 255; it MUST NOT have a length Field of of value 4; there MUST be 333 an attribute following this one; and the next attribute MUST have 334 both the same Type and Extended Type. That is, multiple fragments 335 of the same value MUST be in order and MUST be consecutive 336 attributes in the packet, and the last attribute in a packet MUST 337 NOT have the More flag set (1). 339 When the Length field of an attribute has value less than 255, the 340 More flag SHOULD be clear (0). 342 If a client or server receives an attribute fragment with the 343 "More" flag set (1), but for which no subsequent fragment can be 344 found, then the fragmented attribute is deemed to be an "invalid 345 attribute" and the entire set of fragments SHOULD be silently 346 discarded. If the fragmented attribute is not discarded, it MUST 347 NOT be handled in the same manner as a well-formed attribute. 349 Flags 351 This field is 7 bits long, and is reserved for future use. 352 Implementations MUST set it to zero (0) when encoding an attribute 353 for sending in a packet. The contents SHOULD be ignored on 354 reception. 356 Value 358 This field is similar to the Value field of the Attribute format 359 defined in [RFC2865] Section 5. It may contain a complete set of 360 data (when the Length field has value less than 255), or it may 361 contain a fragment of data (when the More field is set). 363 Any interpretation of the resulting data MUST occur after the 364 fragments have been reassembled. The length of the data MUST be 365 taken as the sum of the lengths of the fragments (i.e. Value 366 fields) from which it is constructed. The format of the data 367 SHOULD be a valid RADIUS data type. 369 This definition increases the RADIUS Attribute Type space as above, 370 but also provides for transport of Attributes which could contain 371 more than 253 octets of data. 373 2.3. TLV Data Type 375 We define a new data type in RADIUS, called "tlv". The "tlv" data 376 type is an encapsulation layer which which permits the "Value" field 377 of an Attribute to contain new sub-Attributes. These sub-Attributes 378 can in turn contain "Value"s of data type TLV. This capability both 379 extends the attribute space, and permits "nested" attributes to be 380 used. This nesting can be used to encapsulate or group data into one 381 or more logical containers. 383 The "tlv" data type re-uses the RADIUS attribute format, as given 384 below: 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | TLV-Type | TLV-Length | TLV-Value ... 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 TLV-Type 394 The Type field is one octet. Up-to-date values of this field are 395 specified by IANA. Values of zero (0) MUST NOT be used. Values 396 254-255 are "Reserved" for use by future extensions to RADIUS. 397 The value 26 has no special meaning. 399 As with Extended-Type above, the TLV-Type is meaningful only 400 within a context defined by "Type" fields of the encapsulating 401 Attributes. That is, the field may be thought of as defining a 402 new type space of the form "Type.Extended-Type.TLV-Type". Where 403 TLVs are nested, the type space is of the form "Type.Extended- 404 Type.TLV-Type.TLV-Type", etc. 406 A RADIUS server MAY ignore Attributes with an unknown "TLV-Type". 408 A RADIUS client MAY ignore Attributes with an unknown "TLV-Type". 410 TLV-Length 412 The TLV-Length field is one octet, and indicates the length of 413 this TLV including the TLV-Type, TLV-Length and TLV-Value fields. 414 It MUST have a value between 3 and 255. If a client or server 415 receives a TLV with an invalid TLV-Length, then the attribute 416 which encapsulates that TLV MUST be deemed to be an "invalid 417 attribute", it SHOULD be silently discarded. If the encapsulating 418 attribute is not discarded, it MUST NOT be handled in the same 419 manner as a well-formed attribute. 421 Note that an "invalid attribute" does not cause the entire packet 422 to be discarded, or to be treated as a negative acknowledgement. 423 Instead, only the "invalid attribute" is discarded. 425 TLV-Value 427 The Value field is one or more octets and contains information 428 specific to the Attribute. The format and length of the TLV-Value 429 field is determined by the TLV-Type and TLV-Length fields. 431 The TLV-Value field SHOULD encapsulate a previously defined RADIUS 432 data type. Using non-standard data types is NOT RECOMMENDED. We 433 note that the TLV-Value field MAY also contain one or more 434 attributes of data type "tlv", which allows for simple grouping 435 and multiple layers of nesting. 437 The TLV-Value field is limited to containing 253 or fewer octets 438 of data. Specifications which require a TLV to contain more than 439 253 octets of data are incompatible with RADIUS, and need to be 440 redesigned. Specifications which require the transport of empty 441 Values (i.e. Length = 2) are incomaptible with RADIUS, and need to 442 be redesigned. 444 The TLV-Value field MUST NOT contain data using the "Extended 445 Type" formats defined in this document. The base Extended 446 Attributes format allows for sufficient flexibility that nesting 447 them inside of a TLV offers little additional value. 449 This TLV definition is compatible with the suggested format of the 450 "String" field of the Vendor-Specific attribute, as defined in 451 [RFC2865] Section 5.26, though that specification does not discuss 452 nesting. 454 Vendors MAY use attributes of type "tlv" in any Vendor Specific 455 Attribute. We RECOMMEND using type "tlv" for VSAs, in preference to 456 any other format. 458 2.3.1. TLV Nesting 460 TLVs may contain other TLVs. When this occurs, the "container" TLV 461 MUST be completely filled by the "contained" TLVs. That is, the 462 "container" TLV-Length field MUST be exactly two (2) more than the 463 sum of the "contained" TLV-Length fields. If the "contained" TLVs 464 over-fill the "container" TLV, the "container" TLV MUST be considered 465 to be an "invalid attribute", and handled as described above. 467 The depth of TLV nesting is limited only by the restrictions on the 468 TLV-Length field. The limit of 253 octets of data results in a limit 469 of 126 levels of nesting. However, nesting depths of more than 4 are 470 NOT RECOMMENDED. 472 2.4. EVS Data Type 474 We define a new data type in RADIUS, called "evs", for "Extended 475 Vendor-Specific". The "evs" data type is an encapsulation layer 476 which which permits the "Value" field of an Attribute to contain a 477 Vendor-Id, followed by a Vendor-Type, and then vendor-defined data. 478 This data can in turn contain valid RADIUS data types, or any other 479 data as determined by the vendor. 481 This data type is intended use in attributes which carry Vendor- 482 Specific information, as is done with the Vendor-Specific Attribute 483 (26). It is RECOMMENDED that this data type be used by a vendor only 484 when the Vendor-Specific Attribute Type space has been fully 485 allocated. 487 Where [RFC2865] Section 5.26 makes a recommendation for the format of 488 the data following the Vendor-Id, we give a strict definition. 489 Experience has shown that many vendors have not followed the 490 [RFC2865] recommendations, leading to interoperability issues. We 491 hope here to give vendors sufficient flexibility as to meet their 492 needs, while minimizing the use of non-standard VSA formats. 494 The "evs" data type MAY be used in Attributes having the format of 495 "Extended Type" or "Extended Type with Flags". It MUST NOT be used 496 in any other Attribute definition, including standard RADIUS 497 Attributes, TLVs, and VSAs. 499 A summary of the "evs" data type format is shown below. The fields 500 are transmitted from left to right. 502 0 1 2 3 503 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 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Vendor-Id | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Vendor-Type | String .... 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 Vendor-Id 512 The high-order octet is 0 and the low-order 3 octets are the SMI 513 Network Management Private Enterprise Code of the Vendor in 514 network byte order. 516 Vendor-Type 518 The Vendor-Type field is one octet. Values are assigned at the 519 sole discretion of the Vendor. 521 String 523 The String field is one or more octets. It SHOULD encapsulate a 524 previously defined RADIUS data type. Using non-standard data 525 types is NOT RECOMMENDED. We note that the String field may be of 526 data type "tlv". However, it MUST NOT be of data type "evs", as 527 the use cases are unclear for one vendor delegating attribute type 528 space to another vendor. 530 The actual format of the information is site or application 531 specific, and a robust implementation SHOULD support the field as 532 undistinguished octets. We recognise that Vendors have complete 533 control over the contents and format of the String field, while at 534 the same time recommending that good practices be followed. 536 Further codification of the range of allowed usage of this field 537 is outside the scope of this specification. 539 Note that unlike the format described in [RFC2865] Section 5.26, this 540 data type has no "Vendor length" field. The length of the "String" 541 field is implicit, and is determined by taking the "Length" of the 542 encapsulating RADIUS Attribute, and subtracting the attribute 543 overhead (3, or 4 octets). 545 2.5. Attribute Naming and Type Identifiers 547 Attributes have traditionally been identified by a unique name and 548 number. For example, the attribute named "User-Name" has been 549 allocated number one (1). This scheme needs to be extended in order 550 to be able to refer to attributes of Extended Type, and to TLVs. It 551 will also be used by IANA for allocating RADIUS Attribute Type 552 values. 554 The names and identifiers given here are intended to be used only in 555 specifications. The system presented here may not be useful when 556 referring to the contents of a RADIUS packet. It imposes no 557 requirements on implementations, as implementations are free to 558 reference RADIUS Attributes via any method they choose. 560 2.5.1. Attribute and TLV Naming 562 RADIUS specifications traditionally use names consisting of one or 563 more words, separated by hyphens, e.g. "User-Name". However, these 564 names are not allocated from a registry, and there is no restriction 565 other than convention on their global uniqueness. 567 Similarly, vendors have often use their company name as the prefix 568 for VSA names, though this practice is not always used. For example, 569 the name "Vendor-My-Attribute" is preferred over the name "My- 570 Attribute". The second form can conflict with attributes from other 571 vendors, whereas the first form cannot. 573 We therefore RECOMMEND that specifications give names to Attributes 574 which attempt to be globally unique across all RADIUS Attributes. We 575 RECOMMEND that vendors use their name as a unique prefix for 576 attribute names. We recognise that these suggestion may sometimes be 577 difficult to implement in practice. 579 TLVs SHOULD be named with a unique prefix that is shared among 580 related attributes. For example, a specification that defines a set 581 of TLVs related to time could create attributes named "Time-Zone", 582 "Time-Day", "Time-Hour", "Time-Minute", etc. 584 2.5.2. Attribute Type Identifiers 586 The RADIUS Attribute Type space defines a context for a particular 587 "Extended-Type" field. The "Extended-Type" field allows for 256 588 possible type code values, with values 1 through 240 available for 589 allocation. We define here an identification method that uses a 590 "dotted number" notation similar to that used for Object Identifiers 591 (OIDs), formatted as "Type.Extended-Type". 593 For example, and attribute within the Type space of 241, having 594 Extended-Type of one (1), is uniquely identified as "241.1". 595 Similarly, an attribute within the Type space of 246, having 596 Extended-Type of ten (10), is uniquely identified as "246.10". 598 The algorithm used to create the Attribute Identifier is simply to 599 concatenate all of the various identification fields (e.g. Type, 600 Extended-Type, etc.), starting from the encapsulating attribute, down 601 to the final encapsulated TLV, separated by a '.' character. 603 2.5.3. TLV Identifiers 605 We can extend the Attribute reference scheme defined above for TLVs. 606 This is done by leveraging the "dotted number" notation. As above, 607 we define an additional TLV type space, within the "Extended Type" 608 space, by appending another "dotted number" in order to identify the 609 TLV. This method can be replied in sequence for nested TLVs. 611 For example, let us say that "245.1" identifies RADIUS Attribute Type 612 245, containing an "Extended Type" of one (1), which is of type 613 "tlv". That attribute will contain 256 possible TLVs, one for each 614 value of the TLV-Type field. The first TLV-Type value of one (1) can 615 then be identified by appending a ".1" to the number of the 616 encapsulating attribute ("241.1"), to yield "241.1.1". Similarly, 617 the sequence "245.2.3.4" identifies RADIUS attribute 245, containing 618 an "Extended Type" of two (2) which is of type "tlv", which in turn 619 contains a TLV with TLV-Type number three (3), which in turn contains 620 another TLV, wth TLV-Type number four (4). 622 2.5.4. VSA Identifiers 624 There has historically been no method for numerically addressing 625 VSAs. The "dotted number" method defined here can also be leveraged 626 to create such an addressing scheme. However, as the VSAs are 627 completely under the control of each individual vendor, this section 628 provides a suggested practice, but does not define a standard of any 629 kind. 631 The Vendor-Specific Attribute has been assigned the Attribute number 632 26. It in turn carries a 24-bit Vendor-Id, and possibly additional 633 VSAs. Where the VSAs follow the [RFC2865] Section 5.26 recommended 634 format, a VSA can be identified as "26.Vendor-Id"."Vendor-Type". 636 For example, Livingston has Vendor-Id 307, and has defined an 637 attribute "IP-Pool" as number 6. This VSA can be uniquely identified 638 as 26.307.6. 640 Note that there is no restriction on the size of the numerical values 641 in this notation. The Vendor-Id is a 24-bit number, and the VSA may 642 have been assigned from a 16-bit vendor-specific Attribute type 643 space. 645 For example, the company USR has been allocated Vendor-Id 429, and 646 has defined a "Version-Id" attribute as number 32768. This VSA can 647 be uniquely identified as 26.429.32768. 649 Where a VSA is a TLV, the "dotted number" notation can be used as 650 above: 26.VID.VSA.TLV1.TLV2.TLV3 where "TLVn" are the numerical 651 values assigned by the vendor to the different nested TLVs. 653 3. Attribute Definitions 655 We define four (4) attributes of "Extended Type", which are allocated 656 from the "Reserved" Attribute Type codes of 241, 242, 243, and 244. 657 We also define two (2) attributes of "Extended Type with Flags", 658 which are allocated from the "Reserved" Attribute Type codes of 245 659 and 246. 661 Type Name 662 ---- ---- 663 241 Extended-Type-1 664 242 Extended-Type-2 665 243 Extended-Type-3 666 244 Extended-Type-4 667 245 Extended-Type-Flagged-1 668 246 Extended-Type-Flagged-2 670 The rest of this section gives a detailed definition for each 671 Attribute based on the above summary. 673 3.1. Extended-Type-1 675 Description 677 This attribute encapsulates attributes of the "Extended Type" 678 format, in the RADIUS Attribute Type Space of 241.{1-255}. 680 A summary of the Extended-Type-1 Attribute format is shown below. 681 The fields are transmitted from left to right. 683 0 1 2 3 684 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 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | Type | Length | Extended-Type | Value ... 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 Type 690 241 for Extended-Type-1. 692 Length 694 >= 4 696 Extended-Type 698 The Extended-Type field is one octet. Up-to-date values of this 699 field are specified by IANA, in the 241.{1-255} RADIUS Attribute 700 Type Space. Further definition of this field is given in Section 701 2,1, above. 703 String 705 The String field is one or more octets. Implementations not 706 supporting this specification SHOULD support the field as 707 undistinguished octets. 709 Implementations supporting this specification MUST use the 710 Identifier of "Type.Extended-Type" to determine the interpretation 711 of the String field. 713 3.2. Extended-Type-2 715 Description 717 This attribute encapsulates attributes of the "Extended Type" 718 format, in the RADIUS Attribute Type Space of 242.{1-255}. 720 A summary of the Extended-Type-2 Attribute format is shown below. 721 The fields are transmitted from left to right. 723 0 1 2 3 724 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 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | Type | Length | Extended-Type | Value ... 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 Type 731 242 for Extended-Type-2. 733 Length 734 >= 4 736 Extended-Type 738 The Extended-Type field is one octet. Up-to-date values of this 739 field are specified by IANA, in the 242.{1-255} RADIUS Attribute 740 Type Space. Further definition of this field is given in Section 741 2,1, above. 743 String 745 The String field is one or more octets. Implementations not 746 supporting this specification SHOULD support the field as 747 undistinguished octets. 749 Implementations supporting this specification MUST use the 750 Identifier of "Type.Extended-Type" to determine the interpretation 751 of the String field 753 3.3. Extended-Type-3 755 Description 757 This attribute encapsulates attributes of the "Extended Type" 758 format, in the RADIUS Attribute Type Space of 243.{1-255}. 760 A summary of the Extended-Type-3 Attribute format is shown below. 761 The fields are transmitted from left to right. 763 0 1 2 3 764 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 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Type | Length | Extended-Type | Value ... 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 Type 771 243 for Extended-Type-3. 773 Length 775 >= 4 777 Extended-Type 779 The Extended-Type field is one octet. Up-to-date values of this 780 field are specified by IANA, in the 243.{1-255} RADIUS Attribute 781 Type Space. Further definition of this field is given in Section 782 2,1, above. 784 String 786 The String field is one or more octets. Implementations not 787 supporting this specification SHOULD support the field as 788 undistinguished octets. 790 Implementations supporting this specification MUST use the 791 Identifier of "Type.Extended-Type" to determine the interpretation 792 of the String field. 794 3.4. Extended-Type-4 796 Description 798 This attribute encapsulates attributes of the "Extended Type" 799 format, in the RADIUS Attribute Type Space of 244.{1-255}. 801 A summary of the Extended-Type-4 Attribute format is shown below. 802 The fields are transmitted from left to right. 804 0 1 2 3 805 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 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Type | Length | Extended-Type | Value ... 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 Type 812 244 for Extended-Type-4. 814 Length 816 >= 4 818 Extended-Type 820 The Extended-Type field is one octet. Up-to-date values of this 821 field are specified by IANA, in the 244.{1-255} RADIUS Attribute 822 Type Space. Further definition of this field is given in Section 823 2,1, above. 825 String 827 The String field is one or more octets. Implementations not 828 supporting this specification SHOULD support the field as 829 undistinguished octets. 831 Implementations supporting this specification MUST use the 832 Identifier of "Type.Extended-Type" to determine the interpretation 833 of the String Field. 835 3.5. Extended-Type-Flagged-1 837 Description 839 This attribute encapsulates attributes of the "Extended Type with 840 Flags" format, in the RADIUS Attribute Type Space of 245.{1-255}. 842 A summary of the Extended-Type-Flagged-1 Attribute format is shown 843 below. The fields are transmitted from left to right. 845 0 1 2 3 846 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 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Type | Length | Extended-Type |M| Flags | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Value ... 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 Type 855 245 for Extended-Type-Flagged-1 857 Length 859 >= 4 861 Extended-Type 863 The Extended-Type field is one octet. Up-to-date values of this 864 field are specified by IANA, in the 245.{1-255} RADIUS Attribute 865 Type Space. Further definition of this field is given in Section 866 2,1, above. 868 M (More) 870 The More Flag is one (1) bit in length, and indicates whether or 871 not the current attribute contains "more" than 251 octets of data. 872 Further definition of this field is given in Section 2.2, above. 874 Flags 875 This field is 7 bits long, and is reserved for future use. 876 Implementations MUST set it to zero (0) when encoding an attribute 877 for sending in a packet. The contents SHOULD be ignored on 878 reception. 880 String 882 The String field is one or more octets. Implementations not 883 supporting this specification SHOULD support the field as 884 undistinguished octets. 886 Implementations supporting this specification MUST use the 887 Identifier of "Type.Extended-Type" to determine the interpretation 888 of the String field. 890 3.6. Extended-Type-Flagged-2 892 Description 894 This attribute encapsulates attributes of the "Extended Type with 895 Flags" format, in the RADIUS Attribute Type Space of 246.{1-255}. 897 A summary of the Extended-Type-Flagged-2 Attribute format is shown 898 below. The fields are transmitted from left to right. 900 0 1 2 3 901 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 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | Type | Length | Extended-Type |M| Flags | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | Value ... 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 Type 910 246 for Extended-Type-Flagged-2 912 Length 914 >= 4 916 Extended-Type 918 The Extended-Type field is one octet. Up-to-date values of this 919 field are specified by IANA, in the 246.{1-255} RADIUS Attribute 920 Type Space. Further definition of this field is given in Section 921 2,1, above. 923 M (More) 925 The More Flag is one (1) bit in length, and indicates whether or 926 not the current attribute contains "more" than 251 octets of data. 927 Further definition of this field is given in Section 2.2, above. 929 Flags 931 This field is 7 bits long, and is reserved for future use. 932 Implementations MUST set it to zero (0) when encoding an attribute 933 for sending in a packet. The contents SHOULD be ignored on 934 reception. 936 String 938 The String field is one or more octets. Implementations not 939 supporting this specification SHOULD support the field as 940 undistinguished octets. 942 Implementations supporting this specification MUST use the 943 Identifier of "Type.Extended-Type" to determine the interpretation 944 of the String field. 946 4. Vendor Specific Attributes 948 We define six new attributes which can carry Vendor Specific 949 information. We define four (4) attributes of the "Extended Type" 950 format, with Type codes (241.26, 242.26, 243.26, 244.26), using the 951 "evs" data type. We also define two (2) attributes of "Extended Type 952 with Flags" format, with Type codes (245.26, 246.26), using the "evs" 953 data type. 955 Type.Extended-Type Name 956 ------------------ ---- 957 241.26 Extended-Vendor-Specific-1 958 242.26 Extended-Vendor-Specific-2 959 243.26 Extended-Vendor-Specific-3 960 244.26 Extended-Vendor-Specific-4 961 245.26 Extended-Vendor-Specific-5 962 246.26 Extended-Vendor-Specific-6 964 The rest of this section gives a detailed definition for each 965 Attribute based on the above summary. 967 4.1. Extended-Vendor-Specific-1 969 Description 970 This attribute defines a RADIUS Type Code of 241.26, using the 971 "evs" data type. 973 A summary of the Extended-Vendor-Specific-1 Attribute format is shown 974 below. The fields are transmitted from left to right. 976 0 1 2 3 977 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 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | Type | Length | Extended-Type | Vendor-Id ... 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 ... Vendor-Id (cont) | Vendor-Type | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | String .... 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 Type.Extended-Type 988 241.26 for Extended-Vendor-Specific-1 990 Length 992 >= 9 994 Vendor-Id 996 The high-order octet is 0 and the low-order 3 octets are the SMI 997 Network Management Private Enterprise Code of the Vendor in 998 network byte order. 1000 Vendor-Type 1002 The Vendor-Type field is one octet. Values are assigned at the 1003 sole discretion of the Vendor. 1005 String 1007 The String field is one or more octets. The actual format of the 1008 information is site or application specific, and a robust 1009 implementation SHOULD support the field as undistinguished octets. 1011 The codification of the range of allowed usage of this field is 1012 outside the scope of this specification. 1014 Implementations supporting this specification MUST use the 1015 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1016 determine the interpretation of the String field. 1018 4.2. Extended-Vendor-Specific-2 1020 Description 1022 This attribute defines a RADIUS Type Code of 242.26, using the 1023 "evs" data type. 1025 A summary of the Extended-Vendor-Specific-2 Attribute format is shown 1026 below. The fields are transmitted from left to right. 1028 0 1 2 3 1029 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 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | Type | Length | Extended-Type | Vendor-Id ... 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 ... Vendor-Id (cont) | Vendor-Type | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | String .... 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 Type.Extended-Type 1040 242.26 for Extended-Vendor-Specific-2 1042 Length 1044 >= 9 1046 Vendor-Id 1048 The high-order octet is 0 and the low-order 3 octets are the SMI 1049 Network Management Private Enterprise Code of the Vendor in 1050 network byte order. 1052 Vendor-Type 1054 The Vendor-Type field is one octet. Values are assigned at the 1055 sole discretion of the Vendor. 1057 String 1059 The String field is one or more octets. The actual format of the 1060 information is site or application specific, and a robust 1061 implementation SHOULD support the field as undistinguished octets. 1063 The codification of the range of allowed usage of this field is 1064 outside the scope of this specification. 1066 Implementations supporting this specification MUST use the 1067 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1068 determine the interpretation of the String field. 1070 4.3. Extended-Vendor-Specific-3 1072 Description 1074 This attribute defines a RADIUS Type Code of 243.26, using the 1075 "evs" data type. 1077 A summary of the Extended-Vendor-Specific-3 Attribute format is shown 1078 below. The fields are transmitted from left to right. 1080 0 1 2 3 1081 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 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | Type | Length | Extended-Type | Vendor-Id ... 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 ... Vendor-Id (cont) | Vendor-Type | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | String .... 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 Type.Extended-Type 1092 243.26 for Extended-Vendor-Specific-3 1094 Length 1096 >= 9 1098 Vendor-Id 1100 The high-order octet is 0 and the low-order 3 octets are the SMI 1101 Network Management Private Enterprise Code of the Vendor in 1102 network byte order. 1104 Vendor-Type 1106 The Vendor-Type field is one octet. Values are assigned at the 1107 sole discretion of the Vendor. 1109 String 1111 The String field is one or more octets. The actual format of the 1112 information is site or application specific, and a robust 1113 implementation SHOULD support the field as undistinguished octets. 1115 The codification of the range of allowed usage of this field is 1116 outside the scope of this specification. 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 String field. 1122 4.4. Extended-Vendor-Specific-4 1124 Description 1126 This attribute defines a RADIUS Type Code of 244.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 | String .... 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 Type.Extended-Type 1144 244.26 for Extended-Vendor-Specific-4 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 String 1162 The String field is one or more octets. The actual format of the 1163 information is site or application specific, and a robust 1164 implementation SHOULD support the field as undistinguished octets. 1166 The codification of the range of allowed usage of this field is 1167 outside the scope of this specification. 1169 Implementations supporting this specification MUST use the 1170 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1171 determine the interpretation of the String field. 1173 4.5. Extended-Vendor-Specific-5 1175 Description 1177 This attribute defines a RADIUS Type Code of 245.26, using the 1178 "evs" data type. 1180 A summary of the Extended-Vendor-Specific-5 Attribute format is shown 1181 below. The fields are transmitted from left to right. 1183 0 1 2 3 1184 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 1185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1186 | Type | Length | Extended-Type |M| Flags | 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 | Vendor-Id | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | Vendor-Type | String .... 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 Type.Extended-Type 1195 245.26 for Extended-Vendor-Specific-5 1197 Length 1199 >= 10 (first fragment) 1200 >= 5 (subsequent fragments) 1202 When a VSA is fragmented across multiple Attributes, only the 1203 first Attribute contains the Vendor-Id and Vendor-Type fields. 1204 Subsequent Attributes contain fragments of the String field only. 1206 M (More) 1208 The More Flag is one (1) bit in length, and indicates whether or 1209 not the current attribute contains "more" than 251 octets of data. 1211 Further definition of this field is given in Section 2.2, above. 1213 Flags 1215 This field is 7 bits long, and is reserved for future use. 1216 Implementations MUST set it to zero (0) when encoding an attribute 1217 for sending in a packet. The contents SHOULD be ignored on 1218 reception. 1220 Vendor-Id 1222 The high-order octet is 0 and the low-order 3 octets are the SMI 1223 Network Management Private Enterprise Code of the Vendor in 1224 network byte order. 1226 Vendor-Type 1228 The Vendor-Type field is one octet. Values are assigned at the 1229 sole discretion of the Vendor. 1231 String 1233 The String field is one or more octets. The actual format of the 1234 information is site or application specific, and a robust 1235 implementation SHOULD support the field as undistinguished octets. 1237 The codification of the range of allowed usage of this field is 1238 outside the scope of this specification. 1240 Implementations supporting this specification MUST use the 1241 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1242 determine the interpretation of the String field. 1244 4.6. Extended-Vendor-Specific-6 1246 Description 1248 This attribute defines a RADIUS Type Code of 246.26, using the 1249 "evs" data type. 1251 A summary of the Extended-Vendor-Specific-6 Attribute format is shown 1252 below. The fields are transmitted from left to right. 1254 0 1 2 3 1255 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 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 | Type | Length | Extended-Type |M| Flags | 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 | Vendor-Id | 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | Vendor-Type | String .... 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 Type.Extended-Type 1266 246.26 for Extended-Vendor-Specific-6 1268 Length 1270 >= 10 (first fragment) 1271 >= 5 (subsequent fragments) 1273 When a VSA is fragmented across multiple Attributes, only the 1274 first Attribute contains the Vendor-Id and Vendor-Type fields. 1275 Subsequent Attributes contain fragments of the String field only. 1277 M (More) 1279 The More Flag is one (1) bit in length, and indicates whether or 1280 not the current attribute contains "more" than 251 octets of data. 1281 Further definition of this field is given in Section 2.2, above. 1283 Flags 1285 This field is 7 bits long, and is reserved for future use. 1286 Implementations MUST set it to zero (0) when encoding an attribute 1287 for sending in a packet. The contents SHOULD be ignored on 1288 reception. 1290 Vendor-Id 1292 The high-order octet is 0 and the low-order 3 octets are the SMI 1293 Network Management Private Enterprise Code of the Vendor in 1294 network byte order. 1296 Vendor-Type 1298 The Vendor-Type field is one octet. Values are assigned at the 1299 sole discretion of the Vendor. 1301 String 1303 The String field is one or more octets. The actual format of the 1304 information is site or application specific, and a robust 1305 implementation SHOULD support the field as undistinguished octets. 1307 The codification of the range of allowed usage of this field is 1308 outside the scope of this specification. 1310 Implementations supporting this specification MUST use the 1311 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1312 determine the interpretation of the String field. 1314 5. Compatibility with traditional RADIUS 1316 There are a number of potential compatibility issues with traditional 1317 RADIUS. This section describes them. 1319 5.1. Attribute Allocation 1321 Some vendors have used Attribute Type codes from the "Reserved" 1322 space, as Vendor Specific Attributes. This practice is considered 1323 anti-social behavior, as noted in [GUIDELINES]. These vendor 1324 definitions conflict with the attributes in the RADIUS Attribute Type 1325 space. The conflicting definitions may make it difficult for 1326 implementations to support both those Vendor Attributes, and the new 1327 Extended Attribute formats. 1329 We RECOMMEND that RADIUS client and server implementations delete all 1330 references to these improperly defined attributes. Failing that, we 1331 RECOMMEND that RADIUS server implementations have a per-client 1332 configurable flag which indicates which type of attributes are being 1333 sent from the client. If the flag is set one way, the conflicting 1334 attributes can be interpreted as being improperly defined Vendor 1335 Specific Attributes. If the flag is set the other way, the attributes 1336 MUST be interpreted as being of the Extended Attributes format. The 1337 default SHOULD be to interpret the attributes as being of the 1338 Extended Attributes format. 1340 Other methods of determining how to decode the attributes into a 1341 "correct" form are NOT RECOMMENDED. Those methods are likely to be 1342 fragile and prone to error. 1344 We RECOMMEND that RADIUS server implementations re-use the above flag 1345 to determine which type of attributes to send in a reply message. If 1346 the request is expected to contain the improperly defined attributes, 1347 the reply SHOULD NOT contain Extended Attributes. If the request is 1348 expected to contain Extended Attributes, the reply MUST NOT contain 1349 the improper Attributes. 1351 RADIUS clients will have fewer issues than servers. Clients MUST NOT 1352 send improperly defined Attributes in a request. For replies, 1353 clients MUST interpret attributes as being of the Extended Attributes 1354 format, instead of the improper definitions. These requirements 1355 impose no change in the RADIUS specifications, as such usage by 1356 vendors has always been in conflict with the standard requirements 1357 and the standards process. 1359 5.2. Proxy Servers 1361 RADIUS Proxy servers will need to forward Attributes having the new 1362 format, even if they do not implement support for the encoding and 1363 decoding of those attributes. We remind implementors of the 1364 following text in [RFC2865] Section 2.3: 1366 The forwarding server MUST NOT change the order of any attributes 1367 of the same type, including Proxy-State. 1369 This requirement solves some of the issues related to proxying of the 1370 new format, but not all. The reason is that proxy servers are 1371 permitted to examine the contents of the packets that they forward. 1372 Many proxy implementations not only examine the attributes, but they 1373 refuse to forward attributes which they do not understand (i.e. 1374 attributes which have no "dictionary" definitions). 1376 This practice is NOT RECOMMENDED. Proxy servers SHOULD forward 1377 attributes, even ones which they do not understand, or which are not 1378 in a local dictionary. When forwarded, these attributes SHOULD be 1379 sent verbatim, with no modifications or changes. The only exception 1380 to this recommendation is when local site policy dictates that 1381 filtering of attributes has to occur. For example, a filter at a 1382 visited network may require removal of certain authorization rules 1383 which apply to the home network, but not to the visited network. 1384 This filtering can sometimes be done even when the contents of the 1385 attributes are unknown, such as when all Vendor-Specific Attributes 1386 are designated for removal. 1388 As seen in [EDUROAM] many proxies do not follow these practices for 1389 unknown Attributes. Some proxies filter out unknown attributes or 1390 attributes which have unexpected lengths (24%, 17/70), some truncate 1391 the attributes to the "expected" length (11%, 8/70), some discard the 1392 request entirely (1%, 1/70), with the rest (63%, 44/70) following the 1393 recommended practice of passing the attributes verbatim. It will be 1394 difficult to widely use the Extended Attributes format until all non- 1395 conformant proxies are fixed. We therefore RECOMMEND that all 1396 proxies which do not support the Extended Attributes (241 through 1397 246) define them as being of data type "string", and delete all other 1398 local definitions for those attributes. 1400 This last change should enable wider usage of the Extended Attributes 1401 format. 1403 6. Guidelines 1405 We recommend the following guidelines when designing attributes using 1406 the new format. The items listed below are not exhaustive. As 1407 experience is gained with the new formats, later specifications may 1408 define additional guidelines. 1410 * Unless otherwise specified, the guidelines in [GUIDELINES] MUST 1411 be followed. 1413 * The data type "esv" MUST NOT be used for standard RADIUS 1414 Attributes, or for TLVs, or for VSAs. 1416 * The data type "tlv" SHOULD NOT be used for standard RADIUS 1417 attributes. While its use is NOT RECOMMENDED by [GUIDELINES], this 1418 specification updates [GUIDELINES] to permit the "tlv" data type in 1419 attributes using the Extended-Type format. 1421 * [RFC2866] "tagged" attributes MUST NOT be defined in the 1422 Extended-Type space. The "tlv" data type should be used instead to 1423 group attributes 1425 6.1. Allocation Request Guidelines 1427 The following items give guidelines for allocation requests made in a 1428 RADIUS specification. 1430 * Discretion is RECOMMENDED when requesting allocation of attributes. 1431 The new space is much larger than the old one, but it is not 1432 infinite. 1434 * When the Type spaces of 241.*, 242.*, 243.*, or 244.* are nearing 1435 exhaustion, a new specification SHOULD be written which requests 1436 allocation of one or more RADIUS Attributes from the "Reserved" 1437 space, using the "Extended Type" format. This process is 1438 preferable to allocating "small" attributes from the 256.* and 1439 246.* Type spaces. 1441 * When the Type spaces of 245.* or 246.* are nearing exhaustion, a 1442 new specification SHOULD be written which requests allocation of 1443 one or more RADIUS Attributes from the "Reserved" space, using the 1444 "Extended Type with flags" format. 1446 * All other specifications SHOULD NOT request allocation from the 1447 standard Attribute Type Space (i.e. Attributes 1 through 255). 1448 That space is deprecated, and is not to be used. 1450 * Attributes which encode 252 octets or less of data SHOULD 1451 request allocation from the Type spaces of 241.*, 242.*, 243.*, 1452 or 244.*. 1454 * Attributes which encode 253 octets or more of data MUST request 1455 allocation from the Type spaces of 245.* or 246.*. 1457 * Where a group of TLVs is strictly defined, and not expected to 1458 change, and and totals less than 247 octets of data, they SHOULD 1459 request allocation from the Type spaces of 241.*, 242.*, 243.*, or 1460 244.*. 1462 * Where a group of TLVs is loosely defined, or is expected to change, 1463 they SHOULD request allocation from the Type spaces of 245.* or 1464 246.*. 1466 6.2. TLV Guidelines 1468 The following items give guidelines for specifications using TLVs. 1470 * when multiple attributes are intended to be grouped or managed 1471 together, the use of TLVs to group related attributes is 1472 RECOMMENDED. 1474 * more than 4 layers (depth) of TLV nesting is NOT RECOMMENDED. 1476 * Specifications SHOULD that the interpretation of an attribute 1477 depends only on its OID, and not on its encoding in the RADIUS 1478 packet. 1480 6.3. Implementation Guidelines 1482 * RADIUS Server implementations SHOULD support this specification 1483 as soon as possible. 1485 * RADIUS Proxy servers SHOULD forward all attributes, even ones 1486 which they do not understand, or which are not in a local 1487 dictionary. These attributes SHOULD be forwarded verbatim, with 1488 no modifications or changes. 1490 * Any attribute which is allocated from the Type spaces of 245.* or 1491 246.*, of data type "text", "string", or "tlv" can end up carrying 1492 more than 251 octets of data, up to the maximum RADIUS packet 1493 length (~4096 octets). Specifications defining such attributes 1494 SHOULD define a maximum length. 1496 6.4. Vendor Guidelines 1498 * Vendors SHOULD use the existing Vendor-Specific Attribute Type 1499 space in preference to the new Extended-Vendor-Specific 1500 attributes, as this specification may take time to be widely 1501 deployed. 1503 7. Rationale 1505 The path to extending the RADIUS protocol has been long and arduous. 1506 A number of proposals have been made and discarded by the RADEXT 1507 working group. These proposals have been judged to be either too 1508 bulky, too complex, too simple, or to be unworkable in practice. We 1509 do not otherwise explain here why earlier proposals did not obtain 1510 working group consensus. 1512 This proposal has the benefit of being simple, as the "Extended Type" 1513 format requires only a one octet change to the Attribute format. 1515 7.1. Attribute Audit 1517 An audit of almost five thousand publicly available attributes 1518 [ATTR], shows the statistics summarized below. The attributes include 1519 over 100 Vendor dictionaries, along with the IANA assigned 1520 attributes: 1522 Count Data Type 1523 ----- --------- 1524 2257 integer 1525 1762 text 1526 273 IPv4 Address 1527 235 string 1528 96 other data types 1529 35 IPv6 Address 1530 18 date 1531 4 Interface Id 1532 3 IPv6 Prefix 1534 4683 Total 1536 The entries in the "Data Type" column are data types recommended by 1537 [GUIDELINES]. The "other data types" row encompasses data types not 1538 recommended by that document. 1540 Manual inspection of the dictionaries shows that approximately 20 (or 1541 0.5%) attributes have the ability to transport more than 253 octets 1542 of data. These attributes are divided between VSAs, and a small 1543 number of standard Attributes. The "Extended Type with Flags" 1544 formats is therefore important, but "long" attributes have had 1545 limited deployment. 1547 8. Examples 1549 A few examples are presented here, in order to illustrate the 1550 encoding of the new attribute formats. These examples are not 1551 intended to be exhaustive, as many others are possible. For 1552 simplicity, we do not show complete packets, only attributes. 1554 The examples are given using a domain-specific language implemented 1555 by the program given in Appendix A. The language is line oriented, 1556 and composed of a sequence of lines matching the grammar ([RFC5234]) 1557 given below: 1559 Identifier = 1*DIGIT *( "." 1*DIGIT ) 1561 HEXCHAR = HEXDIG HEXDIG 1563 STRING = DQUOTE 1*CHAR DQUOTE 1565 TLV = "{" 1*DIGIT DATA "}" 1567 DATA = 1*HEXCHAR / 1*TLV / STRING 1569 LINE = Identifier DATA 1571 The progam has additional restrictions on its input that are not 1572 reflected in the above grammar. For example, the portions of the 1573 Identifier which refer to Type and Extended-Type are limited to 1574 values between 1 and 255. We trust that the source code in Appendix 1575 A is clear, and that these restrictions do not negatively affect the 1576 comprehensability of the examples. 1578 The program reads the input text, and interprets it as a set of 1579 instructions to create RADIUS Attributes. It then prints the hex 1580 encoding of those attributes. It implements the minimum set of 1581 functionality which achieves that goal. This minimalism means that 1582 it does not use attribute dictionaries; it does not implement support 1583 for RADIUS data types; it can be used to encode attributes with 1584 invalid data field(s); and there is no requirement for consistency 1585 from one example to the next. For example, it can be used to encode 1586 a User-Name attribute which contains non-UTF8 data, or a Framed-IP- 1587 Address which contains 253 octets of ASCII data. As a result, it 1588 cannot be used to create RADIUS Attributes for transport in a RADIUS 1589 message. 1591 However, the program correctly encodes the RADIUS attribute fields of 1592 "Type", "Length", "Extended-Type", "More", "Flags", "Vendor-Id", 1593 "Vendor-Type", and "Vendor-Length". It can therefore be used to 1594 encode example attributes from input which is humanly readable. 1596 We do not give examples of "malformed" or "invalid attributes". We 1597 also note that the examples show format, and not consistent meaning. 1598 A particular attribute type code may be used to demonstrate two 1599 different formats. In real specifications, attributes have a static 1600 definitions based on their type code. 1602 The examples given below are strictly for demonstration purposes 1603 only, and do not provide a standard of any kind. 1605 8.1. Extended Type 1607 The following are a series of examples of the "Extended Type" format. 1609 Attribute encapsulating textual data. 1611 241.1 "bob" 1612 -> f1 06 01 62 6f 62 1614 Attribute encapsulating a TLV with TLV-Type of one (1). 1616 241.2 { 1 23 45 } 1617 -> f1 07 02 01 04 23 45 1619 Attribute encapsulating two TLVs, one after the other. 1621 241.2 { 1 23 45 } { 2 67 89 } 1622 -> f1 0b 02 01 04 23 45 02 04 67 89 1624 Attribute encapsulating two TLVs, where the second TLV is itself 1625 encapsulating a TLV. 1627 241.2 { 1 23 45 } { 3 { 1 ab cd } } 1628 -> f1 0d 02 01 04 23 45 03 06 01 04 ab cd 1630 Attribute encapsulating two TLVs, where the second TLV is itself 1631 encapsulating two TLVs. 1633 241.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } 1634 -> f1 12 02 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f 1636 Attribute encapsulating a TLV, which in turn encapsulates a TLV, 1637 to a depth of 5 nestings. 1639 241.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } 1640 -> f1 0f 01 01 0c 02 0a 03 08 04 06 05 04 cd ef 1642 Attribute encapsulating an extended Vendor Specific attribute, 1643 with Vendor-Id of 1, and Vendor-Type of 4, which in turn 1644 encapsulates textual data. 1646 241.26.1.4 "test" 1647 -> f1 0c 1a 00 00 00 01 04 74 65 73 74 1649 Attribute encapsulating an extended Vendor Specific attribute, with 1650 Vendor-Id of 1, and Vendor-Type of 5, which in turn encapsulates 1651 a TLV with TLV-Type of 3, which encapsulates textual data. 1653 241.26.1.5 { 3 "test" } 1654 -> f1 0e 1a 00 00 00 01 05 03 06 74 65 73 74 1656 8.2. Extended Type with Flags 1658 The following are a series of examples of the "Extended Type with 1659 flags" format. 1661 Attribute encapsulating textual data. 1663 245.1 "bob" 1664 -> f5 07 01 00 62 6f 62 1666 Attribute encapsulating a TLV with TLV-Type of one (1). 1668 245.2 { 1 23 45 } 1669 -> f5 08 02 00 01 04 23 45 1671 Attribute encapsulating two TLVs, one after the other. 1673 245.2 { 1 23 45 } { 2 67 89 } 1674 -> f5 0c 02 00 01 04 23 45 02 04 67 89 1676 Attribute encapsulating two TLVs, where the second TLV is itself 1677 encapsulating a TLV. 1679 245.2 { 1 23 45 } { 3 { 1 ab cd } } 1680 -> f5 0e 02 00 01 04 23 45 03 06 01 04 ab cd 1682 Attribute encapsulating two TLVs, where the second TLV is itself 1683 encapsulating two TLVs. 1685 245.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } 1686 -> f5 13 02 00 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f 1688 Attribute encapsulating a TLV, which in turn encapsulates a TLV, 1689 to a depth of 5 nestings. 1691 245.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } 1692 -> f5 10 01 00 01 0c 02 0a 03 08 04 06 05 04 cd ef 1694 Attribute encapsulating an extended Vendor Specific attribute, 1695 with Vendor-Id of 1, and Vendor-Type of 4, which in turn 1696 encapsulates textual data. 1698 245.26.1.4 "test" 1699 -> f5 0d 1a 00 00 00 00 01 04 74 65 73 74 1701 Attribute encapsulating an extended Vendor Specific attribute, 1702 with Vendor-Id of 1, and Vendor-Type of 5, which in turn 1703 encapsulates a TLV with TLV-Type of 3, which encapsulates 1704 textual data. 1706 245.26.1.5 { 3 "test" } 1707 -> f5 0f 1a 00 00 00 00 01 05 03 06 74 65 73 74 1709 Attribute encapsulating more than 251 octets of data. The "Data" 1710 portions are indented for readability. 1712 245.4 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1713 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1714 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1715 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1716 aaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1717 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1718 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1719 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1720 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbcccccccccccccccccccc 1721 cccccccccc 1722 -> f5 ff 04 80 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1723 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1724 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1725 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1726 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1727 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1728 aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb bb bb bb bb bb 1729 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1730 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1731 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1732 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1733 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1734 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 13 04 00 cc 1735 cc cc cc cc cc cc cc cc cc cc cc cc cc cc 1737 Attribute encapsulating an extended Vendor Specific attribute, 1738 with Vendor-Id of 1, and Vendor-Type of 6, which in turn 1739 encapsulates more than 251 octets of data. 1741 As the VSA encapsulates more than 251 octets of data, it is 1742 split into two RADIUS attributes. The first attribute has the 1743 More flag set, and carries the Vendor-Id and Vendor-Type. 1744 The second attribute has the More flag clear, and carries 1745 the rest of the data portion of the VSA. Note that the second 1746 attribute does not include the Vendor-Id ad Vendor-Type fields. 1748 The "Data" portions are indented for readability. 1750 245.26.1.6 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1751 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1752 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1753 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1754 aaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1755 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1756 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1757 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1758 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbccccccccccccc 1759 ccccccccccccccccc 1760 -> f5 ff 1a 80 00 00 00 01 06 aa aa aa aa aa aa aa aa aa aa aa 1761 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1762 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1763 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1764 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1765 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1766 aa aa aa aa aa aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb 1767 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1768 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1769 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1770 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1771 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1772 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 17 1a 00 bb 1773 bb bb bb bb cc cc cc cc cc cc cc cc cc cc 13 45 67 89 1775 9. IANA Considerations 1777 This document has multiple impacts on IANA, in the "RADIUS Attribute 1778 Types" registry. Attribute types which were previously reserved are 1779 now allocated, previously free attributes are marked deprecated, and 1780 the registry is extended from a simple 8-bit array to a tree-like 1781 structure, up to a maximum depth of 125 nodes. 1783 9.1. Attribute Allocations 1785 IANA is requested to move the "Unassigned" numbers in the range 1786 144-191 from "Unassigned" to "Deprecated". This status means that 1787 allocations SHOULD NOT be made from this space. Instead, allocations 1788 SHOULD be taken from the Extended Type space, starting with lower 1789 numbered attributes. However, allocation from the "Deprecated" space 1790 MAY still be performed by publication of an IETF specification, where 1791 that specification requests allocation from the "Deprecated" space, 1792 and gives reasons why use of the Extended Type space is impossible. 1794 IANA is requested to move the following numbers from "Reserved", to 1795 allocated, with the following names: 1797 * 241 Extended-Type-1 1798 * 242 Extended-Type-2 1799 * 243 Extended-Type-3 1800 * 244 Extended-Type-4 1801 * 245 Extended-Type-Flagged-1 1802 * 246 Extended-Type-Flagged-2 1804 These attributes serve as an encapsulation layer for the new RADIUS 1805 Attribute Type tree. 1807 9.2. RADIUS Attribute Type Tree 1809 Each of the attributes allocated above extends the "RADIUS Attribute 1810 Types" to an N-ary tree, via a "dotted number" notation. Each number 1811 in the tree is an 8-bit value (1 to 255). The value zero (0) MUST 1812 NOT be used. Currently, only one level of the tree is defined: 1814 * 241 Extended-Attribute-1 1815 * 241.{1-25} Unassigned 1816 * 241.26 Extended-Vendor-Specific-1 1817 * 241.{27-240} Unassigned 1818 * 241.{241-255} Reserved 1819 * 242 Extended-Attribute-2 1820 * 242.{1-25} Unassigned 1821 * 242.26 Extended-Vendor-Specific-2 1822 * 242.{27-240} Unassigned 1823 * 243 Extended-Attribute-3 1824 * 242.{241-255} Reserved 1825 * 243.{1-25} Unassigned 1826 * 243.26 Extended-Vendor-Specific-3 1827 * 243.{27-240} Unassigned 1828 * 243.{241-255} Reserved 1829 * 244 Extended-Attribute-4 1830 * 244.{1-25} Unassigned 1831 * 244.26 Extended-Vendor-Specific-4 1832 * 244.{27-240} Unassigned 1833 * 244.{241-255} Reserved 1834 * 245 Extended-Attribute-5 1835 * 245.{1-25} Unassigned 1836 * 245.26 Extended-Vendor-Specific-5 1837 * 245.{27-240} Unassigned 1838 * 245.{241-255} Reserved 1839 * 246 Extended-Attribute-6 1840 * 246.{1-25} Unassigned 1841 * 245.26 Extended-Vendor-Specific-6 1842 * 246.{27-240} Unassigned 1843 * 246.{241-255} Reserved 1845 The values marked "Unassigned" above are available for assignment by 1846 IANA in future RADIUS specifications. The values marked "Reserved" 1847 are reserved for future use. 1849 9.3. Assignment Policy 1851 Attributes which are known to always require 252 octets or less of 1852 data MUST be assigned from the lowest unassigned number, e.g. 241.1, 1853 241.2, 241.3, etc. Attributes have the potential to transport more 1854 than 252 octets of data MUST be assigned from the 245.* or 246.* 1855 spaces, again using the lowest unassigned number, and MUST request 1856 assignment from the appropriate Attribute Type Space. 1858 The above policy can be difficult to enforce in the case of TLVs. 1859 For exaple, a set of TLVs may define a logical structure which totals 1860 less than 252 octets of data. Later extensions could assign 1861 additional sub-TLVs, and extend the structure to more than 252 octets 1862 of data. This capability means that TLV definitions SHOULD generally 1863 request assignment from the 245.* or 246.* space. 1865 9.4. Extending the Attribute Type Tree 1867 New specifications may request that the tree be extended to an 1868 additional level or levels. The attribute MUST be of type "tlv". 1870 For example, a specification may request that an "Example-TLV" 1871 attribute be assigned, of data type "tlv". If it is assigned the 1872 number 245.1, then it will define an extension to the registry as 1873 follows: 1875 * 245.1 Example-TLV 1876 * 245.1.{1-253} Unassigned 1877 * 245.1.{254-255} Reserved 1878 Note that this example does not define an "Example-TLV" attribute. 1880 The number zero (0) MUST NOT be used. The last two numbers (254 and 1881 255) MUST be reserved for future use. All other numbers are 1882 available for assignment by IANA. 1884 The Attribute Type Tree can be extended multiple levels in one 1885 specification. For example, the "Example-TLV" above could contain 1886 another attribute, "Example-Nested-TLV", of type "tlv". It would 1887 define an additional extension to the registry as follows: 1889 * 245.1.1 Example-Nested-TLV 1890 * 245.1.1.{1-253} Unassigned 1891 * 245.1.1.{254-255} Reserved 1892 This process may be continued to additional levels of nesting. 1894 Again, this example does not define an "Example-Nested-TLV" 1895 attribute. 1897 9.5. Extending the RADIUS Attribute Type Space 1899 The extended RADIUS Attribute Type space may eventually approach 1900 exhaustion. When necessary, the space SHOULD be extended by 1901 publication of a specification which allocates new attributes of 1902 either the "Extended Type", or the "Extended Type with flags" format. 1903 The specification SHOULD request allocation of a specific number from 1904 the "Reserved" RADIUS Attribute type space, such as 247. The 1905 attribute(s) SHOULD be given a name which follows the naming 1906 convention used in this document. The Extended-Type value of 26 MUST 1907 be allocated to a "Vendor Specific" attribute, of data type "esv". 1908 The Extended-Type values of 241 through 255 MUST be marked as 1909 "Reserved". 1911 IANA SHOULD allocate the attribute(s) as requested. For example, if 1912 allocation of attribute 247 is requested, the following definitions 1913 MUST be made in the specification, and allocated by IANA. 1915 * 247.1 Extended-Attribute-7 1916 * 247.{1-25} Unassigned 1917 * 247.26 Extended-Vendor-Specific-7 1918 * 247.{27-240} Unassigned 1919 * 247.{241-255} Reserved 1921 We note,however, that the above list is an example, and we do not 1922 request or perform allocation of attribute 247 in this document. 1924 10. Security Considerations 1926 This document defines new formats for data carried inside of RADIUS, 1927 but otherwise makes no changes to the security of the RADIUS 1928 protocol. 1930 Attacks on cryptographic hashes are well known, and are getting 1931 better with time, as discussed in[RFC4270]. RADIUS uses the MD5 hash 1932 [RFC1321] for packet authentication and attribute obfuscation. There 1933 are ongoing efforts in the IETF to analyze and address these issues 1934 for the RADIUS protocol. 1936 As with any protocol change, code changes are required in order to 1937 implement the new features. These code changes have the potential to 1938 introduce new vulnerabilities in the software. Since the RADIUS 1939 server performs network authentication, it is an inviting target for 1940 attackers. We RECOMMEND that access to RADIUS servers be kept to a 1941 minimum. 1943 11. References 1945 11.1. Normative references 1947 [RFC1321] 1948 Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, April, 1949 1992 1951 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1952 Requirement Levels", RFC 2119, March, 1997. 1954 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 1955 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1956 2000. 1958 11.2. Informative references 1960 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1962 [RFC2868] Zorn, G., et al, " RADIUS Attributes for Tunnel Protocol 1963 Support", RFC 2868, June 2000. 1965 [RFC4270] Hoffman, P, and Schneier, B, "Attacks on Cryptographic Hashes 1966 in Internet Protocols", RFC 4270, November 2005. 1968 [RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote 1969 Authentication Dial In User Service (RADIUS)", RFC 5176, 1970 January 2008. 1972 [RFC5234] Crocker, D. (Ed.), and Overell, P., "Augmented BNF for Syntax 1973 Specifications: ABNF", RFC 5234, October 2005. 1975 [GUIDELINES] 1976 DeKok, A., and Weber, G., "RADIUS Design Guidelines", draft- 1977 ietf-radext-design-18.txt, work in progress. 1979 [EDUROAM] Internal Eduroam testing page, data retrieved 04 August 2010. 1981 [ATTR] http://github.com/alandekok/freeradius- 1982 server/tree/master/share/, data retrieved September 2010. 1984 Acknowledgments 1986 This document is the result of long discussions in the IETF RADEXT 1987 working group. The authors would like to thank all of the 1988 participants who contributed various ideas over the years. Their 1989 feedback has been invaluable, and has helped to make this 1990 specification better. 1992 Appendix A - Extended Attribute Generator Program 1994 This section contains "C" program source which can be used for 1995 testing. It reads a line-oriented text file, parses it to create 1996 RADIUS formatted attributes, and prints the hex version of those 1997 attributes to standard output. 1999 The input accepts a grammar similar to that given in Section 8, with 2000 some modifications for usability. For example, blank lines are 2001 allowed, lines beginning with a '#' character are interpreted as 2002 comments, numbers (RADIUS Types, etc.) are checked for minimum / 2003 maximum values, and RADIUS Attribute lengths are enforced. 2005 The program is included here for demonstration purposes only, and 2006 does not define a standard of any kind. 2008 ------------------------------------------------------------ 2009 /* 2010 * Copyright (c) 2010 IETF Trust and the persons identified as 2011 * authors of the code. All rights reserved. 2012 * 2013 * Redistribution and use in source and binary forms, with or without 2014 * modification, are permitted provided that the following conditions 2015 * are met: 2016 * 2017 * Redistributions of source code must retain the above copyright 2018 * notice, this list of conditions and the following disclaimer. 2019 * 2020 * Redistributions in binary form must reproduce the above copyright 2021 * notice, this list of conditions and the following disclaimer in 2022 * the documentation and/or other materials provided with the 2023 * distribution. 2024 * 2025 * Neither the name of Internet Society, IETF or IETF Trust, nor the 2026 * names of specific contributors, may be used to endorse or promote 2027 * products derived from this software without specific prior written 2028 * permission. 2029 * 2030 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 2031 * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, 2032 * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 2033 * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 2034 * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS 2035 * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 2036 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED 2037 * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 2038 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON 2039 * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 2040 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT 2041 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 2042 * SUCH DAMAGE. 2043 * 2044 * Author: Alan DeKok 2045 */ 2046 #include 2047 #include 2048 #include 2049 #include 2050 #include 2051 #include 2053 static int encode_tlv(char *buffer, uint8_t *output, size_t outlen); 2055 static const char *hextab = "0123456789abcdef"; 2057 static int encode_data_string(char *buffer, 2058 uint8_t *output, size_t outlen) 2059 { 2060 int length = 0; 2061 char *p; 2063 p = buffer + 1; 2065 while (*p && (outlen > 0)) { 2066 if (*p == '"') { 2067 return length; 2068 } 2070 if (*p != '\\') { 2071 *(output++) = *(p++); 2072 outlen--; 2073 length++; 2074 continue; 2075 } 2077 switch (p[1]) { 2078 default: 2079 *(output++) = p[1]; 2080 break; 2082 case 'n': 2083 *(output++) = '\n'; 2084 break; 2086 case 'r': 2087 *(output++) = '\r'; 2088 break; 2090 case 't': 2091 *(output++) = '\t'; 2092 break; 2093 } 2095 outlen--; 2096 length++; 2097 } 2099 fprintf(stderr, "String is not terminated\n"); 2100 return 0; 2101 } 2103 static int encode_data_tlv(char *buffer, char **endptr, 2104 uint8_t *output, size_t outlen) 2105 { 2106 int depth = 0; 2107 int length; 2108 char *p; 2110 for (p = buffer; *p != '\0'; p++) { 2111 if (*p == '{') depth++; 2112 if (*p == '}') { 2113 depth--; 2114 if (depth == 0) break; 2115 } 2116 } 2118 if (*p != '}') { 2119 fprintf(stderr, "No trailing '}' in string starting " 2120 "with \"%s\"\n", 2121 buffer); 2122 return 0; 2123 } 2125 *endptr = p + 1; 2126 *p = '\0'; 2128 p = buffer + 1; 2129 while (isspace((int) *p)) p++; 2131 length = encode_tlv(p, output, outlen); 2132 if (length == 0) return 0; 2134 return length; 2135 } 2136 static int encode_data(char *p, uint8_t *output, size_t outlen) 2137 { 2138 int length; 2140 if (!isspace((int) *p)) { 2141 fprintf(stderr, "Invalid character following attribute " 2142 "definition\n"); 2143 return 0; 2144 } 2146 while (isspace((int) *p)) p++; 2148 if (*p == '{') { 2149 int sublen; 2150 char *q; 2152 length = 0; 2154 do { 2155 while (isspace((int) *p)) p++; 2156 if (!*p) { 2157 if (length == 0) { 2158 fprintf(stderr, "No data\n"); 2159 return 0; 2160 } 2162 break; 2163 } 2165 sublen = encode_data_tlv(p, &q, output, outlen); 2166 if (sublen == 0) return 0; 2168 length += sublen; 2169 output += sublen; 2170 outlen -= sublen; 2171 p = q; 2172 } while (*q); 2174 return length; 2175 } 2177 if (*p == '"') { 2178 length = encode_data_string(p, output, outlen); 2179 return length; 2180 } 2182 length = 0; 2183 while (*p) { 2184 char *c1, *c2; 2186 while (isspace((int) *p)) p++; 2188 if (!*p) break; 2190 if(!(c1 = memchr(hextab, tolower((int) p[0]), 16)) || 2191 !(c2 = memchr(hextab, tolower((int) p[1]), 16))) { 2192 fprintf(stderr, "Invalid data starting at " 2193 "\"%s\"\n", p); 2194 return 0; 2195 } 2197 *output = ((c1 - hextab) << 4) + (c2 - hextab); 2198 output++; 2199 length++; 2200 p += 2; 2202 outlen--; 2203 if (outlen == 0) { 2204 fprintf(stderr, "Too much data\n"); 2205 return 0; 2206 } 2207 } 2209 if (length == 0) { 2210 fprintf(stderr, "Empty string\n"); 2211 return 0; 2212 } 2214 return length; 2215 } 2217 static int decode_attr(char *buffer, char **endptr) 2218 { 2219 long attr; 2221 attr = strtol(buffer, endptr, 10); 2222 if (*endptr == buffer) { 2223 fprintf(stderr, "No valid number found in string " 2224 "starting with \"%s\"\n", buffer); 2225 return 0; 2226 } 2228 if (!**endptr) { 2229 fprintf(stderr, "Nothing follows attribute number\n"); 2230 return 0; 2231 } 2232 if ((attr <= 0) || (attr > 256)) { 2233 fprintf(stderr, "Attribute number is out of valid " 2234 "range\n"); 2235 return 0; 2236 } 2238 return (int) attr; 2239 } 2241 static int decode_vendor(char *buffer, char **endptr) 2242 { 2243 long vendor; 2245 if (*buffer != '.') { 2246 fprintf(stderr, "Invalid separator before vendor id\n"); 2247 return 0; 2248 } 2250 vendor = strtol(buffer + 1, endptr, 10); 2251 if (*endptr == (buffer + 1)) { 2252 fprintf(stderr, "No valid vendor number found\n"); 2253 return 0; 2254 } 2256 if (!**endptr) { 2257 fprintf(stderr, "Nothing follows vendor number\n"); 2258 return 0; 2259 } 2261 if ((vendor <= 0) || (vendor > (1 << 24))) { 2262 fprintf(stderr, "Vendor number is out of valid range\n"); 2263 return 0; 2264 } 2266 if (**endptr != '.') { 2267 fprintf(stderr, "Invalid data following vendor number\n"); 2268 return 0; 2269 } 2270 (*endptr)++; 2272 return (int) vendor; 2273 } 2275 static int encode_tlv(char *buffer, uint8_t *output, size_t outlen) 2276 { 2277 int attr; 2278 int length; 2279 char *p; 2280 attr = decode_attr(buffer, &p); 2281 if (attr == 0) return 0; 2283 output[0] = attr; 2284 output[1] = 2; 2286 if (*p == '.') { 2287 p++; 2288 length = encode_tlv(p, output + 2, outlen - 2); 2290 } else { 2291 length = encode_data(p, output + 2, outlen - 2); 2292 } 2294 if (length == 0) return 0; 2295 if (length > (255 - 2)) { 2296 fprintf(stderr, "TLV data is too long\n"); 2297 return 0; 2298 } 2300 output[1] += length; 2302 return length + 2; 2303 } 2305 static int encode_vsa(char *buffer, uint8_t *output, size_t outlen) 2306 { 2307 int vendor; 2308 int attr; 2309 int length; 2310 char *p; 2312 vendor = decode_vendor(buffer, &p); 2313 if (vendor == 0) return 0; 2315 output[0] = 0; 2316 output[1] = (vendor >> 16) & 0xff; 2317 output[2] = (vendor >> 8) & 0xff; 2318 output[3] = vendor & 0xff; 2320 length = encode_tlv(p, output + 4, outlen - 4); 2321 if (length == 0) return 0; 2322 if (length > (255 - 6)) { 2323 fprintf(stderr, "VSA data is too long\n"); 2324 return 0; 2325 } 2326 return length + 4; 2327 } 2329 static int encode_evs(char *buffer, uint8_t *output, size_t outlen) 2330 { 2331 int vendor; 2332 int attr; 2333 int length; 2334 char *p; 2336 vendor = decode_vendor(buffer, &p); 2337 if (vendor == 0) return 0; 2339 attr = decode_attr(p, &p); 2340 if (attr == 0) return 0; 2342 output[0] = 0; 2343 output[1] = (vendor >> 16) & 0xff; 2344 output[2] = (vendor >> 8) & 0xff; 2345 output[3] = vendor & 0xff; 2346 output[4] = attr; 2348 length = encode_data(p, output + 5, outlen - 5); 2349 if (length == 0) return 0; 2351 return length + 5; 2352 } 2354 static int encode_extended(char *buffer, 2355 uint8_t *output, size_t outlen) 2356 { 2357 int attr; 2358 int length; 2359 char *p; 2361 attr = decode_attr(buffer, &p); 2362 if (attr == 0) return 0; 2364 output[0] = attr; 2366 if (attr == 26) { 2367 length = encode_evs(p, output + 1, outlen - 1); 2368 } else { 2369 length = encode_data(p, output + 1, outlen - 1); 2370 } 2371 if (length == 0) return 0; 2372 if (length > (255 - 3)) { 2373 fprintf(stderr, "Extended Attr data is too long\n"); 2374 return 0; 2375 } 2377 return length + 1; 2378 } 2380 static int encode_extended_flags(char *buffer, 2381 uint8_t *output, size_t outlen) 2382 { 2383 int attr; 2384 int length, total; 2385 char *p; 2387 attr = decode_attr(buffer, &p); 2388 if (attr == 0) return 0; 2390 /* output[0] is the extended attribute */ 2391 output[1] = 4; 2392 output[2] = attr; 2393 output[3] = 0; 2395 if (attr == 26) { 2396 length = encode_evs(p, output + 4, outlen - 4); 2397 if (length == 0) return 0; 2399 output[1] += 5; 2400 length -= 5; 2401 } else { 2402 length = encode_data(p, output + 4, outlen - 4); 2403 } 2404 if (length == 0) return 0; 2406 total = 0; 2407 while (1) { 2408 int sublen = 255 - output[1]; 2410 if (length <= sublen) { 2411 output[1] += length; 2412 total += output[1]; 2413 break; 2414 } 2416 length -= sublen; 2418 memmove(output + 255 + 4, output + 255, length); 2419 memcpy(output + 255, output, 4); 2421 output[1] = 255; 2422 output[3] |= 0x80; 2424 output += 255; 2425 output[1] = 4; 2426 total += 255; 2427 } 2429 return total; 2430 } 2432 static int encode_rfc(char *buffer, uint8_t *output, size_t outlen) 2433 { 2434 int attr; 2435 int length, sublen; 2436 char *p; 2438 attr = decode_attr(buffer, &p); 2439 if (attr == 0) return 0; 2441 length = 2; 2442 output[0] = attr; 2443 output[1] = 2; 2445 if (attr == 26) { 2446 sublen = encode_vsa(p, output + 2, outlen - 2); 2448 } else if ((*p == ' ') || ((attr < 241) || (attr > 246))) { 2449 sublen = encode_data(p, output + 2, outlen - 2); 2451 } else { 2452 if (*p != '.') { 2453 fprintf(stderr, "Invalid data following " 2454 "attribute number\n"); 2455 return 0; 2456 } 2458 if (attr < 245) { 2459 sublen = encode_extended(p + 1, 2460 output + 2, outlen - 2); 2461 } else { 2463 /* 2464 * Not like the others! 2465 */ 2466 return encode_extended_flags(p + 1, output, outlen); 2467 } 2468 } 2469 if (sublen == 0) return 0; 2470 if (sublen > (255 -2)) { 2471 fprintf(stderr, "RFC Data is too long\n"); 2472 return 0; 2473 } 2475 output[1] += sublen; 2476 return length + sublen; 2477 } 2479 int main(int argc, char *argv[]) 2480 { 2481 int lineno; 2482 size_t i, outlen; 2483 FILE *fp; 2484 char input[8192], buffer[8192]; 2485 uint8_t output[4096]; 2487 if ((argc < 2) || (strcmp(argv[1], "-") == 0)) { 2488 fp = stdin; 2489 } else { 2490 fp = fopen(argv[1], "r"); 2491 if (!fp) { 2492 fprintf(stderr, "Error opening %s: %s\n", 2493 argv[1], strerror(errno)); 2494 exit(1); 2495 } 2496 } 2498 lineno = 0; 2499 while (fgets(buffer, sizeof(buffer), fp) != NULL) { 2500 char *p = strchr(buffer, '\n'); 2502 lineno++; 2504 if (!p) { 2505 if (!feof(fp)) { 2506 fprintf(stderr, "Line %d too long in %s\n", 2507 lineno, argv[1]); 2508 exit(1); 2509 } 2510 } else { 2511 *p = '\0'; 2512 } 2514 p = strchr(buffer, '#'); 2515 if (p) *p = '\0'; 2517 p = buffer; 2518 while (isspace((int) *p)) p++; 2519 if (!*p) continue; 2521 strcpy(input, p); 2522 outlen = encode_rfc(input, output, sizeof(output)); 2523 if (outlen == 0) { 2524 fprintf(stderr, "Parse error in line %d of %s\n", 2525 lineno, input); 2526 exit(1); 2527 } 2529 printf("%s -> ", buffer); 2530 for (i = 0; i < outlen; i++) { 2531 printf("%02x ", output[i]); 2532 } 2533 printf("\n"); 2534 } 2536 if (fp != stdin) fclose(fp); 2538 return 0; 2539 } 2540 ------------------------------------------------------------ 2542 Author's Address 2544 Alan DeKok 2545 Network RADIUS SARL 2546 15 av du Granier 2547 38240 Meylan 2548 France 2550 Email: aland@networkradius.com 2551 URI: http://networkradius.com 2553 Avi Lior 2554 Bridgewater Systems Corporation 2555 303 Terry Fox Drive 2556 Suite 100 2557 Ottawa, Ontario K2K 3J1 2558 Canada 2560 Phone: +1 (613) 591-6655 2561 Email: avi@bridgewatersystems.com 2562 URI: http://www.bridgewatersystems.com/