idnits 2.17.1 draft-ietf-radext-design-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 915. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 926. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 933. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 939. 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This Attribute is available to allow vendors to support their own extended Attributes not suitable for general usage. It MUST not affect the operation of the RADIUS protocol. -- 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 (4 September 2007) is 6076 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '8' on line 785 ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Weber 3 INTERNET-DRAFT Cisco Systems 4 Category: Standards Track Alan DeKok (ed.) 5 FreeRADIUS 6 Expires: March 4, 2008 8 4 September 2007 10 RADIUS Design Guidelines 11 draft-ietf-radext-design-00.txt 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 25, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document provides guidelines for the design of attributes used 43 by the Remote Authentication Dial In User Service (RADIUS) protocol. 44 It is expected that these guidelines will prove useful to authors and 45 reviewers of future RADIUS attribute specifications, both within the 46 IETF as well as other Standards Development Organizations (SDOs). 48 Table of Contents 50 1. Introduction ............................................. 3 51 1.1. Applicability ....................................... 3 52 1.2. Terminology ......................................... 4 53 1.3. Requirements Language ............................... 4 54 2. RADIUS Data Model ........................................ 4 55 2.1. Standard Space ...................................... 5 56 2.1.1. Basic Data Types ............................... 5 57 2.1.2. Tagging Mechanism .............................. 6 58 2.1.3. Complex Attribute Usage ........................ 6 59 2.2. Vendor Space ........................................ 8 60 3. Data Model Issues ........................................ 10 61 3.1. Vendor Space ........................................ 10 62 3.2. Polymorphic Attributes .............................. 12 63 4. IANA Considerations ...................................... 13 64 5. Security Considerations .................................. 13 65 6. References ............................................... 13 66 6.1. Normative References ................................ 13 67 6.2. Informative References .............................. 14 68 Full Copyright Statement ..................................... 21 69 1. Introduction 71 This document provides guidelines for the design of RADIUS attributes 72 both within the IETF as well as within other Standards Development 73 Organizations (SDOs). 75 As with "Guidelines for Authors and Reviewers of MIB Documents" 76 [RFC4181], it is expected that this document will enable authors to 77 check their document against the guidelines prior to requesting a 78 review (such an "Expert Review" described in [RFC3575]). Similarly, 79 it is hoped that this document will be of use to reviewers (such as 80 WG participants or the AAA Doctors) in improving the consistency of 81 reviews. 83 In order to meet these objectives, this document needs to cover not 84 only the science of attribute design, but also the art. As a result, 85 in addition to covering the most frequently encountered issues, this 86 document attempts to provide some of the considerations motivating 87 the guidelines. 89 In order to characterize current attribute usage, both the basic and 90 complex data types defined in the existing RADIUS RFCs are reviewed, 91 together with the ad-hoc extensions to that data model that have been 92 used in Vendor Specific Attributes (VSAs). In addition, 93 recommendations are made with respect to recommended VSA formats as 94 well as handling of RADIUS type 26 attributes within Diameter. 96 1.1. Applicability 98 The major goal of this document is to encourage the development and 99 publication of high quality RADIUS attribute specifications. By 100 articulating RADIUS design guidelines, it is hoped that this document 101 will be a step in that direction. However, the advice in this 102 document will not be helpful unless it is put to use. In particular, 103 the authors recommend: 105 o Development of a program to encourage SDOs to make their RADIUS 106 attribute specifications publicly available; 108 o Review of IETF and SDO specifications according to the 109 guidelines proposed in this document; 111 The advice in this document applies to attributes used to encode 112 data. RADIUS protocol changes, or specification of attributes that 113 can be used to provide new RADIUS commands (such as Service-Type) are 114 out of scope. Since protocol changes require greater expertise and 115 deeper review, such changes should not be undertaken outside the IETF 116 and when handled within the IETF require "IETF Consensus" for 117 adoption, as noted in [RFC3575] Section 2.1. 119 As with protocol changes, this document does not provide guidance to 120 document authors seeking to change the RADIUS operational model. 121 While RADIUS server implementations may keep state, the RADIUS 122 protocol is stateless, although information may be passed from one 123 protocol transaction to another via the State Attribute. As a 124 result, documents which require stateful protocol behavior without 125 use of the State Attribute are inherently incompatible with RADIUS as 126 defined in [RFC2865], and need to be redesigned. 128 See [FIXES] Section 2.1.1 for a more in-depth discussion of the use 129 of the State Attribute. 131 1.2. Terminology 133 This document uses the following terms: 135 Network Access Server (NAS) 136 A device that provides an access service for a user to a network. 138 RADIUS server 139 A RADIUS authentication server is an entity that provides an 140 authentication service to a NAS. 142 RADIUS proxy 143 A RADIUS proxy acts as an authentication server to the NAS, and a 144 RADIUS client to the RADIUS server. 146 1.3. Requirements Language 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC2119]. 152 2. RADIUS Data Model 154 The Remote Authentication Dial In User Service (RADIUS) defined in 155 [RFC2865] [RFC2866] utilizes elements known as attributes, in order 156 to represent authentication, authorization and accounting (AAA) data. 158 Unlike SNMP, first defined in [RFC1157] [RFC1155], RADIUS does not 159 define a formal data definition language. A handful of basic data 160 types are provided, and a data type is associated with an attribute 161 when that attribute is defined. 163 Two distinct attribute spaces are defined: the standard space, and a 164 vendor specific space. Attributes in the standard space generally 165 are composed of a type, length, value (TLV) triplet, although complex 166 attributes have also been defined. The vendor specific space is 167 encapsulated within a single attribute type (Vendor-Specific 168 Attribute or VSA). The format of this space is defined by individual 169 vendors, but the same TLV encoding used by the standard space is 170 recommended in [RFC2865] Section 5.26. The similarity between 171 attribute formats has enabled implementations to leverage common 172 parsing functionality, although in some cases the attributes in the 173 vendor specific space have begun to diverge from the common format. 175 2.1. Standard Space 177 The following subsections describe common data types and formats 178 within the RADIUS standard attribute space. Common exceptions are 179 identified. 181 2.1.1. Basic Data Types 183 The data type of RADIUS attributes is not transported on the wire. 184 Rather, the data type of a RADIUS attribute is fixed when that 185 attribute is defined. Based on the RADIUS attribute type code, 186 RADIUS clients and servers can determine the data type based on pre- 187 configured entries within a data dictionary. 189 RFC 2865 [RFC2865] defines the following data types: 191 text 1-253 octets containing UTF-8 encoded 10646 [RFC3629] 192 characters. Text of length zero (0) MUST NOT be sent; 193 omit the entire attribute instead. 194 string 1-253 octets containing binary data (values 0 through 195 255 decimal, inclusive). Strings of length zero (0) 196 MUST NOT be sent; omit the entire attribute instead. 197 IPv4 address 32 bit value, most significant octet first. 198 integer 32 bit unsigned value, most significant octet first. 199 time 32 bit unsigned value, most significant octet first 200 -- seconds since 00:00:00 UTC, January 1, 1970. 202 In addition to these data types, follow-on RADIUS specifications 203 define attributes using the following additional types: 205 IPv6 address 128 bit value, most significant octet first. 206 IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to 207 128 bits of value, most significant octet first. 208 integer64 64 bit unsigned value, most significant octet first. 210 Examples of the IPv6 address type include NAS-IPv6-Address defined in 211 [RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162] 212 Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3, 213 and in [RFC4818] Section 3. The integer64 type is used for the ARAP- 214 Challenge-Response Attribute defined in [RFC2869] Section 5.15, and 215 the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2. 216 [RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in 217 length, but denotes it as type "String". 219 Given that attributes of type IPv6 address, IPv6 prefix, and 220 integer64 are already in use, it is RECOMMENDED that RADIUS server 221 implementations include support for these additional basic types, in 222 addition to the types defined in [RFC2865]. 224 It is worth noting that since RADIUS only supports unsigned integers 225 of 32 or 64 bits, attributes utilizing signed integer data types or 226 unsigned integer types of other sizes will require code changes, and 227 SHOULD be avoided. 229 2.1.2. Tagging Mechanism 231 [RFC2868] defines an attribute grouping mechanism based on the use of 232 a one octet tag value. Tunnel attributes that refer to the same 233 tunnel are grouped together by virtue of using the same tag value. 235 This tagging mechanism has some drawbacks. There are a limited 236 number of unique tags (31). The tags are not well suited for use 237 with arbitrary binary data values because it is not always possible 238 to tell if the first byte after the Length is the tag or the first 239 byte of the untagged value (assuming the tag is optional). 241 When integer values are tagged, the value portion is reduced to three 242 bytes meaning only 24-bit numbers can be represented. 244 The tagging mechanism does not offer an ability to create nested 245 groups of attributes. 247 Some RADIUS implementations treat tagged attributes as an additional 248 data type. 250 2.1.3. Complex Attribute Usage 252 The RADIUS attribute encoding is summarized in [RFC2865]: 254 0 1 2 255 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 257 | Type | Length | Value ... 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 260 However, some standard attributes do not follow this format. 262 Attributes that utilize sub-fields instead of utilizing a basic data 263 type are known as "complex attributes". As described below, 264 definition of complex attributes can lead to interoperability and 265 deployment issues, so that they need to introduced with care. 267 In general, complex attributes sent from the RADIUS server to the 268 client can be supported by concatenating the values into a String 269 data type field. However, separating these values into different 270 attributes, each with its own type and length, would make it easier 271 for the user to enter the data, would enable additional error 272 checking and would simplify implementations by eliminating special 273 case, attribute specific parsing. 275 One of the fundamental goals of the RADIUS protocol design was to 276 allow RADIUS servers to be configured to support new attributes 277 without requiring server code changes. RADIUS server implementations 278 typically utilize a data dictionary providing support for basic data 279 types, enabling a new attribute to be supported by addition of a 280 dictionary entry, without requiring RADIUS server code changes. 282 On the RADIUS client, code changes are typically required in order to 283 implement a new attribute, since the RADIUS client typically has to 284 compose the attribute dynamically when sending. When receiving, a 285 RADIUS client needs to be able to parse the attribute and carry out 286 the requested service, so that a detailed understanding of the new 287 attribute is required. 289 Given this, the introduction of a new basic or complex attribute will 290 typically require code changes on the RADIUS client, although the 291 magnitude of changes for the complex attribute could be greater, due 292 to the potential need for custom parsing logic. 294 However, the RADIUS server can be configured to send a new attribute 295 by entering its type and data format in the RADIUS server dictionary, 296 then filling in the value within a form based on the data type. For 297 complex attribute types not supported by RADIUS server dictionaries, 298 changes to the dictionary and forms code can be required in order to 299 allow the new attribute to be supported and configured by the RADIUS 300 server. 302 Code changes can also be required in the RADIUS server's receive 303 path, due to limitations in RADIUS server policy languages, which 304 typically only provide for limited operations (such as comparisons or 305 arithmetic operations) on the basic data types. Most existing RADIUS 306 policy languages typically are not capable of parsing sub-elements, 307 or providing sophisticated matching functionality. 309 Given these limitations, the introduction of complex attributes can 310 require code changes on the RADIUS server which would be unnecessary 311 if basic data types were used instead. In addition, attribute- 312 specific parsing means more complex software to develop and maintain, 313 and more complexity can lead to more error prone implementations. 314 This can increase costs to network administrators as well as reducing 315 reliability and introducing deployment barriers. As a result, the 316 introduction of new complex data types within RADIUS attribute 317 specifications SHOULD be avoided. 319 The exception to this recommendation are attributes which can be 320 treated as opaque data, such as the EAP-Message attribute, defined in 321 [RFC3579] Section 3.1. Since these attributes do not need to be 322 parsed by the RADIUS server, the issues arising from policy language 323 limitations do not arise. Similarly, since these attributes can be 324 configured on the server using a data type of String, dictionary 325 limitations are also not encountered. 327 An examination of existing RADIUS RFCs discloses a number of complex 328 attributes that have already been defined. Appendix A includes a 329 listing of complex attributes utilized within [RFC2865], [RFC2868], 330 [RFC2869], [RFC3162], [RFC4818], and [RFC4675]. 332 As can be seen in Appendix A, in most cases complex attributes 333 involve authentication or security functionality that requires code 334 changes on both the RADIUS client and server, regardless of the 335 attribute format. As a result, in most cases the use of complex 336 attributes did not create additional interoperability or deployment 337 issues. 339 In other cases the data are described textually. This is possible 340 because the data types are not sent within the attributes, but are a 341 matter for endpoint interpretation. An implementation can define 342 additional data types (e.g. IPv6 address), and use these data types 343 today by matching them to the attribute's textual description. 345 2.2. Vendor Space 347 As noted in [RFC2865] Section 5.26, the VSA format is defined as 348 follows: 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Type | Length | Vendor-Id 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 Vendor-Id (cont) | String... 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 357 The high-order octet of the Vendor-Id field is 0 and the low-order 3 358 octets are the SMI Network Management Private Enterprise Code of the 359 Vendor in network byte order. 361 While the format of the String field is defined by the vendor, 362 [RFC2865] Section 5.26 notes: 364 It SHOULD be encoded as a sequence of vendor type / vendor length 365 / value fields, as follows. The Attribute-Specific field is 366 dependent on the vendor's definition of that attribute. An 367 example encoding of the Vendor-Specific attribute using this 368 method follows: 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Type | Length | Vendor-Id 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 Vendor-Id (cont) | Vendor type | Vendor length | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Attribute-Specific... 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 380 Multiple sub-attributes MAY be encoded within a single Vendor- 381 Specific attribute, although they do not have to be. 383 Note that the Vendor type field in the recommended format, like the 384 RADIUS type field, is only a single octet. While this results in an 385 efficient encoding, there are situations in which a vendor or SDO 386 will eventually wish to define more than 255 attributes. Also, an 387 SDO can be comprised of multiple subgroups, each of whom can desire 388 autonomy over the definition of attributes within their group. In 389 such a situation, a 16-bit Vendor type field would be more 390 appropriate: 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Type | Length | Vendor-Id 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Vendor-Id (cont) | Vendor type | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Vendor length | Attribute-Specific... 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 Other attribute formats are NOT RECOMMENDED. Examples of NOT 402 RECOMMENDED formats include Vendor types of more than 16 bits, Vendor 403 lengths of less than 8 bits, Vendor lengths of more than 8 bits, and 404 Vendor-Specific contents that are not in Type-Length-Value format. 406 3. Data Model Issues 408 Since the closure of the RADIUS Working Group, the popularity and 409 prevalence of RADIUS has continued to grow. In addition to 410 increasing demand for allocation of attributes within the RADIUS 411 standard attribute space, the number of vendors and SDOs creating new 412 attributes within the vendor-specific attribute space has grown, and 413 this has lead to some divergence in approaches to RADIUS attribute 414 design. 416 In general, standard RADIUS attributes have a more constrained data 417 model than attributes within the vendor space. For example, vendors 418 have evolved the data model to support new functions such as 419 attribute grouping and attribute fragmentation, with different 420 vendors taking different approaches. 422 Given these enhancements, it has become difficult for vendors or SDOs 423 to translate attributes from the vendor space to the more stringent 424 standards space. For example, a vendor-specific attribute utilizing 425 sub-elements could require allocation of several standard space 426 attributes utilizing basic data types. In this case not only would 427 translation require substantial additional work, it would further 428 deplete the RADIUS standard attribute space. Given these 429 limitations, translation of vendor attributes to the standards space 430 is not necessarily desirable, particularly if the VSA specification 431 is publicly available and can be implemented within existing RADIUS 432 clients and servers. In such situations the costs may substantially 433 outweigh the benefits. While it is possible that some of the 434 enhancements made within the vendor space may eventually become 435 available within the standard attribute space, the divergence of the 436 standard and vendor attribute spaces is most likely a permanent 437 feature, and should be recognized as such. 439 For future work, any extensions to the RADIUS data model should be 440 used to minimize the use of complex attributes. 442 3.1. Vendor Space 444 The usage model for RADIUS VSAs is described in [RFC2865] Section 445 6.2: 447 Note that RADIUS defines a mechanism for Vendor-Specific 448 extensions (Attribute 26) and the use of that should be encouraged 449 instead of allocation of global attribute types, for functions 450 specific only to one vendor's implementation of RADIUS, where no 451 interoperability is deemed useful. 453 Nevertheless, many new attributes have been defined in the vendor 454 specific space in situations where interoperability is not only 455 useful, but is required. For example, Standards Development 456 Organizations (SDOs) outside the IETF (such as the IEEE 802 and the 457 3rd Generation Partnership Project (3GPP)) have been assigned Vendor- 458 Ids, enabling them to define their own VSA format and assign Vendor 459 types within their own space. 461 The utilization of VSAs by SDOs outside the IETF has gained in 462 popularity for several reasons: 464 Efficiency 465 As with SNMP, which defines an "Enterprise" Object Identifier (OID) 466 space suitable for use by vendors as well as other SDOs, the 467 definition of RADIUS attributes has become a common occurrence as 468 part of standards activity outside the IETF. For reasons of 469 efficiency, it is easiest for RADIUS attributes required to manage 470 a standard to be developed within the same SDO that develops the 471 standard itself. As noted in "Transferring MIB Work from IETF 472 Bridge MIB WG to IEEE 802.1 WG" [RFC4663], today few vendors are 473 willing to simultaneously fund individuals to participate within an 474 SDO to complete a standard, as well as to participate in IETF in 475 order to complete the associated RADIUS attributes specification. 477 Attribute scarcity 478 The standard RADIUS attribute space is limited to approximately 250 479 unique attributes; of these, only about half remain available for 480 allocation. In the vendor specific space, the number of attributes 481 available is a function of the format of the attribute (the size of 482 the type field). 484 Along with these advantages, some limitations of VSA usage are noted 485 in [RFC2865] Section 5.26: 487 This Attribute is available to allow vendors to support their own 488 extended Attributes not suitable for general usage. It MUST not 489 affect the operation of the RADIUS protocol. 491 Servers not equipped to interpret the vendor-specific information 492 sent by a client MUST ignore it (although it may be reported). 493 Clients which do not receive desired vendor-specific information 494 SHOULD make an attempt to operate without it, although they may do 495 so (and report they are doing so) in a degraded mode. 497 The limitation on changes to the RADIUS protocol effectively 498 prohibits VSAs from changing fundamental aspects of RADIUS operation, 499 such as modifying RADIUS packet sequences, or adding new commands. 500 However, the requirement for clients and servers to be able to 501 operate in the absence of VSAs has proved less of a constraint, since 502 it is still possible for a RADIUS client and server to mutually 503 indicate support for VSAs, after which behavior expectations can be 504 reset. 506 Therefore, RFC 2865 provides considerable latitude for development of 507 new attributes within the vendor space, while prohibiting development 508 of protocol variants. This flexibility implies that RADIUS 509 attributes can often be developed within the vendor space without 510 loss (and possibly even gain) in functionality. 512 As a result, translation of RADIUS attributes developed within the 513 vendor space into the standard space may provide only modest 514 benefits, while accelerating the exhaustion of the standard attribute 515 space. Rather than expecting all RADIUS attribute specifications 516 requiring interoperability to be developed within the IETF and 517 expecting that they be allocated within the standards space, a more 518 scalable approach is to recognize the flexibility of the vendor space 519 while working toward improvements in the quality and availability of 520 RADIUS attribute specifications, regardless of where they are 521 developed. 523 In particular, it is RECOMMENDED that RADIUS Attribute specifications 524 allocate attributes from the vendor space, rather than requesting an 525 allocation from the RADIUS standard attribute space, for attributes 526 matching any of the following criteria: 527 * attributes relying on data types not defined within RADIUS * 528 attributes intended primarily for use within an SDO * attributes 529 intended primarily for use within a group of SDOs. 531 3.2. Polymorphic Attributes 533 A polymorphic attribute is one whose format is dynamic. For example, 534 rather than using a fixed data format, an attribute's format might 535 change based on the contents of another attribute. Or, the meaning 536 of an attribute may be dependent on earlier packets in a sequence. 538 Typically RADIUS server dictionary entries are static, enabling the 539 user to enter the contents of an attribute, without support for 540 changing the format based on dynamic conditions. However, this does 541 not prevent implementations from returning different attributes based 542 on the contents of received attributes; this is a common feature of 543 existing RADIUS implementations. 545 In general, polymorphism is NOT RECOMMENDED. Polymorphism rarely 546 enables capabilities that would not be available through use of 547 multiple attributes, while requiring code changes in the RADIUS 548 server in situations where attributes with fixed formats will not. 549 Thus, polymorphism increases complexity while decreasing generality, 550 without delivering any corresponding benefits. 552 Note that changing an attribute's format dynamically is not the same 553 thing as utilizing a fixed format and computing the attribute itself 554 dynamically. RADIUS authentication attributes such as User-Password, 555 EAP-Message, etc. while being computed dynamically, utilize a fixed 556 format. 558 4. IANA Considerations 560 This document defines the use of a RADIUS type 26 attribute code in 561 the Diameter Protocol space as defined in [RFC3588] and [RFC4005]. 563 5. Security Considerations 565 This specification provides guidelines for the design of RADIUS 566 attributes used in authentication, authorization and accounting. 567 Threats and security issues for this application are described in 568 [RFC3579] and [RFC3580]; security issues encountered in roaming are 569 described in [RFC2607]. 571 Encryption of RADIUS attributes on a per-attribute basis is necessary 572 in some cases. The current standard mechanism for this is described 573 in [RFC2865] Section 5.2 (for obscuring User-Password values) and is 574 based on the MD5 algorithm specified in [RFC1321]. The MD5 algorithm 575 has recently become a focus of scrutiny and concern in security 576 circles, and as a result, the use of this technique in new attributes 577 is NOT RECOMMENDED. 579 Where new RADIUS attributes utilize cryptographic algorithms, 580 algorithm negotiation SHOULD be supported. Specification of a 581 mandatory-to-implement algorithm is REQUIRED, and it is RECOMMENDED 582 that the mandatory-to-implement algorithm be certifiable under FIPS 583 140. 585 6. References 587 6.1. Normative References 589 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 590 Requirement Levels", BCP 14, RFC 2119, March 1997. 592 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 593 Authentication Dial In User Service (RADIUS)", RFC 2865, June 594 2000. 596 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 597 Authentication Dial In User Service)", RFC 3575, July 2003. 599 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 600 Network Access Server Application", RFC 4005, August 2005. 602 6.2. Informative References 604 [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of 605 management information for TCP/IP-based internets", STD 16, 606 RFC 1155, May 1990. 608 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 609 Network Management Protocol (SNMP)", STD 15, RFC 1157, May 610 1990. 612 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 613 April 1992. 615 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 616 Implementation in Roaming", RFC 2607, June 1999. 618 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 620 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., 621 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 622 Support", RFC 2868, June 2000. 624 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", 625 RFC 2869, June 2000. 627 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 628 3162, August 2001. 630 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 631 In User Service) Support For Extensible Authentication 632 Protocol (EAP)", RFC 3579, September 2003. 634 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE 635 802.1X Remote Authentication Dial In User Service (RADIUS) 636 Usage Guidelines", RFC3580, September 2003. 638 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 639 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 641 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 642 RFC 3629, November 2003. 644 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 645 Documents", RFC 4181, September 2005. 647 [RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge MIB WG 648 to IEEE 802.1 WG", RFC 4663, September 2006. 650 [RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for 651 Virtual LAN and Priority Support", RFC 4675, September 2006. 653 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 654 Attribute", RFC 4818, April 2007. 656 [FIXES] Nelson, D. and DeKok, A, "Common Remote Authentication Dial In 657 User Service (RADIUS) Implementation Issues and Suggested 658 Fixes", RFC XXXX, DATE YYYY 660 [IEEE-802.1Q] 661 IEEE Standards for Local and Metropolitan Area Networks: Draft 662 Standard for Virtual Bridged Local Area Networks, 663 P802.1Q-2003, January 2003. 665 Appendix A - Complex Attributes 667 This section summarizes RADIUS attributes with complex data types 668 that are defined with existing RFCs. 670 A.1 CHAP-Password 672 [RFC2865] Section 5.3 defines the CHAP-Password Attribute which is 673 sent from the RADIUS client to the RADIUS server in an Access- 674 Request. The the data type of the CHAP Identifier is not given, only 675 the one octet length: 677 0 1 2 678 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 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 680 | Type | Length | CHAP Ident | String ... 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 683 Since this is an authentication attribute, code changes would have 684 been required on the RADIUS client and server, regardless of the 685 attribute format. 687 A.2 CHAP-Challenge 689 [RFC2865] Section 5.40 defines the CHAP-Challenge Attribute which is 690 sent from the RADIUS client to the RADIUS server in an Access- 691 Request. While the data type of the CHAP Identifier is given, the 692 text also says 694 If the CHAP challenge value is 16 octets long it MAY be placed in 695 the Request Authenticator field instead of using this attribute. 697 Defining attributes to contain values taken from the RADIUS packet 698 header is NOT RECOMMENDED. Attributes should have values that are 699 packed into a RADIUS AVP. 701 A.3 Tunnel-Password 703 [RFC2868] Section 3.5 defines the Tunnel-Password Attribute, which is 704 sent from the RADIUS server to the client in an Access-Accept. This 705 attribute includes Tag and Salt fields, as well as a String field 706 which consists of three logical sub-fields: the Data-Length (one 707 octet) and Password sub-fields (both of which are required), and the 708 optional Padding sub-field. The attribute appears as follows: 710 0 1 2 3 711 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 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Type | Length | Tag | Salt 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 Salt (cont) | String ... 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 Given that the String field is encrypted, this attribute would have 719 required code changes on the RADIUS client and server, regardless of 720 the format. 722 A.4 ARAP-Password 724 [RFC2869] Section 5.4 defines the ARAP-Password attribute, which is 725 sent from the RADIUS client to the server in an Access-Request. It 726 contains four 4 octet values, instead of having a single Value field: 728 0 1 2 3 729 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 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Type | Length | Value1 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Value2 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Value3 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Value4 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 As with the CHAP-Password attribute, this is an authentication 743 attribute which would have required code changes on the RADIUS client 744 and server regardless of format. 746 A.5 ARAP-Features 748 [RFC2869] Section 5.5 defines the ARAP-Features Attribute, which is 749 sent from the RADIUS server to the client in an Access-Accept or 750 Access-Challenge. It contains a compound string of two single octet 751 values, plus three 4-octet values, which the RADIUS client 752 encapsulates in a feature flags packet in the ARAP protocol: 754 0 1 2 3 755 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 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Type | Length | Value1 | Value2 | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Value3 | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Value4 | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Value5 | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 Unlike previous attributes, this attribute contains no encrypted 767 component nor is it directly involved in authentication. The 768 individual sub-fields therefore could have been encapsulated in 769 separate attributes, although this would have required creation of an 770 8 bit data type. 772 A.6 Connect-Info 773 [RFC2869] Section 5.11 defines the Connect-Info attribute, which is 774 used to indicate the nature of the connection. 776 0 1 2 777 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Type | Length | Text... 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 Even though the type is Text, the rest of the description indicates 783 that it is a complex attribute: 785 The Text field consists of UTF-8 encoded 10646 [8] characters. 786 The connection speed SHOULD be included at the beginning of the 787 first Connect-Info attribute in the packet. If the transmit and 788 receive connection speeds differ, they may both be included in the 789 first attribute with the transmit speed first (the speed the NAS 790 modem transmits at), a slash (/), the receive speed, then 791 optionally other information. 792 For example, "28800 V42BIS/LAPM" or "52000/31200 V90" 794 More than one Connect-Info attribute may be present in an 795 Accounting-Request packet to accommodate expected efforts by ITU 796 to have modems report more connection information in a standard 797 format that might exceed 252 octets. 799 This attribute contains no encrypted component nor is it directly 800 involved in authentication. The individual sub-fields therefore 801 could have been encapsulated in separate attributes 803 A.7 Framed-IPv6-Prefix 805 [RFC3162] Section 2.3 defines the Framed-IPv6-Prefix Attribute and 806 [RFC4818] Section 3 reuses this format for the Delegated-IPv6-Prefix 807 Attribute; these attributes are sent from the RADIUS server to the 808 client in an Access-Accept. 810 0 1 2 3 811 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 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Type | Length | Reserved | Prefix-Length | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 Prefix 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 Prefix 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 Prefix 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 Prefix | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 The sub-fields encoded in these attributes are strongly related, and 825 there was no previous definition of this data structure that could be 826 referenced. Support for this attribute requires code changes on both 827 the client and server, due to a new data type being defined. In this 828 case it appears to be acceptable to encode them in one attribute. 830 A.8 Egress-VLANID 832 [RFC4675] Section 2.1 defines the Egress-VLANID Attribute which can 833 be sent by a RADIUS client or server. 835 0 1 2 3 836 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 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | Type | Length | Value 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 Value (cont) | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 While it appears superficially to be of type Integer, the Value field 844 is actually a packed structure, as follows: 846 0 1 2 3 847 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 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Tag Indic. | Pad | VLANID | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 The length of the VLANID field is defined by the [IEEE-802.1Q] 853 specification. The Tag indicator field is either 0x31 or 0x32, for 854 compatibility with the Egress-VLAN-Name, as discussed below. The 855 complex structure of Egress-VLANID overlaps with that of the base 856 Integer data type, meaning that no code changes are required for a 857 RADIUS server to support this attribute. Code changes are required 858 on the NAS, if only to implement the VLAN ID enforcement. 860 Given the IEEE VLAN requirements and the limited data model of 861 RADIUS, the chosen method is likely the best of the possible 862 alternatives. 864 A.9 Egress-VLAN-Name 866 [RFC4675] Section 2.3 defines the Egress-VLAN-Name Attribute which 867 can be sent by a RADIUS client or server. 869 0 1 2 3 870 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 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Type | Length | Tag Indic. | String... 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 The Tag Indicator is either the character '1' or '2', which in ASCII 875 map to the identical values for Tag Indicator in Egress-VLANID, 876 above. The complex structure of this attribute is acceptable for 877 reasons identical to those given for Egress-VLANID. 879 Acknowledgments 881 We would like to acknowledge David Nelson, Bernard Aboba, Emile van 882 Bergen, Barney Wolff and Glen Zorn for contributions to this 883 document. 885 Authors' Addresses 887 Greg Weber 888 Cisco Systems 889 10850 Murdock Road 890 Knoxville, TN 37932 891 USA 893 Email: gdweber@cisco.com 895 Alan DeKok 896 The FreeRADIUS Server Project 897 http://freeradius.org/ 899 Email: aland@freeradius.org 901 Full Copyright Statement 903 Copyright (C) The IETF Trust (2007). 905 This document is subject to the rights, licenses and restrictions 906 contained in BCP 78, and except as set forth therein, the authors 907 retain all their rights. 909 This document and the information contained herein are provided on an 910 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 911 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 912 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 913 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 914 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 915 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 917 Intellectual Property 919 The IETF takes no position regarding the validity or scope of any 920 Intellectual Property Rights or other rights that might be claimed to 921 pertain to the implementation or use of the technology described in 922 this document or the extent to which any license under such rights 923 might or might not be available; nor does it represent that it has 924 made any independent effort to identify any such rights. Information 925 on the procedures with respect to rights in RFC documents can be 926 found in BCP 78 and BCP 79. 928 Copies of IPR disclosures made to the IETF Secretariat and any 929 assurances of licenses to be made available, or the result of an 930 attempt made to obtain a general license or permission for the use of 931 such proprietary rights by implementers or users of this 932 specification can be obtained from the IETF on-line IPR repository at 933 http://www.ietf.org/ipr. 935 The IETF invites any interested party to bring to its attention any 936 copyrights, patents or patent applications, or other proprietary 937 rights that may cover technology that may be required to implement 938 this standard. Please address the information to the IETF at ietf- 939 ipr@ietf.org. 941 Acknowledgment 943 Funding for the RFC Editor function is provided by the IETF 944 Administrative Support Activity (IASA). 946 Open issues 948 Open issues relating to this document are tracked on the following 949 web site: 951 http://www.drizzle.com/~aboba/RADEXT/