idnits 2.17.1 draft-ietf-radext-extended-attributes-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year == Line 383 has weird spacing: '... String b;...' -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 9, 2009) is 5525 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 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 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: September 10, 2009 G. Zorn, Ed. 6 Network Zen 7 March 9, 2009 9 Extended Remote Authentication Dial In User Service (RADIUS) Attributes 10 draft-ietf-radext-extended-attributes-07.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on September 10, 2009. 45 Copyright Notice 47 Copyright (c) 2009 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 in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 For the Remote Authentication Dial In User Service (RADIUS) protocol 59 to continue to support new applications, the RADIUS attribute type 60 space must be extended beyond the current limit of 255 possible 61 attribute types while maintaining backwards compatibility with the 62 existing protocol. This document defines a mechanism to accomplish 63 that task, along with standard methods to group together related 64 attributes and to encode values that don't fit into 253 octets. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 71 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 72 4. RADIUS Type Extension . . . . . . . . . . . . . . . . . . . . 4 73 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 74 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 7. Diameter Considerations . . . . . . . . . . . . . . . . . . . 11 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 80 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 The Remote Authentication Dial In User Service (RADIUS) Protocol 86 [RFC2865] defines two classes of attributes: standard and vendor- 87 specific. 89 Vendor-specific Attributes (VSAs) allow vendors (including Standards 90 Development Organizations (SDOs)) to define their own Attributes, 91 which may not be suitable for general usage; on the other hand, the 92 attributes that belong to the standard RADIUS space are controlled by 93 the IETF and are intended to be of general utility. These attributes 94 are defined in RFCs and are assigned type codes by the Internet 95 Assigned Number Authority (IANA)[IANA]. 97 The standard RADIUS attribute type code is 8 bits in length; hence 98 RADIUS is limited to 255 attribute types. Of these 255 attribute 99 types, approximately 101 have been assigned as of this writing. 100 According to RFC 3575 [RFC3575], types 192-223 are reserved for 101 experimental use; types 224-240 are reserved for implementation- 102 specific use; and values 241-255 are reserved and should not be used. 103 Therefore, as of this writing there are approximately 90 type codes 104 that can be allocated to new attributes. 106 RADIUS evolution must not be hindered by the inability to define new 107 standard RADIUS attributes. This document defines a mechanism to 108 extend the standard RADIUS Attribute space by defining a new scheme 109 to allocate attribute type codes. In addition, mechanisms are 110 defined to support both the grouping of related attributes and the 111 encoding of attribute values the length of which exceed the current 112 limit of 253 octets. 114 2. Terminology 116 Extended Attribute 117 The term used for the new RADIUS attributes that are defined in 118 this document 120 Extended Type 121 The type code assigned to an Extended Attribute 123 2.1. Requirements Language 125 In this document, several words are used to signify the requirements 126 of the specification. These words are often capitalized. The key 127 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 128 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 129 are to be interpreted as described in [RFC2119]. 131 An implementation is not compliant if it fails to satisfy one or more 132 of the must or must not requirements for the protocols it implements. 133 An implementation that satisfies all the MUST, MUST NOT, SHOULD, and 134 SHOULD NOT requirements for its protocols is said to be 135 "unconditionally compliant"; one that satisfies all the MUST and MUST 136 NOT requirements but not all the SHOULD or SHOULD NOT requirements 137 for its protocols is said to be "conditionally compliant". 139 3. Problem Statement 141 A fundamental requirement for extending the RADIUS attribute space is 142 the maintenance of backwards compatibility. This means that RADIUS 143 servers and proxies must be able to continue to decode and encode 144 messages even though they may not need to understand an attribute 145 that has been extended. More specifically, the scheme MUST be 146 compliant with the various RADIUS RFCs such as [RFC2865] and RADIUS 147 Accounting [RFC2866], etc. 149 The scheme SHOULD ensure that the size of the standard type space 150 extension is large enough that it will not be quickly exhausted or is 151 extensible in the event that it is. 153 Furthermore, the scheme SHOULD align with the Diameter NASReq 154 Application [RFC4005], thereby allowing the two AAA standards to 155 interoperate. 157 A need to group related RADIUS attributes together has become 158 prevalent in current work. Therefore, the proposed scheme SHOULD 159 provide a mechanism to group related attributes together. 161 In recent years, attribute sizes have been pushing the current limit 162 of 253 octets. Fragmentation of RADIUS attributes has always been 163 possible by extending the value into another attribute of the same 164 type; however, this approach does not always work (for example, if 165 more than one instance of an attribute occurs in the same RADIUS 166 packet). The proposed scheme SHOULD enable the transmission of 167 attributes longer than 253 octets. 169 4. RADIUS Type Extension 171 The solution described in this document takes the recommended VSA 172 format [RFC2865] as a basis for the RADIUS Extended Attributes. 174 We allocate RADIUS the Vendor-Id of zero (0). In essence we are 175 assigning the IETF a Vendor-Id which is what other SDOs have done in 176 registering their own Vendor-Id. 178 Extended Attributes consist of an attribute header similar to that 179 recommended by RFC 2865 [RFC2865] for Vendor Specific Attributes 180 followed by a non-empty sequence of Type-Length-Value (TLV) triples 181 (see below). If an Extended Attribute contains more than one TLV 182 then all of the encapsulated TLVs MUST fit completely within the 183 Extended Attribute. 185 The Extended Attribute header is 7 octets in length and is encoded as 186 follows: 188 o The first octet contains the Type which is always Vendor-Specific 189 (26) 191 o The second octet contains the length (in octets) of the entire 192 Extended Attribute, including the Extended Attribute header and 193 all encapsulated TLVs 195 o The next 4 octets contain the Vendor-Id (0) 197 o The final octet of the header contains the More flag and Tag 198 field. If the one-bit More flag is set (1) this indicates that 199 the encapsulated TLV is continued in the following Extended 200 Attribute; if the More flag is clear (0) then all of the 201 encapsulated TLVs fit into the current Extended Attribute. The 202 More flag MUST NOT be set if the Extended Attribute contains more 203 than one TLV. The Tag field is used to combine sets of related 204 Extended Attributes into simple, one level groups. 206 o The Data field is an abstract container for TLVs; the Data field 207 MUST contain at least one TLV. 209 TLVs are encoded as follows: 211 o The first two octets contain the Ext-Type field 213 o The next octet is the Ext-Len field, representing the length in 214 octets of the entire TLV, including the length of the Ext-Type 215 field (2 octets), the length of the Ext-Len field itself (1 octet) 216 and the length of the Value field (1 or more octets) 218 o The Value field consists of one or more octets comprising the 219 actual data to be transmitted 221 5. Formal Syntax 223 This section describes the encoding scheme used for RADIUS Extended 224 Attributes. The basis of this encoding is the format recommended for 225 Vendor Specific Attributes in RFC 2865 [RFC2865]. 227 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Type (26) | Length | Vendor-Id (0) | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Vendor-Id (0) |M| Tag | Data... 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Type 237 26 for Vendor-Specific 239 Length 241 > 10 243 Vendor ID 245 The Vendor Id field is 4 octets in length and MUST be zero 246 (0x0000), signifying an extended IETF RADIUS attribute 248 M (More) 250 The More Flag is one (1) bit in length and MUST be present. When 251 a value to be transmitted exceeds 245 octets in length it is 252 fragmented over two or more Extended Attributes. If the More Flag 253 is set (1), this indicates that the Value field of the Extended 254 Attribute contains a fragment of a larger value, which MUST be 255 continued in the next Extended Attribute of the same Ext-Type. 256 When the More Flag is clear (0), the final (or only) fragment of 257 the value is contained in the Extended Attribute. The More Flag 258 MUST NOT be set if the Length is less than 255. Any Extended 259 Attributes containing multiple fragments of the same value MUST be 260 in order and MUST be consecutive attributes in the packet. 262 Tag 264 The Tag field is 7 bits long and MUST be present. It is used to 265 group Extended Attributes. Extended Attributes with the same non- 266 zero value in the Tag field belong to the same group. A Tag value 267 of zero (0) indicates that the attribute is not grouped. A Tag 268 value of all ones (0x7F) is reserved. 270 Data 272 The Data field is >= 4 octets in length. It consists of 1 or more 273 TLVs. 275 TLVs have the following syntax: 277 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Ext-Type | Ext-Len | Value... 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Ext-Type 285 Two (2) octets. Up-to-date values of the Ext-Type field are 286 specified in the most recent "Assigned Numbers" [IANA]. Values 287 64512-65535 (0xFC00-0xFFFF) are reserved. 289 Ext-Len 291 > 3. The length of the Type-Length-Value tuple in octets, 292 including the Ext-Type, Ext-Len and Value fields. 294 Value 296 One or more octets. 298 6. Examples 300 Consider an attribute called Foo of type String. Foo has been 301 allocated an Extended-Type of 257 by IANA. The following figure 302 illustrates the encoding of the string "Hello": 304 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Type (26) | Length | Vendor-Id 308 | | (7 + 8 = 15) | (0) 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Vendor-Id (cont) |M| Tag | Ext-Type 311 |0| (0) | (0X01) 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Ext-Type (cont)| Ext-Len | Value | | 314 (0X01) | (3 + 5 = 8) | (H) | (e) | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | | | | 317 | (l) | (l) | (o) | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Figure 1 322 Now consider another instantiation of the Foo Extended Attribute, 323 this one with a length of 251 octets. In this case the value is 324 fragmented over two Extended Attributes. The first 245 octets are 325 included in the first fragment which has the More bit set and the 326 remaining 6 octets appear in the second attribute. Figure 2 below 327 illustrates the encoding of the first 7 octets of the first Extended 328 Attribute, while Figure 3 shows how the second attribute (containing 329 the string "e end.") is encoded. 331 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Type (26) | Length | Vendor-Id 335 | |(7 + 248 = 255)| (0) 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Vendor-Id (cont) |M| Tag | Ext-Type 338 (0) |1| (0) | (0X01) 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Ext-Type (cont)| Ext-Len | Value | | 341 (0X01) |(3 + 245 = 248)| (H) | (e) | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | | | | | 344 | (l) | (l) | (o) | ( ) | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | | 347 | (W) | ... 348 +-+-+-+-+-+-+-+-+ 350 Figure 2 352 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Type (26) | Length | Vendor-Id 356 | | (7 + 9 = 16) | (0) 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Vendor-Id (cont) |M| Tag | Ext-Type 359 (0) |0| (0) | (0X01) 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 Ext-Type (cont)| Ext-Len | Value | | 362 (0X01) | (3 + 6 = 9) | (e) | ( ) | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | | | | | 365 | (e) | (n) | (d) | (.) | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 Figure 3 370 The next example illustrates several of the features of Extended 371 Attributes: 373 o encapsulation of values greater than 253 octets in length 375 o grouping of related Extended Attributes using tags 377 o encapsulation of more than one TLV in a single Extended Attribute 379 Consider the following structure: 381 struct 382 Integer a; 383 String b; 384 Integer c; 385 endStruct 387 Element 'a' is assigned an Extended Type of 290 (0x0122). Element 388 'b' is assigned an Extended Type of 259 (0x0103) and element 'c' is 389 assigned an Extended Type of 271 (0x010F). The following figure 390 illustrates the encoding where the value of 'a' contains 0xDEADDEAD, 391 the first two octets of 'b' contain the string "He", octets 243-250 392 of 'b' contain "The end." and the value of 'c' is 0x12345678. The 393 attributes are grouped together with TAG=42. Note that this encoding 394 is only one out of several possibilities since there is no strict 395 order in attribute marshalling; for the sake of brevity, octets 3-241 396 of the value of 'b' are omitted from the diagram. 398 1 2 3 399 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 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Type (26) | Length | Vendor-Id 402 | | (7 + 7 = 14) | (0) 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 Vendor-Id (cont) |M| Tag | Ext-Type 405 (0) |0| (42) | (0x01) 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 Ext-Type (cont)| Ext-Len | Value | | 408 (0x22) | (3 + 4 = 7) | (0xDE) | (0xAD) | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | | | 411 | (0xDE) | (0xAD) | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Type (26) | Length | Vendor-Id 418 | |(7 + 248 = 255)| (0) 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Vendor-Id (cont) |M| Tag | Ext-Type 421 (0) |1| (42) | (0x01) 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Ext-Type (cont)| Ext-Len | Value | | 424 (0x03) |(3 + 245 = 248)| (H) | (e) | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 ... 427 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Type (26) | Length | Vendor-Id 431 | | (7+8 = 15) | (0) 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Vendor-Id (cont) |M| Tag | Ext-Type 434 (0) |0| (42) | (0x01) 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 Ext-Type (cont)| Ext-Len | Value | | 437 (0x03) | (3 + 5 = 8) | ( ) | (e) | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | | | | 440 | (n) | (d) | (.) | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Type (26) | Length | Vendor-Id 446 | | (7+7 = 14) | (0) 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 Vendor-Id (cont) |M| Tag | Ext-Type 449 (0) |0| (42) | (0x01) 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 Ext-Type (cont)| Ext-Len | Value | | 452 (0x0F) | (3 + 4 = 7) | (0x12) | (0x34) | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | | | 455 | (0x56) | (0x78) | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Figure 4 460 7. Diameter Considerations 462 Since the Extended Attributes are encoded as Vendor-Specific RADIUS 463 Attributes (see [IANA]), no special handling is required by Diameter 464 [RFC3588] entities; see [RFC4005] for details on the Diameter 465 treatment of RADIUS VSAs. 467 8. Security Considerations 469 This document does not introduce any new security issues into the 470 RADIUS protocol; for known security problems with RADIUS, see 471 [RFC2865], [RFC2869] and [RFC2607]. 473 9. IANA Considerations 475 This standard requires that the Vendor-Id of zero be allocated to the 476 IETF. 478 It also requires that IANA set up a new registry for the RADIUS 479 Extended Types, reserving the values 64512-65535 (0xFC00-0xFFFF) for 480 future purposes. Values in this registry should be allocated using 481 the "IETF Review" policy [RFC5226]. 483 10. References 484 10.1. Normative References 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, March 1997. 489 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 490 "Remote Authentication Dial In User Service (RADIUS)", 491 RFC 2865, June 2000. 493 10.2. Informative References 495 [IANA] Internet Assigned Number Authority, "RADIUS TYPES", 496 August 2008, 497 . 499 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 500 Implementation in Roaming", RFC 2607, June 1999. 502 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 504 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS 505 Extensions", RFC 2869, June 2000. 507 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 508 Authentication Dial In User Service)", RFC 3575, 509 July 2003. 511 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 512 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 514 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 515 "Diameter Network Access Server Application", RFC 4005, 516 August 2005. 518 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 519 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 520 May 2008. 522 Authors' Addresses 524 Yong Li 525 Bridgewater Systems Corporation 526 303 Terry Fox Drive 527 Suite 100 528 Ottawa, Ontario K2K 3J1 529 Canada 531 Phone: +1 (613) 591-6655 532 Email: yongli@bridgewatersystems.com 533 URI: http://www.bridgewatersystems.com/ 535 Avi Lior 536 Bridgewater Systems Corporation 537 303 Terry Fox Drive 538 Suite 100 539 Ottawa, Ontario K2K 3J1 540 Canada 542 Phone: +1 (613) 591-6655 543 Email: avi@bridgewatersystems.com 544 URI: http://www.bridgewatersystems.com/ 546 Glen Zorn (editor) 547 Network Zen 548 1310 East Thomas Street 549 Seattle, Washington 98102 550 US 552 Phone: +1 (206) 377-9035 553 Email: gwz@net-zen.net