idnits 2.17.1 draft-ietf-radext-design-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1365. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1383. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1389. 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 (5 December 2007) is 5986 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 1233 == Outdated reference: A later version (-09) exists of draft-ietf-radext-extended-attributes-00 Summary: 1 error (**), 0 flaws (~~), 3 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: June 5, 2008 7 5 December 2007 9 RADIUS Design Guidelines 10 draft-ietf-radext-design-02.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 June 5, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 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 ............................................. 3 50 1.1. Applicability ....................................... 3 51 1.2. Terminology ......................................... 4 52 1.3. Requirements Language ............................... 4 53 2. RADIUS Data Model ........................................ 4 54 2.1. Standard Space ...................................... 5 55 2.1.1. Basic Data Types ............................... 5 56 2.1.2. Tagging Mechanism .............................. 6 57 2.1.3. Complex Attribute Usage ........................ 7 58 2.1.4. Complex Attributes and Security ................ 9 59 2.1.5. Service definitions and RADIUS ................. 10 60 2.2. Vendor Space ........................................ 10 61 3. Data Model Issues ........................................ 12 62 3.1. Vendor Space ........................................ 13 63 3.1.1. Interoperability Considerations ................ 14 64 3.1.2. Vendor Allocations ............................. 15 65 3.1.3. SDO Allocations ................................ 15 66 3.1.4. Publication of specifications .................. 16 67 3.2. Polymorphic Attributes .............................. 16 68 4. IANA Considerations ...................................... 17 69 5. Security Considerations .................................. 17 70 6. References ............................................... 18 71 6.1. Normative References ................................ 18 72 6.2. Informative References .............................. 18 73 Appendix A - Design Guidelines ............................... 20 74 A.1. Types matching the RADIUS data model ................. 20 75 A.1.1. Transport of simple data ........................ 20 76 A.1.2. Extended data types ............................. 20 77 A.1.3. Complex data types .............................. 21 78 A.2. Improper Data Types .................................. 21 79 A.2.1. Simple Data Types ............................... 21 80 A.2.2. Complex Data Types .............................. 22 81 A.3. Vendor-Specific formats .............................. 22 82 A.4. New functionality in RADIUS. ......................... 23 83 A.5. Allocation of attributes ............................. 23 84 Appendix B - Complex Attributes .............................. 25 85 B.1. CHAP-Password ........................................ 25 86 B.2. CHAP-Challenge ....................................... 25 87 B.3. Tunnel-Password ...................................... 25 88 B.4. ARAP-Password ........................................ 26 89 B.5. ARAP-Features ........................................ 26 90 B.6. Connect-Info ......................................... 27 91 B.7. Framed-IPv6-Prefix ................................... 27 92 B.8. Egress-VLANID ........................................ 28 93 B.9. Egress-VLAN-Name ..................................... 29 94 Full Copyright Statement ..................................... 30 95 1. Introduction 97 This document provides guidelines for the design of RADIUS attributes 98 both within the IETF as well as within other Standards Development 99 Organizations (SDOs). By articulating RADIUS design guidelines, it 100 is hoped that this document will encourage the development and 101 publication of high quality RADIUS attribute specifications. The 102 advice in this document will not be helpful unless it is put to use. 104 As with "Guidelines for Authors and Reviewers of MIB Documents" 105 [RFC4181], it is expected that this document will enable authors to 106 check their document against the guidelines prior to requesting a 107 review (such an "Expert Review" described in [RFC3575]). Similarly, 108 it is hoped that this document will be of use to reviewers (such as 109 WG participants or the AAA Doctors) in improving the consistency of 110 reviews. 112 In order to meet these objectives, this document needs to cover not 113 only the science of attribute design, but also the art. As a result, 114 in addition to covering the most frequently encountered issues, this 115 document attempts to provide some of the considerations motivating 116 the guidelines. 118 In order to characterize current attribute usage, both the basic and 119 complex data types defined in the existing RADIUS RFCs are reviewed, 120 together with the ad-hoc extensions to that data model that have been 121 used in Vendor-Specific Attributes. 123 1.1. Applicability 125 As RADIUS has become more widely accepted as a management protocol, 126 it's usage has become more prevalent, both within the IETF as well as 127 within other SDOs. Given the expanded utilization of RADIUS, it has 128 become apparent that requiring SDOs to accomplish all their RADIUS 129 work within the IETF is inherently inefficient and unscalable. By 130 articulating guidelines for RADIUS attribute design, this document 131 enables SDOs to design their own RADIUS attributes within the Vendor- 132 Specific Attribute (VSA) space, seeking review from the IETF. In 133 order enable IETF review of SDO RADIUS attribute specifications, the 134 authors recommend: 136 * Development of a program to encourage SDOs to make their RADIUS 137 attribute specifications publicly available; 139 * Review of IETF and SDO specifications according to the 140 guidelines proposed in this document; 142 The advice in this document applies to attributes used to encode 143 service-provisioning or authentication data. RADIUS protocol 144 changes, or specification of attributes that can be used to, in 145 effect, provide new RADIUS commands (such as Service-Type) are out of 146 scope. Since protocol changes require greater expertise and deeper 147 review, such changes should not be undertaken outside the IETF and 148 when handled within the IETF require "IETF Consensus" for adoption, 149 as noted in [RFC3575] Section 2.1. 151 As with protocol changes, this document does not provide guidance to 152 document authors seeking to change the RADIUS operational model. 153 While RADIUS server implementations may keep state, the RADIUS 154 protocol is stateless, although information may be passed from one 155 protocol transaction to another via the State Attribute. As a 156 result, documents which require stateful protocol behavior without 157 use of the State Attribute are inherently incompatible with RADIUS as 158 defined in [RFC2865], and need to be redesigned. 160 See [RFC5080] Section 2.1.1 for a more in-depth discussion of the use 161 of the State Attribute. 163 1.2. Terminology 165 This document uses the following terms: 167 Network Access Server (NAS) 168 A device that provides an access service for a user to a network. 170 RADIUS server 171 A RADIUS authentication, authorization, and/or accounting (AAA) 172 server is an entity that provides one or more AAA services to a 173 NAS. 175 RADIUS proxy 176 A RADIUS proxy acts as a RADIUS server to the NAS, and a RADIUS 177 client to the RADIUS server. 179 1.3. Requirements Language 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in [RFC2119]. 185 2. RADIUS Data Model 187 The Remote Authentication Dial In User Service (RADIUS) defined in 188 [RFC2865] and [RFC2866] uses elements known as attributes in order to 189 represent authentication, authorization and accounting data. 191 Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does 192 not define a formal data definition language. A handful of basic 193 data types are provided, and a data type is associated with an 194 attribute when the attribute is defined. 196 Two distinct attribute spaces are defined: the standard space, and a 197 Vendor-Specific space. Attributes in the standard space generally 198 are composed of a type, length, value (TLV) triplet, although complex 199 attributes have also been defined. The Vendor-Specific space is 200 encapsulated within a single attribute type (Vendor-Specific 201 Attribute). The format of this space is defined by individual 202 vendors, but the same TLV encoding used by the standard space is 203 recommended in [RFC2865] Section 5.26. The similarity between 204 attribute formats has enabled implementations to leverage common 205 parsing functionality, although in some cases the attributes in the 206 Vendor-Specific space have begun to diverge from the common format. 208 2.1. Standard Space 210 The following subsections describe common data types and formats 211 within the RADIUS standard attribute space. Common exceptions are 212 identified. 214 2.1.1. Basic Data Types 216 The data type of RADIUS attributes is not transported on the wire. 217 Rather, the data type of a RADIUS attribute is fixed when that 218 attribute is defined. Based on the RADIUS attribute type code, 219 RADIUS clients and servers can determine the data type based on pre- 220 configured entries within a data dictionary. 222 [RFC2865] defines the following data types: 224 text 1-253 octets containing UTF-8 encoded 10646 [RFC3629] 225 characters. Text of length zero (0) MUST NOT be sent; 226 omit the entire attribute instead. 227 string 1-253 octets containing binary data (values 0 through 228 255 decimal, inclusive). Strings of length zero (0) 229 MUST NOT be sent; omit the entire attribute instead. 230 IPv4 address 32 bit value, most significant octet first. 231 integer 32 bit unsigned value, most significant octet first. 232 time 32 bit unsigned value, most significant octet first 233 -- seconds since 00:00:00 UTC, January 1, 1970. 235 In addition to these data types, follow-on RADIUS specifications 236 define attributes using the following additional types: 238 IPv6 address 128 bit value, most significant octet first. 240 IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to 241 128 bits of value, most significant octet first. 242 integer64 64 bit unsigned value, most significant octet first. 243 This type has also been used to represent an IPv6 244 interface identifier. 246 Examples of the IPv6 address type include NAS-IPv6-Address defined in 247 [RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162] 248 Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3, 249 and in [RFC4818] Section 3. The integer64 type is used for the ARAP- 250 Challenge-Response Attribute defined in [RFC2869] Section 5.15, and 251 the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2. 252 [RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in 253 length, but denotes it as type String. 255 Given that attributes of type IPv6 address, IPv6 prefix, and 256 integer64 are already in use, it is RECOMMENDED that RADIUS server 257 implementations include support for these additional basic types, in 258 addition to the types defined in [RFC2865]. 260 Where the intent is to represent a specific IPv6 address, the IPv6 261 address type SHOULD be used. Although it is possible to use the IPv6 262 IPv6 Prefix type with a prefix length of 128 to represent an IPv6 263 address, this usage is NOT RECOMMENDED 265 It is worth noting that since RADIUS only supports unsigned integers 266 of 32 or 64 bits, attributes using signed integer data types or 267 unsigned integer types of other sizes will require code changes, and 268 SHOULD be avoided. 270 For [RFC2865] RADIUS VSAs, the length limitation of the String and 271 Text types is 247 octets instead of 253 octets, due to the additional 272 overhead of the Vendor-Specific Attribute. 274 2.1.2. Tagging Mechanism 276 [RFC2868] defines an attribute grouping mechanism based on the use of 277 a one octet tag value. Tunnel attributes that refer to the same 278 tunnel are grouped together by virtue of using the same tag value. 280 This tagging mechanism has some drawbacks. There are a limited 281 number of unique tags (31). The tags are not well suited for use 282 with arbitrary binary data values, because it is not always possible 283 to tell if the first byte after the Length is the tag or the first 284 byte of the untagged value (assuming the tag is optional). 286 Other limitations of the tagging mechaism are that when integer 287 values are tagged, the value portion is reduced to three bytes 288 meaning only 24-bit numbers can be represented. The tagging 289 mechanism does not offer an ability to create nested groups of 290 attributes. Some RADIUS implementations treat tagged attributes as 291 having additional data types tagged-string and tagged-integer. These 292 types increase the complexity of implementing and managing RADIUS 293 systems. 295 New attributes SHOULD NOT use this tagging method because of the 296 limitations described above. New attributes SHOULD use the grouping 297 method described in [EXTEN]. 299 2.1.3. Complex Attribute Usage 301 The RADIUS attribute encoding is summarized in [RFC2865]: 303 0 1 2 304 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 306 | Type | Length | Value ... 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 309 However, some standard attributes do not follow this format. 310 Attributes that use sub-fields instead of using a basic data type are 311 known as "complex attributes". As described below, the definition of 312 complex attributes can lead to interoperability and deployment 313 issues, so they need to introduced with care. 315 In general, complex attributes sent from the RADIUS server to the 316 client can be supported by concatenating the values into a String 317 data type field. However, separating these values into different 318 attributes, each with its own type and length, would have the 319 following benefits: 321 * it is easier for the user to enter the data as well-known 322 types, rather than complex structures 323 * it enables additional error checking by leveraging the 324 parsing and validation routines for well-known types 325 * it simplifies implementations by eliminating special-case 326 attribute-specific parsing. 328 One of the fundamental goals of the RADIUS protocol design was to 329 allow RADIUS servers to be configured to support new attributes 330 without requiring server code changes. RADIUS server implementations 331 typically use provide support for basic data types, and define 332 attributes in a data dictionary. This architecture enables a new 333 attribute to be supported by the addition of a dictionary entry, 334 without requiring RADIUS server code changes. 336 On the RADIUS client, code changes are typically required in order to 337 implement a new attribute, as the RADIUS client typically has to 338 compose the attribute dynamically when sending. When receiving, a 339 RADIUS client needs to be able to parse the attribute and carry out 340 the requested service. As a result, a detailed understanding of the 341 new attribute is required on clients, and data dictionaries are less 342 useful on clients than on servers. 344 Given these considerations, the introduction of a new basic or 345 complex attribute will typically require code changes on the RADIUS 346 client. The magnitude of changes for the complex attribute could be 347 greater, due to the potential need for custom parsing logic. 349 The RADIUS server can be configured to send a new attribute by 350 entering its type and data format in the RADIUS server dictionary, 351 and then filling in the value within a policy based on the attribute 352 name, data type and type-specific value. For complex attribute types 353 not supported by RADIUS server dictionaries, changes to the 354 dictionary and policy management code can be required in order to 355 allow the new attribute to be supported by and configured on the 356 RADIUS server. 358 Code changes can also be required in the RADIUS server's receive 359 path, due to limitations in RADIUS server policy languages, which 360 typically only provide for limited operations (such as comparisons or 361 arithmetic operations) on the basic data types. Many existing RADIUS 362 policy languages typically are not capable of parsing sub-elements, 363 or providing sophisticated matching functionality. 365 Given these limitations, the introduction of complex attributes can 366 require code changes on the RADIUS server which would be unnecessary 367 if basic data types had been used instead. In addition, attribute- 368 specific parsing means more complex software to develop and maintain. 369 More complexity can lead to more error prone implementations, and 370 interoperatibility problems. This issues can increase costs to 371 network administrators as well as reducing reliability and 372 introducing deployment barriers. As a result, the introduction of 373 new complex data types within RADIUS attribute specifications SHOULD 374 be avoided, except in the case of complex attributes involve 375 authentication or security functionality. 377 As can be seen in Appendix B, most of the complex attributes involve 378 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 (e.g., IPv6 address), 417 and use these data types today by matching them to the attribute's 418 textual description. 420 2.1.4. Complex Attributes and Security 422 The introduction of complex data types brings the potential for the 423 introduction of new security vulnerabilities. Experience shows that 424 the common data types have few security vulnerabilities, or else that 425 all known issues have been found and fixed. New data types require 426 new code, which may introduce new bugs, and therefore new attack 427 vectors. 429 RADIUS servers are highly valued targets, as they control network 430 access and interact with databases that store usernames and 431 passwords. An extreme outcome of a vulnerability due to a new, 432 complex type would be that an attacker is capable of taking complete 433 control over the RADIUS server. 435 The use of attributes representing opaque data does not reduce this 436 threat. The threat merely moves from the RADIUS server to the 437 application that consumes that opaque data. 439 The threat is particularly severe when the opaque data does not 440 originate from, or is checked by the NAS. In those cases, the RADIUS 441 server is potentially exposed to attack by malware residing on an 442 unauthenticated host. Applications consuming opaque data that reside 443 on the RADIUS server SHOULD be properly isolated from the RADIUS 444 server, and SHOULD run with minimal privileges. Any potential 445 vulnerabilities in that application will then have minimal impact on 446 the security of the system as a whole. 448 2.1.5. Service definitions and RADIUS 450 RADIUS specifications define how an existing service or protocol can 451 be provisioned using RADIUS. Therefore, it is expected that a RADIUS 452 attribute specification will reference documents defining the 453 protocol or service to be provisioned. Within the IETF, a RADIUS 454 attribute specification SHOULD NOT be used to define the protocol or 455 service being provisioned. New services using RADIUS for 456 provisioning SHOULD be defined elsewhere and referenced in the RADIUS 457 specification. 459 RADIUS also SHOULD NOT be extended to new commands via attributes. 460 RADIUS attributes are intended 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 SHOULD NOT use new attributes to modify the 470 interpretation of existing RADIUS commands. 472 2.2. Vendor Space 474 As noted in [RFC2865] Section 5.26, the VSA format is defined as 475 follows: 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Type | Length | Vendor-Id 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 Vendor-Id (cont) | String... 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 485 The high-order octet of the Vendor-Id field is 0 and the low-order 3 486 octets are the Structure of Management Information (SMI) Network 487 Management Private Enterprise Code (PEC) of the Vendor in network 488 byte order. 490 While the format of the String field is defined by the vendor, 491 [RFC2865] Section 5.26 notes: 493 It SHOULD be encoded as a sequence of vendor type / vendor length 494 / value fields, as follows. The Attribute-Specific field is 495 dependent on the vendor's definition of that attribute. An 496 example encoding of the Vendor-Specific attribute using this 497 method follows: 499 0 1 2 3 500 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 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Type | Length | Vendor-Id 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 Vendor-Id (cont) | Vendor type | Vendor length | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Attribute-Specific... 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 509 Multiple sub-attributes MAY be encoded within a single Vendor- 510 Specific attribute, although they do not have to be. 512 Note that the Vendor type field in the recommended VSA format is only 513 a single octet, like the RADIUS type field. While this limitation 514 results in an efficient encoding, there are situations in which a 515 vendor or SDO will eventually wish to define more than 255 516 attributes. Also, an SDO can be comprised of multiple subgroups, 517 each of whom can desire autonomy over the definition of attributes 518 within their group. In such a situation, a 16-bit Vendor type field 519 would be more appropriate: 521 0 1 2 3 522 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 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Type | Length | Vendor-Id 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 Vendor-Id (cont) | Vendor type | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Vendor length | Attribute-Specific... 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 Other attribute formats are NOT RECOMMENDED. Examples of NOT 533 RECOMMENDED formats include Vendor types of more than 16 bits, Vendor 534 lengths of less than 8 bits, Vendor lengths of more than 8 bits, and 535 Vendor-Specific contents that are not in Type-Length-Value format. 537 In order to be compatible with the above recommendations for attribute 538 definitions, it is RECOMMENDED that RADIUS servers support attributes 539 using a 16-bit Vendor type field. 541 3. Data Model Issues 543 Since the closure of the RADIUS Working Group, the popularity and 544 prevalence of RADIUS has continued to grow. In addition to 545 increasing demand for allocation of attributes within the RADIUS 546 standard attribute space, the number of vendors and SDOs creating new 547 attributes within the Vendor-Specific attribute space has grown, and 548 this has lead to some divergence in approaches to RADIUS attribute 549 design. 551 In general, standard RADIUS attributes have a more constrained data 552 model than attributes within the vendor space. For example, vendors 553 and SDOs have evolved the data model to support new functions such as 554 attribute grouping and attribute fragmentation, with different groups 555 taking different approaches. 557 Given these enhancements, it has become difficult for vendors or SDOs 558 to translate attributes from the vendor space to the more stringent 559 standards space. For example, a Vendor-Specific attribute using sub- 560 elements could require allocation of several standard space 561 attributes using basic data types. In this case not only would 562 translation require substantial additional work, it would further 563 deplete the RADIUS standard attribute space. Given these 564 limitations, translation of vendor attributes to the standards space 565 is not necessarily desirable, particularly if the VSA specification 566 is publicly available and can be implemented within existing RADIUS 567 clients and servers. In such situations, the costs may substantially 568 outweigh the benefits. It is possible that some of the enhancements 569 made within the vendor space may eventually become available within 570 the standard attribute space. However, the divergence of the 571 standard and vendor attribute spaces is most likely a permanent 572 feature, and should be recognized as such. 574 Recent extensions to the RADIUS data model such as [EXTEN] make it 575 possible to minimize the use of complex attributes. New 576 specifications seeking to extend the standard RADIUS data model 577 SHOULD examine [EXTEN] to see if their needs fit within the extended 578 RADIUS data model. 580 3.1. Vendor Space 582 The usage model for RADIUS VSAs is described in [RFC2865] Section 583 6.2: 585 Note that RADIUS defines a mechanism for Vendor-Specific 586 extensions (Attribute 26) and the use of that should be encouraged 587 instead of allocation of global attribute types, for functions 588 specific only to one vendor's implementation of RADIUS, where no 589 interoperability is deemed useful. 591 Nevertheless, many new attributes have been defined in the vendor 592 specific space in situations where interoperability is not only 593 useful, but is required. For example, Standards Development 594 Organizations (SDOs) outside the IETF (such as the IEEE 802 and the 595 3rd Generation Partnership Project (3GPP)) have been assigned Vendor- 596 Ids, enabling them to define their own VSA format and assign Vendor 597 types within their own space. 599 The use of VSAs by SDOs outside the IETF has gained in popularity for 600 several reasons: 602 Efficiency 603 As with SNMP, which defines an "Enterprise" Object Identifier (OID) 604 space suitable for use by vendors as well as other SDOs, the 605 definition of Vendor-Specific RADIUS attributes has become a common 606 occurrence as part of standards activity outside the IETF. For 607 reasons of efficiency, it is easiest if the RADIUS attributes 608 required to manage a standard are developed within the same SDO 609 that develops the standard itself. As noted in "Transferring MIB 610 Work from IETF Bridge MIB WG to IEEE 802.1 WG" [RFC4663], today few 611 vendors are willing to simultaneously fund individuals to 612 participate within an SDO to complete a standard, as well as to 613 participate in IETF in order to complete the associated RADIUS 614 attributes specification. 616 Attribute scarcity 617 The standard RADIUS attribute space is limited to 255 unique 618 attributes. Of these, only about half remain available for 619 allocation. In the Vendor-Specific space, the number of attributes 620 available is a function of the format of the attribute (the size of 621 the Vendor type field). 623 Along with these advantages, some limitations of VSA usage are noted 624 in [RFC2865] Section 5.26: 626 This Attribute is available to allow vendors to support their own 627 extended Attributes not suitable for general usage. It MUST NOT 628 affect the operation of the RADIUS protocol. 630 Servers not equipped to interpret the vendor-specific information 631 sent by a client MUST ignore it (although it may be reported). 632 Clients which do not receive desired vendor-specific information 633 SHOULD make an attempt to operate without it, although they may do 634 so (and report they are doing so) in a degraded mode. 636 The limitation on changes to the RADIUS protocol effectively 637 prohibits VSAs from changing fundamental aspects of RADIUS operation, 638 such as modifying RADIUS packet sequences, or adding new commands. 639 However, the requirement for clients and servers to be able to 640 operate in the absence of VSAs has proven to be less of a constraint, 641 since it is still possible for a RADIUS client and server to mutually 642 indicate support for VSAs, after which behavior expectations can be 643 reset. 645 Therefore, RFC 2865 provides considerable latitude for development of 646 new attributes within the vendor space, while prohibiting development 647 of protocol variants. This flexibility implies that RADIUS 648 attributes can often be developed within the vendor space without 649 loss (and possibly even gain) in functionality. 651 As a result, translation of RADIUS attributes developed within the 652 vendor space into the standard space may provide only modest 653 benefits, while accelerating the exhaustion of the standard attribute 654 space. We do not expect that all RADIUS attribute specifications 655 requiring interoperability will be developed within the IETF, and 656 allocated from the standards space. A more scalable approach is to 657 recognize the flexibility of the vendor space, while working toward 658 improvements in the quality and availability of RADIUS attribute 659 specifications, regardless of where they are developed. 661 3.1.1. Interoperability Considerations 663 Vendors and SDOs are reminded that the standard RADIUS attribute ID 664 space, and the enumerated value space for enumerated attributes, are 665 reserved for allocation through work published via the IETF, as noted 666 in [RFC3575] Section 2.1. Some vendors and SDOs have in the past 667 performed self-allocation by assigning vendor-specific meaning to 668 "unused" values from the standard RADIUS attribute ID or enumerated 669 value space. This self-allocation results in interoperability 670 issues, and is counter-productive. Similarly, the Vendor-Specific 671 enumeration practice discussed in [RFC2882] Section 2.2.1 is NOT 672 RECOMMENDED. 674 If it is not possible to follow the above procedure, vendors and SDOs 675 they SHOULD self-allocate an attribute from their Vendor-Specific 676 space, and define an appropriate value for it. 678 As a side note, [RFC2865] Section 5.26 uses the term "Vendor-Specific 679 Attribute" to refer to an encoding format which can be used by 680 individual vendors to define attributes not suitable for general 681 usage. However, since then VSAs have also become widely used by SDOs 682 defining attributes intended for multi-vendor interoperability. As 683 such, these attributes are not specific to any single vendor, and the 684 term "Vendor-Specific" may be misleading. An alternate term which 685 better describes this use case is SDO-Specific Attribute (SSA). 687 The design and specification of VSAs for multi-vendor usage SHOULD be 688 undertaken with the same level of care as standard RADIUS attributes. 689 Specifically, the provisions of this document that apply to standard 690 RADIUS attributes also apply to SSAs or VSAs for multi-vendor usage. 692 3.1.2. Vendor Allocations 694 Vendor RADIUS Attribute specifications SHOULD allocate attributes 695 from the vendor space, rather than requesting an allocation from the 696 RADIUS standard attribute space. 698 As discussed in [RFC2865] Section 5.26, the vendor space is intended 699 for vendors to support their own extended attributes not suitable for 700 general use. However, it is RECOMMENDED that vendors follow the 701 guidelines outlined here, which are intended to enable maximum 702 interoperability with minimal changes to existing systems. 704 Following these guidelines means that RADIUS servers can be updated 705 to support the vendor's equipment by editing a RADIUS dictionary. If 706 these guidelines are not followed, then the vendor's equipment can 707 only be supported via code changes in RADIUS server implementations. 708 Such code changes add complexity and delay to implementations. 710 3.1.3. SDO Allocations 712 SDO RADIUS Attribute specifications SHOULD allocate attributes from 713 the vendor space, rather than requesting an allocation from the 714 RADIUS standard attribute space, for attributes matching any of the 715 following criteria: 717 * attributes relying on data types not defined within RADIUS 718 * attributes intended primarily for use within an SDO 719 * attributes intended primarily for use within a group of SDOs. 721 The recommendation for SDOs to allocate attributes from a vendor 722 space rather than via IETF process is a recognition that SDOs may 723 desire to assert change control over their own RADIUS specifications. 724 This change control can be obtained by requesting a PEC from the 725 Internet Assigned Number Authority (IANA), for use as a Vendor-Id 726 within a Vendor-Specific attribute. Further allocation of attributes 727 inside of the VSA space defined by that Vendor-Id is subject solely 728 to the discretion of the SDO. Similarly, the use of data types 729 (complex or not) within that VSA space is solely under the discretion 730 of the SDO. It is RECOMMENDED that SDOs follow the guidelines 731 outlined here, which are intended to enable maximum interoperability 732 with minimal changes to existing systems. 734 It should be understood that SDOs do not have to rehost VSAs into the 735 standards space solely for the purpose of obtaining IETF review. 736 Rehosting puts pressure on the standards space, and may be harmful to 737 interoperability, since it can create two ways to provision the same 738 service. Rehosting may also require changes to the RADIUS data model 739 which will affect implementations that do not intend to support the 740 SDO specifications 742 3.1.4. Publication of specifications 744 SDOs are encouraged to seek early review of SSA specifications by the 745 IETF. This review may be initiated by sending mail to the AAA 746 Doctors list (aaa-doctors@ops.ietf.org). Since the IETF is not a 747 membership organization, in order to enable the RADIUS SSA 748 specification to be reviewed, it is RECOMMENDED that it be made 749 publicly available; this also encourages interoperability. Where the 750 RADIUS SSA specification is embedded within a larger document which 751 cannot be made public, the RADIUS attribute and value definitions 752 SHOULD be published instead as an Informational RFC, as with 753 [RFC4679]. This process SHOULD be followed instead of requesting 754 IANA allocations from within the standard RADIUS attribute space. 756 Similarly, vendors are encouraged to make their specifications 757 publicly available, for maximum interoperability. However, it is not 758 necessary for them to request publication of their VSA specifications 759 as Informational RFCs by the IETF. 761 All other specifications, including new authentication and/or 762 security mechanisms SHOULD be allocated via the standard RADIUS 763 space, as noted in [RFC3575] Section 2.1. 765 3.2. Polymorphic Attributes 767 A polymorphic attribute is one whose format or meaning is dynamic. 768 For example, rather than using a fixed data format, an attribute's 769 format might change based on the contents of another attribute. Or, 770 the meaning of an attribute may depend on earlier packets in a 771 sequence. 773 RADIUS server dictionary entries are typically static, enabling the 774 user to enter the contents of an attribute without support for 775 changing the format based on dynamic conditions. However, this 776 limitation on static types does not prevent implementations from 777 implementing policies that return different attributes based on the 778 contents of received attributes; this is a common feature of existing 779 RADIUS implementations. 781 In general, polymorphism is NOT RECOMMENDED. Polymorphism rarely 782 enables capabilities that would not be available through use of 783 multiple attributes. Polymorphism requires code changes in the 784 RADIUS server in situations where attributes with fixed formats would 785 not require such changes. Thus, polymorphism increases complexity 786 while decreasing generality, without delivering any corresponding 787 benefits. 789 Note that changing an attribute's format dynamically is not the same 790 thing as using a fixed format and computing the attribute itself 791 dynamically. RADIUS authentication attributes such as User-Password, 792 EAP-Message, etc. while being computed dynamically, use a fixed 793 format. 795 4. IANA Considerations 797 This document requires no action by IANA. 799 5. Security Considerations 801 This specification provides guidelines for the design of RADIUS 802 attributes used in authentication, authorization and accounting. 803 Threats and security issues for this application are described in 804 [RFC3579] and [RFC3580]; security issues encountered in roaming are 805 described in [RFC2607]. 807 Encryption of RADIUS attributes on a per-attribute basis is necessary 808 in some cases. The current standard mechanism for this is described 809 in [RFC2865] Section 5.2 (for obscuring User-Password values) and is 810 based on the MD5 algorithm specified in [RFC1321]. The MD5 algorithm 811 has recently become a focus of scrutiny and concern in security 812 circles, and as a result, the use of this technique in new attributes 813 is NOT RECOMMENDED. 815 Where new RADIUS attributes use cryptographic algorithms, algorithm 816 negotiation SHOULD be supported. Specification of a mandatory-to- 817 implement algorithm is REQUIRED, and it is RECOMMENDED that the 818 mandatory-to-implement algorithm be certifiable under FIPS 140 819 [FIPS]. 821 Where new RADIUS attributes encapsulate complex data types, or 822 transport opaque data, the security considerations discussed in 823 Section 2.1.4 SHOULD be addressed. 825 6. References 827 6.1. Normative References 829 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 830 Requirement Levels", BCP 14, RFC 2119, March 1997. 832 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 833 Authentication Dial In User Service (RADIUS)", RFC 2865, June 834 2000. 836 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 837 Authentication Dial In User Service)", RFC 3575, July 2003. 839 6.2. Informative References 841 [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of 842 management information for TCP/IP-based internets", STD 16, 843 RFC 1155, May 1990. 845 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 846 Network Management Protocol (SNMP)", STD 15, RFC 1157, May 847 1990. 849 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 850 April 1992. 852 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 853 Implementation in Roaming", RFC 2607, June 1999. 855 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 857 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., 858 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 859 Support", RFC 2868, June 2000. 861 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", 862 RFC 2869, June 2000. 864 [RFC2882] Mitton, D, "Network Access Servers Requirements: Extended 865 RADIUS Practices", RFC 2882, July 2000. 867 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 868 3162, August 2001. 870 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 871 In User Service) Support For Extensible Authentication 872 Protocol (EAP)", RFC 3579, September 2003. 874 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE 875 802.1X Remote Authentication Dial In User Service (RADIUS) 876 Usage Guidelines", RFC3580, September 2003. 878 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 879 RFC 3629, November 2003. 881 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 882 Documents", RFC 4181, September 2005. 884 [RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge MIB WG 885 to IEEE 802.1 WG", RFC 4663, September 2006. 887 [RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for 888 Virtual LAN and Priority Support", RFC 4675, September 2006. 890 [RFC4679] Mammoliti, V., et al., "DSL Forum Vendor-Specific RADIUS 891 Attributes", RFC 4679, September 2006. 893 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 894 Attribute", RFC 4818, April 2007. 896 [RFC5080] Nelson, D. and DeKok, A, "Common Remote Authentication Dial In 897 User Service (RADIUS) Implementation Issues and Suggested 898 Fixes", RFC 5080, December 2007. 900 [IEEE-802.1Q] 901 IEEE Standards for Local and Metropolitan Area Networks: Draft 902 Standard for Virtual Bridged Local Area Networks, 903 P802.1Q-2003, January 2003. 905 [EXTEN] Li, Y., et al., "Extended Remote Authentication Dial In User 906 Service (RADIUS) Attributes", draft-ietf-radext-extended- 907 attributes-00.txt (work in progress). 909 [FIPS] FIPS 140-3 (DRAFT), "Security Requirements for Cryptographic 910 Modules", http://csrc.nist.gov/publications/fips/fips140-3/ 912 Appendix A - Design Guidelines 914 The following text provides guidelines for the design of attributes 915 used by the RADIUS protocol. Specifications that follow these 916 guidelines are expected to achieve maximum interoperability with 917 minimal changes to existing systems. 919 A.1. Types matching the RADIUS data model 921 A.1.1. Transport of simple data 923 Does the data fit within the existing RADIUS data model, as outlined 924 below? If so, it SHOULD be encapsulated in a [RFC2865] format RADIUS 925 attribute, or in a [RFC2865] format RADIUS VSA. 927 * 32-bit unsigned integer, most significant octet first. 928 * Enumerated data types, represented as a 32-bit unsigned integer 929 with a list of name to value mappings. (e.g., Service-Type) 930 * 64-bit unsigned integer, most significant octet first. 931 * IPv4 address in network byte order. 932 * IPv6 address in network byte order. 933 * IPv6 prefix. 934 * time as 32 bit unsigned value, most significant octet first, in 935 seconds since 00:00:00 UTC, January 1, 1970. 936 * string (i.e., binary data), totalling 253 octets or less in 937 length. This includes the opaque encapsulation of data 938 structures defined outside of RADIUS. See also Section A.1.3, 939 below. 940 * UTF-8 text, totalling 253 octets or less in length. 941 * Complex data types for authentication and/or security. 942 These attributes SHOULD be defined only within the RADIUS 943 attribute space, and SHOULD NOT be defined within the VSA space. 945 Note that the length limitations for VSAs of type String and Text are 946 less than 253 octets, due to the additional overhead of the Vendor- 947 Specific format. 949 A.1.2. Extended data types 951 Where possible, the data types defined above in Section A.1.2 SHOULD 952 be used. The extended data types SHOULD be used only where there is 953 no clear method of expressing the data using existing types. 955 Does the data fit within the extended RADIUS data model, as outlined 956 below? If so, it SHOULD be encapsulated in a [EXTEN] format RADIUS 957 VSA. 959 * Attributes grouped into a logical container. 961 This does not included nested groups. 962 * Attributes requiring the transport of more than 247 octets of 963 Text or String data. This includes the opaque encapsulation 964 of data structures defined outside of RADIUS. See also Section 965 A.1.3, below. 967 A.1.3. Complex data types 969 Does the attribute encapsulate an existing data structure defined 970 outside of the RADIUS specifications? Can the attribute be treated 971 as opaque data by RADIUS servers (including proxies?) If both 972 questions can be answered affirmatively, a complex structure MAY be 973 used in a RADIUS specification. 975 The specification of the attribute SHOULD define the encapsulating 976 attribute to be of type String. The specification SHOULD refer to an 977 external document defining the structure. The specification SHOULD 978 NOT define or describe the structure, as discussed above in Section 979 2.1.3. 981 A.2. Improper Data Types 983 All data types other than the ones described above in Section A.1 984 SHOULD NOT be used. This section describes in detail a number of 985 data types that are NOT RECOMMENDED in new RADIUS specifications. 986 Where possible, replacement data types are suggested. 988 A.2.1. Simple Data Types 990 Does the attribute use any of the following data types? If so, the 991 data type SHOULD be replaced with the suggested alternatives, or 992 SHOULD NOT be used at all. 994 * Signed integers of any size. 995 SHOULD NOT be used. SHOULD be replaced with one or more 996 unsigned integer attributes. The definition of the attribute 997 can contain information that would otherwise go into the sign 998 value of the integer. 999 * 8 bit unsigned integers. 1000 SHOULD be replaced with 32-bit unsigned integer. There is 1001 insufficient justification to save three bytes. 1002 * 16 bit unsigned integers. 1003 SHOULD be replaced with 32-bit unsigned integer. There is 1004 insufficient justification to save two bytes. 1005 * Unsigned integers of size other than 32 or 64. 1006 SHOULD be replaced by an unsigned integer of 32 or 64 bits. 1007 There is insufficient justification to define a new size of 1008 integer. 1010 * Integers of any size in non-network byte order 1011 SHOULD be replaced by unsigned integer of 32 or 64 bits, 1012 in network byte order. There is no reason to transport integers 1013 in any format other than network byte order. 1014 * Tagged data types as described in [RFC2868]. 1015 These data types SHOULD NOT be used in new specifications. The 1016 attribute grouping method defined in [EXTEN] SHOULD be used 1017 instead. 1018 * Complex data structures defined only within RADIUS. 1019 The additional functionality defined in [EXTEN] SHOULD be used 1020 instead. This recommendation does not apply to new attributes 1021 for authentication or security, as described below in Section 1022 A.2.2. 1023 * Multi-field text strings. 1024 Each field SHOULD be encapsulated in a separate attribute. 1025 Where grouping of fields is desired, the additional 1026 functionality defined in [EXTEN] SHOULD be used instead. 1027 * Polymorphic attributes. 1028 Multiple attributes, each with a static data type SHOULD be 1029 defined instead. 1031 A.2.2. Complex Data Types 1033 Does the attribute define a complex data type for purposes other than 1034 authentication or security? If so, this data type SHOULD be replaced 1035 with simpler types, as discussed above in Section A.2.1. Also see 1036 Section 2.1.3 for a discussion of why complex types are problematic. 1038 A.3. Vendor-Specific formats 1040 Does the specification contain Vendor-Specific attributes that match 1041 any of the following criteria? If so, the data type should be 1042 replaced with the suggested alternatives, or should not be used at 1043 all. 1045 * Vendor types of more than 16 bits. 1046 SHOULD NOT be used. Vendor types of 8 or 16 bits SHOULD be used 1047 instead. 1048 * Vendor lengths of less than 8 bits. (i.e., zero bits) 1049 SHOULD NOT be used. Vendor types of 8 or 16 bits SHOULD be used 1050 instead. 1051 * Vendor lengths of more than 8 bits. 1052 SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used 1053 instead. 1054 * Vendor-Specific contents that are not in Type-Length-Value 1055 format. 1056 SHOULD NOT be used. Vendor-Specific attributes SHOULD be in 1057 Type-Length-Value format. 1059 We recognize that SDOs may require more than 256 attributes, which is 1060 the limit of the 8-bit [RFC2865] Vendor-Specific space. Those SDOs 1061 SHOULD use Vendor types of 16 bits. However, SDOs SHOULD NOT use 1062 Vendor types of 16 bits unless there are immediate requirements. 1063 Future-proofing a specification is insufficient grounds for using 1064 16-bit Vendor types. 1066 In general, Vendor-Specific attributes SHOULD follow the [RFC2865] 1067 suggested format, or the [EXTEN] format if more functionality, or a 1068 larger attribute space is necessary. 1070 A.4. New functionality in RADIUS. 1072 Does the specification extend RADIUS by adding new functionality, as 1073 outlined in the list below? If so, it SHOULD NOT use RADIUS. 1074 Another method of achieving the design objectives SHOULD be used. 1076 * Defining new commands in RADIUS using attributes. 1077 This restriction includes new commands created by overloading 1078 the Service-Type attribute to define new values that modify 1079 the functionality of Access-Request packets. 1080 * Using RADIUS as a transport protocol for non-AAA data. 1081 This restriction is partially a subset of the previous one. 1082 Note that using RADIUS to transport authentication methods 1083 (e.g., EAP) is explicitly permitted, even if those methods 1084 require the transport of relatively large amounts of data. 1085 * Extending the RADIUS packet length limitation past 4096 octets. 1086 A multi-packet sequence of Access-Request / Access-Challenge 1087 SHOULD be used instead. If that is not possible, then a method 1088 other than RADIUS SHOULD be used to transport the data. 1090 A.5. Allocation of attributes 1092 Does the attribute have a limited scope of applicability, as outlined 1093 below? If so, then the attributes SHOULD be allocated from the 1094 Vendor-Specific space. 1096 * attributes intended for a vendor to support their own systems, 1097 and not suitable for general usage 1098 * attributes relying on data types not defined within RADIUS 1099 * attributes intended primarily for use within an SDO 1100 * attributes intended primarily for use within a group of SDOs. 1102 Note that the points listed above do not relax the recommendations 1103 discussed in this document. Instead, they recognize that the RADIUS 1104 data model has limitations. In certain situations where 1105 interoperability can be strongly constrained, a data model extended 1106 by the SDO or vendor MAY be used. We recommend, however, that the 1107 RADIUS data model SHOULD be used, even if it is marginally less 1108 efficient than alternatives. 1110 Appendix B - Complex Attributes 1112 This section summarizes RADIUS attributes with complex data types 1113 that are defined in existing RFCs. 1115 B.1. CHAP-Password 1117 [RFC2865] Section 5.3 defines the CHAP-Password Attribute which is 1118 sent from the RADIUS client to the RADIUS server in an Access- 1119 Request. The the data type of the CHAP Identifier is not given, only 1120 the one octet length: 1122 0 1 2 1123 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 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1125 | Type | Length | CHAP Ident | String ... 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1128 Since this is an authentication attribute, code changes are required 1129 on the RADIUS client and server to support it, regardless of the 1130 attribute format. Therefore, this complex data type is acceptable in 1131 this situation. 1133 B.2. CHAP-Challenge 1135 [RFC2865] Section 5.40 defines the CHAP-Challenge Attribute which is 1136 sent from the RADIUS client to the RADIUS server in an Access- 1137 Request. While the data type of the CHAP Identifier is given, the 1138 text also says 1140 If the CHAP challenge value is 16 octets long it MAY be placed in 1141 the Request Authenticator field instead of using this attribute. 1143 Defining attributes to contain values taken from the RADIUS packet 1144 header is NOT RECOMMENDED. Attributes should have values that are 1145 packed into a RADIUS AVP. 1147 B.3. Tunnel-Password 1149 [RFC2868] Section 3.5 defines the Tunnel-Password Attribute, which is 1150 sent from the RADIUS server to the client in an Access-Accept. This 1151 attribute includes Tag and Salt fields, as well as a string field 1152 which consists of three logical sub-fields: the Data-Length (one 1153 octet) and Password sub-fields (both of which are required), and the 1154 optional Padding sub-field. The attribute appears as follows: 1156 0 1 2 3 1157 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 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 | Type | Length | Tag | Salt 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 Salt (cont) | String ... 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 Since this is a security attribute and is encrypted, code changes are 1166 required on the RADIUS client and server to support it, regardless of 1167 the attribute format. Therefore, this complex data type is 1168 acceptable in this situation. 1170 B.4. ARAP-Password 1172 [RFC2869] Section 5.4 defines the ARAP-Password attribute, which is 1173 sent from the RADIUS client to the server in an Access-Request. It 1174 contains four 4 octet values, instead of having a single Value field: 1176 0 1 2 3 1177 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 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 | Type | Length | Value1 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | Value2 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | Value3 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | Value4 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 As with the CHAP-Password attribute, this is an authentication 1191 attribute which would have required code changes on the RADIUS client 1192 and server regardless of format. 1194 B.5. ARAP-Features 1196 [RFC2869] Section 5.5 defines the ARAP-Features Attribute, which is 1197 sent from the RADIUS server to the client in an Access-Accept or 1198 Access-Challenge. It contains a compound string of two single octet 1199 values, plus three 4-octet values, which the RADIUS client 1200 encapsulates in a feature flags packet in the ARAP protocol: 1202 0 1 2 3 1203 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 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 | Type | Length | Value1 | Value2 | 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 | Value3 | 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 | Value4 | 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1211 | Value5 | 1212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 Unlike the previous attributes, this attribute contains no encrypted 1215 component, nor is it directly involved in authentication. The 1216 individual sub-fields therefore could have been encapsulated in 1217 separate attributes. 1219 B.6. Connect-Info 1221 [RFC2869] Section 5.11 defines the Connect-Info attribute, which is 1222 used to indicate the nature of the connection. 1224 0 1 2 1225 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 | Type | Length | Text... 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 Even though the type is Text, the rest of the description indicates 1231 that it is a complex attribute: 1233 The Text field consists of UTF-8 encoded 10646 [8] characters. 1234 The connection speed SHOULD be included at the beginning of the 1235 first Connect-Info attribute in the packet. If the transmit and 1236 receive connection speeds differ, they may both be included in the 1237 first attribute with the transmit speed first (the speed the NAS 1238 modem transmits at), a slash (/), the receive speed, then 1239 optionally other information. 1240 For example, "28800 V42BIS/LAPM" or "52000/31200 V90" 1242 More than one Connect-Info attribute may be present in an 1243 Accounting-Request packet to accommodate expected efforts by ITU 1244 to have modems report more connection information in a standard 1245 format that might exceed 252 octets. 1247 This attribute contains no encrypted component, and is it not 1248 directly involved in authentication. The individual sub-fields could 1249 therefore have been encapsulated in separate attributes. 1251 B.7. Framed-IPv6-Prefix 1253 [RFC3162] Section 2.3 defines the Framed-IPv6-Prefix Attribute and 1254 [RFC4818] Section 3 reuses this format for the Delegated-IPv6-Prefix 1255 Attribute; these attributes are sent from the RADIUS server to the 1256 client in an Access-Accept. 1258 0 1 2 3 1259 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 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | Type | Length | Reserved | Prefix-Length | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 Prefix 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 Prefix 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 Prefix 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 Prefix | 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 The sub-fields encoded in these attributes are strongly related, and 1273 there was no previous definition of this data structure that could be 1274 referenced. Support for this attribute requires code changes on both 1275 the client and server, due to a new data type being defined. In this 1276 case it appears to be acceptable to encode them in one attribute. 1278 B.8. Egress-VLANID 1280 [RFC4675] Section 2.1 defines the Egress-VLANID Attribute which can 1281 be sent by a RADIUS client or server. 1283 0 1 2 3 1284 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 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 | Type | Length | Value 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 Value (cont) | 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 While it appears superficially to be of type Integer, the Value field 1292 is actually a packed structure, as follows: 1294 0 1 2 3 1295 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 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 | Tag Indic. | Pad | VLANID | 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 The length of the VLANID field is defined by the [IEEE-802.1Q] 1301 specification. The Tag indicator field is either 0x31 or 0x32, for 1302 compatibility with the Egress-VLAN-Name, as discussed below. The 1303 complex structure of Egress-VLANID overlaps with that of the base 1304 Integer data type, meaning that no code changes are required for a 1305 RADIUS server to support this attribute. Code changes are required 1306 on the NAS, if only to implement the VLAN ID enforcement. 1308 Given the IEEE VLAN requirements and the limited data model of 1309 RADIUS, the chosen method is likely the best of the possible 1310 alternatives. Future specifications that attempt to obtain similar 1311 functionality SHOULD use the extended types from [EXTEN]. 1313 B.9. Egress-VLAN-Name 1315 [RFC4675] Section 2.3 defines the Egress-VLAN-Name Attribute which 1316 can be sent by a RADIUS client or server. 1318 0 1 2 3 1319 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 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 | Type | Length | Tag Indic. | String... 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 The Tag Indicator is either the character '1' or '2', which in ASCII 1325 map to the identical values for Tag Indicator in Egress-VLANID, 1326 above. The complex structure of this attribute is acceptable for 1327 reasons identical to those given for Egress-VLANID. Future 1328 specifications that attempt to obtain similar functionality SHOULD 1329 use the extended types from [EXTEN]. 1331 Acknowledgments 1333 We would like to acknowledge David Nelson, Bernard Aboba, Emile van 1334 Bergen, Barney Wolff and Glen Zorn for contributions to this 1335 document. 1337 Authors' Addresses 1339 Greg Weber 1340 Knoxville, TN 37932 1341 USA 1343 Email: gdweber@gmail.com 1345 Alan DeKok 1346 The FreeRADIUS Server Project 1347 http://freeradius.org/ 1349 Email: aland@freeradius.org 1351 Full Copyright Statement 1353 Copyright (C) The IETF Trust (2007). 1355 This document is subject to the rights, licenses and restrictions 1356 contained in BCP 78, and except as set forth therein, the authors 1357 retain all their rights. 1359 This document and the information contained herein are provided on an 1360 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1361 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1362 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1363 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1364 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1365 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1367 Intellectual Property 1369 The IETF takes no position regarding the validity or scope of any 1370 Intellectual Property Rights or other rights that might be claimed to 1371 pertain to the implementation or use of the technology described in 1372 this document or the extent to which any license under such rights 1373 might or might not be available; nor does it represent that it has 1374 made any independent effort to identify any such rights. Information 1375 on the procedures with respect to rights in RFC documents can be 1376 found in BCP 78 and BCP 79. 1378 Copies of IPR disclosures made to the IETF Secretariat and any 1379 assurances of licenses to be made available, or the result of an 1380 attempt made to obtain a general license or permission for the use of 1381 such proprietary rights by implementers or users of this 1382 specification can be obtained from the IETF on-line IPR repository at 1383 http://www.ietf.org/ipr. 1385 The IETF invites any interested party to bring to its attention any 1386 copyrights, patents or patent applications, or other proprietary 1387 rights that may cover technology that may be required to implement 1388 this standard. Please address the information to the IETF at ietf- 1389 ipr@ietf.org. 1391 Acknowledgment 1393 Funding for the RFC Editor function is provided by the IETF 1394 Administrative Support Activity (IASA). 1396 Open issues 1398 Open issues relating to this document are tracked on the following 1399 web site: 1401 http://www.drizzle.com/~aboba/RADEXT/