idnits 2.17.1 draft-lior-radius-attribute-type-extension-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 455. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 466. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 473. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 479. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 296 has weird spacing: '... String b;...' -- 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 (June 12, 2007) is 6161 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2866 -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Li 3 Internet-Draft A. Lior 4 Expires: December 14, 2007 BWS 5 G. Zorn 6 Cisco 7 June 12, 2007 9 Remote Authentication Dial In User Service (RADIUS) Attribute Type 10 Extension 11 draft-lior-radius-attribute-type-extension-02.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 14, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 In order for the Remote Authentication Dial In User Service protocol 45 to continue to support new applications, the RADIUS attribute space 46 must be extended beyond the current limit of 255 possible attribute 47 types. This document defines a mechanism to extend the base RADIUS 48 attribute types while maintaining backwards compatibility as well as 49 compatibility with Diameter. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. RADIUS Type Extension . . . . . . . . . . . . . . . . . . . . 4 58 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 65 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 67 Intellectual Property and Copyright Statements . . . . . . . . . . 12 69 1. Introduction 71 The Remote Authentication Dial In User Service (RADIUS) Protocol 72 [RFC2865] defines two classes of attributes: attributes that belong 73 to the standard RADIUS space; and vendor specific attributes (VSAs). 75 VSAs are available to allow vendors (historically including Standards 76 Development Organizations) to support their own extended attributes 77 not suitable for general usage, whereas the attributes that belong to 78 the standard RADIUS space are controlled by the IETF are intended to 79 be suitable for general use. These attributes are defined in RFCs 80 and are assigned type codes by Internet Assigned Number Authority 81 (IANA)IANA [RFC3575]. 83 Attributes that belong to the RADIUS space are allocated a type code 84 that is a single octet and hence RADIUS is limited to 255 attribute 85 types. Of these, 101 or so have already been assigned and 61 are 86 reserved. Therefore, as of this writing there are less than 100 type 87 codes that can be allocated to new attributes. 89 RADIUS evolution must not be hindered by the inability to define new 90 RADIUS attributes. This document defines a mechanism to extend the 91 RADIUS Attribute space by means of a new scheme for allocating 92 attribute type codes. 94 1.1. Terminology 96 The term RADIUS Extended Attribute is the name given to the new 97 RADIUS attribute types that are enabled by this document. The RADIUS 98 Extended Type contains the new type code that is assigned to the 99 RADIUS Extended Attributes. 101 Other terms used in this document are explained below: 103 To be completed... 105 1.2. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 2. Requirements 113 This informative section describes the requirements that drive the 114 solution used to create the RADIUS Extended Attribute types. 116 A fundamental requirement for extending the RADIUS attribute space is 117 to maintain backwards compatibility. This means that RADIUS servers 118 and proxies must be able to continue to decode and encode messages 119 even though they may not need to understand an attribute that has 120 been extended. More specifically, the scheme MUST to be compatible 121 with both RADIUS [RFC2865] and RADIUS Accounting [RFC2866]. 123 The scheme SHOULD ensure that the size of the type-space extension is 124 large enough that it will not be exhausted in the foreseeable future 125 or is itself easily extensible in the event of type code exhaustion. 127 Furthermore, the scheme should align with the Diameter Network Access 128 Server Application [RFC4005], thereby allowing the two IETF AAA 129 standards to interoperate. 131 Although according to the specification the allocation of RADIUS 132 attribute type codes has been controlled by IANA, this has not been 133 the case in reality. In the real world, certain vendors have grabbed 134 attribute type codes that they shouldn't have. The result is that 135 many RADIUS deployments have had to work around these attribute 136 collisions. Therefore, each time a new attribute type is introduced 137 it raises the possibility that something will break. The proposed 138 scheme must be impervious to this artifact. 140 A need to group RADIUS attributes together has become more prevalent 141 in current work. Therefore, the proposed scheme NUST provide a 142 mechanism to group attributes. 144 In recent years, attribute sizes are threatening the limit of 253 145 octets. Fragmentation of RADIUS attributes has always been possible 146 by extending the value into another attribute of the same type. 147 However this approach does not always work, especially if the 148 attribute type repeats in the RADIUS packet. The proposed scheme 149 SHOULD address attribute fragmentation. 151 3. RADIUS Type Extension 153 The solution described in this document uses the Vendor-Specific 154 attribute [RFC2865]as a basis for the creation of the RADIUS Extended 155 Attributes. 157 We allocate RADIUS the Vendor-Id of zero (0). In essence we are 158 assigning the IETF a Vendor-Id which is what other Standard 159 Development Organization have done in registering their own 160 Vendor-Id. 162 Vendor Specific attributes are encoded by using the Vendor-Specific 163 (26) type code, followed by Length (1 octet), a 4 octet Vendor-Id 164 identified using 3 octets (4 octets really) and a string which is 165 vendor-specific [RFC2865]. 167 The string part is encoded as follows: 169 o The first octet represents the RADIUS Extended Type 171 o The next octet is the length of the Extended Attribute, which 172 represents the length of the Extended Type field (1 octet), the 173 length of the length itself (1 octet), the length of the 174 Fragmentation and Tag field (1 octet) and the length of the Value 175 field (1 or more octet(s) 177 o The third octet is the Fragmentation/Tag field (1 octet) 179 o The value is 1 or more octets 181 4. Formal Syntax 183 The following represents the encoding scheme used for RADIUS Extended 184 Attribute(s). It is based upon the Vendor Specific (26) encoding 185 [RFC2865]. 187 +---------------------------------------------------------------+ 188 | 1 2 3 | 189 |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| 190 +---------------+---------------+-------------------------------+ 191 | Type (26) | Length | Vendor-Id (0) | 192 +---------------+---------------+-------------------------------+ 193 | Vendor-Id(0) | Extended-Type | Length | 194 +---------------+---------------+---------------+---------------+ 195 |F| TAG | Value 196 +---------------+--------------- 198 Type 26 for Vendor-Specific. 200 Length >= 10 202 Vendor-Id 204 The high-order octet is zero (0) and the low-order 3 octets are zeros 205 (0)s representing an extended IETF RADIUS attribute. 207 Extended-Type 208 One (1) Octet. Up-to-date values of the RADIUS Extended-Type field 209 are specified in the most recent "Assigned Numbers" IANA [RFC3575] . 210 Values XXXX-YYYY are reserved. 212 Length >= 4 The length of the Extended-Type, Length, Fragmentation 213 and Tag fields and the length of the Value field 215 Fragmentation (F): 217 When set(1) the attribute is fragmented. When clear (0), the 218 attribute is not fragmented. When the value portion of an extended 219 attribute exceeds 246 octets the value is fragmented over one or more 220 extended attribute. In this case the Fragmentation Flag is set on 221 the attribute(s) that contain the value fragments. 223 Tag 225 The Tag field is 7-bits and MUST always be present. It is used to 226 group extended attributes. Attributes with the same non-zero value 227 belong to the same group. A tag value of zero(0) indicates that the 228 attribute is not grouped. A tag value of all-ones (0x7F) is 229 reserved. 231 Value 233 One or more octets. 235 5. Examples 237 Consider an attribute called Foo of type String. Foo is allocated an 238 Extended-Type by IANA of 10. The following figure shows the encoding 239 of Foo(0,10) = "Hello": 241 +---------------------------------------------------------------+ 242 | 1 2 3 | 243 |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| 244 +---------------+---------------+-------------------------------+ 245 | Type (26) | Length | Vendor-Id (0) | 246 | | (6+8 = 14) | | 247 +---------------+---------------+-------------------------------+ 248 | Vendor-Id(0) | Extended-Type | Length | 249 | | (10) | (3 + 5 = 8) | 250 +---------------+---------------+---------------+---------------+ 251 |F| TAG | Value | | | 252 |0| (0) | (H) | (e) | (l) | 253 +---------------+---------------+-------------------------------+ 254 | (l) | (o) | 255 +---------------+---------------+ 257 The next figure shows the encoding of Foo when the length of Foo is 258 251 octets. Foo(0,10) = "Hello W...end.". In this case the value is 259 fragmented over two attributes. The first 246 octets are included in 260 the first fragment and the remaining 5 octets appear in the second 261 attributes which has the Fragmentation bit set to 1. 263 +---------------------------------------------------------------+ 264 | 1 2 3 | 265 |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| 266 +---------------+---------------+-------------------------------+ 267 | Type (26) | Length | Vendor-Id (0) | 268 | |(6 + 249 = 255)| | 269 +---------------+---------------+-------------------------------+ 270 | Vendor-Id(0) | Extended-Type | Length | 271 | | (10) |(3 + 246 = 249)| 272 +---------------+---------------+---------------+---------------+ 273 |F| TAG | Value | | | 274 |0| (0) | (H) | (e) | (l) | 275 +---------------+---------------+-------------------------------+ 276 | (l) | (o) | | (W) | 277 +---------------+---------------+---------------+---------------+ 278 ................ 279 +---------------+---------------+-------------------------------+ 280 | Type (26) | Length | Vendor-Id (0) | 281 | | (6+8 = 14) | | 282 +---------------+---------------+-------------------------------+ 283 | Vendor-Id(0) | Extended-Type | Length | 284 | | (10) | (3 + 5 = 8) | 285 +---------------+---------------+---------------+---------------+ 286 |F| TAG | Value | | | 287 |1| (0) | ( ) | (e) | (n) | 288 +---------------+---------------+-------------------------------+ 289 | (d) | (.) | 290 +---------------+---------------+ 292 Next consider the following structure: 294 struct 295 Integer a; 296 String b; 297 Integer c; 298 endStruct 300 Element 'a' is assigned an extended type of 20. Element 'b' is 301 assigned an extended type of 25 and element 'c' is assigned an 302 extended type of 27. The following figure illustrates the coding 303 where a(0,20) = 0xDEADDEAD, b(0,25) = "He.....The end." and is of 304 length 251 octets; and c(0,27) = 0x12345678. The attributes are 305 grouped together with TAG=42. 307 +---------------------------------------------------------------+ 308 | 1 2 3 | 309 |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| 310 +---------------+---------------+-------------------------------+ 311 | Type (26) | Length | Vendor-Id (0) | 312 | |(6 + 7 = 13) | | 313 +---------------+---------------+-------------------------------+ 314 | Vendor-Id(0) | Extended-Type | Length | 315 | | (20) |(3 + 4 = 7) | 316 +-+-------------+---------------+---------------+---------------+ 317 |F| TAG | Value | | | 318 |0| (42) | (0xde) | (0xad) | (0xde) | 319 +-+-------------+---------------+-------------------------------+ 320 | (0xad) | Type(26) | Length | Vendor-Id(0) | 321 | | | (6 + 249 = 255| | 322 +---------------+---------------+---------------+---------------+ 323 | Vendor-Id (0) | Extended-Type | 324 | | (25) | 325 +---------------+-+-------------+---------------+---------------+ 326 | Length |F| TAG | Value | Value | 327 | (3+246) = 249 |0| (42) | (H) | (e) | 328 +---------------+-+-------------+---------------+---------------+ 330 ........... 331 +---------------+---------------+---------------+---------------+ 332 | Value | Value | Value | Value | 333 | (.) | (T) | (h) | (e) | 334 +---------------+---------------+---------------+---------------+ 335 | Type (26) | Length | Vendor-Id (0) | 336 | | (6+8 = 14) | | 337 +---------------+---------------+-------------------------------+ 338 | Vendor-Id(0) | Extended-Type | Length | 339 | | (25) | (3 + 5 = 8) | 340 +---------------+---------------+---------------+---------------+ 341 |F| TAG | Value | | | 342 |1| (42) | ( ) | (e) | (n) | 343 +---------------+---------------+---------------+---------------+ 344 | (d) | (.) | Type (26) | Length | 345 | | | | (6+7 = 13) | 346 +---------------+---------------+---------------+---------------+ 347 | Vendor-Id (0) | 348 | | 349 +---------------+---------------+-+-------------+---------------+ 350 |Extended-Type | Length |F| TAG | Value | 351 | (27) | (3+4 = 7) |0| (42) | (0x12) | 352 +---------------+---------------+-+-------------+---------------+ 353 | Value | Value | Value | 354 | (0x34) | (0x56) | (0x78) | 355 +---------------+---------------+---------------+ 357 6. Security Considerations 359 TBD 361 7. IANA Considerations 363 This solution requires that the IETF be allocated Vendor-Type of zero 364 to the IETF. 366 It also requires that IANA be set up to manage the RADIUS Extended 367 Attributes. 369 The allocation rules for extended RADIUS attributes align with the 370 rules for allocation of the standard RADIUS attributes. 372 8. Open Issues 374 What is the numbering scheme for attributes that will be used by RFC 375 writers going forward? For example today we write user-name(1). 376 Going forward, will we write foo-bar(0,1)? 378 What is the numbering plan for these attributes? What range should 379 be reserved? 381 We have allocated 1 octets for Extended Type. Is that too little? 382 Note, if we run out the IETF can take out another Vendor-Id. 384 9. References 386 9.1. Normative References 388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", BCP 14, RFC 2119, March 1997. 391 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 392 "Remote Authentication Dial In User Service (RADIUS)", 393 RFC 2865, June 2000. 395 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 397 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 398 Authentication Dial In User Service)", RFC 3575, 399 July 2003. 401 9.2. Informative References 403 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 404 "Diameter Network Access Server Application", RFC 4005, 405 August 2005. 407 Authors' Addresses 409 Yong Li 410 Bridgewater Systems Corporation 411 303 Terry Fox Drive 412 Suite 100 413 Ottawa, Ontario K2K 3J1 414 Canada 416 Phone: (613) 591-6655 417 Email: yongli@bridgewatersystems.com 418 URI: http://www.bridgewatersystems.com/ 420 Avi Lior 421 Bridgewater Systems Corporation 422 303 Terry Fox Drive 423 Suite 100 424 Ottawa, Ontario K2K 3J1 425 Canada 427 Phone: (613) 591-6655 428 Email: avi@bridgewatersystems.com 429 URI: http://www.bridgewatersystems.com/ 430 Glen Zorn 431 Cisco Systems 432 2901 Third Avenue, Suite 600 433 SEA1/5/ 434 Seattle, WA 98121 435 United States of America 437 Phone: 438 Email: gwz@cisco.com 439 URI: http://www.cisco.com/ 441 Full Copyright Statement 443 Copyright (C) The IETF Trust (2007). 445 This document is subject to the rights, licenses and restrictions 446 contained in BCP 78, and except as set forth therein, the authors 447 retain all their rights. 449 This document and the information contained herein are provided on an 450 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 451 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 452 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 453 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 454 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 455 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 457 Intellectual Property 459 The IETF takes no position regarding the validity or scope of any 460 Intellectual Property Rights or other rights that might be claimed to 461 pertain to the implementation or use of the technology described in 462 this document or the extent to which any license under such rights 463 might or might not be available; nor does it represent that it has 464 made any independent effort to identify any such rights. Information 465 on the procedures with respect to rights in RFC documents can be 466 found in BCP 78 and BCP 79. 468 Copies of IPR disclosures made to the IETF Secretariat and any 469 assurances of licenses to be made available, or the result of an 470 attempt made to obtain a general license or permission for the use of 471 such proprietary rights by implementers or users of this 472 specification can be obtained from the IETF on-line IPR repository at 473 http://www.ietf.org/ipr. 475 The IETF invites any interested party to bring to its attention any 476 copyrights, patents or patent applications, or other proprietary 477 rights that may cover technology that may be required to implement 478 this standard. Please address the information to the IETF at 479 ietf-ipr@ietf.org. 481 Acknowledgment 483 Funding for the RFC Editor function is provided by the IETF 484 Administrative Support Activity (IASA).