idnits 2.17.1 draft-ietf-radext-design-05.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1563. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1574. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1581. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1587. 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 == 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. -- 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 (26 August 2008) is 5720 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (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: '8' on line 1431 == Outdated reference: A later version (-09) exists of draft-ietf-radext-extended-attributes-04 == Outdated reference: A later version (-24) exists of draft-ietf-geopriv-radius-lo-19 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Weber 3 INTERNET-DRAFT Individual Contributor 4 Category: Best Current Practice Alan DeKok (ed.) 5 FreeRADIUS 6 Expires: February 26, 2009 7 26 August 2008 9 RADIUS Design Guidelines 10 draft-ietf-radext-design-05.txt 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 7, 2009. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document provides guidelines for the design of attributes used 42 by the Remote Authentication Dial In User Service (RADIUS) protocol. 43 It is expected that these guidelines will prove useful to authors and 44 reviewers of future RADIUS attribute specifications, both within the 45 IETF as well as other Standards Development Organizations (SDOs). 47 Table of Contents 49 1. Introduction ............................................. 4 50 1.1. Applicability ....................................... 4 51 1.2. Terminology ......................................... 5 52 1.3. Requirements Language ............................... 5 53 2. RADIUS Data Model ........................................ 5 54 2.1. Standard Space ...................................... 6 55 2.1.1. Basic Data Types ............................... 6 56 2.1.2. Tagging Mechanism .............................. 7 57 2.1.3. Complex Attribute Usage ........................ 8 58 2.1.4. Complex Attributes and Security ................ 10 59 2.1.5. Service definitions and RADIUS ................. 11 60 2.2. Extended RADIUS Attributes .......................... 11 61 2.3. Vendor Space ........................................ 12 62 3. Data Model Issues ........................................ 13 63 3.1. Vendor Space ........................................ 14 64 3.1.1. Interoperability Considerations ................ 16 65 3.1.2. Vendor Allocations ............................. 16 66 3.1.3. SDO Allocations ................................ 17 67 3.1.4. Publication of specifications .................. 17 68 3.2. Polymorphic Attributes .............................. 18 69 3.3. RADIUS Operational Model ............................ 18 70 4. IANA Considerations ...................................... 21 71 5. Security Considerations .................................. 21 72 6. References ............................................... 22 73 6.1. Normative References ................................ 22 74 6.2. Informative References .............................. 22 75 Appendix A - Design Guidelines ............................... 25 76 A.1. Types matching the RADIUS data model ................. 25 77 A.1.1. Transport of simple data ........................ 25 78 A.1.2. Extended data types ............................. 25 79 A.1.3. Opaque data types ............................... 26 80 A.2. Improper Data Types .................................. 26 81 A.2.1. Simple Data Types ............................... 26 82 A.2.2. Complex Data Types .............................. 27 83 A.3. Vendor-Specific formats .............................. 27 84 A.4. Changes to the RADIUS Operational Model .............. 28 85 A.5. Allocation of attributes ............................. 29 86 Appendix B - Complex Attributes .............................. 30 87 B.1. CHAP-Password ........................................ 30 88 B.2. CHAP-Challenge ....................................... 30 89 B.3. Tunnel-Password ...................................... 30 90 B.4. ARAP-Password ........................................ 31 91 B.5. ARAP-Features ........................................ 31 92 B.6. Connect-Info ......................................... 32 93 B.7. Framed-IPv6-Prefix ................................... 32 94 B.8. Egress-VLANID ........................................ 33 95 B.9. Egress-VLAN-Name ..................................... 34 96 Full Copyright Statement ..................................... 35 97 1. Introduction 99 This document provides guidelines for the design of RADIUS attributes 100 both within the IETF as well as within other Standards Development 101 Organizations (SDOs). By articulating RADIUS design guidelines, it 102 is hoped that this document will encourage the development and 103 publication of high quality RADIUS attribute specifications. 105 However, the advice in this document will not be helpful unless it is 106 put to use. As with "Guidelines for Authors and Reviewers of MIB 107 Documents [RFC4181], it is expected that this document will be used 108 by authors to check their document against the guidelines prior to 109 requesting review (such as an "Expert Review" described in 110 [RFC3575]). Similarly, it is expected that this document will used 111 by reviewers (such as WG participants or the AAA Doctors [DOCTORS]), 112 resulting in an improvement in the consistency of reviews. 114 In order to meet these objectives, this document needs to cover not 115 only the science of attribute design, but also the art. As a result, 116 in addition to covering the most frequently encountered issues, this 117 document attempts to provide some of the considerations motivating 118 the guidelines. 120 In order to characterize current attribute usage, both the basic and 121 complex data types defined in the existing RADIUS RFCs are reviewed, 122 together with the ad-hoc extensions to that data model that have been 123 used in Vendor-Specific Attributes. 125 1.1. Applicability 127 As RADIUS has become more widely accepted as a management protocol, 128 its usage has become more prevalent, both within the IETF as well as 129 within other SDOs. Given the expanded utilization of RADIUS, it has 130 become apparent that requiring SDOs to accomplish all their RADIUS 131 work within the IETF is inherently inefficient and unscalable. By 132 articulating guidelines for RADIUS attribute design, this document 133 enables SDOs to design their own RADIUS attributes within the Vendor- 134 Specific Attribute (VSA) space, seeking review from the IETF. In 135 order to enable IETF review of SDO RADIUS attribute specifications, 136 the authors recommend that: 138 * SDOs make their RADIUS attribute specifications publicly 139 available; 141 * SDOs request review of RADIUS attribute specifications by 142 sending email to the AAA Doctors [DOCTORS] or equivalent mailing 143 list; 144 * IETF and SDO RADIUS attribute specifications are reviewed 145 according to the guidelines proposed in this document; 147 * Reviews of specifications are posted to the RADEXT WG mailing 148 list, the AAA Doctors mailing list [DOCTORS] or another IETF 149 mailing list suggested by the Operations & Management Area 150 Directors of the IETF. 152 The advice in this document applies to attributes used to encode 153 service-provisioning or authentication data. RADIUS protocol 154 changes, or specification of attributes (such as Service-Type) that 155 can be used to, in effect, provide new RADIUS commands require 156 greater expertise and deeper review, as do changes to the RADIUS 157 operational model, as described in Section 3.3 . Such changes should 158 not be undertaken outside the IETF and when handled within the IETF 159 require "IETF Consensus" for adoption, as noted in [RFC3575] Section 160 2.1. 162 1.2. Terminology 164 This document uses the following terms: 166 Network Access Server (NAS) 167 A device that provides an access service for a user to a network. 169 RADIUS server 170 A RADIUS authentication, authorization, and/or accounting (AAA) 171 server is an entity that provides one or more AAA services to a 172 NAS. 174 RADIUS proxy 175 A RADIUS proxy acts as a RADIUS server to the NAS, and a RADIUS 176 client to the RADIUS server. 178 1.3. Requirements Language 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in [RFC2119]. 184 2. RADIUS Data Model 186 The Remote Authentication Dial In User Service (RADIUS) defined in 187 [RFC2865] and [RFC2866] uses elements known as attributes in order to 188 represent authentication, authorization and accounting data. 190 Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does 191 not define a formal data definition language. A handful of basic 192 data types are provided, and a data type is associated with an 193 attribute when the attribute is defined. 195 Two distinct attribute spaces are defined: the standard space, and a 196 Vendor-Specific space. Attributes in the standard space generally 197 are composed of a type, length, value (TLV) triplet, although complex 198 attributes have also been defined. The Vendor-Specific space is 199 encapsulated within a single attribute type (Vendor-Specific 200 Attribute). The format of this space is defined by individual 201 vendors, but the same TLV encoding used by the standard space is 202 recommended in [RFC2865] Section 5.26. The similarity between 203 attribute formats has enabled implementations to leverage common 204 parsing functionality, although in some cases the attributes in the 205 Vendor-Specific space have begun to diverge from the common format. 207 2.1. Standard Space 209 The following subsections describe common data types and formats 210 within the RADIUS standard attribute space. Common exceptions are 211 identified. 213 2.1.1. Basic Data Types 215 The data type of RADIUS attributes is not transported on the wire. 216 Rather, the data type of a RADIUS attribute is fixed when that 217 attribute is defined. Based on the RADIUS attribute type code, 218 RADIUS clients and servers can determine the data type based on pre- 219 configured entries within a data dictionary. 221 [RFC2865] defines the following data types: 223 text 1-253 octets containing UTF-8 encoded 10646 [RFC3629] 224 characters. Text of length zero (0) MUST NOT be sent; 225 omit the entire attribute instead. 226 string 1-253 octets containing binary data (values 0 through 227 255 decimal, inclusive). Strings of length zero (0) 228 MUST NOT be sent; omit the entire attribute instead. 229 IPv4 address 32 bit value, in network byte order. 230 integer 32 bit unsigned value, most significant octet first. 231 time 32 bit unsigned value, most significant octet first 232 -- seconds since 00:00:00 UTC, January 1, 1970. 234 In addition to these data types, follow-on RADIUS specifications 235 define attributes using the following additional types: 237 IPv6 address 128 bit value, most significant octet first. 238 IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to 239 128 bits of value, in network byte order. 241 integer64 64 bit unsigned value, most significant octet first. 242 This type has also been used to represent an IPv6 243 interface identifier. 245 Examples of the IPv6 address type include NAS-IPv6-Address defined in 246 [RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162] 247 Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3, 248 and in [RFC4818] Section 3. The integer64 type is used for the ARAP- 249 Challenge-Response Attribute defined in [RFC2869] Section 5.15, and 250 the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2. 251 [RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in 252 length, but denotes it as type String. 254 Given that attributes of type IPv6 address, IPv6 prefix, and 255 integer64 are already in use, it is RECOMMENDED that RADIUS server 256 implementations include support for these additional basic types, in 257 addition to the types defined in [RFC2865]. 259 Where the intent is to represent a specific IPv6 address, the IPv6 260 address type SHOULD be used. Although it is possible to use the IPv6 261 IPv6 Prefix type with a prefix length of 128 to represent an IPv6 262 address, this usage is NOT RECOMMENDED. 264 It is worth noting that since RADIUS only supports unsigned integers 265 of 32 or 64 bits, attributes using signed integer data types or 266 unsigned integer types of other sizes will require code changes, and 267 SHOULD be avoided. 269 For [RFC2865] RADIUS VSAs, the length limitation of the String and 270 Text types is 247 octets instead of 253 octets, due to the additional 271 overhead of the Vendor-Specific Attribute. 273 2.1.2. Tagging Mechanism 275 [RFC2868] defines an attribute grouping mechanism based on the use of 276 a one octet tag value. Tunnel attributes that refer to the same 277 tunnel are grouped together by virtue of using the same tag value. 279 This tagging mechanism has some drawbacks. There are a limited 280 number of unique tags (31). The tags are not well suited for use 281 with arbitrary binary data values, because it is not always possible 282 to tell if the first byte after the Length is the tag or the first 283 byte of the untagged value (assuming the tag is optional). 285 Other limitations of the tagging mechaism are that when integer 286 values are tagged, the value portion is reduced to three bytes 287 meaning only 24-bit numbers can be represented. The tagging 288 mechanism does not offer an ability to create nested groups of 289 attributes. Some RADIUS implementations treat tagged attributes as 290 having additional data types tagged-string and tagged-integer. These 291 types increase the complexity of implementing and managing RADIUS 292 systems. 294 New attributes SHOULD NOT use this tagging method because of the 295 limitations described above. New attributes SHOULD use the grouping 296 method described in [EXTEN]. 298 2.1.3. Complex Attribute Usage 300 The RADIUS attribute encoding is summarized in [RFC2865]: 302 0 1 2 303 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 305 | Type | Length | Value ... 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 308 However, some standard attributes do not follow this format. 309 Attributes that use sub-fields instead of using a basic data type are 310 known as "complex attributes". As described below, the definition of 311 complex attributes can lead to interoperability and deployment 312 issues, so they need to be introduced with care. 314 In general, complex attributes sent from the RADIUS server to the 315 client can be supported by concatenating the values into a String 316 data type field. However, separating these values into different 317 attributes, each with its own type and length, would have the 318 following benefits: 320 * it is easier for the user to enter the data as well-known 321 types, rather than complex structures; 322 * it enables additional error checking by leveraging the 323 parsing and validation routines for well-known types; 324 * it simplifies implementations by eliminating special-case 325 attribute-specific parsing. 327 One of the fundamental goals of the RADIUS protocol design was to 328 allow RADIUS servers to be configured to support new attributes 329 without requiring server code changes. RADIUS server implementations 330 typically use provide support for basic data types, and define 331 attributes in a data dictionary. This architecture enables a new 332 attribute to be supported by the addition of a dictionary entry, 333 without requiring RADIUS server code changes. 335 On the RADIUS client, code changes are typically required in order to 336 implement a new attribute. The RADIUS client typically has to 337 compose the attribute dynamically when sending. When receiving, a 338 RADIUS client needs to be able to parse the attribute and carry out 339 the requested service. As a result, a detailed understanding of the 340 new attribute is required on clients, and data dictionaries are less 341 useful on clients than on servers. 343 Given these considerations, the introduction of a new basic or 344 complex attribute will typically require code changes on the RADIUS 345 client. The magnitude of changes for the complex attribute could be 346 greater, due to the potential need for custom parsing logic. 348 The RADIUS server can be configured to send a new static attribute by 349 entering its type and data format in the RADIUS server dictionary, 350 and then filling in the value within a policy based on the attribute 351 name, data type and type-specific value. For complex attribute types 352 not supported by RADIUS server dictionaries, changes to the 353 dictionary code can be required in order to allow the new attribute 354 to be supported by and configured on the RADIUS server. 356 Code changes can also be required in policy management and in the 357 RADIUS server's receive path. These changes are due to limitations 358 in RADIUS server policy languages, which typically only provide for 359 limited operations (such as comparisons or arithmetic operations) on 360 the basic data types. Many existing RADIUS policy languages 361 typically are not capable of parsing sub-elements, or providing 362 sophisticated matching functionality. 364 Given these limitations, the introduction of complex attributes can 365 require code changes on the RADIUS server which would be unnecessary 366 if basic data types had been used instead. In addition, attribute- 367 specific parsing means more complex software to develop and maintain. 368 More complexity can lead to more error prone implementations, 369 interoperatibility problems, and even security vulnerabilities. 370 These issues can increase costs to network administrators as well as 371 reducing reliability and introducing deployment barriers. As a 372 result, the introduction of new complex data types within RADIUS 373 attribute specifications SHOULD be avoided, except in the case of 374 complex attributes involving authentication or security 375 functionality. 377 As can be seen in Appendix B, most of the existing complex attributes 378 involve authentication or security functionality. Supporting this 379 functionality requires code changes on both the RADIUS client and 380 server, regardless of the attribute format. As a result, in most 381 cases, the use of complex attributes to represent these methods is 382 acceptable, and does not create additional interoperability or 383 deployment issues. 385 The only other exception to the recommendation against complex types 386 is for types that can be treated as opaque data by the RADIUS server. 387 For example, the EAP-Message attribute, defined in [RFC3579] Section 388 3.1 contains a complex data type that is an EAP packet. Since these 389 complex types do not need to be parsed by the RADIUS server, the 390 issues arising from policy language limitations do not arise. 391 Similarly, since attributes of these complex types can be configured 392 on the server using a data type of String, dictionary limitations are 393 also not encountered. Section A.1 below includes a series of 394 checklists that may be used to analyze a design for RECOMMENDED and 395 NOT RECOMMENDED behavior in relation to complex types. 397 If the RADIUS Server simply passes the contents of an attribute to 398 some non-RADIUS portion of the network, then the data is opaque, and 399 SHOULD be defined to be of type String. A concrete way of judging 400 this requirement is whether or not the attribute definition in the 401 RADIUS document contains delineated fields for sub-parts of the data. 402 If those fields need to be delineated in RADIUS, then the data is not 403 opaque, and it SHOULD be separated into individual RADIUS attributes. 405 An examination of existing RADIUS RFCs discloses a number of complex 406 attributes that have already been defined. Appendix B includes a 407 listing of complex attributes used within [RFC2865], [RFC2868], 408 [RFC2869], [RFC3162], [RFC4818], and [RFC4675]. The discussion of 409 these attributes includes reasons why a complex type is acceptable, 410 or suggestions for how the attribute could have been defined to 411 follow the RADIUS data model. 413 In other cases, the data in the complex type are described textually. 414 This is possible because the data types are not sent within the 415 attributes, but are a matter for endpoint interpretation. An 416 implementation can define additional data types, and use these data 417 types today by matching them to the attribute's textual description. 419 2.1.4. Complex Attributes and Security 421 The introduction of complex data types brings the potential for the 422 introduction of new security vulnerabilities. Experience shows that 423 the common data types have few security vulnerabilities, or else that 424 all known issues have been found and fixed. New data types require 425 new code, which may introduce new bugs, and therefore new attack 426 vectors. 428 RADIUS servers are highly valued targets, as they control network 429 access and interact with databases that store usernames and 430 passwords. An extreme outcome of a vulnerability due to a new, 431 complex type would be that an attacker is capable of taking complete 432 control over the RADIUS server. 434 The use of attributes representing opaque data does not reduce this 435 threat. The threat merely moves from the RADIUS server to the 436 application that consumes that opaque data. 438 The threat is particularly severe when the opaque data originates 439 from the user, and is not validated by the NAS. In those cases, the 440 RADIUS server is potentially exposed to attack by malware residing on 441 an unauthenticated host. Applications consuming opaque data that 442 reside on the RADIUS server SHOULD be properly isolated from the 443 RADIUS server, and SHOULD run with minimal privileges. Any potential 444 vulnerabilities in that application will then have minimal impact on 445 the security of the system as a whole. 447 2.1.5. Service definitions and RADIUS 449 RADIUS specifications define how an existing service or protocol can 450 be provisioned using RADIUS. Therefore, it is expected that a RADIUS 451 attribute specification will reference documents defining the 452 protocol or service to be provisioned. Within the IETF, a RADIUS 453 attribute specification SHOULD NOT be used to define the protocol or 454 service being provisioned. New services using RADIUS for 455 provisioning SHOULD be defined elsewhere and referenced in the RADIUS 456 specification. 458 New attributes, or new values of existing attributes, SHOULD NOT be 459 used to define new RADIUS commands. RADIUS attributes are intended 460 to: 462 * authenticate users 463 * authorize users (i.e., service provisioning or changes to 464 provisioning) 465 * account for user activity (i.e., logging of session activity) 467 New commands (i.e., the Code field in the packet header) are 468 allocated only through "IETF Consensus" as noted in [RFC3575] Section 469 2.1. Specifications also SHOULD NOT use new attributes to modify the 470 interpretation of existing RADIUS commands. 472 2.2. Extended RADIUS Attributes 474 The extended RADIUS attribute document [EXTEN] defines a number of 475 extensions to RADIUS. The standard attribute space is extended by 476 permitting standard allocations from within a specific subset of the 477 VSA space; the format of extended attributes is defined; and extended 478 data types are defined within that format. 480 New specifications seeking to extend the standard RADIUS data model 481 SHOULD examine [EXTEN] to see if their needs fit within the extended 482 RADIUS data model. 484 2.3. Vendor Space 486 As noted in [RFC2865] Section 5.26, the VSA format is defined as 487 follows: 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Type | Length | Vendor-Id 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 Vendor-Id (cont) | String... 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 497 The high-order octet of the Vendor-Id field is 0 and the low-order 3 498 octets are the Structure of Management Information (SMI) Network 499 Management Private Enterprise Code (PEC) of the Vendor in network 500 byte order. 502 While the format of the String field is defined by the vendor, 503 [RFC2865] Section 5.26 notes: 505 It SHOULD be encoded as a sequence of vendor type / vendor length 506 / value fields, as follows. The Attribute-Specific field is 507 dependent on the vendor's definition of that attribute. An 508 example encoding of the Vendor-Specific attribute using this 509 method follows: 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Type | Length | Vendor-Id 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Vendor-Id (cont) | Vendor type | Vendor length | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Attribute-Specific... 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 521 Multiple sub-attributes MAY be encoded within a single Vendor- 522 Specific attribute, although they do not have to be. 524 Note that the Vendor type field in the recommended VSA format is only 525 a single octet, like the RADIUS type field. While this limitation 526 results in an efficient encoding, there are situations in which a 527 vendor or SDO will eventually wish to define more than 255 528 attributes. Also, an SDO can be comprised of multiple subgroups, 529 each of whom can desire autonomy over the definition of attributes 530 within their group. In such a situation, a 16-bit Vendor type field 531 would be more appropriate: 533 0 1 2 3 534 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 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Type | Length | Vendor-Id 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 Vendor-Id (cont) | Vendor type | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Vendor length | Attribute-Specific... 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 If additional functionality is required, the format defined in 544 [EXTEN] SHOULD be used. 546 Other attribute formats are NOT RECOMMENDED. Examples of NOT 547 RECOMMENDED formats include Vendor types of more than 16 bits, Vendor 548 lengths of less than 8 bits, Vendor lengths of more than 8 bits, and 549 Vendor-Specific contents that are not in Type-Length-Value format. 551 In order to be compatible with the above recommendations for 552 attribute definitions, it is RECOMMENDED that RADIUS servers support 553 attributes using a 16-bit Vendor type field. 555 3. Data Model Issues 557 Since the closure of the RADIUS Working Group, the popularity and 558 prevalence of RADIUS has continued to grow. In addition to 559 increasing demand for allocation of attributes within the RADIUS 560 standard attribute space, the number of vendors and SDOs creating new 561 attributes within the Vendor-Specific attribute space has grown, and 562 this has lead to some divergence in approaches to RADIUS attribute 563 design. 565 In general, standard RADIUS attributes have a more constrained data 566 model than attributes within the vendor space. For example, vendors 567 and SDOs have evolved the data model to support new functions such as 568 attribute grouping and attribute fragmentation, with different groups 569 taking different approaches. 571 Given these enhancements, it has become difficult for vendors or SDOs 572 to translate attributes from the vendor space to the more stringent 573 standards space. For example, a Vendor-Specific attribute using sub- 574 elements could require allocation of several standard space 575 attributes using basic data types. In this case not only would 576 translation require substantial additional work, it would further 577 deplete the RADIUS standard attribute space. Given these 578 limitations, translation of vendor attributes to the standards space 579 is not necessarily desirable, particularly if the VSA specification 580 is publicly available and can be implemented within existing RADIUS 581 clients and servers. In such situations, the costs may substantially 582 outweigh the benefits. It is possible that some of the enhancements 583 made within the vendor space may eventually become available within 584 the standard attribute space. However, the divergence of the 585 standard and vendor attribute spaces is most likely a permanent 586 feature, and should be recognized as such. 588 Recent extensions to the RADIUS data model such as [EXTEN] make it 589 possible to minimize the use of complex attributes. New 590 specifications seeking to extend the standard RADIUS data model 591 SHOULD examine [EXTEN] to see if their needs fit within the extended 592 RADIUS data model. 594 3.1. Vendor Space 596 The usage model for RADIUS VSAs is described in [RFC2865] Section 597 6.2: 599 Note that RADIUS defines a mechanism for Vendor-Specific 600 extensions (Attribute 26) and the use of that should be encouraged 601 instead of allocation of global attribute types, for functions 602 specific only to one vendor's implementation of RADIUS, where no 603 interoperability is deemed useful. 605 Nevertheless, many new attributes have been defined in the vendor 606 specific space in situations where interoperability is not only 607 useful, but is required. For example, Standards Development 608 Organizations (SDOs) outside the IETF (such as the IEEE 802 and the 609 3rd Generation Partnership Project (3GPP)) have been assigned Vendor- 610 Ids, enabling them to define their own VSA format and assign Vendor 611 types within their own space. 613 The use of VSAs by SDOs outside the IETF has gained in popularity for 614 several reasons: 616 Efficiency 617 As with SNMP, which defines an "Enterprise" Object Identifier (OID) 618 space suitable for use by vendors as well as other SDOs, the 619 definition of Vendor-Specific RADIUS attributes has become a common 620 occurrence as part of standards activity outside the IETF. For 621 reasons of efficiency, it is easiest if the RADIUS attributes 622 required to manage a standard are developed within the same SDO 623 that develops the standard itself. As noted in "Transferring MIB 624 Work from IETF Bridge MIB WG to IEEE 802.1 WG" [RFC4663], today few 625 vendors are willing to simultaneously fund individuals to 626 participate within an SDO to complete a standard, as well as to 627 participate in IETF in order to complete the associated RADIUS 628 attributes specification. 630 Attribute scarcity 631 The standard RADIUS attribute space is limited to 255 unique 632 attributes. Of these, only about half remain available for 633 allocation. In the Vendor-Specific space, the number of attributes 634 available is a function of the format of the attribute (the size of 635 the Vendor type field). 637 Along with these advantages, some limitations of VSA usage are noted 638 in [RFC2865] Section 5.26: 640 This Attribute is available to allow vendors to support their own 641 extended Attributes not suitable for general usage. It MUST NOT 642 affect the operation of the RADIUS protocol. 644 Servers not equipped to interpret the vendor-specific information 645 sent by a client MUST ignore it (although it may be reported). 646 Clients which do not receive desired vendor-specific information 647 SHOULD make an attempt to operate without it, although they may do 648 so (and report they are doing so) in a degraded mode. 650 The limitation on changes to the RADIUS protocol effectively 651 prohibits VSAs from changing fundamental aspects of RADIUS operation, 652 such as modifying RADIUS packet sequences, or adding new commands. 653 However, the requirement for clients and servers to be able to 654 operate in the absence of VSAs has proven to be less of a constraint, 655 since it is still possible for a RADIUS client and server to mutually 656 indicate support for VSAs, after which behavior expectations can be 657 reset. 659 Therefore, RFC 2865 provides considerable latitude for development of 660 new attributes within the vendor space, while prohibiting development 661 of protocol variants. This flexibility implies that RADIUS 662 attributes can often be developed within the vendor space without 663 loss (and possibly even gain) in functionality. 665 As a result, translation of RADIUS attributes developed within the 666 vendor space into the standard space may provide only modest 667 benefits, while accelerating the exhaustion of the standard attribute 668 space. We do not expect that all RADIUS attribute specifications 669 requiring interoperability will be developed within the IETF, and 670 allocated from the standards space. A more scalable approach is to 671 recognize the flexibility of the vendor space, while working toward 672 improvements in the quality and availability of RADIUS attribute 673 specifications, regardless of where they are developed. 675 3.1.1. Interoperability Considerations 677 Vendors and SDOs are reminded that the standard RADIUS attribute 678 space, and the enumerated value space for enumerated attributes, are 679 reserved for allocation through work published via the IETF, as noted 680 in [RFC3575] Section 2.1. Some vendors and SDOs have in the past 681 performed self-allocation by assigning vendor-specific meaning to 682 "unused" values from the standard RADIUS attribute ID or enumerated 683 value space. This self-allocation results in interoperability 684 issues, and is counter-productive. Similarly, the Vendor-Specific 685 enumeration practice discussed in [RFC2882] Section 2.2.1 is NOT 686 RECOMMENDED. 688 If it is not possible to follow the above procedure, vendors and SDOs 689 SHOULD self-allocate an attribute from their Vendor-Specific space, 690 and define an appropriate value for it. 692 As a side note, [RFC2865] Section 5.26 uses the term "Vendor-Specific 693 Attribute" to refer to an encoding format which can be used by 694 individual vendors to define attributes not suitable for general 695 usage. However, since then VSAs have also become widely used by SDOs 696 defining attributes intended for multi-vendor interoperability. As 697 such, these attributes are not specific to any single vendor, and the 698 term "Vendor-Specific" may be misleading. An alternate term which 699 better describes this use case is SDO-Specific Attribute (SSA). 701 The design and specification of VSAs for multi-vendor usage SHOULD be 702 undertaken with the same level of care as standard RADIUS attributes. 703 Specifically, the provisions of this document that apply to standard 704 RADIUS attributes also apply to SSAs or VSAs for multi-vendor usage. 706 3.1.2. Vendor Allocations 708 Vendor RADIUS Attribute specifications SHOULD allocate attributes 709 from the vendor space, rather than requesting an allocation from the 710 RADIUS standard attribute space. 712 As discussed in [RFC2865] Section 5.26, the vendor space is intended 713 for vendors to support their own extended attributes not suitable for 714 general use. However, it is RECOMMENDED that vendors follow the 715 guidelines outlined here, which are intended to enable maximum 716 interoperability with minimal changes to existing systems. 718 Following these guidelines means that RADIUS servers can be updated 719 to support the vendor's equipment by editing a RADIUS dictionary. If 720 these guidelines are not followed, then the vendor's equipment can 721 only be supported via code changes in RADIUS server implementations. 722 Such code changes add complexity and delay to implementations. 724 3.1.3. SDO Allocations 726 SDO RADIUS Attribute specifications SHOULD allocate attributes from 727 the vendor space, rather than requesting an allocation from the 728 RADIUS standard attribute space, for attributes matching any of the 729 following criteria: 731 * attributes relying on data types not defined within RADIUS 732 * attributes intended primarily for use within an SDO 733 * attributes intended primarily for use within a group of SDOs. 735 Any new RADIUS attributes or values intended for interoperable use 736 across a broad spectrum of the Internet Community SHOULD follow the 737 normal IETF process, and SHOULD result in allocations from the RADIUS 738 standard space. 740 The recommendation for SDOs to allocate attributes from a vendor 741 space rather than via the IETF process is a recognition that SDOs may 742 desire to assert change control over their own RADIUS specifications. 743 This change control can be obtained by requesting a PEC from the 744 Internet Assigned Number Authority (IANA), for use as a Vendor-Id 745 within a Vendor-Specific attribute. Further allocation of attributes 746 inside of the VSA space defined by that Vendor-Id is subject solely 747 to the discretion of the SDO. Similarly, the use of data types 748 (complex or not) within that VSA space is solely under the discretion 749 of the SDO. It is RECOMMENDED that SDOs follow the guidelines 750 outlined here, which are intended to enable maximum interoperability 751 with minimal changes to existing systems. 753 It should be understood that SDOs do not have to rehost VSAs into the 754 standards space solely for the purpose of obtaining IETF review. 755 Rehosting puts pressure on the standards space, and may be harmful to 756 interoperability, since it can create two ways to provision the same 757 service. Rehosting may also require changes to the RADIUS data model 758 which will affect implementations that do not intend to support the 759 SDO specifications. 761 3.1.4. Publication of specifications 763 SDOs are encouraged to seek early review of SSA specifications by the 764 IETF. This review may be initiated by sending mail to the AAA 765 Doctors list [DOCTORS]. Since the IETF is not a membership 766 organization, in order to enable the RADIUS SSA specification to be 767 reviewed, it is RECOMMENDED that it be made publicly available; this 768 also encourages interoperability. Where the RADIUS SSA specification 769 is embedded within a larger document which cannot be made public, the 770 RADIUS attribute and value definitions SHOULD be published instead as 771 an Informational RFC, as with [RFC4679]. This process SHOULD be 772 followed instead of requesting IANA allocations from within the 773 standard RADIUS attribute space. 775 Similarly, vendors are encouraged to make their specifications 776 publicly available, for maximum interoperability. However, it is not 777 necessary for them to request publication of their VSA specifications 778 as Informational RFCs by the IETF. 780 All other specifications, including new authentication and/or 781 security mechanisms SHOULD be allocated via the standard RADIUS 782 space, as noted in [RFC3575] Section 2.1. 784 3.2. Polymorphic Attributes 786 A polymorphic attribute is one whose format or meaning is dynamic. 787 For example, rather than using a fixed data format, an attribute's 788 format might change based on the contents of another attribute. Or, 789 the meaning of an attribute may depend on earlier packets in a 790 sequence. 792 RADIUS server dictionary entries are typically static, enabling the 793 user to enter the contents of an attribute without support for 794 changing the format based on dynamic conditions. However, this 795 limitation on static types does not prevent implementations from 796 implementing policies that return different attributes based on the 797 contents of received attributes; this is a common feature of existing 798 RADIUS implementations. 800 In general, polymorphism is NOT RECOMMENDED. Polymorphism rarely 801 enables capabilities that would not be available through use of 802 multiple attributes. Polymorphism requires code changes in the 803 RADIUS server in situations where attributes with fixed formats would 804 not require such changes. Thus, polymorphism increases complexity 805 while decreasing generality, without delivering any corresponding 806 benefits. 808 Note that changing an attribute's format dynamically is not the same 809 thing as using a fixed format and computing the attribute itself 810 dynamically. RADIUS authentication attributes such as User-Password, 811 EAP-Message, etc. while being computed dynamically, use a fixed 812 format. 814 3.3. RADIUS Operational Model 816 The RADIUS operational model includes several assumptions: 818 * The RADIUS protocol is stateless; 819 * Provisioning of services is not possible within an 820 Access-Reject; 821 * Distinction between authorization checks and user 822 authentication; 823 * Authentication and integrity protection of RADIUS packets; 824 * The RADIUS protocol is a Request/Response protocol. 825 * Packet length restriction. 827 While RADIUS server implementations may keep state, the RADIUS 828 protocol is stateless, although information may be passed from one 829 protocol transaction to another via the State Attribute. As a 830 result, documents which require stateful protocol behavior without 831 use of the State Attribute are inherently incompatible with RADIUS as 832 defined in [RFC2865], and need to be redesigned. See [RFC5080] 833 Section 2.1.1 for a more in-depth discussion of the use of the State 834 Attribute. 836 As noted in [RFC5080] Section 2.6, the intent of an Access-Reject is 837 to deny access to the requested service. As a result, RADIUS does 838 not allow the provisioning of services within an Access-Reject. 839 Documents which include provisioning of services within an Access- 840 Reject are inherently incompatible with RADIUS, and need to be 841 redesigned. 843 As noted in [RFC5080] Section 2.1.1, a RADIUS Access-Request may not 844 contain user authentication attributes or a State Attribute linking 845 the Access-Request to an earlier user authentication. Such an 846 Access-Request, known as an authorization check, provides no 847 assurance that it corresponds to a live user. RADIUS specifications 848 defining attributes containing confidential information (such as 849 Tunnel-Password) should be careful to prohibit such attributes from 850 being returned in response to an authorization check. Also, 851 [RFC5080] Section 2.1.1 notes that authentication mechanisms need to 852 tie a sequence of Access-Request/Access-Challenge packets together 853 into one authentication session. The State Attribute is RECOMMENDED 854 for this purpose. 856 While [RFC2865] did not require authentication and integrity 857 protection of RADIUS Access-Request packets, subsequent 858 authentication mechanism specifications such as RADIUS/EAP [RFC3579] 859 and Digest Authentication [RFC5090] have mandated authentication and 860 integrity protection for certain RADIUS packets. [RFC5080] Section 861 2.1.1 makes this behavior RECOMMENDED for all Access-Request packets, 862 including Access-Request packets performing authorization checks. It 863 is expected that specifications for new RADIUS authentication 864 mechanisms will continue this practice. 866 The RADIUS protocol as defined in [RFC2865] is a request-response 867 protocol spoken between RADIUS clients and servers. A single RADIUS 868 Access-Request packet will solicit in response at most a single 869 Access-Accept, Access-Reject or Access-Challenge packet, sent to the 870 IP address and port of the RADIUS Client that originated the Access- 871 Request. Similarly, a single Change-of-Authorization (CoA)-Request 872 packet [RFC5176] will solicit in response at most a single CoA-ACK or 873 CoA-NAK packet, sent to the IP address and port of the Dynamic 874 Authorization Client (DAC) that originated the CoA-Request. A single 875 Disconnect-Request packet will solicit in response at most a single 876 Disconnect-ACK or Disconnect-NAK packet, sent to the IP address and 877 port of the Dynamic Authorization Client (DAC) that originated the 878 CoA-Request. Changes to this model are likely to require major 879 revisions to existing implementations and so this practice is NOT 880 RECOMMENDED. 882 The Length field in the RADIUS packet header is defined in [RFC2865] 883 Section 3. It is noted there that the maximum length of a RADIUS 884 packet is 4096 octets. As a result, attribute designers SHOULD NOT 885 assume that a RADIUS implementation can successfully process RADIUS 886 packets larger than 4096 octets. If a situation is envisaged where 887 it may be necessary to carry authentication, authorization or 888 accounting data in a packet larger than 4096 octets, then one of the 889 following approaches is RECOMMENDED: 891 1. Utilization of a sequence of packets. 892 For RADIUS authentication, a sequence of Access-Request/ Access- 893 Challenge packets would be used. For this to be feasible, 894 attribute designers need to enable inclusion of attributes that 895 can consume considerable space within Access-Challenge packets. 896 To maintain compatibility with existing NASes, either the use of 897 Access-Challenge packets needs to be permissible (as with 898 RADIUS/EAP, defined in [RFC3579]), or support for receipt of an 899 Access-Challenge needs to be indicated by the NAS (as in RADIUS 900 Location [RADIUSLOC]). Also, the specification needs to clearly 901 describe how attribute splitting is to be signalled and how 902 attributes included within the sequence are to be interpreted, 903 without requiring stateful operation. Unfortunately, previous 904 specifications have not always exhibited the required foresight. 905 For example, even though very large filter rules are 906 conceivable, the NAS-Filter-Rule Attribute defined in [RFC4849] 907 is not permitted in an Access-Challenge packet, nor is a 908 mechanism specified to allow a set of NAS-Filter-Rule attributes 909 to be split across an Access-Request/Access-Challenge sequence. 911 In the case of RADIUS accounting, transporting large amounts of 912 data would require a sequence of Accounting-Request packets. 913 This is a non-trivial change to RADIUS, since RADIUS accounting 914 clients would need to be modified to split the attribute stream 915 across multiple Accounting-Requests, and billing servers would 916 need to be modified to re-assemble and interpret the attribute 917 stream. 919 2. Utilization of names rather than values. 920 Where an attribute relates to a policy that could conceivably be 921 pre-provisioned on the NAS, then the name of the pre-provisioned 922 policy can be transmitted in an attribute, rather than the 923 policy itself, which could be quite large. An example of this 924 is the Filter-Id Attribute defined in [RFC2865] Section 5.11, 925 which enables a set of pre-provisioned filter rules to be 926 referenced by name. 928 3. Utilization of Packetization Layer Path MTU Discovery 929 techniques, as specified in [RFC4821]. As a last resort, where 930 the above techniques cannot be made to work, it may be possible 931 to apply the techniques described in [RFC4821] to discovery of 932 of the maximum supported RADIUS packet size on the path between 933 a RADIUS client and a home server. While such an approach can 934 avoid the complexity of utilization of a sequence of packets, 935 dynamic discovery is likely to be time consuming and cannot be 936 guaranteed to work with existing RADIUS implementations. As a 937 result, this technique is not generally applicable. 939 4. IANA Considerations 941 This document requires no action by IANA. 943 5. Security Considerations 945 This specification provides guidelines for the design of RADIUS 946 attributes used in authentication, authorization and accounting. 947 Threats and security issues for this application are described in 948 [RFC3579] and [RFC3580]; security issues encountered in roaming are 949 described in [RFC2607]. 951 Encryption of RADIUS attributes on a per-attribute basis is necessary 952 in some cases. The current standard mechanism for this is described 953 in [RFC2865] Section 5.2 (for obscuring User-Password values) and is 954 based on the MD5 algorithm specified in [RFC1321]. The MD5 and SHA-1 955 algorithms have recently become a focus of scrutiny and concern in 956 security circles, and as a result, the use of these algorithms in new 957 attributes is NOT RECOMMENDED. 959 Where new RADIUS attributes use cryptographic algorithms, algorithm 960 negotiation SHOULD be supported. Specification of a mandatory-to- 961 implement algorithm is REQUIRED, and it is RECOMMENDED that the 962 mandatory-to-implement algorithm be certifiable under FIPS 140 963 [FIPS]. 965 Where new RADIUS attributes encapsulate complex data types, or 966 transport opaque data, the security considerations discussed in 967 Section 2.1.4 SHOULD be addressed. 969 6. References 971 6.1. Normative References 973 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 974 Requirement Levels", BCP 14, RFC 2119, March 1997. 976 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 977 Authentication Dial In User Service (RADIUS)", RFC 2865, June 978 2000. 980 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 981 Authentication Dial In User Service)", RFC 3575, July 2003. 983 6.2. Informative References 985 [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of 986 management information for TCP/IP-based internets", STD 16, 987 RFC 1155, May 1990. 989 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 990 Network Management Protocol (SNMP)", STD 15, RFC 1157, May 991 1990. 993 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 994 April 1992. 996 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 997 Implementation in Roaming", RFC 2607, June 1999. 999 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1001 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., 1002 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 1003 Support", RFC 2868, June 2000. 1005 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", 1006 RFC 2869, June 2000. 1008 [RFC2882] Mitton, D, "Network Access Servers Requirements: Extended 1009 RADIUS Practices", RFC 2882, July 2000. 1011 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 1012 3162, August 2001. 1014 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 1015 In User Service) Support For Extensible Authentication 1016 Protocol (EAP)", RFC 3579, September 2003. 1018 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE 1019 802.1X Remote Authentication Dial In User Service (RADIUS) 1020 Usage Guidelines", RFC3580, September 2003. 1022 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1023 RFC 3629, November 2003. 1025 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 1026 Documents", RFC 4181, September 2005. 1028 [RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge MIB WG 1029 to IEEE 802.1 WG", RFC 4663, September 2006. 1031 [RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for 1032 Virtual LAN and Priority Support", RFC 4675, September 2006. 1034 [RFC4679] Mammoliti, V., et al., "DSL Forum Vendor-Specific RADIUS 1035 Attributes", RFC 4679, September 2006. 1037 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 1038 Attribute", RFC 4818, April 2007. 1040 [RFC4821] Mathis, M. and Heffner, J, "Packetization Layer Path MTU 1041 Discovery", RFC 4821, March 2007. 1043 [RFC4849] Congdon, P. et al, "RADIUS Filter-Rule Attribute", RFC 4849, 1044 April 2007. 1046 [RFC5080] Nelson, D. and DeKok, A, "Common Remote Authentication Dial In 1047 User Service (RADIUS) Implementation Issues and Suggested 1048 Fixes", RFC 5080, December 2007. 1050 [RFC5090] Sterman, B. et al., "RADIUS Extension for Digest 1051 Authentication", RFC 5090, February 2008. 1053 [RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote 1054 Authentication Dial In User Service (RADIUS)", RFC 5176, 1055 January 2008. 1057 [DOCTORS] AAA Doctors Mailing list 1059 [EXTEN] Li, Y., et al., "Extended Remote Authentication Dial In User 1060 Service (RADIUS) Attributes", draft-ietf-radext-extended- 1061 attributes-04.txt, (work in progress). 1063 [FIPS] FIPS 140-3 (DRAFT), "Security Requirements for Cryptographic 1064 Modules", http://csrc.nist.gov/publications/fips/fips140-3/ 1066 [IEEE-802.1Q] 1067 IEEE Standards for Local and Metropolitan Area Networks: Draft 1068 Standard for Virtual Bridged Local Area Networks, 1069 P802.1Q-2003, January 2003. 1071 [RADIUSLOC] 1072 Tschofenig, H. (Ed.), "Carrying Location Objects in RADIUS and 1073 Diameter", draft-ietf-geopriv-radius-lo-19.txt, (work in 1074 progress) 1076 Appendix A - Design Guidelines 1078 The following text provides guidelines for the design of attributes 1079 used by the RADIUS protocol. Specifications that follow these 1080 guidelines are expected to achieve maximum interoperability with 1081 minimal changes to existing systems. 1083 A.1. Types matching the RADIUS data model 1085 A.1.1. Transport of simple data 1087 Does the data fit within the existing RADIUS data model, as outlined 1088 below? If so, it SHOULD be encapsulated in a [RFC2865] format RADIUS 1089 attribute, or in a [RFC2865] format RADIUS VSA. 1091 * 32-bit unsigned integer, most significant octet first. 1092 * Enumerated data types, represented as a 32-bit unsigned integer 1093 with a list of name to value mappings. (e.g., Service-Type) 1094 * 64-bit unsigned integer, most significant octet first. 1095 * IPv4 address in network byte order. 1096 * IPv6 address in network byte order. 1097 * IPv6 prefix. 1098 * time as 32 bit unsigned value, most significant octet first, in 1099 seconds since 00:00:00 UTC, January 1, 1970. 1100 * string (i.e., binary data), totalling 253 octets or less in 1101 length. This includes the opaque encapsulation of data 1102 structures defined outside of RADIUS. See also Section A.1.3, 1103 below. 1104 * UTF-8 text, totalling 253 octets or less in length. 1105 * Complex data types for authentication and/or security. 1106 These attributes SHOULD be defined only within the RADIUS 1107 attribute space, and SHOULD NOT be defined within the VSA space. 1109 Note that the length limitations for VSAs of type String and Text are 1110 less than 253 octets, due to the additional overhead of the Vendor- 1111 Specific format. 1113 A.1.2. Extended data types 1115 Where possible, the data types defined above in Section A.1.1 SHOULD 1116 be used. The extended data types defined in [EXTEN] SHOULD be used 1117 only where there is no clear method of expressing the data using 1118 existing types. 1120 Does the data fit within the extended RADIUS data model, as outlined 1121 below? If so, it SHOULD be encapsulated in a [EXTEN] format RADIUS 1122 VSA. 1124 * Attributes grouped into a logical container. 1125 This does not include nested groups. 1126 * Attributes requiring the transport of more than 247 octets of 1127 Text or String data. This includes the opaque encapsulation 1128 of data structures defined outside of RADIUS. See also Section 1129 A.1.3, below. 1131 A.1.3. Opaque data types 1133 Does the attribute encapsulate an existing data structure defined 1134 outside of the RADIUS specifications? Can the attribute be treated 1135 as opaque data by RADIUS servers (including proxies?) If both 1136 questions can be answered affirmatively, a complex structure MAY be 1137 used in a RADIUS specification. 1139 The specification of the attribute SHOULD define the encapsulating 1140 attribute to be of type String. The specification SHOULD refer to an 1141 external document defining the structure. The specification SHOULD 1142 NOT define or describe the structure, as discussed above in Section 1143 2.1.3. 1145 A.2. Improper Data Types 1147 All data types other than the ones described above in Section A.1 1148 SHOULD NOT be used. This section describes in detail a number of 1149 data types that are NOT RECOMMENDED in new RADIUS specifications. 1150 Where possible, replacement data types are suggested. 1152 A.2.1. Simple Data Types 1154 Does the attribute use any of the following data types? If so, the 1155 data type SHOULD be replaced with the suggested alternatives, or 1156 SHOULD NOT be used at all. 1158 * Signed integers of any size. 1159 SHOULD NOT be used. SHOULD be replaced with one or more 1160 unsigned integer attributes. The definition of the attribute 1161 can contain information that would otherwise go into the sign 1162 value of the integer. 1163 * 8 bit unsigned integers. 1164 SHOULD be replaced with 32-bit unsigned integer. There is 1165 insufficient justification to save three bytes. 1166 * 16 bit unsigned integers. 1167 SHOULD be replaced with 32-bit unsigned integer. There is 1168 insufficient justification to save two bytes. 1169 * Unsigned integers of size other than 32 or 64. 1170 SHOULD be replaced by an unsigned integer of 32 or 64 bits. 1171 There is insufficient justification to define a new size of 1172 integer. 1173 * Integers of any size in non-network byte order 1174 SHOULD be replaced by unsigned integer of 32 or 64 bits, 1175 in network byte order. There is no reason to transport integers 1176 in any format other than network byte order. 1177 * Tagged data types as described in [RFC2868]. 1178 These data types SHOULD NOT be used in new specifications. The 1179 attribute grouping method defined in [EXTEN] SHOULD be used 1180 instead. 1181 * Complex data structures defined only within RADIUS. 1182 The additional functionality defined in [EXTEN] SHOULD be used 1183 instead. This recommendation does not apply to new attributes 1184 for authentication or security, as described below in Section 1185 A.2.2. 1186 * Multi-field text strings. 1187 Each field SHOULD be encapsulated in a separate attribute. 1188 Where grouping of fields is desired, the additional 1189 functionality defined in [EXTEN] SHOULD be used instead. 1190 * Polymorphic attributes. 1191 Multiple attributes, each with a static data type SHOULD be 1192 defined instead. 1194 A.2.2. Complex Data Types 1196 Does the attribute define a complex data type for purposes other than 1197 authentication or security? If so, this data type SHOULD be replaced 1198 with simpler types, as discussed above in Section A.2.1. Also see 1199 Section 2.1.3 for a discussion of why complex types are problematic. 1201 A.3. Vendor-Specific formats 1203 Does the specification contain Vendor-Specific attributes that match 1204 any of the following criteria? If so, the data type should be 1205 replaced with the suggested alternatives, or should not be used at 1206 all. 1208 * Vendor types of more than 16 bits. 1209 SHOULD NOT be used. Vendor types of 8 or 16 bits SHOULD be used 1210 instead. 1211 * Vendor lengths of less than 8 bits. (i.e., zero bits) 1212 SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used 1213 instead. 1214 * Vendor lengths of more than 8 bits. 1215 SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used 1216 instead. 1217 * Vendor-Specific contents that are not in Type-Length-Value 1218 format. 1219 SHOULD NOT be used. Vendor-Specific attributes SHOULD be in 1220 Type-Length-Value format. 1222 We recognize that SDOs may require more than 256 attributes, which is 1223 the limit of the 8-bit [RFC2865] Vendor-Specific space. Those SDOs 1224 SHOULD use Vendor types of 16 bits, as described in [EXTEN]. 1225 However, SDOs SHOULD NOT use Vendor types of 16 bits unless there are 1226 immediate requirements. Future-proofing a specification is 1227 insufficient grounds for using 16-bit Vendor types. 1229 In general, Vendor-Specific attributes SHOULD follow the [RFC2865] 1230 suggested format, or the [EXTEN] format if more functionality or a 1231 larger attribute space is necessary. 1233 A.4. Changes to the RADIUS Operational Model 1235 Does the specification extend change the RADIUS operation model, as 1236 outlined in the list below? If so, then another method of achieving 1237 the design objectives SHOULD be used. Potential problem areas 1238 include: 1240 * Defining new commands in RADIUS using attributes. 1241 The addition of new commands to RADIUS MUST be handled via 1242 allocation of a new Code, and not by the use of an attribute. 1243 This restriction includes new commands created by overloading 1244 the Service-Type attribute to define new values that modify 1245 the functionality of Access-Request packets. 1246 * Using RADIUS as a transport protocol for data unrelated to 1247 authentication, authorization, or accounting. Using RADIUS to 1248 transport authentication methods such as EAP is explicitly 1249 permitted, even if those methods require the transport of 1250 relatively large amounts of data. Transport of opaque data 1251 relating to AAA is also permitted, as discussed above in 1252 Section 2.1.3. However, if the specification does not relate 1253 to AAA, then RADIUS SHOULD NOT be used. 1254 * Assuming support for packet lengths greater than 4096 octets. 1255 Attribute designers cannot assume that RADIUS implementations 1256 can successfully handle packets larger than 4096 octets. 1257 If a specification could lead to a RADIUS packet larger than 1258 4096 octets, then the alternatives described in Section 3.3 1259 SHOULD be considered. 1260 * Stateless operation. The RADIUS protocol is stateless, and 1261 documents which require stateful protocol behavior without the 1262 use of the State Attribute need to be redesigned. 1263 * Provisioning of service in an Access-Reject. Such provisioning 1264 is not permitted, and MUST NOT be used. If limited access needs 1265 to be provided, then an Access-Accept with appropriate 1266 authorizations can be used instead. 1267 * Lack of user authentication or authorization restrictions. 1269 In an authorization check, where there is no demonstration of a 1270 live user, confidential data cannot be returned. Where there 1271 is a link to a previous user authentication, the State attribute 1272 needs to be present. 1273 * Lack of per-packet integrity and authentication. 1274 It is expected that documents will support per-packet 1275 integrity and authentication. 1276 * Modification of RADIUS packet sequences. 1277 In RADIUS, each request is encapsulated in it's own packet, and 1278 elicits a single response that is sent to the requester. Since 1279 changes to this paradigm are likely to require major 1280 modifications to RADIUS client and server implementations, they 1281 SHOULD be avoided if possible. 1282 For further details, see Section 3.3. 1284 A.5. Allocation of attributes 1286 Does the attribute have a limited scope of applicability, as outlined 1287 below? If so, then the attributes SHOULD be allocated from the 1288 Vendor-Specific space. 1290 * attributes intended for a vendor to support their own systems, 1291 and not suitable for general usage 1292 * attributes relying on data types not defined within RADIUS 1293 * attributes intended primarily for use within an SDO 1294 * attributes intended primarily for use within a group of SDOs. 1296 Note that the points listed above do not relax the recommendations 1297 discussed in this document. Instead, they recognize that the RADIUS 1298 data model has limitations. In certain situations where 1299 interoperability can be strongly constrained, a data model extended 1300 by the SDO or vendor MAY be used. We recommend, however, that the 1301 RADIUS data model SHOULD be used, even if it is marginally less 1302 efficient than alternatives. 1304 When attributes are used primarily within a group of SDOs, and are 1305 not applicable to the wider Internet community, we expect that one 1306 SDO will be responsible for allocation from their own private space. 1308 Appendix B - Complex Attributes 1310 This section summarizes RADIUS attributes with complex data types 1311 that are defined in existing RFCs. 1313 B.1. CHAP-Password 1315 [RFC2865] Section 5.3 defines the CHAP-Password Attribute which is 1316 sent from the RADIUS client to the RADIUS server in an Access- 1317 Request. The the data type of the CHAP Identifier is not given, only 1318 the one octet length: 1320 0 1 2 1321 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 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1323 | Type | Length | CHAP Ident | String ... 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1326 Since this is an authentication attribute, code changes are required 1327 on the RADIUS client and server to support it, regardless of the 1328 attribute format. Therefore, this complex data type is acceptable in 1329 this situation. 1331 B.2. CHAP-Challenge 1333 [RFC2865] Section 5.40 defines the CHAP-Challenge Attribute which is 1334 sent from the RADIUS client to the RADIUS server in an Access- 1335 Request. While the data type of the CHAP Identifier is given, the 1336 text also says 1338 If the CHAP challenge value is 16 octets long it MAY be placed in 1339 the Request Authenticator field instead of using this attribute. 1341 Defining attributes to contain values taken from the RADIUS packet 1342 header is NOT RECOMMENDED. Attributes should have values that are 1343 packed into a RADIUS AVP. 1345 B.3. Tunnel-Password 1347 [RFC2868] Section 3.5 defines the Tunnel-Password Attribute, which is 1348 sent from the RADIUS server to the client in an Access-Accept. This 1349 attribute includes Tag and Salt fields, as well as a string field 1350 which consists of three logical sub-fields: the Data-Length (one 1351 octet) and Password sub-fields (both of which are required), and the 1352 optional Padding sub-field. The attribute appears as follows: 1354 0 1 2 3 1355 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 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 | Type | Length | Tag | Salt 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 Salt (cont) | String ... 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 Since this is a security attribute and is encrypted, code changes are 1364 required on the RADIUS client and server to support it, regardless of 1365 the attribute format. Therefore, this complex data type is 1366 acceptable in this situation. 1368 B.4. ARAP-Password 1370 [RFC2869] Section 5.4 defines the ARAP-Password attribute, which is 1371 sent from the RADIUS client to the server in an Access-Request. It 1372 contains four 4 octet values, instead of having a single Value field: 1374 0 1 2 3 1375 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 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | Type | Length | Value1 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 | Value2 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 | Value3 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 | Value4 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 | 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 As with the CHAP-Password attribute, this is an authentication 1389 attribute which would have required code changes on the RADIUS client 1390 and server regardless of format. 1392 B.5. ARAP-Features 1394 [RFC2869] Section 5.5 defines the ARAP-Features Attribute, which is 1395 sent from the RADIUS server to the client in an Access-Accept or 1396 Access-Challenge. It contains a compound string of two single octet 1397 values, plus three 4-octet values, which the RADIUS client 1398 encapsulates in a feature flags packet in the ARAP protocol: 1400 0 1 2 3 1401 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 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 | Type | Length | Value1 | Value2 | 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 | Value3 | 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 | Value4 | 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 | Value5 | 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 Unlike the previous attributes, this attribute contains no encrypted 1413 component, nor is it directly involved in authentication. The 1414 individual sub-fields therefore could have been encapsulated in 1415 separate attributes. 1417 B.6. Connect-Info 1419 [RFC2869] Section 5.11 defines the Connect-Info attribute, which is 1420 used to indicate the nature of the connection. 1422 0 1 2 1423 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 | Type | Length | Text... 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 Even though the type is Text, the rest of the description indicates 1429 that it is a complex attribute: 1431 The Text field consists of UTF-8 encoded 10646 [8] characters. 1432 The connection speed SHOULD be included at the beginning of the 1433 first Connect-Info attribute in the packet. If the transmit and 1434 receive connection speeds differ, they may both be included in the 1435 first attribute with the transmit speed first (the speed the NAS 1436 modem transmits at), a slash (/), the receive speed, then 1437 optionally other information. 1438 For example, "28800 V42BIS/LAPM" or "52000/31200 V90" 1440 More than one Connect-Info attribute may be present in an 1441 Accounting-Request packet to accommodate expected efforts by ITU 1442 to have modems report more connection information in a standard 1443 format that might exceed 252 octets. 1445 This attribute contains no encrypted component, and is it not 1446 directly involved in authentication. The individual sub-fields could 1447 therefore have been encapsulated in separate attributes. 1449 B.7. Framed-IPv6-Prefix 1451 [RFC3162] Section 2.3 defines the Framed-IPv6-Prefix Attribute and 1452 [RFC4818] Section 3 reuses this format for the Delegated-IPv6-Prefix 1453 Attribute; these attributes are sent from the RADIUS server to the 1454 client in an Access-Accept. 1456 0 1 2 3 1457 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 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 | Type | Length | Reserved | Prefix-Length | 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 Prefix 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 Prefix 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 Prefix 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 Prefix | 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 The sub-fields encoded in these attributes are strongly related, and 1471 there was no previous definition of this data structure that could be 1472 referenced. Support for this attribute requires code changes on both 1473 the client and server, due to a new data type being defined. In this 1474 case it appears to be acceptable to encode them in one attribute. 1476 B.8. Egress-VLANID 1478 [RFC4675] Section 2.1 defines the Egress-VLANID Attribute which can 1479 be sent by a RADIUS client or server. 1481 0 1 2 3 1482 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 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 | Type | Length | Value 1485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1486 Value (cont) | 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 While it appears superficially to be of type Integer, the Value field 1490 is actually a packed structure, as follows: 1492 0 1 2 3 1493 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 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 | Tag Indic. | Pad | VLANID | 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 The length of the VLANID field is defined by the [IEEE-802.1Q] 1499 specification. The Tag indicator field is either 0x31 or 0x32, for 1500 compatibility with the Egress-VLAN-Name, as discussed below. The 1501 complex structure of Egress-VLANID overlaps with that of the base 1502 Integer data type, meaning that no code changes are required for a 1503 RADIUS server to support this attribute. Code changes are required 1504 on the NAS, if only to implement the VLAN ID enforcement. 1506 Given the IEEE VLAN requirements and the limited data model of 1507 RADIUS, the chosen method is likely the best of the possible 1508 alternatives. Future specifications that attempt to obtain similar 1509 functionality SHOULD use the extended types from [EXTEN]. 1511 B.9. Egress-VLAN-Name 1513 [RFC4675] Section 2.3 defines the Egress-VLAN-Name Attribute which 1514 can be sent by a RADIUS client or server. 1516 0 1 2 3 1517 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 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 | Type | Length | Tag Indic. | String... 1520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 The Tag Indicator is either the character '1' or '2', which in ASCII 1523 map to the identical values for Tag Indicator in Egress-VLANID, 1524 above. The complex structure of this attribute is acceptable for 1525 reasons identical to those given for Egress-VLANID. Future 1526 specifications that attempt to obtain similar functionality SHOULD 1527 use the extended types from [EXTEN]. 1529 Acknowledgments 1531 We would like to acknowledge David Nelson, Bernard Aboba, Emile van 1532 Bergen, Barney Wolff and Glen Zorn for contributions to this 1533 document. 1535 Authors' Addresses 1537 Greg Weber 1538 Knoxville, TN 37932 1539 USA 1541 Email: gdweber@gmail.com 1543 Alan DeKok 1544 The FreeRADIUS Server Project 1545 http://freeradius.org/ 1547 Email: aland@freeradius.org 1549 Full Copyright Statement 1551 Copyright (C) The IETF Trust (2008). 1553 This document is subject to the rights, licenses and restrictions 1554 contained in BCP 78, and except as set forth therein, the authors 1555 retain all their rights. 1557 This document and the information contained herein are provided on an 1558 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1559 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1560 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1561 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1562 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1563 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1565 Intellectual Property 1567 The IETF takes no position regarding the validity or scope of any 1568 Intellectual Property Rights or other rights that might be claimed to 1569 pertain to the implementation or use of the technology described in 1570 this document or the extent to which any license under such rights 1571 might or might not be available; nor does it represent that it has 1572 made any independent effort to identify any such rights. Information 1573 on the procedures with respect to rights in RFC documents can be 1574 found in BCP 78 and BCP 79. 1576 Copies of IPR disclosures made to the IETF Secretariat and any 1577 assurances of licenses to be made available, or the result of an 1578 attempt made to obtain a general license or permission for the use of 1579 such proprietary rights by implementers or users of this 1580 specification can be obtained from the IETF on-line IPR repository at 1581 http://www.ietf.org/ipr. 1583 The IETF invites any interested party to bring to its attention any 1584 copyrights, patents or patent applications, or other proprietary 1585 rights that may cover technology that may be required to implement 1586 this standard. Please address the information to the IETF at ietf- 1587 ipr@ietf.org. 1589 Acknowledgment 1591 Funding for the RFC Editor function is provided by the IETF 1592 Administrative Support Activity (IASA). 1594 Open issues 1596 Open issues relating to this document are tracked on the following 1597 web site: 1599 http://www.drizzle.com/~aboba/RADEXT/