idnits 2.17.1 draft-ietf-radext-radius-extensions-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC2865, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3575, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2866, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5176, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC6158, 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 (28 January 2013) is 4104 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 3003 -- Looks like a reference, but probably isn't: '0' on line 2938 -- Looks like a reference, but probably isn't: '2' on line 2888 -- Looks like a reference, but probably isn't: '3' on line 2918 -- Looks like a reference, but probably isn't: '4' on line 2842 -- Looks like a reference, but probably isn't: '8192' on line 2980 -- Looks like a reference, but probably isn't: '4096' on line 2981 == Unused Reference: 'RFC5176' is defined on line 2449, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2866 ** Downref: Normative reference to an Informational RFC: RFC 5176 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'PEN' Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Alan DeKok 3 INTERNET-DRAFT Network RADIUS 4 Category: Proposed Standard Avi Lior 5 Updates: 2865, 2866, 3575, 5176, 6158 BWS 6 7 Expires: July 28, 2013 8 28 January 2013 10 Remote Authentication Dial In User Service (RADIUS) Protocol 11 Extensions 12 draft-ietf-radext-radius-extensions-09.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 June 26, 2013. 46 Copyright Notice 47 Copyright (c) 2013 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. Caveats and Limitations ............................. 6 64 1.1.1. Failure to Meet Certain Goals .................. 6 65 1.1.2. Implementation Recommendations ................. 6 66 1.2. Terminology ......................................... 7 67 1.3. Requirements Language ............................... 8 68 2. Extensions to RADIUS ..................................... 9 69 2.1. Extended Type ....................................... 10 70 2.2. Long Extended Type .................................. 11 71 2.3. TLV Data Type ....................................... 13 72 2.3.1. TLV Nesting .................................... 15 73 2.4. EVS Data Type ....................................... 16 74 2.5. Integer64 Data Type ................................. 17 75 2.6. Vendor-ID Field ..................................... 18 76 2.7. Attribute Naming and Type Identifiers ............... 18 77 2.7.1. Attribute and TLV Naming ....................... 18 78 2.7.2. Attribute Type Identifiers ..................... 19 79 2.7.3. TLV Identifiers ................................ 19 80 2.7.4. VSA Identifiers ................................ 20 81 2.8. Invalid Attributes .................................. 21 82 3. Attribute Definitions .................................... 21 83 3.1. Extended-Type-1 ..................................... 22 84 3.2. Extended-Type-2 ..................................... 23 85 3.3. Extended-Type-3 ..................................... 24 86 3.4. Extended-Type-4 ..................................... 25 87 3.5. Long-Extended-Type-1 ................................ 25 88 3.6. Long-Extended-Type-2 ................................ 27 89 4. Vendor Specific Attributes ............................... 28 90 4.1. Extended-Vendor-Specific-1 .......................... 28 91 4.2. Extended-Vendor-Specific-2 .......................... 29 92 4.3. Extended-Vendor-Specific-3 .......................... 31 93 4.4. Extended-Vendor-Specific-4 .......................... 32 94 4.5. Extended-Vendor-Specific-5 .......................... 33 95 4.6. Extended-Vendor-Specific-6 .......................... 34 96 5. Compatibility with traditional RADIUS .................... 36 97 5.1. Attribute Allocation ................................ 36 98 5.2. Proxy Servers ....................................... 37 99 6. Guidelines ............................................... 38 100 6.1. Updates to RFC 6158 ................................. 38 101 6.2. Guidelines for Simple Data Types .................... 38 102 6.3. Guidelines for Complex Data Types ................... 39 103 6.4. Design Guidelines For the New Types ................. 40 104 6.5. TLV Guidelines ...................................... 40 105 6.6. Allocation Request Guidelines ....................... 41 106 6.7. Allocation Requests Guidelines for TLVs ............. 42 107 6.8. Implementation Guidelines ........................... 42 108 6.9. Vendor Guidelines ................................... 43 109 7. Rationale for This Design ................................ 43 110 7.1. Attribute Audit ..................................... 43 111 8. Diameter Considerations .................................. 44 112 9. Examples ................................................. 44 113 9.1. Extended Type ....................................... 46 114 9.2. Long Extended Type .................................. 47 115 10. IANA Considerations ..................................... 49 116 10.1. Attribute Allocations .............................. 50 117 10.2. RADIUS Attribute Type Tree ......................... 50 118 10.3. Allocation Instructions ............................ 51 119 10.3.1. Requested Allocation from the Standard Space .. 51 120 10.3.2. Requested Allocation from the short extended sp 51 121 10.3.3. Requested Allocation from the long extended spa 52 122 10.3.4. Allocation Preferences ........................ 52 123 10.3.5. Extending the Type Space via TLV Data Type .... 52 124 10.3.6. Allocation within a TLV ....................... 53 125 10.3.7. Allocation of Other Data Types ................ 53 126 11. Security Considerations ................................. 53 127 12. References .............................................. 54 128 12.1. Normative references ............................... 54 129 12.2. Informative references ............................. 54 130 Appendix A - Extended Attribute Generator Program ............ 56 131 1. Introduction 133 Under current allocation pressure, we expect that the RADIUS 134 Attribute Type space will be exhausted by 2014 or 2015. We therefore 135 need a way to extend the type space, so that new specifications may 136 continue to be developed. Other issues have also been shown with 137 RADIUS. The attribute grouping method defined in [RFC2868] has been 138 shown to be impractical, and a more powerful mechanism is needed. 139 Multiple attributes have been defined which transport more than the 140 253 octets of data originally envisioned with the protocol. Each of 141 these attributes is handled as a "special case" inside of RADIUS 142 implementations, instead of as a general method. We therefore also 143 need a standardized method of transporting large quantities of data. 144 Finally, some vendors are close to allocating all of the Attributes 145 within their Vendor-Specific Attribute space. It would be useful to 146 leverage changes to the base protocol for extending the Vendor- 147 Specific Attribute space. 149 We satisfy all of these requirements through the following changes 150 given in this document: 152 * defining an "Extended Type" format, which adds 8 bits of "Extended 153 Type" to the RADIUS Attribute Type space, by using one octet of the 154 "Value" field. This method gives us a general way of extending 155 the Attribute Type Space. (Section 2.1) 157 * allocating 4 attributes as using the format of "Extended Type". 158 This allocation extends the RADIUS Attribute Type Space by 159 approximately 1000 values. (Sections 3.1, 3.2, 3.3, and 3.4) 161 * defining a "Long Extended Type" format, which inserts an additional 162 octet between the "Extended Type" octet, and the "Value" field. 163 This method gives us a general way of adding additional 164 functionality to the protocol. (Section 2.2) 166 * defining a method which uses the additional octet in the "Long 167 Extended Type" to indicate data fragmentation across multiple 168 Attributes. This method provides a standard way for an Attribute 169 to carry more than 253 octets of data. (Section 2.2) 171 * allocating 2 attributes as using the format "Long Extended Type". 172 This allocation extends the RADIUS Attribute Type Space 173 by an additional 500 values. (Sections 3.5 and 3.6) 175 * defining a new "Type Length Value" (TLV) data type. The data type 176 allows an attribute to carry TLVs as "sub-attributes", which can in 177 turn encapsulate other TLVs as "sub-sub-attributes." This change 178 creates a standard way to group a set of Attributes. (Section 2.3) 180 * defining a new "extended Vendor-Specific" (EVS) data type. The 181 data type allows an attribute to carry Vendor-Specific Attributes 182 (VSAs) inside of the new attribute formats. (Section 2.4) 184 * defining a new "integer64" data type. The data type allows 185 counters which track more than 2^32 octets of data. (Section 2.5) 187 * allocating 6 attributes using the new EVS data type. This 188 allocation extends the Vendor-Specific Attribute Type space by 189 over 1500 values. (Sections 4.1 through 4.6) 191 * Define the "Vendor-ID" for Vendor-Specific attributes to encompass 192 the entire 4 octets of the Vendor field. [RFC2865] Section 5.26 193 defined it to be 3 octets, with the high octet being zero. 194 (Section 2.5) 196 * Describing compatibility with existing RADIUS systems. (Section 5) 198 * Defining guidelines for the use of these changes for IANA, 199 implementations of this specification, and for future RADIUS 200 specifications. (Section 6) 202 As with any protocol change, the changes defined here are the result 203 of a series of compromises. We have tried to find a balance between 204 flexibility, space in the RADIUS message, compatibility with existing 205 deployments, and implementation difficulty. 207 1.1. Caveats and Limitations 209 This section describes some caveats and limitations with the 210 proposal. 212 1.1.1. Failure to Meet Certain Goals 214 One goal which was not met by the above modifications is to have an 215 incentive for standards to use the new space. We would ideally like 216 to deprecate the "Unassigned" attributes in the standard space, which 217 would permit allocation, but under more stringent guidelines. 218 However, [RFC5226] has no provisions for a "Deprecated" entry in an 219 IANA managed registry. 221 1.1.2. Implementation Recommendations 223 It is RECOMMENDED that implementations support this specification. 224 It is RECOMMENDED that new specifications use the formats defined in 225 this specification. 227 The alternative to the above recommendations is a circular argument 228 of not implementing this specification because no other standards 229 reference it, and also not defining new standards referencing this 230 specification because no implementations exist. 232 As noted earlier, the "standard space" is almost entirely allocated. 233 Ignoring the looming crisis benefits no one. 235 1.2. Terminology 237 This document uses the following terms: 239 Silently discard 240 This means the implementation discards the packet without further 241 processing. The implementation MAY provide the capability of 242 logging the error, including the contents of the silently discarded 243 packet, and SHOULD record the event in a statistics counter. 245 Invalid attribute 246 This means that the Length field of an Attribute is valid (as per 247 [RFC2865], Section 5, top of page 25). However, the Value field of 248 the attribute does not follow the format required by the data type 249 defined for that Attribute. e.g. an Attribute of type "address" 250 which encapsulates more than four, or less than four, octets of 251 data. See Section 2.8 for a more complete definition. 253 Standard space 254 Codes in the RADIUS Attribute Type Space that are allocated by IANA 255 and that follow the format defined in Section 5 of [RFC2865]. 257 Extended space 258 Codes in the RADIUS Attribute Type Space that require the 259 extensions defined in this document, and are an extension of the 260 standard space, but which cannot be represented within the standard 261 space. 263 Short extended space 264 Codes in the extended space which use the "Extended Type" format. 266 Long extended space 267 Codes in the extended space which use the "Long Extended Type" 268 format. 270 The following terms are used here with the meanings defined in BCP 271 26 [RFC5226]: "name space", "assigned value", "registration", 272 "Private Use", "Reserved", "Unassigned", "IETF Review", and 273 "Standards Action". 275 1.3. Requirements Language 277 In this document, several words are used to signify the requirements 278 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 279 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 280 and "OPTIONAL" in this document are to be interpreted as described in 281 [RFC2119]. 283 2. Extensions to RADIUS 285 This section defines two new attribute formats; "Extended Type"; and 286 "Long Extended Type". It defines a new Type-Length-Value (TLV) data 287 type, an Extended-Vendor-Specific (EVS) data type, and an Integer64 288 data type. It defines a new method for naming attributes and 289 identifying Attributes using the new attribute formats. It finally 290 defines the new term "invalid attribute", and describes how it 291 affects implementations. 293 The new attribute formats are designed to be compatible with the 294 attribute format given in [RFC2865] Section 5. The meaning and 295 interpretation of the Type and Length fields is unchanged from that 296 specification. This reuse allows the new formats to be compatible 297 RADIUS implementations which do not implement this specification. 298 Those implementations can simply ignore the Value field of an 299 attribute, or forward it verbatim. 301 The changes to the attribute format come about by "stealing" one or 302 more octets from the Value field. This change has the effect that 303 the Value field of [RFC2865] Section 5 contains both the new octets 304 given here, and any attribute-specific Value. The result is that 305 Values in this specification are limited to less than 253 octets in 306 size. This limitation is overcome through the use of the "Long 307 Extended Type" format. 309 We reiterate that the formats given in this document do not insert 310 new data into an attribute. Instead, we "steal" one octet of Value, 311 so that the definition of the Length field remains unchanged. The 312 new attribute formats are designed to be compatible with the 313 attribute format given in [RFC2865] Section 5. The meaning and 314 interpretation of the Type and Length fields is unchanged from that 315 specification. This reuse allows the new formats to be compatible 316 RADIUS implementations which do not implement this specification. 317 Those implementations can simply ignore the Value field of an 318 attribute, or forward it verbatim. 320 The changes to the attribute format come about by "stealing" one or 321 more octets from the Value field. This change has the effect that 322 the Value field of [RFC2865] Section 5 contains both the new octets 323 given here, and any attribute-specific Value. The result is that 324 Values in this specification are limited to less than 253 octets in 325 size. This limitation is overcome through the use of the "Long 326 Extended Type" format. 328 2.1. Extended Type 330 This section defines a new attribute format, called "Extended Type". 331 A summary of the Attribute format is shown below. The fields are 332 transmitted from left to right. 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Type | Length | Extended-Type | Value ... 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Type 342 This field is identical to the Type field of the Attribute format 343 defined in [RFC2865] Section 5. 345 Length 347 The Length field is one octet, and indicates the length of this 348 Attribute including the Type, Length, Extended-Type, and Value 349 fields. Permitted values are between 4 and 255. If a client or 350 server receives an Extended Attribute with a Length of 2 or 3, 351 then that Attribute MUST be considered to be an "invalid 352 attribute", and handled as per Section 2.8, below. 354 Extended-Type 356 The Extended-Type field is one octet. Up-to-date values of this 357 field are specified according to the policies and rules described 358 in Section 10. Unlike the Type field defined in [RFC2865] Section 359 5, no values are allocated for experimental or implementation- 360 specific use. Values 241-255 are reserved and SHOULD NOT be used. 362 The Extended-Type is meaningful only within a context defined by 363 the Type field. That is, this field may be thought of as defining 364 a new type space of the form "Type.Extended-Type". See Section 365 2.5, below, for additional discussion. 367 A RADIUS server MAY ignore Attributes with an unknown 368 "Type.Extended-Type". 370 A RADIUS client MAY ignore Attributes with an unknown 371 "Type.Extended-Type". 373 Value 375 This field is similar to the Value field of the Attribute format 376 defined in [RFC2865] Section 5. The format of the data SHOULD be 377 a valid RADIUS data type. 379 The addition of the Extended-Type field decreases the maximum 380 length for attributes of type "text" or "string" from 253 to 252 381 octets. Where an Attribute needs to carry more than 252 octets of 382 data, the "Long Extended Type" format SHOULD be used. 384 Experience has shown that the "experimental" and "implementation 385 specific" attributes defined in [RFC2865] Section 5 have had little 386 practical value. We therefore do not continue that practice here 387 with the Extended-Type field. 389 2.2. Long Extended Type 391 This section defines a new attribute format, called "Long Extended 392 Type". It leverages the "Extended Type" format in order to permit 393 the transport of attributes encapsulating more than 253 octets of 394 data. A summary of the Attribute format is shown below. The fields 395 are transmitted from left to right. 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Type | Length | Extended-Type |M| Reserved | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Value ... 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Type 407 This field is identical to the Type field of the Attribute format 408 defined in [RFC2865] Section 5. 410 Length 412 The Length field is one octet, and indicates the length of this 413 Attribute including the Type, Length, Extended-Type, and Value 414 fields. Permitted values are between 5 and 255. If a client or 415 server receives a "Long Extended Type" with a Length of 2, 3, or 416 4, then that Attribute MUST be considered to be an "invalid 417 attribute", and be handled as per Section 2.8, below. 419 Note that this Length is limited to the length of this fragment. 420 There is no field which gives an explicit value for the total size 421 of the fragmented attribute. 423 Extended-Type 424 This field is identical to the Extended-Type field defined above 425 in Section 2.1. 427 M (More) 429 The More field is one (1) bit in length, and indicates whether or 430 not the current attribute contains "more" than 251 octets of data. 431 The More field MUST be clear (0) if the Length field has value 432 less than 255. The More field MAY be set (1) if the Length field 433 has value of 255. 435 If the More field is set (1), it indicates that the Value field 436 has been fragmented across multiple RADIUS attributes. When the 437 More field is set (1), the attribute SHOULD have a Length field of 438 value 255; it MUST NOT have a length Field of value 4; there MUST 439 be an attribute following this one; and the next attribute MUST 440 have both the same Type and Extended Type. That is, multiple 441 fragments of the same value MUST be in order and MUST be 442 consecutive attributes in the packet, and the last attribute in a 443 packet MUST NOT have the More field set (1). 445 When the Length field of an attribute has value less than 255, the 446 More field SHOULD be clear (0). 448 If a client or server receives an attribute fragment with the 449 "More" field set (1), but for which no subsequent fragment can be 450 found, then the fragmented attribute is considered to be an 451 "invalid attribute", and handled as per Section 2.8, below. 453 Reserved 455 This field is 7 bits long, and is reserved for future use. 456 Implementations MUST set it to zero (0) when encoding an attribute 457 for sending in a packet. The contents SHOULD be ignored on 458 reception. 460 Future specifications may define additional meaning for this 461 field. Implementations therefore MUST NOT treat this field as 462 invalid if it is non-zero. 464 Value 466 This field is similar to the Value field of the Attribute format 467 defined in [RFC2865] Section 5. It may contain a complete set of 468 data (when the Length field has value less than 255), or it may 469 contain a fragment of data (when the More field is set). 471 Any interpretation of the resulting data MUST occur after the 472 fragments have been reassembled. The length of the data MUST be 473 taken as the sum of the lengths of the fragments (i.e. Value 474 fields) from which it is constructed. The format of the data 475 SHOULD be a valid RADIUS data type. 477 We note that the maximum size of a fragmented attribute is limited 478 only by the RADIUS packet length limitation (i.e. 4096 octets, not 479 counting various headers and overhead). Implementations SHOULD be 480 able to handle fragmented attributes of 4096 octets. 482 This definition increases the RADIUS Attribute Type space as above, 483 but also provides for transport of Attributes which could contain 484 more than 253 octets of data. 486 Note that [RFC2865] Section 5 says: 488 If multiple Attributes with the same Type are present, the order 489 of Attributes with the same Type MUST be preserved by any proxies. 490 The order of Attributes of different Types is not required to be 491 preserved. A RADIUS server or client MUST NOT have any 492 dependencies on the order of attributes of different types. A 493 RADIUS server or client MUST NOT require attributes of the same 494 type to be contiguous. 496 These requirements also apply to the "Long Extended Type" attribute, 497 including fragments. Implementations MUST be able to process non- 498 contiguous fragments. That is, fragments which are mixed together 499 with other attributes of a different Type. 501 2.3. TLV Data Type 503 We define a new data type in RADIUS, called "tlv". The "tlv" data 504 type is an encapsulation layer which permits the "Value" field of an 505 Attribute to contain new sub-Attributes. These sub-Attributes can in 506 turn contain "Value"s of data type TLV. This capability both extends 507 the attribute space, and permits "nested" attributes to be used. 508 This nesting can be used to encapsulate or group data into one or 509 more logical containers. 511 The "tlv" data type re-uses the RADIUS attribute format, as given 512 below: 514 0 1 2 3 515 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 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | TLV-Type | TLV-Length | TLV-Value ... 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 TLV-Type 521 The Type field is one octet. Up-to-date values of this field are 522 specified according to the policies and rules described in Section 523 10. Values 254-255 are "Reserved" for use by future extensions to 524 RADIUS. The value 26 has no special meaning, and MUST NOT be 525 treated as a Vendor Specific attribute. 527 As with Extended-Type above, the TLV-Type is meaningful only 528 within the context defined by "Type" fields of the encapsulating 529 Attributes. That is, the field may be thought of as defining a 530 new type space of the form "Type.Extended-Type.TLV-Type". Where 531 TLVs are nested, the type space is of the form "Type.Extended- 532 Type.TLV-Type.TLV-Type", etc. 534 A RADIUS server MAY ignore Attributes with an unknown "TLV-Type". 536 A RADIUS client MAY ignore Attributes with an unknown "TLV-Type". 538 A RADIUS proxy SHOULD forward Attributes with an unknown "TLV- 539 Type" verbatim. 541 TLV-Length 543 The TLV-Length field is one octet, and indicates the length of 544 this TLV including the TLV-Type, TLV-Length and TLV-Value fields. 545 It MUST have a value between 3 and 255. If a client or server 546 receives a TLV with an invalid TLV-Length, then the attribute 547 which encapsulates that TLV MUST be considered to be an "invalid 548 attribute", and handled as per Section 2.8, below. 550 TLV-Value 552 The Value field is one or more octets and contains information 553 specific to the Attribute. The format and length of the TLV-Value 554 field is determined by the TLV-Type and TLV-Length fields. 556 The TLV-Value field SHOULD encapsulate a previously defined RADIUS 557 data type. Use of non-standard data types SHOULD NOT be done. We 558 note that the TLV-Value field MAY also contain one or more 559 attributes of data type "tlv", which allows for simple grouping 560 and multiple layers of nesting. 562 The TLV-Value field is limited to containing 253 or fewer octets 563 of data. Specifications which require a TLV to contain more than 564 253 octets of data are incompatible with RADIUS, and need to be 565 redesigned. Specifications which require the transport of empty 566 Values (i.e. Length = 2) are incompatible with RADIUS, and need to 567 be redesigned. 569 The TLV-Value field MUST NOT contain data using the "Extended 570 Type" formats defined in this document. The base Extended 571 Attributes format allows for sufficient flexibility that nesting 572 them inside of a TLV offers little additional value. 574 This TLV definition is compatible with the suggested format of the 575 "String" field of the Vendor-Specific attribute, as defined in 576 [RFC2865] Section 5.26, though that specification does not discuss 577 nesting. 579 Vendors MAY use attributes of type "tlv" in any Vendor Specific 580 Attribute. It is RECOMMENDED to use type "tlv" for VSAs, in 581 preference to any other format. 583 If multiple TLVs with the same TLV-Type are present, the order of 584 TLVs with the same TLV-Type MUST be preserved by any proxies. The 585 order of TLVs of different TLV-Types is not required to be preserved. 586 A RADIUS server or client MUST NOT have any dependencies on the order 587 of TLVs of different TLV-Types. A RADIUS server or client MUST NOT 588 require TLVs of the same TLV-type to be contiguous. 590 The interpretation of multiple TLVs of the same TLV-Type MUST be that 591 of a logical "and", unless otherwise specified. That is, multiple 592 TLVs are interpreted as specifying a set or a list of values. 593 Specifications SHOULD NOT define TLVs to be interpreted as a logical 594 "or". Doing so would mean that a RADIUS client or server would make 595 an arbitrary, and non-deterministic choice among the values. 597 2.3.1. TLV Nesting 599 TLVs may contain other TLVs. When this occurs, the "container" TLV 600 MUST be completely filled by the "contained" TLVs. That is, the 601 "container" TLV-Length field MUST be exactly two (2) more than the 602 sum of the "contained" TLV-Length fields. If the "contained" TLVs 603 over-fill the "container" TLV, the "container" TLV MUST be considered 604 to be an "invalid attribute", and handled as described in Section 605 2.8, below. 607 The depth of TLV nesting is limited only by the restrictions on the 608 TLV-Length field. The limit of 253 octets of data results in a limit 609 of 126 levels of nesting. However, nesting depths of more than 4 are 610 NOT RECOMMENDED. 612 2.4. EVS Data Type 614 We define a new data type in RADIUS, called "evs", for "Extended 615 Vendor-Specific". The "evs" data type is an encapsulation layer 616 which permits the "Value" field of an Attribute to contain a Vendor- 617 Id, followed by a Vendor-Type, and then vendor-defined data. This 618 data can in turn contain valid RADIUS data types, or any other data 619 as determined by the vendor. 621 This data type is intended use in attributes which carry Vendor- 622 Specific information, as is done with the Vendor-Specific Attribute 623 (26). It is RECOMMENDED that this data type be used by a vendor only 624 when the Vendor-Specific Attribute Type space has been fully 625 allocated. 627 Where [RFC2865] Section 5.26 makes a recommendation for the format of 628 the data following the Vendor-Id, we give a strict definition. 629 Experience has shown that many vendors have not followed the 630 [RFC2865] recommendations, leading to interoperability issues. We 631 hope here to give vendors sufficient flexibility as to meet their 632 needs, while minimizing the use of non-standard VSA formats. 634 The "evs" data type MAY be used in Attributes having the format of 635 "Extended Type" or "Long Extended Type". It MUST NOT be used in any 636 other Attribute definition, including standard RADIUS Attributes, 637 TLVs, and VSAs. 639 A summary of the "evs" data type format is shown below. The fields 640 are transmitted from left to right. 642 0 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Vendor-Id | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Vendor-Type | String .... 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 Vendor-Id 652 The 4 octets are the Network Management Private Enterprise Code 653 [PEN] of the Vendor in network byte order. 655 Vendor-Type 657 The Vendor-Type field is one octet. Values are assigned at the 658 sole discretion of the Vendor. 660 Value 662 The Value field is one or more octets. It SHOULD encapsulate a 663 previously defined RADIUS data type. Using non-standard data 664 types is NOT RECOMMENDED. We note that the Value field may be of 665 data type "tlv". However, it MUST NOT be of data type "evs", as 666 the use cases are unclear for one vendor delegating Attribute Type 667 space to another vendor. 669 The actual format of the information is site or application 670 specific, and a robust implementation SHOULD support the field as 671 undistinguished octets. We recognise that Vendors have complete 672 control over the contents and format of the Value field, while at 673 the same time recommending that good practices be followed. 675 Further codification of the range of allowed usage of this field 676 is outside the scope of this specification. 678 Note that unlike the format described in [RFC2865] Section 5.26, this 679 data type has no "Vendor length" field. The length of the "String" 680 field is implicit, and is determined by taking the "Length" of the 681 encapsulating RADIUS Attribute, and subtracting the length of the 682 attribute header (2 octets), the extended type (1 octet), the Vendor- 683 Id (4 octets), and the Vendor-type (1 octet). i.e. For "Extended 684 Type" attributes, the length of the String field is eight (8) less 685 than the value of the Length field. For "Long Extended Type" 686 attributes, the length of the String field is nine (9) less than the 687 value of the Length field. 689 2.5. Integer64 Data Type 691 We define a new data type in RADIUS, called "integer64", which 692 carries a 64-bit unsigned integer in network byte order. 694 This data type is intended to be used in any situation where there is 695 a need to have counters which can count past 2^32. The expected use 696 of this data type is within Accounting-Request packets, but this data 697 type SHOULD be used in any packet where 32-bit integers are expected 698 to be insufficient. 700 The "integer64" data type can be used in Attributes of any format, 701 standard space, extended attributes, TLVs, and VSAs. 703 A summary of the "integer64" data type format is shown below. The 704 fields are transmitted from left to right. 706 0 1 2 3 707 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 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Value ... 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 Attributes having data type "integer64" MUST have the relevant Length 716 field set to eight more than the length of the Attribute header. For 717 standard space Attributes and TLVs, this means that the Length field 718 MUST be set to ten (10). For "Extended Type" Attributes, the Length 719 field MUST be set to eleven (11). For "Long Extended Type" 720 Attributes, the Length field MUST be set to twelve (12). 722 2.6. Vendor-ID Field 724 We define the Vendor-ID field of Vendor-Specific Attributes to 725 encompass the entire 4 octets of the Vendor field. [RFC2865] Section 726 5.26 defined it to be 3 octets, with the high octet being zero. This 727 change has no immediate impact on RADIUS, as the maximum Private 728 Enterprise Code defined is still within 16 bits. 730 However, it is best to make advance preparations for changes in the 731 protocol. As such, it is RECOMMENDED that all implementations 732 support four (4) octets for the Vendor-ID field, instead of three 733 (3). 735 2.7. Attribute Naming and Type Identifiers 737 Attributes have traditionally been identified by a unique name and 738 number. For example, the attribute named "User-Name" has been 739 allocated number one (1). This scheme needs to be extended in order 740 to be able to refer to attributes of Extended Type, and to TLVs. It 741 will also be used by IANA for allocating RADIUS Attribute Type 742 values. 744 The names and identifiers given here are intended to be used only in 745 specifications. The system presented here may not be useful when 746 referring to the contents of a RADIUS packet. It imposes no 747 requirements on implementations, as implementations are free to 748 reference RADIUS Attributes via any method they choose. 750 2.7.1. Attribute and TLV Naming 752 RADIUS specifications traditionally use names consisting of one or 753 more words, separated by hyphens, e.g. "User-Name". However, these 754 names are not allocated from a registry, and there is no restriction 755 other than convention on their global uniqueness. 757 Similarly, vendors have often used their company name as the prefix 758 for VSA names, though this practice is not universal. For example, 759 for a vendor named "Example", the name "Example-Attribute-Name" 760 SHOULD be used instead of "Attribute-Name". The second form can 761 conflict with attributes from other vendors, whereas the first form 762 cannot. 764 It is therefore RECOMMENDED that specifications give names to 765 Attributes which attempt to be globally unique across all RADIUS 766 Attributes. It is RECOMMENDED that vendors use their name as a 767 unique prefix for attribute names, e.g. Livingston-IP-Pool instead of 768 IP-Pool. It is RECOMMENDED that implementations enforce uniqueness 769 on names, which would otherwise lead to ambiguity and problems. 771 We recognise that these suggestions may sometimes be difficult to 772 implement in practice. 774 TLVs SHOULD be named with a unique prefix that is shared among 775 related attributes. For example, a specification that defines a set 776 of TLVs related to time could create attributes named "Time-Zone", 777 "Time-Day", "Time-Hour", "Time-Minute", etc. 779 2.7.2. Attribute Type Identifiers 781 The RADIUS Attribute Type space defines a context for a particular 782 "Extended-Type" field. The "Extended-Type" field allows for 256 783 possible type code values, with values 1 through 240 available for 784 allocation. We define here an identification method that uses a 785 "dotted number" notation similar to that used for Object Identifiers 786 (OIDs), formatted as "Type.Extended-Type". 788 For example, an attribute within the Type space of 241, having 789 Extended-Type of one (1), is uniquely identified as "241.1". 790 Similarly, an attribute within the Type space of 246, having 791 Extended-Type of ten (10), is uniquely identified as "246.10". 793 The algorithm used to create the Attribute Identifier is simply to 794 concatenate all of the various identification fields (e.g. Type, 795 Extended-Type, etc.), starting from the encapsulating attribute, down 796 to the final encapsulated TLV, separated by a '.' character. 798 2.7.3. TLV Identifiers 800 We can extend the Attribute reference scheme defined above for TLVs. 801 This is done by leveraging the "dotted number" notation. As above, 802 we define an additional TLV type space, within the "Extended Type" 803 space, by appending another "dotted number" in order to identify the 804 TLV. This method can be replied in sequence for nested TLVs. 806 For example, let us say that "245.1" identifies RADIUS Attribute Type 807 245, containing an "Extended Type" of one (1), which is of type 808 "tlv". That attribute will contain 256 possible TLVs, one for each 809 value of the TLV-Type field. The first TLV-Type value of one (1) can 810 then be identified by appending a ".1" to the number of the 811 encapsulating attribute ("241.1"), to yield "241.1.1". Similarly, 812 the sequence "245.2.3.4" identifies RADIUS attribute 245, containing 813 an "Extended Type" of two (2) which is of type "tlv", which in turn 814 contains a TLV with TLV-Type number three (3), which in turn contains 815 another TLV, with TLV-Type number four (4). 817 2.7.4. VSA Identifiers 819 There has historically been no method for numerically addressing 820 VSAs. The "dotted number" method defined here can also be leveraged 821 to create such an addressing scheme. However, as the VSAs are 822 completely under the control of each individual vendor, this section 823 provides a suggested practice, but does not define a standard of any 824 kind. 826 The Vendor-Specific Attribute has been assigned the Attribute number 827 26. It in turn carries a 24-bit Vendor-Id, and possibly additional 828 VSAs. Where the VSAs follow the [RFC2865] Section 5.26 recommended 829 format, a VSA can be identified as "26.Vendor-Id.Vendor-Type". 831 For example, Livingston has Vendor-Id 307, and has defined an 832 attribute "IP-Pool" as number 6. This VSA can be uniquely identified 833 as 26.307.6, but it cannot be uniquely identified by name, as other 834 vendors may have used the same name. 836 Note that there are few restrictions on the size of the numerical 837 values in this notation. The Vendor-Id is a 24-bit number, and the 838 VSA may have been assigned from a 16-bit vendor-specific Attribute 839 Type space. Implementations SHOULD be capable of handling 32-bit 840 numbers at each level of the "dotted number" notation. 842 For example, the company USR has been allocated Vendor-Id 429, and 843 has defined a "Version-Id" attribute as number 32768. This VSA can 844 be uniquely identified as 26.429.32768, and again cannot be uniquely 845 identified by name. 847 Where a VSA is a TLV, the "dotted number" notation can be used as 848 above: 26.Vendor-Id.Vendor-Type.TLV1.TLV2.TLV3 where "TLVn" are the 849 numerical values assigned by the vendor to the different nested TLVs. 851 2.8. Invalid Attributes 853 The term "invalid attribute" is new to this specification. It is 854 defined to mean that the Length field of an Attribute is valid (as 855 per [RFC2865], Section 5, top of page 25). However, the Value field 856 of the attribute does not follow the format required by the data type 857 defined for that Attribute. e.g. an Attribute of data type "address" 858 which encapsulates less than four, or more than four octets of data. 859 Or, an IPV6 Prefix attribute which has a Prefix value of more than 860 128. Many other forms of an "invalid attribute" are possible, but 861 are not enumerated here. 863 While the content of these attributes is malformed, we emphasize that 864 the encapsulating RADIUS packet, or attribute, or TLV, is well 865 formed, and can be correctly decoded. The existence of an "invalid 866 attribute" in a packet MUST NOT result in the implementation 867 discarding the entire packet, or treating the packet as a negative 868 acknowledgement. Instead, only the "invalid attribute" is treated 869 differently. 871 When an implementation receives an "invalid attribute", it SHOULD be 872 silently discarded. If it is not discarded, it MUST NOT be handled 873 in the same manner as a well-formed attribute. For example, 874 receiving an Attribute of data type "address" containing less than 875 four octets, or more than four octets of data means that the 876 Attribute MUST NOT be treated as being of data type "address". The 877 reason here is that if the attribute does not carry an IPv4 address, 878 the receiver has no idea what format the data is in, and it is 879 therefore not an IPv4 address. 881 For Attributes of type "Long Extended Type", an Attribute is 882 considered to be an "invalid attribute" when does not match the 883 criteria set out in Section 2.2, above. 885 For Attributes of type "TLV", an Attribute is considered to be an 886 "invalid attribute" when the TLV-Length field allows the 887 encapsulating Attribute to be parsed, but the TLV-Value field does 888 not match the criteria for that TLV. Implementations SHOULD NOT 889 treat the "invalid attribute" property as being transitive. That is, 890 the Attribute encapsulating the "invalid attribute" SHOULD NOT be 891 treated as an "invalid attribute". That encapsulating Attribute 892 might contain multiple TLVs, only one of which is an "invalid 893 attribute". 895 3. Attribute Definitions 897 We define four (4) attributes of "Extended Type", which are allocated 898 from the "Reserved" Attribute Type codes of 241, 242, 243, and 244. 900 We also define two (2) attributes of "Long Extended Type", which are 901 allocated from the "Reserved" Attribute Type codes of 245 and 246. 903 Type Name 904 ---- ---- 905 241 Extended-Type-1 906 242 Extended-Type-2 907 243 Extended-Type-3 908 244 Extended-Type-4 909 245 Long-Extended-Type-1 910 246 Long-Extended-Type-2 912 The rest of this section gives a detailed definition for each 913 Attribute based on the above summary. 915 3.1. Extended-Type-1 917 Description 919 This attribute encapsulates attributes of the "Extended Type" 920 format, in the RADIUS Attribute Type Space of 241.{1-255}. 922 A summary of the Extended-Type-1 Attribute format is shown below. 923 The fields are transmitted from left to right. 925 0 1 2 3 926 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 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Type | Length | Extended-Type | Value ... 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 Type 933 241 for Extended-Type-1. 935 Length 937 >= 4 939 Extended-Type 941 The Extended-Type field is one octet. Up-to-date values of this 942 field are specified in the 241.{1-255} RADIUS Attribute Type 943 Space, according to the policies and rules described in Section 944 10. Further definition of this field is given in Section 2.1, 945 above. 947 Value 948 The Value field is one or more octets. Implementations not 949 supporting this specification SHOULD support the field as 950 undistinguished octets. 952 Implementations supporting this specification MUST use the 953 Identifier of "Type.Extended-Type" to determine the interpretation 954 of the Value field. 956 3.2. Extended-Type-2 958 Description 960 This attribute encapsulates attributes of the "Extended Type" 961 format, in the RADIUS Attribute Type Space of 242.{1-255}. 963 A summary of the Extended-Type-2 Attribute format is shown below. 964 The fields are transmitted from left to right. 966 0 1 2 3 967 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 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Type | Length | Extended-Type | Value ... 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 Type 974 242 for Extended-Type-2. 976 Length 978 >= 4 980 Extended-Type 982 The Extended-Type field is one octet. Up-to-date values of this 983 field are specified in the 242.{1-255} RADIUS Attribute Type 984 Space, according to the policies and rules described in Section 985 10. Further definition of this field is given in Section 2.1, 986 above. 988 Value 990 The Value field is one or more octets. Implementations not 991 supporting this specification SHOULD support the field as 992 undistinguished octets. 994 Implementations supporting this specification MUST use the 995 Identifier of "Type.Extended-Type" to determine the interpretation 996 of the Value field 998 3.3. Extended-Type-3 1000 Description 1002 This attribute encapsulates attributes of the "Extended Type" 1003 format, in the RADIUS Attribute Type Space of 243.{1-255}. 1005 A summary of the Extended-Type-3 Attribute format is shown below. 1006 The fields are transmitted from left to right. 1008 0 1 2 3 1009 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 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | Type | Length | Extended-Type | Value ... 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 Type 1016 243 for Extended-Type-3. 1018 Length 1020 >= 4 1022 Extended-Type 1024 The Extended-Type field is one octet. Up-to-date values of this 1025 field are specified in the 243.{1-255} RADIUS Attribute Type 1026 Space, according to the policies and rules described in Section 1027 10. Further definition of this field is given in Section 2.1, 1028 above. 1030 Value 1032 The Value field is one or more octets. Implementations not 1033 supporting this specification SHOULD support the field as 1034 undistinguished octets. 1036 Implementations supporting this specification MUST use the 1037 Identifier of "Type.Extended-Type" to determine the interpretation 1038 of the Value field. 1040 3.4. Extended-Type-4 1042 Description 1044 This attribute encapsulates attributes of the "Extended Type" 1045 format, in the RADIUS Attribute Type Space of 244.{1-255}. 1047 A summary of the Extended-Type-4 Attribute format is shown below. 1048 The fields are transmitted from left to right. 1050 0 1 2 3 1051 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 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | Type | Length | Extended-Type | Value ... 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 Type 1058 244 for Extended-Type-4. 1060 Length 1062 >= 4 1064 Extended-Type 1066 The Extended-Type field is one octet. Up-to-date values of this 1067 field are specified in the 244.{1-255} RADIUS Attribute Type 1068 Space, according to the policies and rules described in Section 1069 10. Further definition of this field is given in Section 2.1, 1070 above. 1072 Value 1074 The Value field is one or more octets. Implementations not 1075 supporting this specification SHOULD support the field as 1076 undistinguished octets. 1078 Implementations supporting this specification MUST use the 1079 Identifier of "Type.Extended-Type" to determine the interpretation 1080 of the Value Field. 1082 3.5. Long-Extended-Type-1 1084 Description 1086 This attribute encapsulates attributes of the "Long Extended Type" 1087 format, in the RADIUS Attribute Type Space of 245.{1-255}. 1089 A summary of the Long-Extended-Type-1 Attribute format is shown 1090 below. The fields are transmitted from left to right. 1092 0 1 2 3 1093 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 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Type | Length | Extended-Type |M| Reserved | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Value ... 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 Type 1102 245 for Long-Extended-Type-1 1104 Length 1106 >= 5 1108 Extended-Type 1110 The Extended-Type field is one octet. Up-to-date values of this 1111 field are specified in the 245.{1-255} RADIUS Attribute Type 1112 Space, according to the policies and rules described in Section 1113 10. Further definition of this field is given in Section 2.1, 1114 above. 1116 M (More) 1118 The More field is one (1) bit in length, and indicates whether or 1119 not the current attribute contains "more" than 251 octets of data. 1120 Further definition of this field is given in Section 2.2, above. 1122 Reserved 1124 This field is 7 bits long, and is reserved for future use. 1125 Implementations MUST set it to zero (0) when encoding an attribute 1126 for sending in a packet. The contents SHOULD be ignored on 1127 reception. 1129 Value 1131 The Value field is one or more octets. Implementations not 1132 supporting this specification SHOULD support the field as 1133 undistinguished octets. 1135 Implementations supporting this specification MUST use the 1136 Identifier of "Type.Extended-Type" to determine the interpretation 1137 of the Value field. 1139 3.6. Long-Extended-Type-2 1141 Description 1143 This attribute encapsulates attributes of the "Long Extended Type" 1144 format, in the RADIUS Attribute Type Space of 246.{1-255}. 1146 A summary of the Long-Extended-Type-2 Attribute format is shown 1147 below. The fields are transmitted from left to right. 1149 0 1 2 3 1150 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 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | Type | Length | Extended-Type |M| Reserved | 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 | Value ... 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 Type 1159 246 for Long-Extended-Type-2 1161 Length 1163 >= 5 1165 Extended-Type 1167 The Extended-Type field is one octet. Up-to-date values of this 1168 field are specified in the 246.{1-255} RADIUS Attribute Type 1169 Space, according to the policies and rules described in Section 1170 10. Further definition of this field is given in Section 2.1, 1171 above. 1173 M (More) 1175 The More field is one (1) bit in length, and indicates whether or 1176 not the current attribute contains "more" than 251 octets of data. 1177 Further definition of this field is given in Section 2.2, above. 1179 Reserved 1181 This field is 7 bits long, and is reserved for future use. 1182 Implementations MUST set it to zero (0) when encoding an attribute 1183 for sending in a packet. The contents SHOULD be ignored on 1184 reception. 1186 Value 1188 The Value field is one or more octets. Implementations not 1189 supporting this specification SHOULD support the field as 1190 undistinguished octets. 1192 Implementations supporting this specification MUST use the 1193 Identifier of "Type.Extended-Type" to determine the interpretation 1194 of the Value field. 1196 4. Vendor Specific Attributes 1198 We define six new attributes which can carry Vendor Specific 1199 information. We define four (4) attributes of the "Extended Type" 1200 format, with Type codes (241.26, 242.26, 243.26, 244.26), using the 1201 "evs" data type. We also define two (2) attributes using "Long 1202 Extended Type" format, with Type codes (245.26, 246.26), which are of 1203 the "evs" data type. 1205 Type.Extended-Type Name 1206 ------------------ ---- 1207 241.26 Extended-Vendor-Specific-1 1208 242.26 Extended-Vendor-Specific-2 1209 243.26 Extended-Vendor-Specific-3 1210 244.26 Extended-Vendor-Specific-4 1211 245.26 Extended-Vendor-Specific-5 1212 246.26 Extended-Vendor-Specific-6 1214 The rest of this section gives a detailed definition for each 1215 Attribute based on the above summary. 1217 4.1. Extended-Vendor-Specific-1 1219 Description 1221 This attribute defines a RADIUS Type Code of 241.26, using the 1222 "evs" data type. 1224 A summary of the Extended-Vendor-Specific-1 Attribute format is shown 1225 below. The fields are transmitted from left to right. 1227 0 1 2 3 1228 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 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 | Type | Length | Extended-Type | Vendor-Id ... 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 ... Vendor-Id (cont) | Vendor-Type | 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 | Value .... 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 Type.Extended-Type 1240 241.26 for Extended-Vendor-Specific-1 1242 Length 1244 >= 9 1246 Vendor-Id 1248 The 4 octets are the Network Management Private Enterprise Code 1249 [PEN] of the Vendor in network byte order. 1251 Vendor-Type 1253 The Vendor-Type field is one octet. Values are assigned at the 1254 sole discretion of the Vendor. 1256 Value 1258 The Value field is one or more octets. The actual format of the 1259 information is site or application specific, and a robust 1260 implementation SHOULD support the field as undistinguished octets. 1262 The codification of the range of allowed usage of this field is 1263 outside the scope of this specification. 1265 The length of the Value field is eight (8) less than the value of 1266 the Length field. 1268 Implementations supporting this specification MUST use the 1269 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1270 determine the interpretation of the Value field. 1272 4.2. Extended-Vendor-Specific-2 1274 Description 1276 This attribute defines a RADIUS Type Code of 242.26, using the 1277 "evs" data type. 1279 A summary of the Extended-Vendor-Specific-2 Attribute format is shown 1280 below. The fields are transmitted from left to right. 1282 0 1 2 3 1283 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 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 | Type | Length | Extended-Type | Vendor-Id ... 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 ... Vendor-Id (cont) | Vendor-Type | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 | Value .... 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 Type.Extended-Type 1294 242.26 for Extended-Vendor-Specific-2 1296 Length 1298 >= 9 1300 Vendor-Id 1302 The 4 octets are the Network Management Private Enterprise Code 1303 [PEN] of the Vendor in network byte order. 1305 Vendor-Type 1307 The Vendor-Type field is one octet. Values are assigned at the 1308 sole discretion of the Vendor. 1310 Value 1312 The Value field is one or more octets. The actual format of the 1313 information is site or application specific, and a robust 1314 implementation SHOULD support the field as undistinguished octets. 1316 The codification of the range of allowed usage of this field is 1317 outside the scope of this specification. 1319 The length of the Value field is eight (8) less than the value of 1320 the Length field. 1322 Implementations supporting this specification MUST use the 1323 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1324 determine the interpretation of the Value field. 1326 4.3. Extended-Vendor-Specific-3 1328 Description 1330 This attribute defines a RADIUS Type Code of 243.26, using the 1331 "evs" data type. 1333 A summary of the Extended-Vendor-Specific-3 Attribute format is shown 1334 below. The fields are transmitted from left to right. 1336 0 1 2 3 1337 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 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | Type | Length | Extended-Type | Vendor-Id ... 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 ... Vendor-Id (cont) | Vendor-Type | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | Value .... 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 Type.Extended-Type 1348 243.26 for Extended-Vendor-Specific-3 1350 Length 1352 >= 9 1354 Vendor-Id 1356 The 4 octets are the Network Management Private Enterprise Code 1357 [PEN] of the Vendor in network byte order. 1359 Vendor-Type 1361 The Vendor-Type field is one octet. Values are assigned at the 1362 sole discretion of the Vendor. 1364 Value 1366 The Value field is one or more octets. The actual format of the 1367 information is site or application specific, and a robust 1368 implementation SHOULD support the field as undistinguished octets. 1370 The codification of the range of allowed usage of this field is 1371 outside the scope of this specification. 1373 The length of the Value field is eight (8) less than the value of 1374 the Length field. 1376 Implementations supporting this specification MUST use the 1377 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1378 determine the interpretation of the Value field. 1380 4.4. Extended-Vendor-Specific-4 1382 Description 1384 This attribute defines a RADIUS Type Code of 244.26, using the 1385 "evs" data type. 1387 A summary of the Extended-Vendor-Specific-3 Attribute format is shown 1388 below. The fields are transmitted from left to right. 1390 0 1 2 3 1391 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 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 | Type | Length | Extended-Type | Vendor-Id ... 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 ... Vendor-Id (cont) | Vendor-Type | 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1397 | Value .... 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 Type.Extended-Type 1402 244.26 for Extended-Vendor-Specific-4 1404 Length 1406 >= 9 1408 Vendor-Id 1410 The 4 octets are the Network Management Private Enterprise Code 1411 [PEN] of the Vendor in network byte order. 1413 Vendor-Type 1415 The Vendor-Type field is one octet. Values are assigned at the 1416 sole discretion of the Vendor. 1418 Value 1420 The Value field is one or more octets. The actual format of the 1421 information is site or application specific, and a robust 1422 implementation SHOULD support the field as undistinguished octets. 1424 The codification of the range of allowed usage of this field is 1425 outside the scope of this specification. 1427 The length of the Value field is eight (8) less than the value of 1428 the Length field. 1430 Implementations supporting this specification MUST use the 1431 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1432 determine the interpretation of the Value field. 1434 4.5. Extended-Vendor-Specific-5 1436 Description 1438 This attribute defines a RADIUS Type Code of 245.26, using the 1439 "evs" data type. 1441 A summary of the Extended-Vendor-Specific-5 Attribute format is shown 1442 below. The fields are transmitted from left to right. 1444 0 1 2 3 1445 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 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 | Type | Length | Extended-Type |M| Reserved | 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | Vendor-Id | 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | Vendor-Type | Value .... 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 Type.Extended-Type 1456 245.26 for Extended-Vendor-Specific-5 1458 Length 1460 >= 10 (first fragment) 1461 >= 5 (subsequent fragments) 1463 When a VSA is fragmented across multiple Attributes, only the 1464 first Attribute contains the Vendor-Id and Vendor-Type fields. 1465 Subsequent Attributes contain fragments of the Value field only. 1467 M (More) 1469 The More field is one (1) bit in length, and indicates whether or 1470 not the current attribute contains "more" than 251 octets of data. 1471 Further definition of this field is given in Section 2.2, above. 1473 Reserved 1475 This field is 7 bits long, and is reserved for future use. 1476 Implementations MUST set it to zero (0) when encoding an attribute 1477 for sending in a packet. The contents SHOULD be ignored on 1478 reception. 1480 Vendor-Id 1482 The 4 octets are the Network Management Private Enterprise Code 1483 [PEN] of the Vendor in network byte order. 1485 Vendor-Type 1487 The Vendor-Type field is one octet. Values are assigned at the 1488 sole discretion of the Vendor. 1490 Value 1492 The Value field is one or more octets. The actual format of the 1493 information is site or application specific, and a robust 1494 implementation SHOULD support the field as undistinguished octets. 1496 The codification of the range of allowed usage of this field is 1497 outside the scope of this specification. 1499 Implementations supporting this specification MUST use the 1500 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1501 determine the interpretation of the Value field. 1503 4.6. Extended-Vendor-Specific-6 1505 Description 1507 This attribute defines a RADIUS Type Code of 246.26, using the 1508 "evs" data type. 1510 A summary of the Extended-Vendor-Specific-6 Attribute format is shown 1511 below. The fields are transmitted from left to right. 1513 0 1 2 3 1514 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 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 | Type | Length | Extended-Type |M| Reserved | 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 | Vendor-Id | 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 | Vendor-Type | Value .... 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 Type.Extended-Type 1525 246.26 for Extended-Vendor-Specific-6 1527 Length 1529 >= 10 (first fragment) 1530 >= 5 (subsequent fragments) 1532 When a VSA is fragmented across multiple Attributes, only the 1533 first Attribute contains the Vendor-Id and Vendor-Type fields. 1534 Subsequent Attributes contain fragments of the Value field only. 1536 M (More) 1538 The More field is one (1) bit in length, and indicates whether or 1539 not the current attribute contains "more" than 251 octets of data. 1540 Further definition of this field is given in Section 2.2, above. 1542 Reserved 1544 This field is 7 bits long, and is reserved for future use. 1545 Implementations MUST set it to zero (0) when encoding an attribute 1546 for sending in a packet. The contents SHOULD be ignored on 1547 reception. 1549 Vendor-Id 1551 The 4 octets are the Network Management Private Enterprise Code 1552 [PEN] of the Vendor in network byte order. 1554 Vendor-Type 1556 The Vendor-Type field is one octet. Values are assigned at the 1557 sole discretion of the Vendor. 1559 Value 1561 The Value field is one or more octets. The actual format of the 1562 information is site or application specific, and a robust 1563 implementation SHOULD support the field as undistinguished octets. 1565 The codification of the range of allowed usage of this field is 1566 outside the scope of this specification. 1568 Implementations supporting this specification MUST use the 1569 Identifier of "Type.Extended-Type.Vendor-Id.Vendor-Type" to 1570 determine the interpretation of the Value field. 1572 5. Compatibility with traditional RADIUS 1574 There are a number of potential compatibility issues with traditional 1575 RADIUS, as defined in [RFC6158] and earlier. This section describes 1576 them. 1578 5.1. Attribute Allocation 1580 Some vendors have used Attribute Type codes from the "Reserved" 1581 space, as part of vendor-defined dictionaries. This practice is 1582 considered anti-social behavior, as noted in [RFC6158]. These vendor 1583 definitions conflict with the attributes in the RADIUS Attribute Type 1584 space. The conflicting definitions may make it difficult for 1585 implementations to support both those Vendor Attributes, and the new 1586 Extended Attribute formats. 1588 We RECOMMEND that RADIUS client and server implementations delete all 1589 references to these improperly defined attributes. Failing that, we 1590 RECOMMEND that RADIUS server implementations have a per-client 1591 configurable flag which indicates which type of attributes are being 1592 sent from the client. If the flag is set to "Non-Standard 1593 Attributes", the conflicting attributes can be interpreted as being 1594 improperly defined Vendor Specific Attributes. If the flag is set the 1595 "IETF Attributes", the attributes MUST be interpreted as being of the 1596 Extended Attributes format. The default SHOULD be to interpret the 1597 attributes as being of the Extended Attributes format. 1599 Other methods of determining how to decode the attributes into a 1600 "correct" form are NOT RECOMMENDED. Those methods are likely to be 1601 fragile and prone to error. 1603 We RECOMMEND that RADIUS server implementations re-use the above flag 1604 to determine which type of attributes to send in a reply message. If 1605 the request is expected to contain the improperly defined attributes, 1606 the reply SHOULD NOT contain Extended Attributes. If the request is 1607 expected to contain Extended Attributes, the reply MUST NOT contain 1608 the improper Attributes. 1610 RADIUS clients will have fewer issues than servers. Clients MUST NOT 1611 send improperly defined Attributes in a request. For replies, 1612 clients MUST interpret attributes as being of the Extended Attributes 1613 format, instead of the improper definitions. These requirements 1614 impose no change in the RADIUS specifications, as such usage by 1615 vendors has always been in conflict with the standard requirements 1616 and the standards process. 1618 Existing clients that send these improperly defined attributes 1619 usually have a configuration setting which can disable this behavior. 1620 We RECOMMEND that vendors ship products with the default set to 1621 "disabled". We RECOMMEND that administrators set this flag to 1622 "disabled" on all equipment that they manage. 1624 5.2. Proxy Servers 1626 RADIUS Proxy servers will need to forward Attributes having the new 1627 format, even if they do not implement support for the encoding and 1628 decoding of those attributes. We remind implementors of the 1629 following text in [RFC2865] Section 2.3: 1631 The forwarding server MUST NOT change the order of any attributes 1632 of the same type, including Proxy-State. 1634 This requirement solves some of the issues related to proxying of the 1635 new format, but not all. The reason is that proxy servers are 1636 permitted to examine the contents of the packets that they forward. 1637 Many proxy implementations not only examine the attributes, but they 1638 refuse to forward attributes which they do not understand (i.e. 1639 attributes for which they have no local dictionary definitions). 1641 This practice is NOT RECOMMENDED. Proxy servers SHOULD forward 1642 attributes, even ones which they do not understand, or which are not 1643 in a local dictionary. When forwarded, these attributes SHOULD be 1644 sent verbatim, with no modifications or changes. This requirement 1645 includes "invalid attributes", as there may be some other system in 1646 the network which understands them. 1648 The only exception to this recommendation is when local site policy 1649 dictates that filtering of attributes has to occur. For example, a 1650 filter at a visited network may require removal of certain 1651 authorization rules which apply to the home network, but not to the 1652 visited network. This filtering can sometimes be done even when the 1653 contents of the attributes are unknown, such as when all Vendor- 1654 Specific Attributes are designated for removal. 1656 As seen in [EDUROAM] many proxies do not follow these practices for 1657 unknown Attributes. Some proxies filter out unknown attributes or 1658 attributes which have unexpected lengths (24%, 17/70), some truncate 1659 the attributes to the "expected" length (11%, 8/70), some discard the 1660 request entirely (1%, 1/70), with the rest (63%, 44/70) following the 1661 recommended practice of passing the attributes verbatim. It will be 1662 difficult to widely use the Extended Attributes format until all non- 1663 conformant proxies are fixed. We therefore RECOMMEND that all 1664 proxies which do not support the Extended Attributes (241 through 1665 246) define them as being of data type "string", and delete all other 1666 local definitions for those attributes. 1668 This last change should enable wider usage of the Extended Attributes 1669 format. 1671 6. Guidelines 1673 This specification proposes a number of changes to RADIUS, and 1674 therefore requires a set of guidelines, as has been done in 1675 [RFC6158]. These guidelines include suggestions around design, 1676 interaction with IANA, usage, and implementation of attributes using 1677 the new formats. 1679 6.1. Updates to RFC 6158 1681 This specification updates [RFC6158] by adding the data types "evs", 1682 "tlv" and "integer64"; defining them to be "basic" data types; and 1683 permitting their use subject to the restrictions outlined below. 1685 The recommendations for the use of the new data types and attribute 1686 formats are given below. 1688 6.2. Guidelines for Simple Data Types 1690 [RFC6158] Section A.2.1 says in part: 1692 * Unsigned integers of size other than 32 bits. 1693 SHOULD be replaced by an unsigned integer of 32 bits. There is 1694 insufficient justification to define a new size of integer. 1696 We update that specification to permit unsigned integers of 64 bits, 1697 for the reasons defined above in Section 2.5. The updated text is as 1698 follows: 1700 * Unsigned integers of size other than 32 or 64 bits. 1701 SHOULD be replaced by an unsigned integer of 32 or 64 bits. 1702 There is insufficient justification to define a new size 1703 of integer. 1705 That section later continues with the following list item: 1707 * Nested attribute-value pairs (AVPs). 1708 Attributes should be defined in a flat typespace. 1710 We update that specification to permit nested TLVs, as defined in 1711 this document: 1713 * Nested attribute-value pairs (AVPs) using the extended 1714 attribute format MAY be used. All other nested AVP or TLV 1715 formats MUST NOT be used. 1717 The [RFC6158] recommendations for "basic" data types apply to the 1718 three types listed above. All other recommendations given in 1719 [RFC6158] for "basic" data types remain unchanged. 1721 6.3. Guidelines for Complex Data Types 1723 [RFC6158] Section 2.1 says: 1725 Complex data types MAY be used in situations where they reduce 1726 complexity in non-RADIUS systems or where using the basic data 1727 types 1728 would be awkward (such as where grouping would be required in 1729 order 1730 to link related attributes). 1732 Since the extended attribute format allows for grouping of complex 1733 types via TLVs, the guidelines for complex data types need to be 1734 updated as follows: 1736 Complex data types MAY be used where they reduce complexity in 1737 non-RADIUS systems, though this practice is NOT RECOMMENDED. The 1738 complex data type exceptions of [RFC6158] Section 3.2.4 still 1739 apply. In all other situations, complex data types MUST NOT be 1740 used. Instead, complex data types MUST be decomposed into TLVs. 1742 The checklist in Appendix A.2.2 is similarly updated to add a new 1743 requirement at the top of that section, 1745 Does the attribute: 1747 * define a complex type which can be represented via TLVs? 1749 If so, this data type MUST be represented via TLVs. 1751 Note that this requirement does not over-ride Section A.1, which 1752 permits the transport of complex types in certain situations. 1754 All other recommendations given in [RFC6158] for "complex" data types 1755 remain unchanged. 1757 6.4. Design Guidelines For the New Types 1759 This section gives design guidelines for specifications defining 1760 attributes using the new format. The items listed below are not 1761 exhaustive. As experience is gained with the new formats, later 1762 specifications may define additional guidelines. 1764 * The data type "evs" MUST NOT be used for standard RADIUS 1765 Attributes, or for TLVs, or for VSAs. 1767 * The data type "tlv" SHOULD NOT be used for standard RADIUS 1768 attributes. This format was NOT RECOMMENDED by [RFC6158], 1769 but their utility is now evident. 1771 * [RFC2866] "tagged" attributes MUST NOT be defined in the 1772 Extended-Type space. The "tlv" data type should be used instead 1773 to group attributes. 1775 * The "integer64" data type MAY be used in any RADIUS attribute. 1776 The use of 64-bit integers is NOT RECOMMENDED by [RFC6158], but 1777 their utility is now evident. 1779 * Any attribute which is allocated from the "long extended space" of 1780 data type "text", "string", or "tlv" can potentially carry more 1781 than 251 octets of data. Specifications defining such attributes 1782 SHOULD define a maximum length to guide implementations. 1784 All other recommendations given in [RFC6158] for attribute design 1785 guidelines apply to attributes using the "short extended space" and 1786 "long extended space". 1788 6.5. TLV Guidelines 1790 The following items give design guidelines for specifications using 1791 TLVs. 1793 * when multiple attributes are intended to be grouped or managed 1794 together, the use of TLVs to group related attributes is 1795 RECOMMENDED. 1797 * more than 4 layers (depth) of TLV nesting is NOT RECOMMENDED. 1799 * Interpretation of an attribute depends only on its type 1800 definition (e.g. Type.Extended-Type.TLV-Type), and 1801 not on its encoding or location in the RADIUS packet. 1803 * Where a group of TLVs is strictly defined, and not expected to 1804 change, and totals less than 247 octets of data, they SHOULD 1805 request allocation from the "short extended space". 1807 * Where a group of TLVs is loosely defined, or is expected to change, 1808 they SHOULD request allocation from the "long extended space". 1810 All other recommendations given in [RFC6158] for attribute design 1811 guidelines apply to attributes using the TLV format. 1813 6.6. Allocation Request Guidelines 1815 The following items give guidelines for allocation requests made in a 1816 RADIUS specification. 1818 * Discretion is RECOMMENDED when requesting allocation of attributes. 1819 The new space is much larger than the old one, but it is not 1820 infinite. 1822 * Specifications which allocate many attributes MUST NOT request that 1823 allocation be made from the standard space. That space is under 1824 allocation pressure, and the extended space is more suitable for 1825 large allocations. 1827 * Specifications which allocate many related attributes SHOULD define 1828 one or more TLVs to contain related attributes. 1830 * Specifications SHOULD request allocation from a specific space. 1831 The IANA considerations given in Section 9, below, give instruction 1832 to IANA, but authors should assist IANA where possible. 1834 * Specifications of an attribute which encodes 252 octets or less of 1835 data MAY request allocation from the "short extended space". 1837 * Specifications of an attribute which always encode less than 253 1838 octets of data MUST NOT request allocation from the long extended 1839 space. The standard space, or the short extended space MUST be 1840 used instead. 1842 * Specifications of an attribute which encodes 253 octets or more of 1843 data MUST request allocation from the "long extended space". 1845 * When the extended space is nearing exhaustion, a new specification 1846 SHOULD be written which requests allocation of one or more RADIUS 1847 Attributes from the "Reserved" portion of the standard space, 1848 values 247-255, using an appropriate format ("Short Extended Type", 1849 or "Long Extended Type") 1851 An allocation request made in a specification SHOULD use one of the 1852 following formats when allocating an attribute type code: 1854 * TBDn - request allocation of an attribute from the "standard 1855 space". The value "n" should be "1" or more, to track individual 1856 attributes which are to be allocated. 1858 * SHORT-TBDn - request allocation of an attribute from the "short 1859 extended space". The value "n" should be "1" or more, to track 1860 individual attributes which are to be allocated. 1862 * LONG-TBDn - request allocation of an attribute from the "long 1863 extended space". The value "n" should be "1" or more, to track 1864 individual attributes which are to be allocated. 1866 These guidelines should help specification authors and IANA 1867 communicate effectively and clearly. 1869 6.7. Allocation Requests Guidelines for TLVs 1871 Specifications may allocate a new attribute of type TLV, and at the 1872 same time, allocate sub-attributes within that TLV. These 1873 specifications SHOULD request allocation of specific values for the 1874 sub-TLV. The "dotted number" notation MUST be used. 1876 For example, a specification may request allocation of a TLV as 1877 SHORT-TBD1. Within that attribute, it could request allocation of 1878 three sub-TLVs, as SHORT-TBD1.1, SHORT-TBD1.2, and SHORT-TBD1.3. 1880 Specifications may request allocation of additional sub-TLVs within 1881 an existing attribute of type TLV. Those specifications SHOULD use 1882 the "TBDn" format for every entry in the "dotted number" notation. 1884 For example, a specification may request allocation within an 1885 existing TLV, with "dotted number" notation MM.NN. Within that 1886 attribute, the specification could request allocation of three sub- 1887 TLVs, as MM.NN.TBD1, MM.NN.TBD2, and MM.NN.TBD3. 1889 6.8. Implementation Guidelines 1891 * RADIUS client implementations SHOULD support this specification, 1892 in order to permit the easy deployment of specifications using 1893 the changes defined herein. 1895 * RADIUS server implementations SHOULD support this specification, 1896 in order to permit the easy deployment of specifications using 1897 the changes defined herein. 1899 * RADIUS proxy servers MUST follow the specifications in section 5.2 1901 6.9. Vendor Guidelines 1903 * Vendors SHOULD use the existing Vendor-Specific Attribute Type 1904 space in preference to the new Extended-Vendor-Specific 1905 attributes, as this specification may take time to become widely 1906 deployed. 1908 * Vendors SHOULD implement this specification. The changes to 1909 RADIUS are relatively small, and are likely to quickly be used 1910 in new specifications. 1912 7. Rationale for This Design 1914 The path to extending the RADIUS protocol has been long and arduous. 1915 A number of proposals have been made and discarded by the RADEXT 1916 working group. These proposals have been judged to be either too 1917 bulky, too complex, too simple, or to be unworkable in practice. We 1918 do not otherwise explain here why earlier proposals did not obtain 1919 working group consensus. 1921 The changes outlined here have the benefit of being simple, as the 1922 "Extended Type" format requires only a one octet change to the 1923 Attribute format. The downside is that the "Long Extended Type" 1924 format is awkward, and the 7 Reserved bits will likely never be used 1925 for anything. 1927 7.1. Attribute Audit 1929 An audit of almost five thousand publicly available attributes [ATTR] 1930 (2010), shows the statistics summarized below. The attributes include 1931 over 100 Vendor dictionaries, along with the IANA assigned 1932 attributes: 1934 Count Data Type 1935 ----- --------- 1936 2257 integer 1937 1762 text 1938 273 IPv4 Address 1939 225 string 1940 96 other data types 1941 35 IPv6 Address 1942 18 date 1943 10 integer64 1944 4 Interface Id 1945 3 IPv6 Prefix 1947 4683 Total 1949 The entries in the "Data Type" column are data types recommended by 1950 [RFC6158], along with "integer64". The "other data types" row 1951 encompasses all other data types, including complex data types and 1952 data types transporting opaque data. 1954 We see that over half of the attributes encode less than 16 octets of 1955 data. It is therefore important to have an extension mechanism which 1956 adds as little as possible to the size of these attributes. Another 1957 result is that the overwhelming majority of attributes use simple 1958 data types. 1960 Of the attributes defined above, 177 were declared as being inside of 1961 a TLV. This is approximately 4% of the total. We did not 1962 investigate whether additional attributes were defined in a flat name 1963 space, but could have been defined as being inside of a TLV. We 1964 expect that the number could be as high as 10% of attributes. 1966 Manual inspection of the dictionaries shows that approximately 20 (or 1967 0.5%) attributes have the ability to transport more than 253 octets 1968 of data. These attributes are divided between VSAs, and a small 1969 number of standard Attributes such as EAP-Message. 1971 The results of this audit and analysis is reflected in the design of 1972 the extended attributes. The extended format has minimal overhead, 1973 it permits TLVs, and it has support for "long" attributes. 1975 8. Diameter Considerations 1977 The attribute formats defined in this specification need to be 1978 transported in Diameter. While Diameter supports attributes longer 1979 than 253 octets and grouped attributes, we do not use that 1980 functionality here. Instead, we define the simplest possible 1981 encapsulation method. 1983 The new formats MUST be treated the same as traditional RADIUS 1984 attributes when converting from RADIUS to Diameter, or vice versa. 1985 That is, the new attribute space is not converted to any "extended" 1986 Diameter attribute space. Fragmented attributes are not converted to 1987 a single long Diameter attribute. The new EVS data types are not 1988 converted to Diameter attributes with the "V" bit set. 1990 In short, this document mandates no changes for existing RADIUS to 1991 Diameter, or Diameter to RADIUS gateways. 1993 9. Examples 1995 A few examples are presented here in order to illustrate the encoding 1996 of the new attribute formats. These examples are not intended to be 1997 exhaustive, as many others are possible. For simplicity, we do not 1998 show complete packets, only attributes. 2000 The examples are given using a domain-specific language implemented 2001 by the program given in Appendix A. The language is line oriented, 2002 and composed of a sequence of lines matching the grammar ([RFC5234]) 2003 given below: 2005 Identifier = 1*DIGIT *( "." 1*DIGIT ) 2007 HEXCHAR = HEXDIG HEXDIG 2009 STRING = DQUOTE 1*CHAR DQUOTE 2011 TLV = "{" 1*DIGIT DATA "}" 2013 DATA = 1*HEXCHAR / 1*TLV / STRING 2015 LINE = Identifier DATA 2017 The program has additional restrictions on its input that are not 2018 reflected in the above grammar. For example, the portions of the 2019 Identifier which refer to Type and Extended-Type are limited to 2020 values between 1 and 255. We trust that the source code in Appendix 2021 A is clear, and that these restrictions do not negatively affect the 2022 comprehensibility of the examples. 2024 The program reads the input text, and interprets it as a set of 2025 instructions to create RADIUS Attributes. It then prints the hex 2026 encoding of those attributes. It implements the minimum set of 2027 functionality which achieves that goal. This minimalism means that 2028 it does not use attribute dictionaries; it does not implement support 2029 for RADIUS data types; it can be used to encode attributes with 2030 invalid data fields; and there is no requirement for consistency from 2031 one example to the next. For example, it can be used to encode a 2032 User-Name attribute which contains non-UTF8 data, or a Framed-IP- 2033 Address which contains 253 octets of ASCII data. As a result, it 2034 MUST NOT be used to create RADIUS Attributes for transport in a 2035 RADIUS message. 2037 However, the program correctly encodes the RADIUS attribute fields of 2038 "Type", "Length", "Extended-Type", "More", "Reserved", "Vendor-Id", 2039 "Vendor-Type", and "Vendor-Length". It encodes RADIUS attribute data 2040 types "evs" and TLV. It can therefore be used to encode example 2041 attributes from inputs which are humanly readable. 2043 We do not give examples of "malformed" or "invalid attributes". We 2044 also note that the examples show format, rather than consistent 2045 meaning. A particular Attribute Type code may be used to demonstrate 2046 two different formats. In real specifications, attributes have a 2047 static definitions based on their type code. 2049 The examples given below are strictly for demonstration purposes 2050 only, and do not provide a standard of any kind. 2052 9.1. Extended Type 2054 The following are a series of examples of the "Extended Type" format. 2056 Attribute encapsulating textual data. 2058 241.1 "bob" 2059 -> f1 06 01 62 6f 62 2061 Attribute encapsulating a TLV with TLV-Type of one (1). 2063 241.2 { 1 23 45 } 2064 -> f1 07 02 01 04 23 45 2066 Attribute encapsulating two TLVs, one after the other. 2068 241.2 { 1 23 45 } { 2 67 89 } 2069 -> f1 0b 02 01 04 23 45 02 04 67 89 2071 Attribute encapsulating two TLVs, where the second TLV is itself 2072 encapsulating a TLV. 2074 241.2 { 1 23 45 } { 3 { 1 ab cd } } 2075 -> f1 0d 02 01 04 23 45 03 06 01 04 ab cd 2077 Attribute encapsulating two TLVs, where the second TLV is itself 2078 encapsulating two TLVs. 2080 241.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } 2081 -> f1 12 02 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f 2083 Attribute encapsulating a TLV, which in turn encapsulates a TLV, 2084 to a depth of 5 nestings. 2086 241.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } 2087 -> f1 0f 01 01 0c 02 0a 03 08 04 06 05 04 cd ef 2089 Attribute encapsulating an extended Vendor Specific attribute, 2090 with Vendor-Id of 1, and Vendor-Type of 4, which in turn 2091 encapsulates textual data. 2093 241.26.1.4 "test" 2094 -> f1 0c 1a 00 00 00 01 04 74 65 73 74 2096 Attribute encapsulating an extended Vendor Specific attribute, with 2097 Vendor-Id of 1, and Vendor-Type of 5, which in turn encapsulates 2098 a TLV with TLV-Type of 3, which encapsulates textual data. 2100 241.26.1.5 { 3 "test" } 2101 -> f1 0e 1a 00 00 00 01 05 03 06 74 65 73 74 2103 9.2. Long Extended Type 2105 The following are a series of examples of the "Long Extended Type" 2106 format. 2108 Attribute encapsulating textual data. 2110 245.1 "bob" 2111 -> f5 07 01 00 62 6f 62 2113 Attribute encapsulating a TLV with TLV-Type of one (1). 2115 245.2 { 1 23 45 } 2116 -> f5 08 02 00 01 04 23 45 2118 Attribute encapsulating two TLVs, one after the other. 2120 245.2 { 1 23 45 } { 2 67 89 } 2121 -> f5 0c 02 00 01 04 23 45 02 04 67 89 2123 Attribute encapsulating two TLVs, where the second TLV is itself 2124 encapsulating a TLV. 2126 245.2 { 1 23 45 } { 3 { 1 ab cd } } 2127 -> f5 0e 02 00 01 04 23 45 03 06 01 04 ab cd 2129 Attribute encapsulating two TLVs, where the second TLV is itself 2130 encapsulating two TLVs. 2132 245.2 { 1 23 45 } { 3 { 1 ab cd } { 2 "foo" } } 2133 -> f5 13 02 00 01 04 23 45 03 0b 01 04 ab cd 02 05 66 6f 6f 2135 Attribute encapsulating a TLV, which in turn encapsulates a TLV, 2136 to a depth of 5 nestings. 2138 245.1 { 1 { 2 { 3 { 4 { 5 cd ef } } } } } 2139 -> f5 10 01 00 01 0c 02 0a 03 08 04 06 05 04 cd ef 2141 Attribute encapsulating an extended Vendor Specific attribute, 2142 with Vendor-Id of 1, and Vendor-Type of 4, which in turn 2143 encapsulates textual data. 2145 245.26.1.4 "test" 2146 -> f5 0d 1a 00 00 00 00 01 04 74 65 73 74 2148 Attribute encapsulating an extended Vendor Specific attribute, 2149 with Vendor-Id of 1, and Vendor-Type of 5, which in turn 2150 encapsulates a TLV with TLV-Type of 3, which encapsulates 2151 textual data. 2153 245.26.1.5 { 3 "test" } 2154 -> f5 0f 1a 00 00 00 00 01 05 03 06 74 65 73 74 2156 Attribute encapsulating more than 251 octets of data. The "Data" 2157 portions are indented for readability. 2159 245.4 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2160 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2161 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2162 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2163 aaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2164 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2165 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2166 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2167 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbcccccccccccccccccccc 2168 cccccccccc 2169 -> f5 ff 04 80 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2170 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2171 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2172 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2173 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2174 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2175 aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb bb bb bb bb bb 2176 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2177 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2178 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2179 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2180 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2181 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 13 04 00 cc 2182 cc cc cc cc cc cc cc cc cc cc cc cc cc cc 2184 Attribute encapsulating an extended Vendor Specific attribute, 2185 with Vendor-Id of 1, and Vendor-Type of 6, which in turn 2186 encapsulates more than 251 octets of data. 2188 As the VSA encapsulates more than 251 octets of data, it is 2189 split into two RADIUS attributes. The first attribute has the 2190 More field set, and carries the Vendor-Id and Vendor-Type. 2191 The second attribute has the More field clear, and carries 2192 the rest of the data portion of the VSA. Note that the second 2193 attribute does not include the Vendor-Id ad Vendor-Type fields. 2195 The "Data" portions are indented for readability. 2197 245.26.1.6 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2198 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2199 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2200 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2201 aaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2202 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2203 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2204 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2205 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbccccccccccccc 2206 ccccccccccccccccc 2207 -> f5 ff 1a 80 00 00 00 01 06 aa aa aa aa aa aa aa aa aa aa aa 2208 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2209 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2210 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2211 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2212 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 2213 aa aa aa aa aa aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb 2214 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2215 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2216 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2217 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2218 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb 2219 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 18 1a 00 bb 2220 bb bb bb bb cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 2222 10. IANA Considerations 2224 This document updates [RFC3575] in that it adds new IANA 2225 considerations for RADIUS Attributes. These considerations modify 2226 and extend the IANA considerations for RADIUS, rather than replacing 2227 them. 2229 The IANA considerations of this document are limited to the "RADIUS 2230 Attribute Types" registry. Some Attribute Type values which were 2231 previously marked "Reserved" are now allocated, and the registry is 2232 extended from a simple 8-bit array to a tree-like structure, up to a 2233 maximum depth of 125 nodes. Detailed instructions are given below. 2235 10.1. Attribute Allocations 2237 IANA is requested to move the following Attribute Type values from 2238 "Reserved", to "Allocated", with the corresponding names: 2240 * 241 Extended-Type-1 2241 * 242 Extended-Type-2 2242 * 243 Extended-Type-3 2243 * 244 Extended-Type-4 2244 * 245 Long-Extended-Type-1 2245 * 246 Long-Extended-Type-2 2247 These values serve as an encapsulation layer for the new RADIUS 2248 Attribute Type tree. 2250 10.2. RADIUS Attribute Type Tree 2252 Each of the Attribute Type values allocated above extends the "RADIUS 2253 Attribute Types" to an N-ary tree, via a "dotted number" notation. 2254 Allocation of an Attribute Type value "TYPE" using the new Extended 2255 type format results in allocation of 255 new Attribute Type values, 2256 of format "TYPE.1" through "TYPE.255". Value twenty-six (26) is 2257 assigned as "Extended-Vendor-Specific-*". Values "TYPE.241" through 2258 "TYPE.255" are marked "Reserved". All other values are "Unassigned". 2260 The initial set of Attribute Type values and names assigned by this 2261 document is given below. 2263 * 241 Extended-Attribute-1 2264 * 241.{1-25} Unassigned 2265 * 241.26 Extended-Vendor-Specific-1 2266 * 241.{27-240} Unassigned 2267 * 241.{241-255} Reserved 2268 * 242 Extended-Attribute-2 2269 * 242.{1-25} Unassigned 2270 * 242.26 Extended-Vendor-Specific-2 2271 * 242.{27-240} Unassigned 2272 * 243 Extended-Attribute-3 2273 * 242.{241-255} Reserved 2274 * 243.{1-25} Unassigned 2275 * 243.26 Extended-Vendor-Specific-3 2276 * 243.{27-240} Unassigned 2277 * 243.{241-255} Reserved 2278 * 244 Extended-Attribute-4 2279 * 244.{1-25} Unassigned 2280 * 244.26 Extended-Vendor-Specific-4 2281 * 244.{27-240} Unassigned 2282 * 244.{241-255} Reserved 2283 * 245 Extended-Attribute-5 2284 * 245.{1-25} Unassigned 2285 * 245.26 Extended-Vendor-Specific-5 2286 * 245.{27-240} Unassigned 2287 * 245.{241-255} Reserved 2288 * 246 Extended-Attribute-6 2289 * 246.{1-25} Unassigned 2290 * 245.26 Extended-Vendor-Specific-6 2291 * 246.{27-240} Unassigned 2292 * 246.{241-255} Reserved 2294 As per [RFC5226], the values marked "Unassigned" above are available 2295 via for assignment by IANA in future RADIUS specifications. The 2296 values marked "Reserved" are reserved for future use. 2298 The Extended-Vendor-Specific spaces (TYPE.26) are for Private Use, 2299 and allocations are not managed by IANA. 2301 Allocation of Reserved entries in the extended space requires 2302 Standards Action. 2304 All other allocations in the extended space require IETF Review. 2306 10.3. Allocation Instructions 2308 This section defines what actions IANA needs to take when allocating 2309 new attributes. Different actions are required when allocating 2310 attributes from the standard space, attributes of Extended Type 2311 format, attributes of the "Long Extended Type" format, preferential 2312 allocations, attributes of data type TLV, attributes within a TLV, 2313 and attributes of other data types. 2315 10.3.1. Requested Allocation from the Standard Space 2317 Specifications can request allocation of an Attribute from within the 2318 standard space (e.g. Attribute Type Codes 1 through 255), subject to 2319 the considerations of [RFC3575] and this document. 2321 10.3.2. Requested Allocation from the short extended space 2323 Specifications can request allocation of an Attribute which requires 2324 the format Extended Type, by specifying the short extended space In 2325 that case, IANA should assign the lowest Unassigned number from the 2326 Attribute Type space with the relevant format. 2328 10.3.3. Requested Allocation from the long extended space 2330 Specifications can request allocation of an Attribute which requires 2331 the format "Long Extended Type", by specifying the extended space 2332 (long). In that case, IANA should assign the lowest Unassigned 2333 number from the Attribute Type space with the relevant format. 2335 10.3.4. Allocation Preferences 2337 Specifications which make no request for allocation from a specific 2338 Type Space should have Attributes allocated using the following 2339 criteria: 2341 * when the standard space has no more Unassigned attributes, 2342 all allocations should be performed from the extended space. 2344 * specifications which allocate a small number of attributes 2345 (i.e. less than ten) should have all allocations made from 2346 the standard space. 2348 * specifications which would allocate a large percentage of the 2349 remaining standard space attributes should have all allocations 2350 made from the extended space. 2352 * specifications which request allocation of an attribute of 2353 data type TLV should have that attribute allocated from the 2354 extended space. 2356 * specifications which request allocation of an attribute 2357 which can transport 253 or more octets of data should have 2358 that attribute allocated from within the long extended space, 2359 We note that Section 6.5, above requires specifications to 2360 request this allocation. 2362 There is otherwise no requirement that all attributes within a 2363 specification be allocated from one type space or another. 2364 Specifications can simultaneously allocate attributes from both the 2365 standard space and the extended space. 2367 10.3.5. Extending the Type Space via TLV Data Type 2369 When specifications request allocation of an attribute of data type 2370 "tlv", that allocation extends the Attribute Type Tree by one more 2371 level. Allocation of an Attribute Type value "TYPE.TLV", with Data 2372 Type TLV, results in allocation of 255 new Attribute Type values, of 2373 format "TYPE.TLV.1" through "TYPE.TLV.255". Values 254-255 are 2374 marked "Reserved". All other values are "Unassigned". Value 26 has 2375 no special meaning. 2377 For example, if a new attribute "Example-TLV" of data type "tlv" is 2378 assigned the identifier "245.1", then the extended tree will be 2379 allocated as below: 2381 * 245.1 Example-TLV 2382 * 245.1.{1-253} Unassigned 2383 * 245.1.{254-255} Reserved 2385 Note that this example does not define an "Example-TLV" attribute. 2387 The Attribute Type Tree can be extended multiple levels in one 2388 specification when the specification requests allocation of nested 2389 TLVs, as discussed below. 2391 10.3.6. Allocation within a TLV 2393 Specifications can request allocation of Attribute Type values within 2394 an Attribute of Data Type TLV. The encapsulating TLV can be 2395 allocated in the same specification, or it can have been previously 2396 allocated. 2398 Specifications need to request allocation within a specific Attribute 2399 Type value (e.g. "TYPE.TLV.*"). Allocations are performed from the 2400 smallest Unassigned value, proceeding to the largest Unassigned 2401 value. 2403 Where the Attribute being allocated is of Data Type TLV, the 2404 Attribute Type tree is extended by one level, as given in the 2405 previous section. Allocations can then be made within that level. 2407 10.3.7. Allocation of Other Data Types 2409 Attribute Type value allocations are otherwise allocated from the 2410 smallest Unassigned value, proceeding to the largest Unassigned 2411 value. e.g. Starting from 241.1, proceeding through 241.255, then to 2412 242.1, through 242.255, etc. 2414 11. Security Considerations 2416 This document defines new formats for data carried inside of RADIUS, 2417 but otherwise makes no changes to the security of the RADIUS 2418 protocol. 2420 Attacks on cryptographic hashes are well known, and are getting 2421 better with time, as discussed in[RFC4270]. RADIUS uses the MD5 hash 2422 [RFC1321] for packet authentication and attribute obfuscation. There 2423 are ongoing efforts in the IETF to analyze and address these issues 2424 for the RADIUS protocol. 2426 As with any protocol change, code changes are required in order to 2427 implement the new features. These code changes have the potential to 2428 introduce new vulnerabilities in the software. Since the RADIUS 2429 server performs network authentication, it is an inviting target for 2430 attackers. We RECOMMEND that access to RADIUS servers be kept to a 2431 minimum. 2433 12. References 2435 12.1. Normative references 2437 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2438 Requirement Levels", RFC 2119, March, 1997. 2440 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 2441 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2442 2000. 2444 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 2446 [RFC3575] Aboba, B, "IANA Considerations for RADIUS (Remote 2447 Authentication Dial In User Service)", RFC 3575, July 2003. 2449 [RFC5176] Chiba, M, et. al., "Dynamic Authorization Extensions to Remote 2450 Authentication Dial In User Service (RADIUS)", RFC 5176, 2451 January 2008. 2453 [RFC5226] Narten, T. and Alvestrand, H, "Guidelines for Writing an IANA 2454 Considerations Section in RFCs", RFC 5226, May 2008. 2456 [RFC6158] DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC 2457 6158, March 2011. 2459 [PEN] http://www.iana.org/assignments/enterprise-numbers 2461 12.2. Informative references 2463 [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, 2464 April, 1992 2466 [RFC2868] Zorn, G., et al, " RADIUS Attributes for Tunnel Protocol 2467 Support", RFC 2868, June 2000. 2469 [RFC4270] Hoffman, P, and Schneier, B, "Attacks on Cryptographic Hashes 2470 in Internet Protocols", RFC 4270, November 2005. 2472 [RFC5234] Crocker, D. (Ed.), and Overell, P., "Augmented BNF for Syntax 2473 Specifications: ABNF", RFC 5234, October 2005. 2475 [EDUROAM] Internal Eduroam testing page, data retrieved 04 August 2010. 2477 [ATTR] http://github.com/alandekok/freeradius- 2478 server/tree/master/share/, data retrieved September 2010. 2480 Acknowledgments 2482 This document is the result of long discussions in the IETF RADEXT 2483 working group. The authors would like to thank all of the 2484 participants who contributed various ideas over the years. Their 2485 feedback has been invaluable, and has helped to make this 2486 specification better. 2488 Appendix A - Extended Attribute Generator Program 2490 This section contains "C" program source which can be used for 2491 testing. It reads a line-oriented text file, parses it to create 2492 RADIUS formatted attributes, and prints the hex version of those 2493 attributes to standard output. 2495 The input accepts a grammar similar to that given in Section 9, with 2496 some modifications for usability. For example, blank lines are 2497 allowed, lines beginning with a '#' character are interpreted as 2498 comments, numbers (RADIUS Types, etc.) are checked for minimum / 2499 maximum values, and RADIUS Attribute lengths are enforced. 2501 The program is included here for demonstration purposes only, and 2502 does not define a standard of any kind. 2504 ------------------------------------------------------------ 2505 /* 2506 * Copyright (c) 2010 IETF Trust and the persons identified as 2507 * authors of the code. All rights reserved. 2508 * 2509 * Redistribution and use in source and binary forms, with or without 2510 * modification, are permitted provided that the following conditions 2511 * are met: 2512 * 2513 * Redistributions of source code must retain the above copyright 2514 * notice, this list of conditions and the following disclaimer. 2515 * 2516 * Redistributions in binary form must reproduce the above copyright 2517 * notice, this list of conditions and the following disclaimer in 2518 * the documentation and/or other materials provided with the 2519 * distribution. 2520 * 2521 * Neither the name of Internet Society, IETF or IETF Trust, nor the 2522 * names of specific contributors, may be used to endorse or promote 2523 * products derived from this software without specific prior written 2524 * permission. 2525 * 2526 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 2527 * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, 2528 * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 2529 * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 2530 * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS 2531 * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 2532 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED 2533 * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 2534 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON 2535 * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 2536 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT 2537 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 2538 * SUCH DAMAGE. 2539 * 2540 * Author: Alan DeKok 2541 */ 2542 #include 2543 #include 2544 #include 2545 #include 2546 #include 2547 #include 2549 static int encode_tlv(char *buffer, uint8_t *output, size_t outlen); 2551 static const char *hextab = "0123456789abcdef"; 2553 static int encode_data_string(char *buffer, 2554 uint8_t *output, size_t outlen) 2555 { 2556 int length = 0; 2557 char *p; 2559 p = buffer + 1; 2561 while (*p && (outlen > 0)) { 2562 if (*p == '"') { 2563 return length; 2564 } 2566 if (*p != '\\') { 2567 *(output++) = *(p++); 2568 outlen--; 2569 length++; 2570 continue; 2571 } 2573 switch (p[1]) { 2574 default: 2575 *(output++) = p[1]; 2576 break; 2578 case 'n': 2579 *(output++) = '\n'; 2580 break; 2582 case 'r': 2583 *(output++) = '\r'; 2584 break; 2586 case 't': 2587 *(output++) = '\t'; 2588 break; 2589 } 2591 outlen--; 2592 length++; 2593 } 2595 fprintf(stderr, "String is not terminated\n"); 2596 return 0; 2597 } 2599 static int encode_data_tlv(char *buffer, char **endptr, 2600 uint8_t *output, size_t outlen) 2601 { 2602 int depth = 0; 2603 int length; 2604 char *p; 2606 for (p = buffer; *p != '\0'; p++) { 2607 if (*p == '{') depth++; 2608 if (*p == '}') { 2609 depth--; 2610 if (depth == 0) break; 2611 } 2612 } 2614 if (*p != '}') { 2615 fprintf(stderr, "No trailing '}' in string starting " 2616 "with \"%s\"\n", 2617 buffer); 2618 return 0; 2619 } 2621 *endptr = p + 1; 2622 *p = '\0'; 2624 p = buffer + 1; 2625 while (isspace((int) *p)) p++; 2627 length = encode_tlv(p, output, outlen); 2628 if (length == 0) return 0; 2630 return length; 2631 } 2632 static int encode_data(char *p, uint8_t *output, size_t outlen) 2633 { 2634 int length; 2636 if (!isspace((int) *p)) { 2637 fprintf(stderr, "Invalid character following attribute " 2638 "definition\n"); 2639 return 0; 2640 } 2642 while (isspace((int) *p)) p++; 2644 if (*p == '{') { 2645 int sublen; 2646 char *q; 2648 length = 0; 2650 do { 2651 while (isspace((int) *p)) p++; 2652 if (!*p) { 2653 if (length == 0) { 2654 fprintf(stderr, "No data\n"); 2655 return 0; 2656 } 2658 break; 2659 } 2661 sublen = encode_data_tlv(p, &q, output, outlen); 2662 if (sublen == 0) return 0; 2664 length += sublen; 2665 output += sublen; 2666 outlen -= sublen; 2667 p = q; 2668 } while (*q); 2670 return length; 2671 } 2673 if (*p == '"') { 2674 length = encode_data_string(p, output, outlen); 2675 return length; 2676 } 2678 length = 0; 2679 while (*p) { 2680 char *c1, *c2; 2682 while (isspace((int) *p)) p++; 2684 if (!*p) break; 2686 if(!(c1 = memchr(hextab, tolower((int) p[0]), 16)) || 2687 !(c2 = memchr(hextab, tolower((int) p[1]), 16))) { 2688 fprintf(stderr, "Invalid data starting at " 2689 "\"%s\"\n", p); 2690 return 0; 2691 } 2693 *output = ((c1 - hextab) << 4) + (c2 - hextab); 2694 output++; 2695 length++; 2696 p += 2; 2698 outlen--; 2699 if (outlen == 0) { 2700 fprintf(stderr, "Too much data\n"); 2701 return 0; 2702 } 2703 } 2705 if (length == 0) { 2706 fprintf(stderr, "Empty string\n"); 2707 return 0; 2708 } 2710 return length; 2711 } 2713 static int decode_attr(char *buffer, char **endptr) 2714 { 2715 long attr; 2717 attr = strtol(buffer, endptr, 10); 2718 if (*endptr == buffer) { 2719 fprintf(stderr, "No valid number found in string " 2720 "starting with \"%s\"\n", buffer); 2721 return 0; 2722 } 2724 if (!**endptr) { 2725 fprintf(stderr, "Nothing follows attribute number\n"); 2726 return 0; 2727 } 2728 if ((attr <= 0) || (attr > 256)) { 2729 fprintf(stderr, "Attribute number is out of valid " 2730 "range\n"); 2731 return 0; 2732 } 2734 return (int) attr; 2735 } 2737 static int decode_vendor(char *buffer, char **endptr) 2738 { 2739 long vendor; 2741 if (*buffer != '.') { 2742 fprintf(stderr, "Invalid separator before vendor id\n"); 2743 return 0; 2744 } 2746 vendor = strtol(buffer + 1, endptr, 10); 2747 if (*endptr == (buffer + 1)) { 2748 fprintf(stderr, "No valid vendor number found\n"); 2749 return 0; 2750 } 2752 if (!**endptr) { 2753 fprintf(stderr, "Nothing follows vendor number\n"); 2754 return 0; 2755 } 2757 if ((vendor <= 0) || (vendor > (1 << 24))) { 2758 fprintf(stderr, "Vendor number is out of valid range\n"); 2759 return 0; 2760 } 2762 if (**endptr != '.') { 2763 fprintf(stderr, "Invalid data following vendor number\n"); 2764 return 0; 2765 } 2766 (*endptr)++; 2768 return (int) vendor; 2769 } 2771 static int encode_tlv(char *buffer, uint8_t *output, size_t outlen) 2772 { 2773 int attr; 2774 int length; 2775 char *p; 2776 attr = decode_attr(buffer, &p); 2777 if (attr == 0) return 0; 2779 output[0] = attr; 2780 output[1] = 2; 2782 if (*p == '.') { 2783 p++; 2784 length = encode_tlv(p, output + 2, outlen - 2); 2786 } else { 2787 length = encode_data(p, output + 2, outlen - 2); 2788 } 2790 if (length == 0) return 0; 2791 if (length > (255 - 2)) { 2792 fprintf(stderr, "TLV data is too long\n"); 2793 return 0; 2794 } 2796 output[1] += length; 2798 return length + 2; 2799 } 2801 static int encode_vsa(char *buffer, uint8_t *output, size_t outlen) 2802 { 2803 int vendor; 2804 int attr; 2805 int length; 2806 char *p; 2808 vendor = decode_vendor(buffer, &p); 2809 if (vendor == 0) return 0; 2811 output[0] = 0; 2812 output[1] = (vendor >> 16) & 0xff; 2813 output[2] = (vendor >> 8) & 0xff; 2814 output[3] = vendor & 0xff; 2816 length = encode_tlv(p, output + 4, outlen - 4); 2817 if (length == 0) return 0; 2818 if (length > (255 - 6)) { 2819 fprintf(stderr, "VSA data is too long\n"); 2820 return 0; 2821 } 2822 return length + 4; 2823 } 2825 static int encode_evs(char *buffer, uint8_t *output, size_t outlen) 2826 { 2827 int vendor; 2828 int attr; 2829 int length; 2830 char *p; 2832 vendor = decode_vendor(buffer, &p); 2833 if (vendor == 0) return 0; 2835 attr = decode_attr(p, &p); 2836 if (attr == 0) return 0; 2838 output[0] = 0; 2839 output[1] = (vendor >> 16) & 0xff; 2840 output[2] = (vendor >> 8) & 0xff; 2841 output[3] = vendor & 0xff; 2842 output[4] = attr; 2844 length = encode_data(p, output + 5, outlen - 5); 2845 if (length == 0) return 0; 2847 return length + 5; 2848 } 2850 static int encode_extended(char *buffer, 2851 uint8_t *output, size_t outlen) 2852 { 2853 int attr; 2854 int length; 2855 char *p; 2857 attr = decode_attr(buffer, &p); 2858 if (attr == 0) return 0; 2860 output[0] = attr; 2862 if (attr == 26) { 2863 length = encode_evs(p, output + 1, outlen - 1); 2864 } else { 2865 length = encode_data(p, output + 1, outlen - 1); 2866 } 2867 if (length == 0) return 0; 2868 if (length > (255 - 3)) { 2869 fprintf(stderr, "Extended Attr data is too long\n"); 2870 return 0; 2871 } 2873 return length + 1; 2874 } 2876 static int encode_extended_flags(char *buffer, 2877 uint8_t *output, size_t outlen) 2878 { 2879 int attr; 2880 int length, total; 2881 char *p; 2883 attr = decode_attr(buffer, &p); 2884 if (attr == 0) return 0; 2886 /* output[0] is the extended attribute */ 2887 output[1] = 4; 2888 output[2] = attr; 2889 output[3] = 0; 2891 if (attr == 26) { 2892 length = encode_evs(p, output + 4, outlen - 4); 2893 if (length == 0) return 0; 2895 output[1] += 5; 2896 length -= 5; 2897 } else { 2898 length = encode_data(p, output + 4, outlen - 4); 2899 } 2900 if (length == 0) return 0; 2902 total = 0; 2903 while (1) { 2904 int sublen = 255 - output[1]; 2906 if (length <= sublen) { 2907 output[1] += length; 2908 total += output[1]; 2909 break; 2910 } 2912 length -= sublen; 2914 memmove(output + 255 + 4, output + 255, length); 2915 memcpy(output + 255, output, 4); 2917 output[1] = 255; 2918 output[3] |= 0x80; 2920 output += 255; 2921 output[1] = 4; 2922 total += 255; 2923 } 2925 return total; 2926 } 2928 static int encode_rfc(char *buffer, uint8_t *output, size_t outlen) 2929 { 2930 int attr; 2931 int length, sublen; 2932 char *p; 2934 attr = decode_attr(buffer, &p); 2935 if (attr == 0) return 0; 2937 length = 2; 2938 output[0] = attr; 2939 output[1] = 2; 2941 if (attr == 26) { 2942 sublen = encode_vsa(p, output + 2, outlen - 2); 2944 } else if ((*p == ' ') || ((attr < 241) || (attr > 246))) { 2945 sublen = encode_data(p, output + 2, outlen - 2); 2947 } else { 2948 if (*p != '.') { 2949 fprintf(stderr, "Invalid data following " 2950 "attribute number\n"); 2951 return 0; 2952 } 2954 if (attr < 245) { 2955 sublen = encode_extended(p + 1, 2956 output + 2, outlen - 2); 2957 } else { 2959 /* 2960 * Not like the others! 2961 */ 2962 return encode_extended_flags(p + 1, output, outlen); 2963 } 2964 } 2965 if (sublen == 0) return 0; 2966 if (sublen > (255 -2)) { 2967 fprintf(stderr, "RFC Data is too long\n"); 2968 return 0; 2969 } 2971 output[1] += sublen; 2972 return length + sublen; 2973 } 2975 int main(int argc, char *argv[]) 2976 { 2977 int lineno; 2978 size_t i, outlen; 2979 FILE *fp; 2980 char input[8192], buffer[8192]; 2981 uint8_t output[4096]; 2983 if ((argc < 2) || (strcmp(argv[1], "-") == 0)) { 2984 fp = stdin; 2985 } else { 2986 fp = fopen(argv[1], "r"); 2987 if (!fp) { 2988 fprintf(stderr, "Error opening %s: %s\n", 2989 argv[1], strerror(errno)); 2990 exit(1); 2991 } 2992 } 2994 lineno = 0; 2995 while (fgets(buffer, sizeof(buffer), fp) != NULL) { 2996 char *p = strchr(buffer, '\n'); 2998 lineno++; 3000 if (!p) { 3001 if (!feof(fp)) { 3002 fprintf(stderr, "Line %d too long in %s\n", 3003 lineno, argv[1]); 3004 exit(1); 3005 } 3006 } else { 3007 *p = '\0'; 3008 } 3010 p = strchr(buffer, '#'); 3011 if (p) *p = '\0'; 3013 p = buffer; 3014 while (isspace((int) *p)) p++; 3015 if (!*p) continue; 3017 strcpy(input, p); 3018 outlen = encode_rfc(input, output, sizeof(output)); 3019 if (outlen == 0) { 3020 fprintf(stderr, "Parse error in line %d of %s\n", 3021 lineno, input); 3022 exit(1); 3023 } 3025 printf("%s -> ", buffer); 3026 for (i = 0; i < outlen; i++) { 3027 printf("%02x ", output[i]); 3028 } 3029 printf("\n"); 3030 } 3032 if (fp != stdin) fclose(fp); 3034 return 0; 3035 } 3036 ------------------------------------------------------------ 3038 Author's Address 3040 Alan DeKok 3041 Network RADIUS SARL 3042 15 av du Granier 3043 38240 Meylan 3044 France 3046 Email: aland@networkradius.com 3047 URI: http://networkradius.com 3049 Avi Lior 3050 Bridgewater Systems Corporation 3051 303 Terry Fox Drive 3052 Suite 100 3053 Ottawa, Ontario K2K 3J1 3054 Canada 3056 Phone: +1 (613) 591-6655 3057 Email: avi@bridgewatersystems.com 3058 URI: http://www.bridgewatersystems.com/