idnits 2.17.1 draft-ietf-radext-design-01.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 1322. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1333. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1340. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1346. 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 (15 November 2007) is 6006 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 1191 == Unused Reference: 'RFC4005' is defined on line 795, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) == Outdated reference: A later version (-09) exists of draft-ietf-radext-extended-attributes-00 Summary: 2 errors (**), 0 flaws (~~), 5 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: Standards Track Alan DeKok (ed.) 5 FreeRADIUS 6 Expires: May 15, 2008 7 15 November 2007 9 RADIUS Design Guidelines 10 draft-ietf-radext-design-01.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 May 15, 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. Service definitions and RADIUS ................. 9 59 2.2. Vendor Space ........................................ 10 60 3. Data Model Issues ........................................ 11 61 3.1. Vendor Space ........................................ 12 62 3.1.1. Interoperability Considerations ................ 14 63 3.1.2. Vendor Allocations ............................. 14 64 3.1.3. SDO Allocations ................................ 15 65 3.1.4. Publication of specifications .................. 15 66 3.2. Polymorphic Attributes .............................. 16 67 4. IANA Considerations ...................................... 16 68 5. Security Considerations .................................. 16 69 6. References ............................................... 17 70 6.1. Normative References ................................ 17 71 6.2. Informative References .............................. 17 72 Appendix A - Design Guidelines ............................... 20 73 A.1. Types matching the RADIUS data model ................. 20 74 A.1.1. Transport of simple data ........................ 20 75 A.1.2. Extended data types ............................. 20 76 A.1.3. Complex data types .............................. 21 77 A.2. Improper Data Types .................................. 21 78 A.2.1. Simple Data Types ............................... 21 79 A.2.2. Complex Data Types .............................. 22 80 A.3. Vendor-Specific formats .............................. 22 81 A.4. New functionality in RADIUS. ......................... 23 82 A.5. Allocation of attributes ............................. 23 83 Appendix B - Complex Attributes .............................. 25 84 B.1. CHAP-Password ........................................ 25 85 B.2. CHAP-Challenge ....................................... 25 86 B.3. Tunnel-Password ...................................... 25 87 B.4. ARAP-Password ........................................ 26 88 B.5. ARAP-Features ........................................ 26 89 B.6. Connect-Info ......................................... 27 90 B.7. Framed-IPv6-Prefix ................................... 27 91 B.8. Egress-VLANID ........................................ 28 92 B.9. Egress-VLAN-Name ..................................... 29 93 Full Copyright Statement ..................................... 30 94 1. Introduction 96 This document provides guidelines for the design of RADIUS attributes 97 both within the IETF as well as within other Standards Development 98 Organizations (SDOs). It recognizes that requiring SDOs to 99 accomplish all their RADIUS work within the IETF is inherently 100 inefficient and unscalable. By articulating guidelines for attribute 101 design, this document enables to SDOs to design their own RADIUS 102 attributes within the Vendor-Specific Attribute (VSA) space, seeking 103 review from the IETF. 105 As with "Guidelines for Authors and Reviewers of MIB Documents" 106 [RFC4181], it is expected that this document will enable authors to 107 check their document against the guidelines prior to requesting a 108 review (such an "Expert Review" described in [RFC3575]). Similarly, 109 it is hoped that this document will be of use to reviewers (such as 110 WG participants or the AAA Doctors) in improving the consistency of 111 reviews. 113 In order to meet these objectives, this document needs to cover not 114 only the science of attribute design, but also the art. As a result, 115 in addition to covering the most frequently encountered issues, this 116 document attempts to provide some of the considerations motivating 117 the guidelines. 119 In order to characterize current attribute usage, both the basic and 120 complex data types defined in the existing RADIUS RFCs are reviewed, 121 together with the ad-hoc extensions to that data model that have been 122 used in Vendor-Specific Attributes. 124 1.1. Applicability 126 The major goal of this document is to encourage the development and 127 publication of high quality RADIUS attribute specifications. By 128 articulating RADIUS design guidelines, it is hoped that this document 129 will be a step in that direction. However, the advice in this 130 document will not be helpful unless it is put to use. In particular, 131 the authors recommend: 133 * Development of a program to encourage SDOs to make their RADIUS 134 attribute specifications publicly available; 136 * Review of IETF and SDO specifications according to the 137 guidelines proposed in this document; 139 The advice in this document applies to attributes used to encode 140 data. RADIUS protocol changes, or specification of attributes that 141 can be used to provide new RADIUS commands (such as Service-Type) are 142 out of scope. Since protocol changes require greater expertise and 143 deeper review, such changes should not be undertaken outside the IETF 144 and when handled within the IETF require "IETF Consensus" for 145 adoption, as noted in [RFC3575] Section 2.1. 147 As with protocol changes, this document does not provide guidance to 148 document authors seeking to change the RADIUS operational model. 149 While RADIUS server implementations may keep state, the RADIUS 150 protocol is stateless, although information may be passed from one 151 protocol transaction to another via the State Attribute. As a 152 result, documents which require stateful protocol behavior without 153 use of the State Attribute are inherently incompatible with RADIUS as 154 defined in [RFC2865], and need to be redesigned. 156 See [RFC5080] Section 2.1.1 for a more in-depth discussion of the use 157 of the State Attribute. 159 1.2. Terminology 161 This document uses the following terms: 163 Network Access Server (NAS) 164 A device that provides an access service for a user to a network. 166 RADIUS server 167 A RADIUS authentication, authorization, and/or accounting (AAA) 168 server is an entity that provides one or more AAA services to a 169 NAS. 171 RADIUS proxy 172 A RADIUS proxy acts as a RADIUS server to the NAS, and a RADIUS 173 client to the RADIUS server. 175 1.3. Requirements Language 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in [RFC2119]. 181 2. RADIUS Data Model 183 The Remote Authentication Dial In User Service (RADIUS) defined in 184 [RFC2865] and [RFC2866] uses elements known as attributes in order to 185 represent authentication, authorization and accounting data. 187 Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does 188 not define a formal data definition language. A handful of basic 189 data types are provided, and a data type is associated with an 190 attribute when the attribute is defined. 192 Two distinct attribute spaces are defined: the standard space, and a 193 Vendor-Specific space. Attributes in the standard space generally 194 are composed of a type, length, value (TLV) triplet, although complex 195 attributes have also been defined. The Vendor-Specific space is 196 encapsulated within a single attribute type (Vendor-Specific 197 Attribute). The format of this space is defined by individual 198 vendors, but the same TLV encoding used by the standard space is 199 recommended in [RFC2865] Section 5.26. The similarity between 200 attribute formats has enabled implementations to leverage common 201 parsing functionality, although in some cases the attributes in the 202 Vendor-Specific space have begun to diverge from the common format. 204 2.1. Standard Space 206 The following subsections describe common data types and formats 207 within the RADIUS standard attribute space. Common exceptions are 208 identified. 210 2.1.1. Basic Data Types 212 The data type of RADIUS attributes is not transported on the wire. 213 Rather, the data type of a RADIUS attribute is fixed when that 214 attribute is defined. Based on the RADIUS attribute type code, 215 RADIUS clients and servers can determine the data type based on pre- 216 configured entries within a data dictionary. 218 [RFC2865] defines the following data types: 220 text 1-253 octets containing UTF-8 encoded 10646 [RFC3629] 221 characters. Text of length zero (0) MUST NOT be sent; 222 omit the entire attribute instead. 223 string 1-253 octets containing binary data (values 0 through 224 255 decimal, inclusive). Strings of length zero (0) 225 MUST NOT be sent; omit the entire attribute instead. 226 IPv4 address 32 bit value, most significant octet first. 227 integer 32 bit unsigned value, most significant octet first. 228 time 32 bit unsigned value, most significant octet first 229 -- seconds since 00:00:00 UTC, January 1, 1970. 231 In addition to these data types, follow-on RADIUS specifications 232 define attributes using the following additional types: 234 IPv6 address 128 bit value, most significant octet first. 235 IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to 236 128 bits of value, most significant octet first. 237 integer64 64 bit unsigned value, most significant octet first. 239 Examples of the IPv6 address type include NAS-IPv6-Address defined in 240 [RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162] 241 Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3, 242 and in [RFC4818] Section 3. The integer64 type is used for the ARAP- 243 Challenge-Response Attribute defined in [RFC2869] Section 5.15, and 244 the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2. 245 [RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in 246 length, but denotes it as type String. 248 Given that attributes of type IPv6 address, IPv6 prefix, and 249 integer64 are already in use, it is RECOMMENDED that RADIUS server 250 implementations include support for these additional basic types, in 251 addition to the types defined in [RFC2865]. 253 It is worth noting that since RADIUS only supports unsigned integers 254 of 32 or 64 bits, attributes using signed integer data types or 255 unsigned integer types of other sizes will require code changes, and 256 SHOULD be avoided. 258 For [RFC2865] RADIUS VSAs, the length limitation of the String and 259 Text types is 247 octets instead of 253 octets, due to the additional 260 overhead of the Vendor-Specific Attribute. 262 2.1.2. Tagging Mechanism 264 [RFC2868] defines an attribute grouping mechanism based on the use of 265 a one octet tag value. Tunnel attributes that refer to the same 266 tunnel are grouped together by virtue of using the same tag value. 268 This tagging mechanism has some drawbacks. There are a limited 269 number of unique tags (31). The tags are not well suited for use 270 with arbitrary binary data values, because it is not always possible 271 to tell if the first byte after the Length is the tag or the first 272 byte of the untagged value (assuming the tag is optional). 274 Other limitations of the tagging mechaism are that when integer 275 values are tagged, the value portion is reduced to three bytes 276 meaning only 24-bit numbers can be represented. The tagging 277 mechanism does not offer an ability to create nested groups of 278 attributes. Some RADIUS implementations treat tagged attributes as 279 having additional data types tagged-string and tagged-integer. These 280 types increase the complexity of implementing and managing RADIUS 281 systems. 283 New attributes SHOULD NOT use this tagging method because of the 284 limitatations described above. New attributes SHOULD use the 285 grouping method described in [EXTEN]. 287 2.1.3. Complex Attribute Usage 289 The RADIUS attribute encoding is summarized in [RFC2865]: 291 0 1 2 292 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 294 | Type | Length | Value ... 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 297 However, some standard attributes do not follow this format. 298 Attributes that use sub-fields instead of using a basic data type are 299 known as "complex attributes". As described below, the definition of 300 complex attributes can lead to interoperability and deployment 301 issues, so they need to introduced with care. 303 In general, complex attributes sent from the RADIUS server to the 304 client can be supported by concatenating the values into a String 305 data type field. However, separating these values into different 306 attributes, each with its own type and length, would have the 307 following benefits: 309 * it is easier for the user to enter the data as well-known 310 types, rather than complex structures 311 * it enables additional error checking by leveraging the 312 parsing and validation routines for well-known types 313 * it simplifies implementations by eliminating special-case 314 attribute-specific parsing. 316 One of the fundamental goals of the RADIUS protocol design was to 317 allow RADIUS servers to be configured to support new attributes 318 without requiring server code changes. RADIUS server implementations 319 typically use provide support for basic data types, and define 320 attributes in a data dictionary. This architecture enables a new 321 attribute to be supported by the addition of a dictionary entry, 322 without requiring RADIUS server code changes. 324 On the RADIUS client, code changes are typically required in order to 325 implement a new attribute, as the RADIUS client typically has to 326 compose the attribute dynamically when sending. When receiving, a 327 RADIUS client needs to be able to parse the attribute and carry out 328 the requested service. As a result, a detailed understanding of the 329 new attribute is required on clients, and data dictionaries are less 330 useful on clients than on servers. 332 Given these considerations, the introduction of a new basic or 333 complex attribute will typically require code changes on the RADIUS 334 client. The magnitude of changes for the complex attribute could be 335 greater, due to the potential need for custom parsing logic. 337 The RADIUS server can be configured to send a new attribute by 338 entering its type and data format in the RADIUS server dictionary, 339 and then filling in the value within a policy based on the attribute 340 name, data type and type-specific value. For complex attribute types 341 not supported by RADIUS server dictionaries, changes to the 342 dictionary and policy management code can be required in order to 343 allow the new attribute to be supported by and configured on the 344 RADIUS server. 346 Code changes can also be required in the RADIUS server's receive 347 path, due to limitations in RADIUS server policy languages, which 348 typically only provide for limited operations (such as comparisons or 349 arithmetic operations) on the basic data types. Most existing RADIUS 350 policy languages typically are not capable of parsing sub-elements, 351 or providing sophisticated matching functionality. 353 Given these limitations, the introduction of complex attributes can 354 require code changes on the RADIUS server which would be unnecessary 355 if basic data types had been used instead. In addition, attribute- 356 specific parsing means more complex software to develop and maintain. 357 More complexity can lead to more error prone implementations, and 358 interoperatibility problems. This issues can increase costs to 359 network administrators as well as reducing reliability and 360 introducing deployment barriers. As a result, the introduction of 361 new complex data types within RADIUS attribute specifications SHOULD 362 be avoided, except in the case of complex attributes involve 363 authentication or security functionality. 365 As can be seen in Appendix B, most of the complex attributes involve 366 authentication or security functionality. Supporting this 367 functionality requires code changes on both the RADIUS client and 368 server, regardless of the attribute format. As a result, in most 369 cases, the use of complex attributes to represent these methods is 370 acceptable, and does not create additional interoperability or 371 deployment issues. 373 The only other exception to the recommendation against complex types 374 is for types that can be treated as opaque data by the RADIUS server. 375 For example, the EAP-Message attribute, defined in [RFC3579] Section 376 3.1 contains a complex data type that is an EAP packet. Since these 377 complex types do not need to be parsed by the RADIUS server, the 378 issues arising from policy language limitations do not arise. 379 Similarly, since attributes of these complex types can be configured 380 on the server using a data type of String, dictionary limitations are 381 also not encountered. Section A.1 below includes a series of 382 checklists that may be used to analyze a design for RECOMMENDED and 383 NOT RECOMMENDED behavior in relation to complex types. 385 If the RADIUS Server simply passes the contents of an attribute to 386 some non-RADIUS portion of the network, then the data is opaque, and 387 SHOULD be defined to be of type String. A concrete way of judging 388 this requirement is whether or not the attribute definition in the 389 RADIUS document contains delineated fields for sub-parts of the data. 390 If those fields need to be delineated in RADIUS, then the data is not 391 opaque, and it SHOULD be separated into individual RADIUS attributes. 393 An examination of existing RADIUS RFCs discloses a number of complex 394 attributes that have already been defined. Appendix B includes a 395 listing of complex attributes used within [RFC2865], [RFC2868], 396 [RFC2869], [RFC3162], [RFC4818], and [RFC4675]. The discussion of 397 these attributes includes reasons why a complex type is acceptable, 398 or suggestions for how the attribute could have been defined to 399 follow the RADIUS data model. 401 In other cases, the data in the complex type are described textually. 402 This is possible because the data types are not sent within the 403 attributes, but are a matter for endpoint interpretation. An 404 implementation can define additional data types (e.g., IPv6 address), 405 and use these data types today by matching them to the attribute's 406 textual description. 408 2.1.4. Service definitions and RADIUS 410 RADIUS specifications define how an existing service or protocol can 411 be provisioned using RADIUS. Therefore, it is expected that a RADIUS 412 attribute specification will reference documents defining the 413 protocol or service to be provisioned. Within the IETF, a RADIUS 414 attribute specification SHOULD NOT be used to define the protocol or 415 service being provisioned. New services using RADIUS for 416 provisioning SHOULD be defined elsewhere and referenced in the RADIUS 417 specification. 419 RADIUS also SHOULD NOT be extended to new commands via attributes. 420 RADIUS attributes are intended to: 422 * authenticate users 423 * authorize users (i.e., service provisioning or changes to 424 provisioning) 425 * account for user activity (i.e., logging of session activity) 427 New commands (i.e., the Code field in the packet header) are 428 allocated only through "IETF Consensus" as noted in [RFC3575] Section 429 2.1. Specifications SHOULD NOT use new attributes to modify the 430 interpretation of existing RADIUS commands. 432 2.2. Vendor Space 434 As noted in [RFC2865] Section 5.26, the VSA format is defined as 435 follows: 437 0 1 2 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Type | Length | Vendor-Id 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 Vendor-Id (cont) | String... 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 445 The high-order octet of the Vendor-Id field is 0 and the low-order 3 446 octets are the Structure of Management Information (SMI) Network 447 Management Private Enterprise Code (PEC) of the Vendor in network 448 byte order. 450 While the format of the String field is defined by the vendor, 451 [RFC2865] Section 5.26 notes: 453 It SHOULD be encoded as a sequence of vendor type / vendor length 454 / value fields, as follows. The Attribute-Specific field is 455 dependent on the vendor's definition of that attribute. An 456 example encoding of the Vendor-Specific attribute using this 457 method follows: 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Type | Length | Vendor-Id 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 Vendor-Id (cont) | Vendor type | Vendor length | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Attribute-Specific... 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 469 Multiple sub-attributes MAY be encoded within a single Vendor- 470 Specific attribute, although they do not have to be. 472 Note that the Vendor type field in the recommended VSA format is only 473 a single octet, like the RADIUS type field. While this limitation 474 results in an efficient encoding, there are situations in which a 475 vendor or SDO will eventually wish to define more than 255 476 attributes. Also, an SDO can be comprised of multiple subgroups, 477 each of whom can desire autonomy over the definition of attributes 478 within their group. In such a situation, a 16-bit Vendor type field 479 would be more appropriate: 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Type | Length | Vendor-Id 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Vendor-Id (cont) | Vendor type | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Vendor length | Attribute-Specific... 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 Other attribute formats are NOT RECOMMENDED. Examples of NOT 492 RECOMMENDED formats include Vendor types of more than 16 bits, Vendor 493 lengths of less than 8 bits, Vendor lengths of more than 8 bits, and 494 Vendor-Specific contents that are not in Type-Length-Value format. 496 In order to be compatible with the above recommendations for attribute 497 definitions, it is RECOMMENDED that RADIUS servers support attributes 498 using a 16-bit Vendor type field. 500 3. Data Model Issues 502 Since the closure of the RADIUS Working Group, the popularity and 503 prevalence of RADIUS has continued to grow. In addition to 504 increasing demand for allocation of attributes within the RADIUS 505 standard attribute space, the number of vendors and SDOs creating new 506 attributes within the Vendor-Specific attribute space has grown, and 507 this has lead to some divergence in approaches to RADIUS attribute 508 design. 510 In general, standard RADIUS attributes have a more constrained data 511 model than attributes within the vendor space. For example, vendors 512 and SDOs have evolved the data model to support new functions such as 513 attribute grouping and attribute fragmentation, with different groups 514 taking different approaches. 516 Given these enhancements, it has become difficult for vendors or SDOs 517 to translate attributes from the vendor space to the more stringent 518 standards space. For example, a Vendor-Specific attribute using sub- 519 elements could require allocation of several standard space 520 attributes using basic data types. In this case not only would 521 translation require substantial additional work, it would further 522 deplete the RADIUS standard attribute space. Given these 523 limitations, translation of vendor attributes to the standards space 524 is not necessarily desirable, particularly if the VSA specification 525 is publicly available and can be implemented within existing RADIUS 526 clients and servers. In such situations, the costs may substantially 527 outweigh the benefits. While it is possible that some of the 528 enhancements made within the vendor space may eventually become 529 available within the standard attribute space, the divergence of the 530 standard and vendor attribute spaces is most likely a permanent 531 feature, and should be recognized as such. 533 Recent extensions to the RADIUS data model such as [EXTEN] make it 534 possible to minimize the use of complex attributes. New 535 specifications seeking to extend the standard RADIUS data model 536 SHOULD examine [EXTEN] to see if their needs fit within the extended 537 RADIUS data model. 539 3.1. Vendor Space 541 The usage model for RADIUS VSAs is described in [RFC2865] Section 542 6.2: 544 Note that RADIUS defines a mechanism for Vendor-Specific 545 extensions (Attribute 26) and the use of that should be encouraged 546 instead of allocation of global attribute types, for functions 547 specific only to one vendor's implementation of RADIUS, where no 548 interoperability is deemed useful. 550 Nevertheless, many new attributes have been defined in the vendor 551 specific space in situations where interoperability is not only 552 useful, but is required. For example, Standards Development 553 Organizations (SDOs) outside the IETF (such as the IEEE 802 and the 554 3rd Generation Partnership Project (3GPP)) have been assigned Vendor- 555 Ids, enabling them to define their own VSA format and assign Vendor 556 types within their own space. 558 The use of VSAs by SDOs outside the IETF has gained in popularity for 559 several reasons: 561 Efficiency 562 As with SNMP, which defines an "Enterprise" Object Identifier (OID) 563 space suitable for use by vendors as well as other SDOs, the 564 definition of Vendor-Specific RADIUS attributes has become a common 565 occurrence as part of standards activity outside the IETF. For 566 reasons of efficiency, it is easiest if the RADIUS attributes 567 required to manage a standard are developed within the same SDO 568 that develops the standard itself. As noted in "Transferring MIB 569 Work from IETF Bridge MIB WG to IEEE 802.1 WG" [RFC4663], today few 570 vendors are willing to simultaneously fund individuals to 571 participate within an SDO to complete a standard, as well as to 572 participate in IETF in order to complete the associated RADIUS 573 attributes specification. 575 Attribute scarcity 576 The standard RADIUS attribute space is limited to 255 unique 577 attributes. Of these, only about half remain available for 578 allocation. In the Vendor-Specific space, the number of attributes 579 available is a function of the format of the attribute (the size of 580 the Vendor type field). 582 Along with these advantages, some limitations of VSA usage are noted 583 in [RFC2865] Section 5.26: 585 This Attribute is available to allow vendors to support their own 586 extended Attributes not suitable for general usage. It MUST not 587 affect the operation of the RADIUS protocol. 589 Servers not equipped to interpret the vendor-specific information 590 sent by a client MUST ignore it (although it may be reported). 591 Clients which do not receive desired vendor-specific information 592 SHOULD make an attempt to operate without it, although they may do 593 so (and report they are doing so) in a degraded mode. 595 The limitation on changes to the RADIUS protocol effectively 596 prohibits VSAs from changing fundamental aspects of RADIUS operation, 597 such as modifying RADIUS packet sequences, or adding new commands. 598 However, the requirement for clients and servers to be able to 599 operate in the absence of VSAs has proven to be less of a constraint, 600 since it is still possible for a RADIUS client and server to mutually 601 indicate support for VSAs, after which behavior expectations can be 602 reset. 604 Therefore, RFC 2865 provides considerable latitude for development of 605 new attributes within the vendor space, while prohibiting development 606 of protocol variants. This flexibility implies that RADIUS 607 attributes can often be developed within the vendor space without 608 loss (and possibly even gain) in functionality. 610 As a result, translation of RADIUS attributes developed within the 611 vendor space into the standard space may provide only modest 612 benefits, while accelerating the exhaustion of the standard attribute 613 space. Rather than expecting all RADIUS attribute specifications 614 requiring interoperability to be developed within the IETF and 615 expecting that they be allocated within the standards space, a more 616 scalable approach is to recognize the flexibility of the vendor space 617 while working toward improvements in the quality and availability of 618 RADIUS attribute specifications, regardless of where they are 619 developed. 621 3.1.1. Interoperability Considerations 623 Vendors and SDOs are reminded that the standard RADIUS attribute ID 624 space, and the enumerated value space for enumerated attributes, are 625 reserved for allocation through work published via the IETF, as noted 626 in [RFC3575] Section 2.1. Some vendors and SDOs have in the past 627 performed self-allocation by assigning vendor-specific meaning to 628 "unused" values from the standard RADIUS attribute ID or enumerated 629 value space. This self-allocation results in interoperability 630 issues, and is counter-productive. Similarly, the Vendor-Specific 631 enumeration practice discussed in [RFC2882] Section 2.2.1 is NOT 632 RECOMMENDED. 634 If it is not possible to follow the above procedure, vendors and SDOs 635 they SHOULD self-allocate an attribute from their Vendor-Specific 636 space, and define an appropriate value for it. 638 As a side note, [RFC2865] Section 5.26 uses the term "Vendor-Specific 639 Attribute" to refer to an encoding format which can be used by 640 individual vendors to define attributes not suitable for general 641 usage. However, since then VSAs have also become widely used by SDOs 642 defining attributes intended for multi-vendor interoperability. As 643 such, these attributes are not specific to any single vendor, and the 644 term "Vendor-Specific" may be misleading. An alternate term which 645 better describes this use case is SDO-Specific Attribute (SSA). 647 The design and specification of VSAs for multi-vendor usage SHOULD be 648 undertaken with the same level of care as standard RADIUS attributes. 649 Specifically, the provisions of this document that apply to standard 650 RADIUS attributes also apply to SSAs or VSAs for multi-vendor usage. 652 3.1.2. Vendor Allocations 654 Vendor RADIUS Attribute specifications SHOULD allocate attributes 655 from the vendor space, rather than requesting an allocation from the 656 RADIUS standard attribute space. 658 As discussed in [RFC2865] Section 5.26, the vendor space is intended 659 for vendors to support their own extended attributes not suitable for 660 general use. However, it is RECOMMENDED that vendors follow the 661 guidelines outlined here, which are intended to enable maximum 662 interoperability with minimal changes to existing systems. 664 Following these guidelines means that RADIUS servers can be updated 665 to support the vendor's equipment by editing a RADIUS dictionary. If 666 these guidelines are not followed, then the vendor's equipment can 667 only be supported via code changes in RADIUS server implementations. 668 Such code changes add complexity and delay to implementations. 670 3.1.3. SDO Allocations 672 SDO RADIUS Attribute specifications SHOULD allocate attributes from 673 the vendor space, rather than requesting an allocation from the 674 RADIUS standard attribute space, for attributes matching any of the 675 following criteria: 677 * attributes relying on data types not defined within RADIUS 678 * attributes intended primarily for use within an SDO 679 * attributes intended primarily for use within a group of SDOs. 681 The recommendation for SDOs to allocate attributes from a vendor 682 space rather than via IETF process is a recognition that SDOs may 683 desire to assert change control over their own RADIUS specifications. 684 This change control can be obtained by requesting a PEC from the 685 Internet Assigned Number Authority (IANA), for use as a Vendor-Id 686 within a Vendor-Specific attribute. Further allocation of attributes 687 inside of the VSA space defined by that Vendor-Id is subject solely 688 to the discretion of the SDO. Similarly, the use of data types 689 (complex or not) within that VSA space is solely under the discretion 690 of the SDO. It is RECOMMENDED that SDOs follow the guidelines 691 outlined here, which are intended to enable maximum interoperability 692 with minimal changes to existing systems. 694 It should be understood that SDOs do not have to rehost VSAs into the 695 standards space solely for the purpose of obtaining IETF review. 696 Rehosting puts pressure on the standards space, and may be harmful to 697 interoperability, since it can create two ways to provision the same 698 service. Rehosting may also require changes to the RADIUS data model 699 which will affect implementations that do not intend to support the 700 SDO specifications 702 3.1.4. Publication of specifications 704 SDOs are encouraged to seek early review of SSA specifications by the 705 IETF. This review may be initiated by sending mail to the AAA 706 Doctors list (aaa-doctors@ops.ietf.org). Since the IETF is not a 707 membership organization, in order to enable the RADIUS SSA 708 specification to be reviewed, it is RECOMMENDED that it be made 709 publicly available; this also encourages interoperability. Where the 710 RADIUS SSA specification is embedded within a larger document which 711 cannot be made public, the RADIUS attribute and value definitions 712 SHOULD be published instead as an Informational RFC, as with 713 [RFC4679]. This process SHOULD be followed instead of requesting 714 IANA allocations from within the standard RADIUS attribute space. 716 Similarly, vendors are encouraged to make their specifications 717 publicly available, for maximum interoperability. However, it is not 718 necessary for them to request publication of their VSA specifications 719 as Informational RFCs by the IETF. 721 All other specifications, including new authentication and/or 722 security mechanisms SHOULD be allocated via the standard RADIUS 723 space, as noted in [RFC3575] Section 2.1. 725 3.2. Polymorphic Attributes 727 A polymorphic attribute is one whose format or meaning is dynamic. 728 For example, rather than using a fixed data format, an attribute's 729 format might change based on the contents of another attribute. Or, 730 the meaning of an attribute may depend on earlier packets in a 731 sequence. 733 RADIUS server dictionary entries are typically static, enabling the 734 user to enter the contents of an attribute without support for 735 changing the format based on dynamic conditions. However, this 736 limitation on static types does not prevent implementations from 737 implementing policies that return different attributes based on the 738 contents of received attributes; this is a common feature of existing 739 RADIUS implementations. 741 In general, polymorphism is NOT RECOMMENDED. Polymorphism rarely 742 enables capabilities that would not be available through use of 743 multiple attributes. Polymorphism requires code changes in the 744 RADIUS server in situations where attributes with fixed formats would 745 not require such changes. Thus, polymorphism increases complexity 746 while decreasing generality, without delivering any corresponding 747 benefits. 749 Note that changing an attribute's format dynamically is not the same 750 thing as using a fixed format and computing the attribute itself 751 dynamically. RADIUS authentication attributes such as User-Password, 752 EAP-Message, etc. while being computed dynamically, use a fixed 753 format. 755 4. IANA Considerations 757 This document requires no action by IANA. 759 5. Security Considerations 761 This specification provides guidelines for the design of RADIUS 762 attributes used in authentication, authorization and accounting. 763 Threats and security issues for this application are described in 764 [RFC3579] and [RFC3580]; security issues encountered in roaming are 765 described in [RFC2607]. 767 Encryption of RADIUS attributes on a per-attribute basis is necessary 768 in some cases. The current standard mechanism for this is described 769 in [RFC2865] Section 5.2 (for obscuring User-Password values) and is 770 based on the MD5 algorithm specified in [RFC1321]. The MD5 algorithm 771 has recently become a focus of scrutiny and concern in security 772 circles, and as a result, the use of this technique in new attributes 773 is NOT RECOMMENDED. 775 Where new RADIUS attributes use cryptographic algorithms, algorithm 776 negotiation SHOULD be supported. Specification of a mandatory-to- 777 implement algorithm is REQUIRED, and it is RECOMMENDED that the 778 mandatory-to-implement algorithm be certifiable under FIPS 140 779 [FIPS]. 781 6. References 783 6.1. Normative References 785 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 786 Requirement Levels", BCP 14, RFC 2119, March 1997. 788 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 789 Authentication Dial In User Service (RADIUS)", RFC 2865, June 790 2000. 792 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 793 Authentication Dial In User Service)", RFC 3575, July 2003. 795 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 796 Network Access Server Application", RFC 4005, August 2005. 798 6.2. Informative References 800 [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of 801 management information for TCP/IP-based internets", STD 16, 802 RFC 1155, May 1990. 804 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 805 Network Management Protocol (SNMP)", STD 15, RFC 1157, May 806 1990. 808 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 809 April 1992. 811 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 812 Implementation in Roaming", RFC 2607, June 1999. 814 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 816 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., 817 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 818 Support", RFC 2868, June 2000. 820 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", 821 RFC 2869, June 2000. 823 [RFC2882] Mitton, D, "Network Access Servers Requirements: Extended 824 RADIUS Practices", RFC 2882, July 2000. 826 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 827 3162, August 2001. 829 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 830 In User Service) Support For Extensible Authentication 831 Protocol (EAP)", RFC 3579, September 2003. 833 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE 834 802.1X Remote Authentication Dial In User Service (RADIUS) 835 Usage Guidelines", RFC3580, September 2003. 837 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 838 RFC 3629, November 2003. 840 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 841 Documents", RFC 4181, September 2005. 843 [RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge MIB WG 844 to IEEE 802.1 WG", RFC 4663, September 2006. 846 [RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for 847 Virtual LAN and Priority Support", RFC 4675, September 2006. 849 [RFC4679] Mammoliti, V., et al., "DSL Forum Vendor-Specific RADIUS 850 Attributes", RFC 4679, September 2006. 852 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 853 Attribute", RFC 4818, April 2007. 855 [RFC5080] Nelson, D. and DeKok, A, "Common Remote Authentication Dial In 856 User Service (RADIUS) Implementation Issues and Suggested 857 Fixes", RFC 5080, December 2007. 859 [IEEE-802.1Q] 860 IEEE Standards for Local and Metropolitan Area Networks: Draft 861 Standard for Virtual Bridged Local Area Networks, 862 P802.1Q-2003, January 2003. 864 [EXTEN] Li, Y., et al., "Extended Remote Authentication Dial In User 865 Service (RADIUS) Attributes", draft-ietf-radext-extended- 866 attributes-00.txt (work in progress). 868 [FIPS] FIPS 140-3 (DRAFT), "Security Requirements for Cryptographic 869 Modules", http://csrc.nist.gov/publications/fips/fips140-3/ 871 Appendix A - Design Guidelines 873 The following text provides guidelines for the design of attributes 874 used by the RADIUS protocol. Specifications that follow these 875 guidelines are expected to achieve maximum interoperability with 876 minimal changes to existing systems. 878 A.1. Types matching the RADIUS data model 880 A.1.1. Transport of simple data 882 Does the data fit within the existing RADIUS data model, as outlined 883 below? If so, it SHOULD be encapsulated in a [RFC2865] format RADIUS 884 attribute, or in a [RFC2865] format RADIUS VSA. 886 * 32-bit unsigned integer, most significant octet first. 887 * Enumerated data types, represented as a 32-bit unsigned integer 888 with a list of name to value mappings. (e.g., Service-Type) 889 * 64-bit unsigned integer, most significant octet first. 890 * IPv4 address in network byte order. 891 * IPv6 address in network byte order. 892 * IPv6 prefix. 893 * time as 32 bit unsigned value, most significant octet first, in 894 seconds since 00:00:00 UTC, January 1, 1970. 895 * string (i.e., binary data), totalling 253 octets or less in 896 length. This includes the opaque encapsulation of data 897 structures defined outside of RADIUS. See also Section A.1.3, 898 below. 899 * UTF-8 text, totalling 253 octets or less in length. 900 * Complex data types for authentication and/or security. 901 These attributes SHOULD be defined only within the RADIUS 902 attribute space, and SHOULD NOT be defined within the VSA space. 904 Note that the length limitations for VSAs of type String and Text are 905 less than 253 octets, due to the additional overhead of the Vendor- 906 Specific format. 908 A.1.2. Extended data types 910 Where possible, the data types defined above in Section A.1.2 SHOULD 911 be used. The extended data types SHOULD be used only where there is 912 no clear method of expressing the data using existing types. 914 Does the data fit within the extended RADIUS data model, as outlined 915 below? If so, it SHOULD be encapsulated in a [EXTEN] format RADIUS 916 VSA. 918 * Attributes grouped into a logical container. 920 This does not included nested groups. 921 * Attributes requiring the transport of more than 247 octets of 922 Text or String data. This includes the opaque encapsulation 923 of data structures defined outside of RADIUS. See also Section 924 A.1.3, below. 926 A.1.3. Complex data types 928 Does the attribute encapsulate an existing data structure defined 929 outside of the RADIUS specifications? Can the attribute be treated 930 as opaque data by RADIUS servers (including proxies?) If both 931 questions can be answered affirmatively, a complex structure MAY be 932 used in a RADIUS specification. 934 The specification of the attribute SHOULD define the encapsulating 935 attribute to be of type String. The specification SHOULD refer to an 936 external document defining the structure. The specification SHOULD 937 NOT define or describe the structure, as discussed above in Section 938 2.1.3. 940 A.2. Improper Data Types 942 All data types other than the ones described above in Section A.1 943 SHOULD NOT be used. This section describes in detail a number of 944 data types that are NOT RECOMMENDED in new RADIUS specifications. 945 Where possible, replacement data types are suggested. 947 A.2.1. Simple Data Types 949 Does the attribute use any of the following data types? If so, the 950 data type SHOULD be replaced with the suggested alternatives, or 951 SHOULD NOT be used at all. 953 * Signed integers of any size. 954 SHOULD NOT be used. SHOULD be replaced with one or more 955 unsigned integer attributes. The definition of the attribute 956 can contain information that would otherwise go into the sign 957 value of the integer. 958 * 8 bit unsigned integers. 959 SHOULD be replaced with 32-bit unsigned integer. There is 960 insufficient justification to save three bytes. 961 * 16 bit unsigned integers. 962 SHOULD be replaced with 32-bit unsigned integer. There is 963 insufficient justification to save two bytes. 964 * Unsigned integers of size other than 32 or 64. 965 SHOULD be replaced by an unsigned integer of 32 or 64 bits. 966 There is insufficient justification to define a new size of 967 integer. 969 * Integers of any size in non-network byte order 970 SHOULD be replaced by unsigned integer of 32 or 64 bits, 971 in network byte order. There is no reason to transport integers 972 in any format other than network byte order. 973 * Tagged data types as described in [RFC2868]. 974 These data types SHOULD NOT be used in new specifications. The 975 attribute grouping method defined in [EXTEN] SHOULD be used 976 instead. 977 * Complex data structures defined only within RADIUS. 978 The additional functionality defined in [EXTEN] SHOULD be used 979 instead. This recommendation does not apply to new attributes 980 for authentication or security, as described below in Section 981 A.2.2. 982 * Multi-field text strings. 983 Each field SHOULD be encapsulated in a separate attribute. 984 Where grouping of fields is desired, the additional 985 functionality defined in [EXTEN] SHOULD be used instead. 986 * Polymorphic attributes. 987 Multiple attributes, each with a static data type SHOULD be 988 defined instead. 990 A.2.2. Complex Data Types 992 Does the attribute define a complex data type for purposes other than 993 authentication or security? If so, this data type SHOULD be replaced 994 with simpler types, as discussed above in Section A.2.1. Also see 995 Section 2.1.3 for a discussion of why complex types are problematic. 997 A.3. Vendor-Specific formats 999 Does the specification contain Vendor-Specific attributes that match 1000 any of the following criteria? If so, the data type should be 1001 replaced with the suggested alternatives, or should not be used at 1002 all. 1004 * Vendor types of more than 16 bits. 1005 SHOULD NOT be used. Vendor types of 8 or 16 bits SHOULD be used 1006 instead. 1007 * Vendor lengths of less than 8 bits. (i.e., zero bits) 1008 SHOULD NOT be used. Vendor types of 8 or 16 bits SHOULD be used 1009 instead. 1010 * Vendor lengths of more than 8 bits. 1011 SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used 1012 instead. 1013 * Vendor-Specific contents that are not in Type-Length-Value 1014 format. 1015 SHOULD NOT be used. Vendor-Specific attributes SHOULD be in 1016 Type-Length-Value format. 1018 We recognize that SDOs may require more than 256 attributes, which is 1019 the limit of the 8-bit [RFC2865] Vendor-Specific space. Those SDOs 1020 SHOULD use Vendor types of 16 bits. However, SDOs SHOULD NOT use 1021 Vendor types of 16 bits unless there are immediate requirements. 1022 Future-proofing a specification is insufficient grounds for using 1023 16-bit Vendor types. 1025 In general, Vendor-Specific attributes SHOULD follow the [RFC2865] 1026 suggested format, or the [EXTEN] format if more functionality, or a 1027 larger attribute space is necessary. 1029 A.4. New functionality in RADIUS. 1031 Does the specification extend RADIUS by adding new functionality, as 1032 outlined in the list below? If so, it SHOULD NOT use RADIUS. 1033 Another method of achieving the design objectives SHOULD be used. 1035 * Defining new commands in RADIUS using attributes. 1036 This restriction includes new commands created by overloading 1037 the Service-Type attribute to define new values that modify 1038 the functionality of Access-Request packets. 1039 * Using RADIUS as a transport protocol for non-AAA data. 1040 This restriction is partially a subset of the previous one. 1041 Note that using RADIUS to transport authentication methods 1042 (e.g., EAP) is explicitly permitted, even if those methods 1043 require the transport of relatively large amounts of data. 1044 * Extending the RADIUS packet length limitation past 4096 octets. 1045 A multi-packet sequence of Access-Request / Access-Challenge 1046 SHOULD be used instead. If that is not possible, then a method 1047 other than RADIUS SHOULD be used to transport the data. 1049 A.5. Allocation of attributes 1051 Does the attribute have a limited scope of applicability, as outlined 1052 below? If so, then the attributes SHOULD be allocated from the 1053 Vendor-Specific space. 1055 * attributes intended for a vendor to support their own systems, 1056 and not suitable for general usage 1057 * attributes relying on data types not defined within RADIUS 1058 * attributes intended primarily for use within an SDO 1059 * attributes intended primarily for use within a group of SDOs. 1061 Note that the points listed above do not relax the recommendations 1062 discussed in this document. Instead, they recognize that the RADIUS 1063 data model has limitations. In certain situations where 1064 interoperability can be strongly constrained, a data model extended 1065 by the SDO or vendor MAY be used. We recommend, however, that the 1066 RADIUS data model SHOULD be used, even if it is marginally less 1067 efficient than alternatives. 1069 Appendix B - Complex Attributes 1071 This section summarizes RADIUS attributes with complex data types 1072 that are defined in existing RFCs. 1074 B.1. CHAP-Password 1076 [RFC2865] Section 5.3 defines the CHAP-Password Attribute which is 1077 sent from the RADIUS client to the RADIUS server in an Access- 1078 Request. The the data type of the CHAP Identifier is not given, only 1079 the one octet length: 1081 0 1 2 1082 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 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1084 | Type | Length | CHAP Ident | String ... 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1087 Since this is an authentication attribute, code changes are required 1088 on the RADIUS client and server to support it, regardless of the 1089 attribute format. Therefore, this complex data type is acceptable in 1090 this situation. 1092 B.2. CHAP-Challenge 1094 [RFC2865] Section 5.40 defines the CHAP-Challenge Attribute which is 1095 sent from the RADIUS client to the RADIUS server in an Access- 1096 Request. While the data type of the CHAP Identifier is given, the 1097 text also says 1099 If the CHAP challenge value is 16 octets long it MAY be placed in 1100 the Request Authenticator field instead of using this attribute. 1102 Defining attributes to contain values taken from the RADIUS packet 1103 header is NOT RECOMMENDED. Attributes should have values that are 1104 packed into a RADIUS AVP. 1106 B.3. Tunnel-Password 1108 [RFC2868] Section 3.5 defines the Tunnel-Password Attribute, which is 1109 sent from the RADIUS server to the client in an Access-Accept. This 1110 attribute includes Tag and Salt fields, as well as a string field 1111 which consists of three logical sub-fields: the Data-Length (one 1112 octet) and Password sub-fields (both of which are required), and the 1113 optional Padding sub-field. The attribute appears as follows: 1115 0 1 2 3 1116 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 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Type | Length | Tag | Salt 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 Salt (cont) | String ... 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 Since this is a security attribute and is encrypted, code changes are 1125 required on the RADIUS client and server to support it, regardless of 1126 the attribute format. Therefore, this complex data type is 1127 acceptable in this situation. 1129 B.4. ARAP-Password 1131 [RFC2869] Section 5.4 defines the ARAP-Password attribute, which is 1132 sent from the RADIUS client to the server in an Access-Request. It 1133 contains four 4 octet values, instead of having a single Value field: 1135 0 1 2 3 1136 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 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | Type | Length | Value1 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | Value2 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 | Value3 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 | Value4 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 As with the CHAP-Password attribute, this is an authentication 1150 attribute which would have required code changes on the RADIUS client 1151 and server regardless of format. 1153 B.5. ARAP-Features 1155 [RFC2869] Section 5.5 defines the ARAP-Features Attribute, which is 1156 sent from the RADIUS server to the client in an Access-Accept or 1157 Access-Challenge. It contains a compound string of two single octet 1158 values, plus three 4-octet values, which the RADIUS client 1159 encapsulates in a feature flags packet in the ARAP protocol: 1161 0 1 2 3 1162 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 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 | Type | Length | Value1 | Value2 | 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 | Value3 | 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 | Value4 | 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 | Value5 | 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 Unlike the previous attributes, this attribute contains no encrypted 1174 component, nor is it directly involved in authentication. The 1175 individual sub-fields therefore could have been encapsulated in 1176 separate attributes. 1178 B.6. Connect-Info 1179 [RFC2869] Section 5.11 defines the Connect-Info attribute, which is 1180 used to indicate the nature of the connection. 1182 0 1 2 1183 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | Type | Length | Text... 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 Even though the type is Text, the rest of the description indicates 1189 that it is a complex attribute: 1191 The Text field consists of UTF-8 encoded 10646 [8] characters. 1192 The connection speed SHOULD be included at the beginning of the 1193 first Connect-Info attribute in the packet. If the transmit and 1194 receive connection speeds differ, they may both be included in the 1195 first attribute with the transmit speed first (the speed the NAS 1196 modem transmits at), a slash (/), the receive speed, then 1197 optionally other information. 1198 For example, "28800 V42BIS/LAPM" or "52000/31200 V90" 1200 More than one Connect-Info attribute may be present in an 1201 Accounting-Request packet to accommodate expected efforts by ITU 1202 to have modems report more connection information in a standard 1203 format that might exceed 252 octets. 1205 This attribute contains no encrypted component, and is it not 1206 directly involved in authentication. The individual sub-fields could 1207 therefore have been encapsulated in separate attributes. 1209 B.7. Framed-IPv6-Prefix 1211 [RFC3162] Section 2.3 defines the Framed-IPv6-Prefix Attribute and 1212 [RFC4818] Section 3 reuses this format for the Delegated-IPv6-Prefix 1213 Attribute; these attributes are sent from the RADIUS server to the 1214 client in an Access-Accept. 1216 0 1 2 3 1217 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 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 | Type | Length | Reserved | Prefix-Length | 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 Prefix 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 Prefix 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 Prefix 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 Prefix | 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 The sub-fields encoded in these attributes are strongly related, and 1231 there was no previous definition of this data structure that could be 1232 referenced. Support for this attribute requires code changes on both 1233 the client and server, due to a new data type being defined. In this 1234 case it appears to be acceptable to encode them in one attribute. 1236 B.8. Egress-VLANID 1238 [RFC4675] Section 2.1 defines the Egress-VLANID Attribute which can 1239 be sent by a RADIUS client or server. 1241 0 1 2 3 1242 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 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 | Type | Length | Value 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 Value (cont) | 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 While it appears superficially to be of type Integer, the Value field 1250 is actually a packed structure, as follows: 1252 0 1 2 3 1253 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 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 | Tag Indic. | Pad | VLANID | 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 The length of the VLANID field is defined by the [IEEE-802.1Q] 1259 specification. The Tag indicator field is either 0x31 or 0x32, for 1260 compatibility with the Egress-VLAN-Name, as discussed below. The 1261 complex structure of Egress-VLANID overlaps with that of the base 1262 Integer data type, meaning that no code changes are required for a 1263 RADIUS server to support this attribute. Code changes are required 1264 on the NAS, if only to implement the VLAN ID enforcement. 1266 Given the IEEE VLAN requirements and the limited data model of 1267 RADIUS, the chosen method is likely the best of the possible 1268 alternatives. Future specifications that attempt to obtain similar 1269 functionality SHOULD use the extended types from [EXTEN]. 1271 B.9. Egress-VLAN-Name 1273 [RFC4675] Section 2.3 defines the Egress-VLAN-Name Attribute which 1274 can be sent by a RADIUS client or server. 1276 0 1 2 3 1277 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 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | Type | Length | Tag Indic. | String... 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 The Tag Indicator is either the character '1' or '2', which in ASCII 1282 map to the identical values for Tag Indicator in Egress-VLANID, 1283 above. The complex structure of this attribute is acceptable for 1284 reasons identical to those given for Egress-VLANID. Future 1285 specifications that attempt to obtain similar functionality SHOULD 1286 use the extended types from [EXTEN]. 1288 Acknowledgments 1290 We would like to acknowledge David Nelson, Bernard Aboba, Emile van 1291 Bergen, Barney Wolff and Glen Zorn for contributions to this 1292 document. 1294 Authors' Addresses 1296 Greg Weber 1297 Knoxville, TN 37932 1298 USA 1300 Email: gdweber@gmail.com 1302 Alan DeKok 1303 The FreeRADIUS Server Project 1304 http://freeradius.org/ 1306 Email: aland@freeradius.org 1308 Full Copyright Statement 1310 Copyright (C) The IETF Trust (2007). 1312 This document is subject to the rights, licenses and restrictions 1313 contained in BCP 78, and except as set forth therein, the authors 1314 retain all their rights. 1316 This document and the information contained herein are provided on an 1317 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1318 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1319 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1320 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1321 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1322 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1324 Intellectual Property 1326 The IETF takes no position regarding the validity or scope of any 1327 Intellectual Property Rights or other rights that might be claimed to 1328 pertain to the implementation or use of the technology described in 1329 this document or the extent to which any license under such rights 1330 might or might not be available; nor does it represent that it has 1331 made any independent effort to identify any such rights. Information 1332 on the procedures with respect to rights in RFC documents can be 1333 found in BCP 78 and BCP 79. 1335 Copies of IPR disclosures made to the IETF Secretariat and any 1336 assurances of licenses to be made available, or the result of an 1337 attempt made to obtain a general license or permission for the use of 1338 such proprietary rights by implementers or users of this 1339 specification can be obtained from the IETF on-line IPR repository at 1340 http://www.ietf.org/ipr. 1342 The IETF invites any interested party to bring to its attention any 1343 copyrights, patents or patent applications, or other proprietary 1344 rights that may cover technology that may be required to implement 1345 this standard. Please address the information to the IETF at ietf- 1346 ipr@ietf.org. 1348 Acknowledgment 1350 Funding for the RFC Editor function is provided by the IETF 1351 Administrative Support Activity (IASA). 1353 Open issues 1355 Open issues relating to this document are tracked on the following 1356 web site: 1358 http://www.drizzle.com/~aboba/RADEXT/