idnits 2.17.1 draft-dekok-radext-radius-extensions-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC2865, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2866, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5176, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (Using the creation date from RFC2865, updated by this document, for RFC5378 checks: 1999-03-04) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (8 February 2011) is 4825 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 2503 -- Looks like a reference, but probably isn't: '0' on line 2438 -- Looks like a reference, but probably isn't: '2' on line 2388 -- Looks like a reference, but probably isn't: '3' on line 2418 -- Looks like a reference, but probably isn't: '4' on line 2342 -- Looks like a reference, but probably isn't: '8192' on line 2480 -- Looks like a reference, but probably isn't: '4096' on line 2481 == Unused Reference: 'RFC2866' is defined on line 1956, but no explicit reference was found in the text == Unused Reference: 'RFC5176' is defined on line 1964, 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 (~~), 7 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: March 1, 2011 8 8 February 2011 10 Remote Authentication Dial In User Service (RADIUS) Protocol 11 Extensions 12 draft-dekok-radext-radius-extensions-01.txt 14 Abstract 16 The Remote Authentication Dial In User Service (RADIUS) protocol is 17 nearing exhaustion of its current 8-bit attribute type space. In 18 addition, experience shows a growing need for complex grouping, along 19 with attributes which can carry more than 253 octets of data. This 20 document defines changes to RADIUS which address all of the above 21 problems. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on 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 ................................... 33 98 7. Rationale ................................................ 34 99 7.1. Attribute Audit ..................................... 34 100 8. Examples ................................................. 34 101 8.1. Extended Type ....................................... 36 102 8.2. Extended Type with Flags ............................ 37 103 9. IANA Considerations ...................................... 39 104 9.1. Attribute Allocations ............................... 39 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 ................................. 42 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. 1419 6.1. Allocation Request Guidelines 1421 The following items give guidelines for allocation requests made in a 1422 RADIUS specification. 1424 * Discretion is RECOMMENDED when requesting allocation of attributes. 1425 The new space is much larger than the old one, but it is not 1426 infinite. 1428 * When the Type spaces of 241.*, 242.*, 243.*, or 244.* are nearing 1429 exhaustion, a new specification SHOULD be written which requests 1430 allocation of one or more RADIUS Attributes from the "Reserved" 1431 space, using the "Extended Type" format. This process is 1432 preferable to allocating "small" attributes from the 256.* and 1433 246.* Type spaces. 1435 * When the Type spaces of 245.* or 246.* are nearing exhaustion, a 1436 new specification SHOULD be written which requests allocation of 1437 one or more RADIUS Attributes from the "Reserved" space, using the 1438 "Extended Type with flags" format. 1440 * All other specifications SHOULD NOT request allocation from the 1441 standard Attribute Type Space (i.e. Attributes 1 through 255). 1442 That space is deprecated, and is not to be used. 1444 * Attributes which encode 252 octets or less of data SHOULD 1445 request allocation from the Type spaces of 241.*, 242.*, 243.*, 1446 or 244.*. 1448 * Attributes which encode 253 octets or more of data MUST request 1449 allocation from the Type spaces of 245.* or 246.*. 1451 * Where a group of TLVs is strictly defined, and not expected to 1452 change, and and totals less than 247 octets of data, they SHOULD 1453 request allocation from the Type spaces of 241.*, 242.*, 243.*, or 1454 244.*. 1456 * Where a group of TLVs is loosely defined, or is expected to change, 1457 they SHOULD request allocation from the Type spaces of 245.* or 1458 246.*. 1460 6.2. TLV Guidelines 1462 The following items give guidelines for specifications using TLVs. 1464 * when multiple attributes are intended to be grouped or managed 1465 together, the use of TLVs to group related attributes is 1466 RECOMMENDED. 1468 * more than 4 layers (depth) of TLV nesting is NOT RECOMMENDED. 1470 * Specifications SHOULD that the interpretation of an attribute 1471 depends only on its OID, and not on its encoding in the RADIUS 1472 packet. 1474 6.3. Implementation Guidelines 1476 * RADIUS Server implementations SHOULD support this specification 1477 as soon as possible. 1479 * RADIUS Proxy servers SHOULD forward all attributes, even ones 1480 which they do not understand, or which are not in a local 1481 dictionary. These attributes SHOULD be forwarded verbatim, with 1482 no modifications or changes. 1484 * Any attribute which is allocated from the Type spaces of 245.* or 1485 246.*, of data type "text", "string", or "tlv" can end up carrying 1486 more than 251 octets of data, up to the maximum RADIUS packet 1487 length (~4096 octets). Specifications defining such attributes 1488 SHOULD define a maximum length. 1490 6.4. Vendor Guidelines 1492 * Vendors SHOULD use the existing Vendor-Specific Attribute Type 1493 space in preference to the new Extended-Vendor-Specific 1494 attributes, as this specification may take time to be widely 1495 deployed. 1497 7. Rationale 1499 The path to extending the RADIUS protocol has been long and arduous. 1500 A number of proposals have been made and discarded by the RADEXT 1501 working group. These proposals have been judged to be either too 1502 bulky, too complex, too simple, or to be unworkable in practice. We 1503 do not otherwise explain here why earlier proposals did not obtain 1504 working group consensus. 1506 This proposal has the benefit of being simple, as the "Extended Type" 1507 format requires only a one octet change to the Attribute format. 1509 7.1. Attribute Audit 1511 An audit of almost five thousand publicly available attributes 1512 [ATTR], shows the statistics summarized below. The attributes include 1513 over 100 Vendor dictionaries, along with the IANA assigned 1514 attributes: 1516 Count Data Type 1517 ----- --------- 1518 2257 integer 1519 1762 text 1520 273 IPv4 Address 1521 235 string 1522 96 other data types 1523 35 IPv6 Address 1524 18 date 1525 4 Interface Id 1526 3 IPv6 Prefix 1528 4683 Total 1530 The entries in the "Data Type" column are data types recommended by 1531 [GUIDELINES]. The "other data types" row encompasses data types not 1532 recommended by that document. 1534 Manual inspection of the dictionaries shows that approximately 20 (or 1535 0.5%) attributes have the ability to transport more than 253 octets 1536 of data. These attributes are divided between VSAs, and a small 1537 number of standard Attributes. The "Extended Type with Flags" 1538 formats is therefore important, but "long" attributes have had 1539 limited deployment. 1541 8. Examples 1543 A few examples are presented here, in order to illustrate the 1544 encoding of the new attribute formats. These examples are not 1545 intended to be exhaustive, as many others are possible. For 1546 simplicity, we do not show complete packets, only attributes. 1548 The examples are given using a domain-specific language implemented 1549 by the program given in Appendix A. The language is line oriented, 1550 and composed of a sequence of lines matching the grammar ([RFC5234]) 1551 given below: 1553 Identifier = 1*DIGIT *( "." 1*DIGIT ) 1555 HEXCHAR = HEXDIG HEXDIG 1557 STRING = DQUOTE 1*CHAR DQUOTE 1559 TLV = "{" 1*DIGIT DATA "}" 1561 DATA = 1*HEXCHAR / 1*TLV / STRING 1563 LINE = Identifier DATA 1565 The progam has additional restrictions on its input that are not 1566 reflected in the above grammar. For example, the portions of the 1567 Identifier which refer to Type and Extended-Type are limited to 1568 values between 1 and 255. We trust that the source code in Appendix 1569 A is clear, and that these restrictions do not negatively affect the 1570 comprehensability of the examples. 1572 The program reads the input text, and interprets it as a set of 1573 instructions to create RADIUS Attributes. It then prints the hex 1574 encoding of those attributes. It implements the minimum set of 1575 functionality which achieves that goal. This minimalism means that 1576 it does not use attribute dictionaries; it does not implement support 1577 for RADIUS data types; it can be used to encode attributes with 1578 invalid data field(s); and there is no requirement for consistency 1579 from one example to the next. For example, it can be used to encode 1580 a User-Name attribute which contains non-UTF8 data, or a Framed-IP- 1581 Address which contains 253 octets of ASCII data. As a result, it 1582 cannot be used to create RADIUS Attributes for transport in a RADIUS 1583 message. 1585 However, the program correctly encodes the RADIUS attribute fields of 1586 "Type", "Length", "Extended-Type", "More", "Flags", "Vendor-Id", 1587 "Vendor-Type", and "Vendor-Length". It can therefore be used to 1588 encode example attributes from input which is humanly readable. 1590 We do not give examples of "malformed" or "invalid attributes". We 1591 also note that the examples show format, and not consistent meaning. 1592 A particular attribute type code may be used to demonstrate two 1593 different formats. In real specifications, attributes have a static 1594 definitions based on their type code. 1596 The examples given below are strictly for demonstration purposes 1597 only, and do not provide a standard of any kind. 1599 8.1. Extended Type 1601 The following are a series of examples of the "Extended Type" format. 1603 Attribute encapsulating textual data. 1605 241.1 "bob" 1606 -> f1 06 01 62 6f 62 1608 Attribute encapsulating a TLV with TLV-Type of one (1). 1610 241.2 { 1 23 45 } 1611 -> f1 07 02 01 04 23 45 1613 Attribute encapsulating two TLVs, one after the other. 1615 241.2 { 1 23 45 } { 2 67 89 } 1616 -> f1 0b 02 01 04 23 45 02 04 67 89 1618 Attribute encapsulating two TLVs, where the second TLV is itself 1619 encapsulating a TLV. 1621 241.2 { 1 23 45 } { 3 { 1 ab cd } } 1622 -> f1 0d 02 01 04 23 45 03 06 01 04 ab cd 1624 Attribute encapsulating two TLVs, where the second TLV is itself 1625 encapsulating two TLVs. 1627 241.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } 1628 -> f1 12 02 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f 1630 Attribute encapsulating a TLV, which in turn encapsulates a TLV, 1631 to a depth of 5 nestings. 1633 241.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } 1634 -> f1 0f 01 01 0c 02 0a 03 08 04 06 05 04 cd ef 1636 Attribute encapsulating an extended Vendor Specific attribute, 1637 with Vendor-Id of 1, and Vendor-Type of 4, which in turn 1638 encapsulates textual data. 1640 241.26.1.4 "test" 1641 -> f1 0c 1a 00 00 00 01 04 74 65 73 74 1643 Attribute encapsulating an extended Vendor Specific attribute, with 1644 Vendor-Id of 1, and Vendor-Type of 5, which in turn encapsulates 1645 a TLV with TLV-Type of 3, which encapsulates textual data. 1647 241.26.1.5 { 3 "test" } 1648 -> f1 0e 1a 00 00 00 01 05 03 06 74 65 73 74 1650 8.2. Extended Type with Flags 1652 The following are a series of examples of the "Extended Type with 1653 flags" format. 1655 Attribute encapsulating textual data. 1657 245.1 "bob" 1658 -> f5 07 01 00 62 6f 62 1660 Attribute encapsulating a TLV with TLV-Type of one (1). 1662 245.2 { 1 23 45 } 1663 -> f5 08 02 00 01 04 23 45 1665 Attribute encapsulating two TLVs, one after the other. 1667 245.2 { 1 23 45 } { 2 67 89 } 1668 -> f5 0c 02 00 01 04 23 45 02 04 67 89 1670 Attribute encapsulating two TLVs, where the second TLV is itself 1671 encapsulating a TLV. 1673 245.2 { 1 23 45 } { 3 { 1 ab cd } } 1674 -> f5 0e 02 00 01 04 23 45 03 06 01 04 ab cd 1676 Attribute encapsulating two TLVs, where the second TLV is itself 1677 encapsulating two TLVs. 1679 245.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } 1680 -> f5 13 02 00 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f 1682 Attribute encapsulating a TLV, which in turn encapsulates a TLV, 1683 to a depth of 5 nestings. 1685 245.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } 1686 -> f5 10 01 00 01 0c 02 0a 03 08 04 06 05 04 cd ef 1688 Attribute encapsulating an extended Vendor Specific attribute, 1689 with Vendor-Id of 1, and Vendor-Type of 4, which in turn 1690 encapsulates textual data. 1692 245.26.1.4 "test" 1693 -> f5 0d 1a 00 00 00 00 01 04 74 65 73 74 1695 Attribute encapsulating an extended Vendor Specific attribute, 1696 with Vendor-Id of 1, and Vendor-Type of 5, which in turn 1697 encapsulates a TLV with TLV-Type of 3, which encapsulates 1698 textual data. 1700 245.26.1.5 { 3 "test" } 1701 -> f5 0f 1a 00 00 00 00 01 05 03 06 74 65 73 74 1703 Attribute encapsulating more than 251 octets of data. The "Data" 1704 portions are indented for readability. 1706 245.4 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1707 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1708 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1709 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1710 aaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1711 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1712 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1713 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1714 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbcccccccccccccccccccc 1715 cccccccccc 1716 -> f5 ff 04 80 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1717 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1718 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1719 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1720 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1721 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1722 aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb bb bb bb bb bb 1723 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1724 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1725 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1726 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1727 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1728 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 13 04 00 cc 1729 cc cc cc cc cc cc cc cc cc cc cc cc cc cc 1731 Attribute encapsulating an extended Vendor Specific attribute, 1732 with Vendor-Id of 1, and Vendor-Type of 6, which in turn 1733 encapsulates more than 251 octets of data. 1735 As the VSA encapsulates more than 251 octets of data, it is 1736 split into two RADIUS attributes. The first attribute has the 1737 More flag set, and carries the Vendor-Id and Vendor-Type. 1738 The second attribute has the More flag clear, and carries 1739 the rest of the data portion of the VSA. Note that the second 1740 attribute does not include the Vendor-Id ad Vendor-Type fields. 1742 The "Data" portions are indented for readability. 1744 245.26.1.6 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1745 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1746 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1747 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 1748 aaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1749 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1750 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1751 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1752 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbccccccccccccc 1753 ccccccccccccccccc 1754 -> f5 ff 1a 80 00 00 00 01 06 aa aa aa aa aa aa aa aa aa aa aa 1755 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1756 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1757 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1758 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1759 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 1760 aa aa aa aa aa aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb 1761 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1762 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1763 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1764 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1765 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 1766 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 17 1a 00 bb 1767 bb bb bb bb cc cc cc cc cc cc cc cc cc cc 13 45 67 89 1769 9. IANA Considerations 1771 This document has multiple impacts on IANA, in the "RADIUS Attribute 1772 Types" registry. Attribute types which were previously reserved are 1773 now allocated, previously free attributes are marked deprecated, and 1774 the registry is extended from a simple 8-bit array to a tree-like 1775 structure, up to a maximum depth of 125 nodes. 1777 9.1. Attribute Allocations 1779 IANA is requested to move the "Unassigned" numbers in the range 1780 144-191 from "Unassigned" to "Deprecated". This status means that 1781 allocations SHOULD NOT be made from this space. Instead, allocations 1782 SHOULD be taken from the Extended Type space, starting with lower 1783 numbered attributes. However, allocation from the "Deprecated" space 1784 MAY still be performed by publication of an IETF specification, where 1785 that specification requests allocation from the "Deprecated" space, 1786 and gives reasons why use of the Extended Type space is impossible. 1788 IANA is requested to move the following numbers from "Reserved", to 1789 allocated, with the following names: 1791 * 241 Extended-Type-1 1792 * 242 Extended-Type-2 1793 * 243 Extended-Type-3 1794 * 244 Extended-Type-4 1795 * 245 Extended-Type-Flagged-1 1796 * 246 Extended-Type-Flagged-2 1798 These attributes serve as an encapsulation layer for the new RADIUS 1799 Attribute Type tree. 1801 9.2. RADIUS Attribute Type Tree 1803 Each of the attributes allocated above extends the "RADIUS Attribute 1804 Types" to an N-ary tree, via a "dotted number" notation. Each number 1805 in the tree is an 8-bit value (1 to 255). The value zero (0) MUST 1806 NOT be used. Currently, only one level of the tree is defined: 1808 * 241 Extended-Attribute-1 1809 * 241.{1-25} Unassigned 1810 * 241.26 Extended-Vendor-Specific-1 1811 * 241.{27-240} Unassigned 1812 * 241.{241-255} Reserved 1813 * 242 Extended-Attribute-2 1814 * 242.{1-25} Unassigned 1815 * 242.26 Extended-Vendor-Specific-2 1816 * 242.{27-240} Unassigned 1817 * 243 Extended-Attribute-3 1818 * 242.{241-255} Reserved 1819 * 243.{1-25} Unassigned 1820 * 243.26 Extended-Vendor-Specific-3 1821 * 243.{27-240} Unassigned 1822 * 243.{241-255} Reserved 1823 * 244 Extended-Attribute-4 1824 * 244.{1-25} Unassigned 1825 * 244.26 Extended-Vendor-Specific-4 1826 * 244.{27-240} Unassigned 1827 * 244.{241-255} Reserved 1828 * 245 Extended-Attribute-5 1829 * 245.{1-25} Unassigned 1830 * 245.26 Extended-Vendor-Specific-5 1831 * 245.{27-240} Unassigned 1832 * 245.{241-255} Reserved 1833 * 246 Extended-Attribute-6 1834 * 246.{1-25} Unassigned 1835 * 245.26 Extended-Vendor-Specific-6 1836 * 246.{27-240} Unassigned 1837 * 246.{241-255} Reserved 1839 The values marked "Unassigned" above are available for assignment by 1840 IANA in future RADIUS specifications. The values marked "Reserved" 1841 are reserved for future use. 1843 9.3. Assignment Policy 1845 Attributes which are known to always require 252 octets or less of 1846 data MUST be assigned from the lowest unassigned number, e.g. 241.1, 1847 241.2, 241.3, etc. Attributes have the potential to transport more 1848 than 252 octets of data MUST be assigned from the 245.* or 246.* 1849 spaces, again using the lowest unassigned number, and MUST request 1850 assignment from the appropriate Attribute Type Space. 1852 The above policy can be difficult to enforce in the case of TLVs. 1853 For exaple, a set of TLVs may define a logical structure which totals 1854 less than 252 octets of data. Later extensions could assign 1855 additional sub-TLVs, and extend the structure to more than 252 octets 1856 of data. This capability means that TLV definitions SHOULD generally 1857 request assignment from the 245.* or 246.* space. 1859 9.4. Extending the Attribute Type Tree 1861 New specifications may request that the tree be extended to an 1862 additional level or levels. The attribute MUST be of type "tlv". 1864 For example, a specification may request that an "Example-TLV" 1865 attribute be assigned, of data type "tlv". If it is assigned the 1866 number 245.1, then it will define an extension to the registry as 1867 follows: 1869 * 245.1 Example-TLV 1870 * 245.1.{1-253} Unassigned 1871 * 245.1.{254-255} Reserved 1873 Note that this example does not define an "Example-TLV" attribute. 1875 The number zero (0) MUST NOT be used. The last two numbers (254 and 1876 255) MUST be reserved for future use. All other numbers are 1877 available for assignment by IANA. 1879 The Attribute Type Tree can be extended multiple levels in one 1880 specification. For example, the "Example-TLV" above could contain 1881 another attribute, "Example-Nested-TLV", of type "tlv". It would 1882 define an additional extension to the registry as follows: 1884 * 245.1.1 Example-Nested-TLV 1885 * 245.1.1.{1-253} Unassigned 1886 * 245.1.1.{254-255} Reserved 1887 This process may be continued to additional levels of nesting. 1889 Again, this example does not define an "Example-Nested-TLV" 1890 attribute. 1892 9.5. Extending the RADIUS Attribute Type Space 1894 The extended RADIUS Attribute Type space may eventually approach 1895 exhaustion. When necessary, the space SHOULD be extended by 1896 publication of a specification which allocates new attributes of 1897 either the "Extended Type", or the "Extended Type with flags" format. 1898 The specification SHOULD request allocation of a specific number from 1899 the "Reserved" RADIUS Attribute type space, such as 247. The 1900 attribute(s) SHOULD be given a name which follows the naming 1901 convention used in this document. The Extended-Type value of 26 MUST 1902 be allocated to a "Vendor Specific" attribute, of data type "esv". 1903 The Extended-Type values of 241 through 255 MUST be marked as 1904 "Reserved". 1906 IANA SHOULD allocate the attribute(s) as requested. For example, if 1907 allocation of attribute 247 is requested, the following definitions 1908 MUST be made in the specification, and allocated by IANA. 1910 * 247.1 Extended-Attribute-7 1911 * 247.{1-25} Unassigned 1912 * 247.26 Extended-Vendor-Specific-7 1913 * 247.{27-240} Unassigned 1914 * 247.{241-255} Reserved 1916 We note,however, that the above list is an example, and we do not 1917 request or perform allocation of attribute 247 in this document. 1919 10. Security Considerations 1921 This document defines new formats for data carried inside of RADIUS, 1922 but otherwise makes no changes to the security of the RADIUS 1923 protocol. 1925 Attacks on cryptographic hashes are well known, and are getting 1926 better with time, as discussed in[RFC4270]. RADIUS uses the MD5 hash 1928 [RFC1321] for packet authentication and attribute obfuscation. There 1929 are ongoing efforts in the IETF to analyze and address these issues 1930 for the RADIUS protocol. 1932 As with any protocol change, code changes are required in order to 1933 implement the new features. These code changes have the potential to 1934 introduce new vulnerabilities in the software. Since the RADIUS 1935 server performs network authentication, it is an inviting target for 1936 attackers. We RECOMMEND that access to RADIUS servers be kept to a 1937 minimum. 1939 11. References 1941 11.1. Normative references 1943 [RFC1321] 1944 Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, April, 1945 1992 1947 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1948 Requirement Levels", RFC 2119, March, 1997. 1950 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 1951 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1952 2000. 1954 11.2. Informative references 1956 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1958 [RFC2868] Zorn, G., et al, " RADIUS Attributes for Tunnel Protocol 1959 Support", RFC 2868, June 2000. 1961 [RFC4270] Hoffman, P, and Schneier, B, "Attacks on Cryptographic Hashes 1962 in Internet Protocols", RFC 4270, November 2005. 1964 [RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote 1965 Authentication Dial In User Service (RADIUS)", RFC 5176, 1966 January 2008. 1968 [RFC5234] Crocker, D. (Ed.), and Overell, P., "Augmented BNF for Syntax 1969 Specifications: ABNF", RFC 5234, October 2005. 1971 [GUIDELINES] 1972 DeKok, A., and Weber, G., "RADIUS Design Guidelines", draft- 1973 ietf-radext-design-18.txt, work in progress. 1975 [EDUROAM] Internal Eduroam testing page, data retrieved 04 August 2010. 1977 [ATTR] http://github.com/alandekok/freeradius- 1978 server/tree/master/share/, data retrieved September 2010. 1980 Acknowledgments 1982 This document is the result of long discussions in the IETF RADEXT 1983 working group. The authors would like to thank all of the 1984 participants who contributed various ideas over the years. Their 1985 feedback has been invaluable, and has helped to make this 1986 specification better. 1988 Appendix A - Extended Attribute Generator Program 1990 This section contains "C" program source which can be used for 1991 testing. It reads a line-oriented text file, parses it to create 1992 RADIUS formatted attributes, and prints the hex version of those 1993 attributes to standard output. 1995 The input accepts a grammar similar to that given in Section 8, with 1996 some modifications for usability. For example, blank lines are 1997 allowed, lines beginning with a '#' character are interpreted as 1998 comments, numbers (RADIUS Types, etc.) are checked for minimum / 1999 maximum values, and RADIUS Attribute lengths are enforced. 2001 The program is included here for demonstration purposes only, and 2002 does not define a standard of any kind. 2004 ------------------------------------------------------------ 2005 /* 2006 * Copyright (c) 2010 IETF Trust and the persons identified as 2007 * authors of the code. All rights reserved. 2008 * 2009 * Redistribution and use in source and binary forms, with or without 2010 * modification, are permitted provided that the following conditions 2011 * are met: 2012 * 2013 * Redistributions of source code must retain the above copyright 2014 * notice, this list of conditions and the following disclaimer. 2015 * 2016 * Redistributions in binary form must reproduce the above copyright 2017 * notice, this list of conditions and the following disclaimer in 2018 * the documentation and/or other materials provided with the 2019 * distribution. 2020 * 2021 * Neither the name of Internet Society, IETF or IETF Trust, nor the 2022 * names of specific contributors, may be used to endorse or promote 2023 * products derived from this software without specific prior written 2024 * permission. 2025 * 2026 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 2027 * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, 2028 * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 2029 * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 2030 * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS 2031 * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 2032 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED 2033 * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 2034 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON 2035 * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 2036 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT 2037 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 2038 * SUCH DAMAGE. 2039 * 2040 * Author: Alan DeKok 2041 */ 2042 #include 2043 #include 2044 #include 2045 #include 2046 #include 2047 #include 2049 static int encode_tlv(char *buffer, uint8_t *output, size_t outlen); 2051 static const char *hextab = "0123456789abcdef"; 2053 static int encode_data_string(char *buffer, 2054 uint8_t *output, size_t outlen) 2055 { 2056 int length = 0; 2057 char *p; 2059 p = buffer + 1; 2061 while (*p && (outlen > 0)) { 2062 if (*p == '"') { 2063 return length; 2064 } 2066 if (*p != '\\') { 2067 *(output++) = *(p++); 2068 outlen--; 2069 length++; 2070 continue; 2071 } 2073 switch (p[1]) { 2074 default: 2075 *(output++) = p[1]; 2076 break; 2078 case 'n': 2079 *(output++) = '\n'; 2080 break; 2082 case 'r': 2083 *(output++) = '\r'; 2084 break; 2086 case 't': 2087 *(output++) = '\t'; 2088 break; 2089 } 2091 outlen--; 2092 length++; 2093 } 2095 fprintf(stderr, "String is not terminated\n"); 2096 return 0; 2097 } 2099 static int encode_data_tlv(char *buffer, char **endptr, 2100 uint8_t *output, size_t outlen) 2101 { 2102 int depth = 0; 2103 int length; 2104 char *p; 2106 for (p = buffer; *p != '\0'; p++) { 2107 if (*p == '{') depth++; 2108 if (*p == '}') { 2109 depth--; 2110 if (depth == 0) break; 2111 } 2112 } 2114 if (*p != '}') { 2115 fprintf(stderr, "No trailing '}' in string starting " 2116 "with \"%s\"\n", 2117 buffer); 2118 return 0; 2119 } 2121 *endptr = p + 1; 2122 *p = '\0'; 2124 p = buffer + 1; 2125 while (isspace((int) *p)) p++; 2127 length = encode_tlv(p, output, outlen); 2128 if (length == 0) return 0; 2130 return length; 2131 } 2132 static int encode_data(char *p, uint8_t *output, size_t outlen) 2133 { 2134 int length; 2136 if (!isspace((int) *p)) { 2137 fprintf(stderr, "Invalid character following attribute " 2138 "definition\n"); 2139 return 0; 2140 } 2142 while (isspace((int) *p)) p++; 2144 if (*p == '{') { 2145 int sublen; 2146 char *q; 2148 length = 0; 2150 do { 2151 while (isspace((int) *p)) p++; 2152 if (!*p) { 2153 if (length == 0) { 2154 fprintf(stderr, "No data\n"); 2155 return 0; 2156 } 2158 break; 2159 } 2161 sublen = encode_data_tlv(p, &q, output, outlen); 2162 if (sublen == 0) return 0; 2164 length += sublen; 2165 output += sublen; 2166 outlen -= sublen; 2167 p = q; 2168 } while (*q); 2170 return length; 2171 } 2173 if (*p == '"') { 2174 length = encode_data_string(p, output, outlen); 2175 return length; 2176 } 2178 length = 0; 2179 while (*p) { 2180 char *c1, *c2; 2182 while (isspace((int) *p)) p++; 2184 if (!*p) break; 2186 if(!(c1 = memchr(hextab, tolower((int) p[0]), 16)) || 2187 !(c2 = memchr(hextab, tolower((int) p[1]), 16))) { 2188 fprintf(stderr, "Invalid data starting at " 2189 "\"%s\"\n", p); 2190 return 0; 2191 } 2193 *output = ((c1 - hextab) << 4) + (c2 - hextab); 2194 output++; 2195 length++; 2196 p += 2; 2198 outlen--; 2199 if (outlen == 0) { 2200 fprintf(stderr, "Too much data\n"); 2201 return 0; 2202 } 2203 } 2205 if (length == 0) { 2206 fprintf(stderr, "Empty string\n"); 2207 return 0; 2208 } 2210 return length; 2211 } 2213 static int decode_attr(char *buffer, char **endptr) 2214 { 2215 long attr; 2217 attr = strtol(buffer, endptr, 10); 2218 if (*endptr == buffer) { 2219 fprintf(stderr, "No valid number found in string " 2220 "starting with \"%s\"\n", buffer); 2221 return 0; 2222 } 2224 if (!**endptr) { 2225 fprintf(stderr, "Nothing follows attribute number\n"); 2226 return 0; 2227 } 2228 if ((attr <= 0) || (attr > 256)) { 2229 fprintf(stderr, "Attribute number is out of valid " 2230 "range\n"); 2231 return 0; 2232 } 2234 return (int) attr; 2235 } 2237 static int decode_vendor(char *buffer, char **endptr) 2238 { 2239 long vendor; 2241 if (*buffer != '.') { 2242 fprintf(stderr, "Invalid separator before vendor id\n"); 2243 return 0; 2244 } 2246 vendor = strtol(buffer + 1, endptr, 10); 2247 if (*endptr == (buffer + 1)) { 2248 fprintf(stderr, "No valid vendor number found\n"); 2249 return 0; 2250 } 2252 if (!**endptr) { 2253 fprintf(stderr, "Nothing follows vendor number\n"); 2254 return 0; 2255 } 2257 if ((vendor <= 0) || (vendor > (1 << 24))) { 2258 fprintf(stderr, "Vendor number is out of valid range\n"); 2259 return 0; 2260 } 2262 if (**endptr != '.') { 2263 fprintf(stderr, "Invalid data following vendor number\n"); 2264 return 0; 2265 } 2266 (*endptr)++; 2268 return (int) vendor; 2269 } 2271 static int encode_tlv(char *buffer, uint8_t *output, size_t outlen) 2272 { 2273 int attr; 2274 int length; 2275 char *p; 2276 attr = decode_attr(buffer, &p); 2277 if (attr == 0) return 0; 2279 output[0] = attr; 2280 output[1] = 2; 2282 if (*p == '.') { 2283 p++; 2284 length = encode_tlv(p, output + 2, outlen - 2); 2286 } else { 2287 length = encode_data(p, output + 2, outlen - 2); 2288 } 2290 if (length == 0) return 0; 2291 if (length > (255 - 2)) { 2292 fprintf(stderr, "TLV data is too long\n"); 2293 return 0; 2294 } 2296 output[1] += length; 2298 return length + 2; 2299 } 2301 static int encode_vsa(char *buffer, uint8_t *output, size_t outlen) 2302 { 2303 int vendor; 2304 int attr; 2305 int length; 2306 char *p; 2308 vendor = decode_vendor(buffer, &p); 2309 if (vendor == 0) return 0; 2311 output[0] = 0; 2312 output[1] = (vendor >> 16) & 0xff; 2313 output[2] = (vendor >> 8) & 0xff; 2314 output[3] = vendor & 0xff; 2316 length = encode_tlv(p, output + 4, outlen - 4); 2317 if (length == 0) return 0; 2318 if (length > (255 - 6)) { 2319 fprintf(stderr, "VSA data is too long\n"); 2320 return 0; 2321 } 2322 return length + 4; 2323 } 2325 static int encode_evs(char *buffer, uint8_t *output, size_t outlen) 2326 { 2327 int vendor; 2328 int attr; 2329 int length; 2330 char *p; 2332 vendor = decode_vendor(buffer, &p); 2333 if (vendor == 0) return 0; 2335 attr = decode_attr(p, &p); 2336 if (attr == 0) return 0; 2338 output[0] = 0; 2339 output[1] = (vendor >> 16) & 0xff; 2340 output[2] = (vendor >> 8) & 0xff; 2341 output[3] = vendor & 0xff; 2342 output[4] = attr; 2344 length = encode_data(p, output + 5, outlen - 5); 2345 if (length == 0) return 0; 2347 return length + 5; 2348 } 2350 static int encode_extended(char *buffer, 2351 uint8_t *output, size_t outlen) 2352 { 2353 int attr; 2354 int length; 2355 char *p; 2357 attr = decode_attr(buffer, &p); 2358 if (attr == 0) return 0; 2360 output[0] = attr; 2362 if (attr == 26) { 2363 length = encode_evs(p, output + 1, outlen - 1); 2364 } else { 2365 length = encode_data(p, output + 1, outlen - 1); 2366 } 2367 if (length == 0) return 0; 2368 if (length > (255 - 3)) { 2369 fprintf(stderr, "Extended Attr data is too long\n"); 2370 return 0; 2371 } 2373 return length + 1; 2374 } 2376 static int encode_extended_flags(char *buffer, 2377 uint8_t *output, size_t outlen) 2378 { 2379 int attr; 2380 int length, total; 2381 char *p; 2383 attr = decode_attr(buffer, &p); 2384 if (attr == 0) return 0; 2386 /* output[0] is the extended attribute */ 2387 output[1] = 4; 2388 output[2] = attr; 2389 output[3] = 0; 2391 if (attr == 26) { 2392 length = encode_evs(p, output + 4, outlen - 4); 2393 if (length == 0) return 0; 2395 output[1] += 5; 2396 length -= 5; 2397 } else { 2398 length = encode_data(p, output + 4, outlen - 4); 2399 } 2400 if (length == 0) return 0; 2402 total = 0; 2403 while (1) { 2404 int sublen = 255 - output[1]; 2406 if (length <= sublen) { 2407 output[1] += length; 2408 total += output[1]; 2409 break; 2410 } 2412 length -= sublen; 2414 memmove(output + 255 + 4, output + 255, length); 2415 memcpy(output + 255, output, 4); 2417 output[1] = 255; 2418 output[3] |= 0x80; 2420 output += 255; 2421 output[1] = 4; 2422 total += 255; 2423 } 2425 return total; 2426 } 2428 static int encode_rfc(char *buffer, uint8_t *output, size_t outlen) 2429 { 2430 int attr; 2431 int length, sublen; 2432 char *p; 2434 attr = decode_attr(buffer, &p); 2435 if (attr == 0) return 0; 2437 length = 2; 2438 output[0] = attr; 2439 output[1] = 2; 2441 if (attr == 26) { 2442 sublen = encode_vsa(p, output + 2, outlen - 2); 2444 } else if ((*p == ' ') || ((attr < 241) || (attr > 246))) { 2445 sublen = encode_data(p, output + 2, outlen - 2); 2447 } else { 2448 if (*p != '.') { 2449 fprintf(stderr, "Invalid data following " 2450 "attribute number\n"); 2451 return 0; 2452 } 2454 if (attr < 245) { 2455 sublen = encode_extended(p + 1, 2456 output + 2, outlen - 2); 2457 } else { 2459 /* 2460 * Not like the others! 2461 */ 2462 return encode_extended_flags(p + 1, output, outlen); 2463 } 2464 } 2465 if (sublen == 0) return 0; 2466 if (sublen > (255 -2)) { 2467 fprintf(stderr, "RFC Data is too long\n"); 2468 return 0; 2469 } 2471 output[1] += sublen; 2472 return length + sublen; 2473 } 2475 int main(int argc, char *argv[]) 2476 { 2477 int lineno; 2478 size_t i, outlen; 2479 FILE *fp; 2480 char input[8192], buffer[8192]; 2481 uint8_t output[4096]; 2483 if ((argc < 2) || (strcmp(argv[1], "-") == 0)) { 2484 fp = stdin; 2485 } else { 2486 fp = fopen(argv[1], "r"); 2487 if (!fp) { 2488 fprintf(stderr, "Error opening %s: %s\n", 2489 argv[1], strerror(errno)); 2490 exit(1); 2491 } 2492 } 2494 lineno = 0; 2495 while (fgets(buffer, sizeof(buffer), fp) != NULL) { 2496 char *p = strchr(buffer, '\n'); 2498 lineno++; 2500 if (!p) { 2501 if (!feof(fp)) { 2502 fprintf(stderr, "Line %d too long in %s\n", 2503 lineno, argv[1]); 2504 exit(1); 2505 } 2506 } else { 2507 *p = '\0'; 2508 } 2510 p = strchr(buffer, '#'); 2511 if (p) *p = '\0'; 2513 p = buffer; 2514 while (isspace((int) *p)) p++; 2515 if (!*p) continue; 2517 strcpy(input, p); 2518 outlen = encode_rfc(input, output, sizeof(output)); 2519 if (outlen == 0) { 2520 fprintf(stderr, "Parse error in line %d of %s\n", 2521 lineno, input); 2522 exit(1); 2523 } 2525 printf("%s -> ", buffer); 2526 for (i = 0; i < outlen; i++) { 2527 printf("%02x ", output[i]); 2528 } 2529 printf("\n"); 2530 } 2532 if (fp != stdin) fclose(fp); 2534 return 0; 2535 } 2536 ------------------------------------------------------------ 2538 Author's Address 2540 Alan DeKok 2541 Network RADIUS SARL 2542 15 av du Granier 2543 38240 Meylan 2544 France 2546 Email: aland@networkradius.com 2547 URI: http://networkradius.com 2549 Avi Lior 2550 Bridgewater Systems Corporation 2551 303 Terry Fox Drive 2552 Suite 100 2553 Ottawa, Ontario K2K 3J1 2554 Canada 2556 Phone: +1 (613) 591-6655 2557 Email: avi@bridgewatersystems.com 2558 URI: http://www.bridgewatersystems.com/