idnits 2.17.1 draft-ietf-radext-extended-attributes-04.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 535. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 546. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 553. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 559. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 366 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 (July 7, 2008) is 5766 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) -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) Summary: 1 error (**), 0 flaws (~~), 2 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 Intended status: Standards Track BWS 5 Expires: January 8, 2009 G. Zorn 6 NetCube Technologies 7 July 7, 2008 9 Extended Remote Authentication Dial In User Service (RADIUS) Attributes 10 draft-ietf-radext-extended-attributes-04.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 8, 2009. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 For the Remote Authentication Dial In User Service (RADIUS) protocol 44 to continue to support new applications the RADIUS attribute type 45 space must be extended beyond the current limit of 255 possible 46 attribute types while maintaining backwards compatibility with the 47 existing protocol. This document defines a mechanism to accomplish 48 that task, along with standard methods to group together related 49 attributes and to encode values that don't fit into 253 octets. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 57 4. RADIUS Type Extension . . . . . . . . . . . . . . . . . . . . 4 58 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 59 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 62 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 65 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 67 Intellectual Property and Copyright Statements . . . . . . . . . . 13 69 1. Introduction 71 The Remote Authentication Dial In User Service (RADIUS) Protocol 72 [RFC2865] defines two classes of attributes: standard and vendor- 73 specific. 75 Vendor-specific Attributes (VSAs) allow vendors (including Standards 76 Development Organizations (SDOs)) to define their own Attributes, 77 which may not be suitable for general usage; on the other hand, the 78 attributes that belong to the standard RADIUS space are controlled by 79 the IETF and are intended to be of general utility. These attributes 80 are defined in RFCs and are assigned type codes by the Internet 81 Assigned Number Authority (IANA)[IANA]. 83 The standard RADIUS attribute type code is 8 bits in length; hence 84 RADIUS is limited to 255 attribute types. Of these 255 attribute 85 types, 101 or so have been assigned. According to RFC 3575 86 [RFC3575], types 192-223 are reserved for experimental use; types 87 224-240 are reserved for implementation-specific use; and values 241- 88 255 are reserved and should not be used. Therefore, as of this 89 writing there are approximately 90 type codes that can be allocated 90 to new attributes. 92 RADIUS evolution must not be hindered by the inability to define new 93 standard RADIUS attributes. This document defines a mechanism to 94 extend the standard RADIUS Attribute space by defining a new scheme 95 to allocate attribute type codes. In addition, mechanisms are 96 defined to support both the grouping of related attributes and the 97 encoding of attribute values the length of which exceed the current 98 limit of 253 octets. 100 2. Terminology 102 Extended Attribute 103 The term used for the new RADIUS attributes that are defined in 104 this document 106 Extended Type 107 The type code assigned to an Extended Attribute 109 2.1. Requirements Language 111 In this document, several words are used to signify the requirements 112 of the specification. These words are often capitalized. The key 113 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 114 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 115 are to be interpreted as described in [RFC2119]. 117 An implementation is not compliant if it fails to satisfy one or more 118 of the must or must not requirements for the protocols it implements. 119 An implementation that satisfies all the MUST, MUST NOT, SHOULD, and 120 SHOULD NOT requirements for its protocols is said to be 121 "unconditionally compliant"; one that satisfies all the MUST and MUST 122 NOT requirements but not all the SHOULD or SHOULD NOT requirements 123 for its protocols is said to be "conditionally compliant". 125 3. Problem Statement 127 A fundamental requirement for extending the RADIUS attribute space is 128 the maintenance of backwards compatibility. This means that RADIUS 129 servers and proxies must be able to continue to decode and encode 130 messages even though they may not need to understand an attribute 131 that has been extended. More specifically, the scheme MUST be 132 compliant with the various RADIUS RFCs such as [RFC2865] and RADIUS 133 Accounting [RFC2866], etc. 135 The scheme SHOULD ensure that the size of the standard type space 136 extension is large enough that it will not be quickly exhausted or is 137 extensible in the event that it is. 139 Furthermore, the scheme SHOULD align with the Diameter NASReq 140 Application [RFC4005], thereby allowing the two AAA standards to 141 interoperate. 143 A need to group related RADIUS attributes together has become 144 prevalent in current work. Therefore, the proposed scheme SHOULD 145 provide a mechanism to group related attributes together. 147 In recent years, attribute sizes have been threatening the limit of 148 253 octets. Fragmentation of RADIUS attributes has always been 149 possible by extending the value into another attribute of the same 150 type; however, this approach does not always work (for example, if 151 more than one instance of an attribute occurs in the same RADIUS 152 packet). The proposed scheme SHOULD enable the transmission of 153 attributes longer than 253 octets. 155 4. RADIUS Type Extension 157 The solution described in this document takes the recommended VSA 158 format [RFC2865] as a basis for the RADIUS Extended Attributes. 160 We allocate RADIUS the Vendor-Id of zero (0). In essence we are 161 assigning the IETF a Vendor-Id which is what other SDOs have done in 162 registering their own Vendor-Id. 164 Extended Attributes consist of an attribute header similar to that 165 recommended by RFC 2865 [RFC2865] for Vendor Specific Attributes 166 followed by a non-empty sequence of Type-Length-Value (TLV) triples 167 (see below). If an Extended Attribute contains more than one TLV 168 then all of the encapsulated TLVs MUST fit completely within the 169 Extended Attribute. 171 The Extended Attribute header is 7 octets in length and is encoded as 172 follows: 174 o The first octet contains the Type which is always Vendor-Specific 175 (26) 177 o The second octet contains the length (in octets) of the entire 178 Extended Attribute, including the Extended Attribute header and 179 all encapsulated TLVs 181 o The next 4 octets contain the Vendor-Id (0) 183 o The final octet of the header contains the More flag and Tag 184 field. If the one bit More flag is set (1) this indicates that 185 the encapsulated TLV is continued in the following Extended 186 Attribute; if the More flag is clear (0) then all of the 187 encapsulated TLVs fit into the current Extended Attribute. The 188 More flag MUST NOT be set if the Extended Attribute contains more 189 than one TLV. The Tag field is used to combine sets of related 190 Extended Attributes into simple groups. 192 o The Data field is an abstract container for TLVs; the Data field 193 MUST contain at least one TLV. 195 TLVs are encoded as follows: 197 o The first two octets contain the Ext-Type field 199 o The next octet is the Ext-Length field, representing the length of 200 the entire TLV, including the length of the Ext-Type field (2 201 octets), the length of the Ext-Length field itself (1 octet) and 202 the length of the Value field (1 or more octets) 204 o The Value field consists of one or more octets comprising the 205 actual data to be transmitted 207 5. Formal Syntax 209 This section describes the encoding scheme used for RADIUS Extended 210 Attributes. The basis of this encoding is the format recommended for 211 Vendor Specific Attributes in RFC 2865 [RFC2865]. 213 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Type (26) | Length | Vendor-Id (0) | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Vendor-Id (0) |M| Tag | Data... 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Type 223 26 for Vendor-Specific 225 Length 227 >=11 229 Vendor ID 231 The high-order octet is zero (0) and the low-order 3 octets are 232 zeros (0)s representing an extended IETF RADIUS attribute 234 M (More) 236 The More Flag is one (1) bit in length and MUST be present. When 237 a value to be transmitted exceeds 246 octets in length it is 238 fragmented over two or more Extended Attributes. If the More Flag 239 is set (1), this indicates that the Value field of the Extended 240 Attribute contains a fragment of a larger value, which is 241 continued in the next Extended Attribute of the same Ext-Type. 242 When the More Flag is clear (0), the final (or only) fragment of 243 the value is contained in the Extended Attribute. 245 Tag 247 The Tag field is 7 bits long and MUST be present. It is used to 248 group Extended Attributes. Extended Attributes with the same non- 249 zero value in the Tag field belong to the same group. A Tag value 250 of zero (0) indicates that the attribute is not grouped. A Tag 251 value of all ones (0x7F) is reserved. 253 Data 255 The Data field is >= 4 octets in length. It consists of 1 or more 256 TLVs. 258 TLVs have the following syntax: 260 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Ext-Type | Ext-Len | Value... 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Ext-Type 268 Two (2) octets. Up-to-date values of the Ext-Type field are 269 specified in the most recent "Assigned Numbers" [IANA]. Values 270 XXXX-YYYY are reserved. 272 Ext-Len 274 >= 4. The length of the Extended Attribute, including the Ext- 275 Type, Ext-Length and Value fields. 277 Value 279 One or more octets. 281 6. Examples 283 Consider an attribute called Foo of type String. Foo has been 284 allocated an Extended-Type 0f 257 by IANA. The following figure 285 shows the encoding of Foo(0,4) = "Hello": 287 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Type (26) | Length | Vendor-Id 291 | | (7 + 8 = 15) | (0) 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Vendor-Id (cont) |M| Tag | Ext-Type 294 |0| (0) | (0) 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Ext-Type (cont)| Ext-Length | Value | | 297 (257) | (3 + 5 = 8) | (H) | (e) | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | | | | 300 | (l) | (l) | (o) | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Figure 1 305 Now consider another instantiation of the Foo Extended Attribute, 306 this one with a length of 251 octets. In this case the value is 307 fragmented over two Extended Attributes. The first 245 octets are 308 included in the first fragment which has the More bit set and the 309 remaining 6 octets appear in the second attribute. Figure 2 below 310 illustrates the encoding of the first 7 octets of the first Extended 311 Attribute (Foo(0,6) = "Hello W"), while Figure 3 shows how the second 312 attribute (Foo(246,250) = "e end.") is encoded. 314 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Type (26) | Length | Vendor-Id 318 | |(7 + 248 = 255)| (0) 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Vendor-Id (cont) |M| Tag | Ext-Type 321 (0) |1| (0) | (0) 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Ext-Type (cont)| Ext-Length | Value | | 324 (257) |(3 + 245 = 248)| (H) | (e) | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | | | | | 327 | (l) | (l) | (o) | ( ) | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | | 330 | (W) | ... 331 +-+-+-+-+-+-+-+-+ 333 Figure 2 335 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Type (26) | Length | Vendor-Id 339 | | (7 + 9 = 15) | (0) 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Vendor-Id (cont) |M| Tag | Ext-Type 342 (0) |0| (0) | (0) 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 Ext-Type (cont)| Ext-Length | Value | | 345 (256) | (3 + 6 = 9) | (e) | ( ) | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | | | | | 348 | (e) | (n) | (d) | (.) | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 Figure 3 353 The next example illustrates several of the features of Extended 354 Attributes: 356 o encapsulation of values greater than 253 octets in length 358 o grouping of related Extended Attributes using tags 360 o encapsulation of more than one TLV in a single Extended Attribute 362 Consider the following structure: 364 struct 365 Integer a; 366 String b; 367 Integer c; 368 endStruct 370 Element a is assigned an Extended Type of 290. Element b is assigned 371 an Extended Type of 259 and element c is assigned an Extended Type of 372 271. The following figure illustrates the coding where a(0,20) = 373 0xDEADDEAD, b(0,1) = "He", b(243,250) = "The end." and is of length 374 251 octets; and c(0,27) = 0x12345678. The attributes are grouped 375 together with TAG=42. For the sake of brevity, the value of b(3,241) 376 is omitted. 378 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Type (26) | Length | Vendor-Id 382 | | (7 + 7 = 14) | (0) 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 Vendor-Id (cont) |M| Tag | Ext-Type 385 (0) |0| (42) | (0) 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 Ext-Type (cont)| Ext-Length | Value | | 388 (290) | (3 + 4 = 7) | (0xDE) | (0xAD) | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | | | 391 | (0xDE | (0xAD) | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 1 2 3 395 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 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Type (26) | Length | Vendor-Id 398 | |(7 + 248 = 255)| (0) 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Vendor-Id (cont) |M| Tag | Ext-Type 401 (0) |1| (42) | (0) 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 Ext-Type (cont)| Ext-Length | Value | | 405 (259) |(3 + 245 = 248)| (H) | (e) | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 ... 408 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Type (26) | Length | Vendor-Id 412 | | (7+8+7=22) | (0) 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 Vendor-Id (cont) |M| Tag | Ext-Type 415 (0) |0| (42) | (0) 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Ext-Type (cont)| Ext-Length | Value | | 418 (259) | (3 + 5 = 8) | ( ) | (e) | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | | | | Ext-Type 421 | (n) | (d) | (.) | (0) 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Ext-Type (cont)| Ext-Length | Value | | 424 (271) | (3 + 4 = 7) | (0x12) | (0x34) | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | | | 427 | (0x78) | (0x56) | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 Figure 4 432 7. Security Considerations 434 TBD 436 8. IANA Considerations 438 This solution requires that the Vendor-Type of zero be allocated to 439 the IETF. 441 It also requires that IANA set up a new registry for the RADIUS 442 Extended Attribute Types. 444 9. Open Issues 446 What is the numbering scheme for attributes that will be used by RFC 447 writers going forward? For example today we write user-name(1). 449 Going forward, will we write foo-bar(0,1)? 451 What is the numbering plan for these attributes? What (if any) range 452 should be reserved? What should the IANA policy for allocation new 453 Vendor-Ids to the IETF? 455 It seems like RFC 4005 covers most of the question regarding Diameter 456 compatibility, but a few questions remain. For example, should we 457 require that the 'M' bit be set or not? 459 10. References 461 10.1. Normative References 463 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 464 Requirement Levels", BCP 14, RFC 2119, March 1997. 466 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 467 "Remote Authentication Dial In User Service (RADIUS)", 468 RFC 2865, June 2000. 470 10.2. Informative References 472 [IANA] Internet Assigned Number Authority, "RADIUS TYPES", 473 August 2007, 474 . 476 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 478 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 479 Authentication Dial In User Service)", RFC 3575, 480 July 2003. 482 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 483 "Diameter Network Access Server Application", RFC 4005, 484 August 2005. 486 Authors' Addresses 488 Yong Li 489 Bridgewater Systems Corporation 490 303 Terry Fox Drive 491 Suite 100 492 Ottawa, Ontario K2K 3J1 493 Canada 495 Phone: +1 (613) 591-6655 496 Email: yongli@bridgewatersystems.com 497 URI: http://www.bridgewatersystems.com/ 499 Avi Lior 500 Bridgewater Systems Corporation 501 303 Terry Fox Drive 502 Suite 100 503 Ottawa, Ontario K2K 3J1 504 Canada 506 Phone: +1 (613) 591-6655 507 Email: avi@bridgewatersystems.com 508 URI: http://www.bridgewatersystems.com/ 510 Glen Zorn 511 NetCube Technologies 512 77/440 Soi Phoomjit 513 Rama IV Road 514 Phrakanong Klongtoie 515 Bangkok 10110 516 Thailand 518 Phone: +66 (0) 6600 6480 519 Email: gwz@netcube.com 521 Full Copyright Statement 523 Copyright (C) The IETF Trust (2008). 525 This document is subject to the rights, licenses and restrictions 526 contained in BCP 78, and except as set forth therein, the authors 527 retain all their rights. 529 This document and the information contained herein are provided on an 530 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 531 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 532 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 533 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 534 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 535 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 537 Intellectual Property 539 The IETF takes no position regarding the validity or scope of any 540 Intellectual Property Rights or other rights that might be claimed to 541 pertain to the implementation or use of the technology described in 542 this document or the extent to which any license under such rights 543 might or might not be available; nor does it represent that it has 544 made any independent effort to identify any such rights. Information 545 on the procedures with respect to rights in RFC documents can be 546 found in BCP 78 and BCP 79. 548 Copies of IPR disclosures made to the IETF Secretariat and any 549 assurances of licenses to be made available, or the result of an 550 attempt made to obtain a general license or permission for the use of 551 such proprietary rights by implementers or users of this 552 specification can be obtained from the IETF on-line IPR repository at 553 http://www.ietf.org/ipr. 555 The IETF invites any interested party to bring to its attention any 556 copyrights, patents or patent applications, or other proprietary 557 rights that may cover technology that may be required to implement 558 this standard. Please address the information to the IETF at 559 ietf-ipr@ietf.org. 561 Acknowledgment 563 Funding for the RFC Editor function is provided by the IETF 564 Administrative Support Activity (IASA).