idnits 2.17.1 draft-ietf-radext-design-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (8 November 2010) is 4915 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-sterman-sip-aaa - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Alan DeKok (ed.) 3 INTERNET-DRAFT FreeRADIUS 4 Category: Best Current Practice G. Weber 5 Individual Contributor 6 Expires: May 8, 2011 7 8 November 2010 9 RADIUS Design Guidelines 10 draft-ietf-radext-design-19 12 Abstract 14 This document provides guidelines for the design of attributes used 15 by the Remote Authentication Dial In User Service (RADIUS) protocol. 16 It is expected that these guidelines will prove useful to authors and 17 reviewers of future RADIUS attribute specifications, both within the 18 IETF as well as other Standards Development Organizations (SDOs). 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on May 8, 2011. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info/) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction ............................................. 5 73 1.1. Terminology ......................................... 5 74 1.2. Requirements Language ............................... 6 75 1.3. Applicability ....................................... 6 76 1.3.1. Reviews ........................................ 7 77 2. Guidelines ............................................... 8 78 2.1. Data Types .......................................... 9 79 2.2. Vendor-Specific Attribute Space ..................... 10 80 2.3. Service definitions and RADIUS ...................... 11 81 2.4. Translation of Vendor Specifications ................ 11 82 3. Rationale ................................................ 12 83 3.1. RADIUS Operational Model ............................ 12 84 3.2. Data Model Issues ................................... 15 85 3.2.1. Issues with Definitions of Types ............... 16 86 3.2.2. Tagging Mechanism .............................. 17 87 3.2.3. Complex Data Types ............................. 17 88 3.2.4. Complex Data Type Exceptions ................... 19 89 3.3. Vendor Space ........................................ 20 90 3.3.1. Interoperability Considerations ................ 21 91 3.3.2. Vendor Allocations ............................. 21 92 3.3.3. SDO Allocations ................................ 22 93 3.4. Polymorphic Attributes .............................. 22 94 4. IANA Considerations ...................................... 23 95 5. Security Considerations .................................. 23 96 5.1. New Data Types and Complex Attributes ............... 24 97 6. References ............................................... 25 98 6.1. Normative References ................................ 25 99 6.2. Informative References .............................. 25 100 Appendix A - Design Guidelines ............................... 28 101 A.1. Types matching the RADIUS data model ................. 28 102 A.1.1. Transport of basic data types ................... 28 103 A.1.2. Transport of Authentication and Security Data ... 28 104 A.1.3. Opaque data types ............................... 28 105 A.1.4. Pre-existing data types ......................... 28 106 A.2. Improper Data Types .................................. 29 107 A.2.1. Simple Data Types ............................... 29 108 A.2.2. More Complex Data Types ......................... 30 109 A.3. Vendor-Specific formats .............................. 30 110 A.4. Changes to the RADIUS Operational Model .............. 31 111 A.5. Allocation of attributes ............................. 32 112 Appendix B - Complex Attributes .............................. 33 113 B.1. CHAP-Password ........................................ 33 114 B.2. CHAP-Challenge ....................................... 33 115 B.3. Tunnel-Password ...................................... 33 116 B.4. ARAP-Password ........................................ 34 117 B.5. ARAP-Features ........................................ 34 118 B.6. Connect-Info ......................................... 35 119 B.7. Framed-IPv6-Prefix ................................... 36 120 B.8. Egress-VLANID ........................................ 36 121 B.9. Egress-VLAN-Name ..................................... 37 122 B.10. Digest-* ............................................ 37 124 1. Introduction 126 This document provides guidelines for the design of Remote 127 Authentication Dial In User Service (RADIUS) attributes both within 128 the IETF as well as within other SDOs. By articulating RADIUS design 129 guidelines, it is hoped that this document will encourage the 130 development and publication of high quality RADIUS attribute 131 specifications. 133 However, the advice in this document will not be helpful unless it is 134 put to use. As with "Guidelines for Authors and Reviewers of MIB 135 Documents" [RFC4181], it is expected that this document will be used 136 by authors to check their document against the guidelines prior to 137 publication, or requesting review (such as an "Expert Review" 138 described in [RFC3575]). Similarly, it is expected that this 139 document will be used by reviewers (such as WG participants or the 140 AAA Doctors [DOCTORS]), resulting in an improvement in the 141 consistency of reviews. 143 In order to meet these objectives, this document needs to cover not 144 only the science of attribute design, but also the art. Therefore, 145 in addition to covering the most frequently encountered issues, this 146 document explains some of the considerations motivating the 147 guidelines. These considerations include complexity trade-offs that 148 make it difficult to provide "hard and fast" rules for attribute 149 design. This document explains those trade-offs through reviews of 150 current attribute usage. 152 The rest of the document is organized as follows. Section 1 153 discusses the applicability of the guidelines and defines a 154 recommended review process for RADIUS specifications. Section 2 155 defines the design guidelines in terms of what is "RECOMMENDED" and 156 "NOT RECOMMENDED". Section 3 gives a longer explanation of the 157 rationale behind the guidelines given in the previous section. 158 Appendix A repeats the guidelines in a "checklist" format. Appendix 159 B discusses previously defined attributes which do not follow the 160 guidelines. 162 Authors of new RADIUS specifications can be compliant with the design 163 guidelines by working through the checklists given in Appendix A. 164 Reviewers of RADIUS spcifications are expected to be familiar with 165 the entire document. 167 1.1. Terminology 169 This document uses the following terms: 171 Network Access Server (NAS) 172 A device that provides an access service for a user to a network. 174 RADIUS server 175 A RADIUS authentication, authorization, and/or accounting (AAA) 176 server is an entity that provides one or more AAA services to a 177 NAS. 179 standard space 180 Codes in the RADIUS Attribute Type Space which are allocated by 181 IANA and which follow the format defined in RFC 2865 [RFC2865] 182 Section 5. 184 vendor space 185 The contents of the "String" field of a Vendor-Specific Attribute 186 (VSA), as defined in [RFC2865] Section 5.26. These attributes 187 provide a unique attribute type space for each vendor (identified 188 by the Vendor-Type field) which they can self-allocate. 190 1.2. Requirements Language 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in [RFC2119]. 196 1.3. Applicability 198 The advice in this document applies to RADIUS attributes used to 199 encode service-provisioning, authentication, or accounting data, 200 based on the attribute encodings and data formats defined in RFC 2865 201 [RFC2865], RFC 2866 [RFC2866] and subsequent RADIUS RFCs. 203 Since this document represents a Best Current Practice, it does not 204 update or deprecate existing standards. As a result, uses of the 205 terms "MUST" and "MUST NOT" are limited to requirements already 206 present in existing documents. 208 It is RECOMMENDED that these guidelines be followed for all new 209 RADIUS specifications, whether they originate from a vendor, an SDO, 210 or the IETF. Doing so will ensure the widest possible applicability 211 and interoperability of the specifications, while requiring minimal 212 changes to existing systems. In particular, it is expected that 213 RADIUS specifications requesting allocation within the standard space 214 will follow these guidelines, and will explain why this is not 215 possible if they cannot. 217 However, there are situations in which vendors or SDOs can choose not 218 to follow these guidelines without major consequences. As noted in 220 [RFC2865] Section 5.26, Vendor-Specific Attributes (VSAs) are 221 "available to allow vendors to support their own extended Attributes 222 not suitable for general usage." Where vendors or SDOs develop 223 specifications "not suitable for general usage", limited 224 interoperability and inability to use existing implementations may be 225 acceptable and in these situations, vendors and SDOs MAY choose to 226 not conform to these guidelines. 228 Note that the RADEXT WG is currently (as of 2010) involved in 229 developing updates to RADIUS. Those updates will provide their own 230 usage guidelines that may modify some of the guidelines defined here, 231 such as defining new data types, practices, etc. 233 RADIUS protocol changes, or specification of attributes (such as 234 Service-Type) that can, in effect, provide new RADIUS commands 235 require greater expertise and deeper review, as do changes to the 236 RADIUS operational model. As a result, such changes are outside the 237 scope of this document and MUST NOT be undertaken outside the IETF. 239 1.3.1. Reviews 241 For specifications utilizing attributes within the standard space, 242 conformance with the design guidelines in this document is expected 243 unless a good case can be made for an exception. Reviewers SHOULD 244 use the design guidelines as a review checklist. 246 While not required, IETF review may also be beneficial for 247 specifications utilizing the Vendor-Specific space. Experience has 248 shown that attributes not originally designed for general usage can 249 subsequently garner wide-spread deployment. An example is the 250 vendor-specific attributes defined in [RFC2548], which have been 251 widely implemented within IEEE 802.11 Access Points. 253 In order to assist in the development of specifications conforming to 254 these guidelines, authors can request review by sending email to the 255 AAA Doctors [DOCTORS] or equivalent mailing list. The IETF 256 Operations & Management Area Directors will then arrange for the 257 review to be completed and posted to the AAA Doctors mailing list 258 [DOCTORS], RADEXT WG mailing list, or other IETF mailing list. Since 259 reviews are handled by volunteers, responses are provided on a best- 260 effort basis, with no service level guarantees. Authors are 261 encouraged to seek review as early as possible, so as to avoid 262 potential delays. 264 As reviewers require access to the specification, vendors and SDOs 265 are encouraged to make them publicly available. Where the RADIUS 266 specification is embedded within a larger document which cannot be 267 made public, the RADIUS attribute and value definitions can be made 268 available on a public web site or can be published as an 269 Informational RFC, as with [RFC4679]. 271 The review process requires neither allocation of attributes within 272 the IETF standard attribute space nor publication of an IETF RFC. 273 Requiring SDOs or vendors to rehost VSAs into the IETF standards 274 attribute space solely for the purpose of obtaining review would put 275 pressure on the standards space, and may be harmful to 276 interoperability, since would create two ways to provision the same 277 service. Rehosting may also require changes to the RADIUS data model 278 which will affect implementations that do not intend to support the 279 SDO or vendor specifications. 281 Similarly, vendors are encouraged to make their specifications 282 publicly available, for maximum interoperability. However, it is not 283 necessary for a vendor to request publication of a VSA specification 284 as an Informational RFC by the IETF. 286 2. Guidelines 288 The RADIUS protocol as defined in [RFC2865] and [RFC2866] uses 289 elements known as attributes in order to represent authentication, 290 authorization and accounting data. 292 Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does 293 not define a formal data definition language. The data type of 294 RADIUS attributes is not transported on the wire. Rather, the data 295 type of a RADIUS attribute is fixed when an attribute is defined. 296 Based on the RADIUS attribute type code, RADIUS clients and servers 297 can determine the data type based on preconfigured entries within a 298 data dictionary. 300 To explain the implications of this early RADIUS design decision, we 301 distinguish two kinds of data types, namely "basic" and "complex". 302 Basic data types use one of the existing RADIUS data types as defined 303 in Section 2.1, encapsulated in a [RFC2865] RADIUS attribute, or in a 304 [RFC2865] RADIUS VSA. All other data formats are "complex types". 306 RADIUS attributes can be classified into one of three broad 307 categories: 309 * Attributes that are of interest to a single vendor, e.g., for a 310 product or product line. Minimal cross-vendor interoperability 311 is needed. 313 Vendor-Specific Attributes (VSAs) are appropriate for use in 314 this situation. Code-point allocation is managed by the vendor 315 with the number space defined by their Private Enterprise Number 316 (PEN). 318 * Attributes that are of interest to an industry segment, where an 319 SDO defines the attributes for that industry. Multi-vendor 320 interoperability within an industry segment is expected. 322 Vendor-Specific Attributes (VSAs) MUST be used. Code-point 323 allocation is managed by the SDO with the number space defined 324 by the SDOs PEN, rather then the PEN of an individual vendor. 326 * Attributes that are of broad interest to the Internet Community. 327 Multi-vendor interoperability is expected. 329 Attributes within the standard space are appropriate for this 330 purpose, and are allocated via IANA as described in [RFC3575]. 331 Since the standard space represents a finite resource, and is 332 the only attribute space available for use by IETF working 333 groups, vendors and SDOs are encouraged to utilize the VSA 334 space, rather than requesting allocation of attributes from the 335 standard space. Usage of attribute type codes reserved for 336 standard attributes is considered anti-social behavior and is 337 strongly discouraged. 339 2.1. Data Types 341 RADIUS defines a limited set of data types, defined as "basic data 342 types". The following data qualifies as "basic data types": 344 * 32-bit unsigned integer, in network byte order. 346 * Enumerated data types, represented as a 32-bit unsigned integer 347 with a list of name to value mappings. (e.g. Service-Type) 349 * IPv4 address in network byte order. 351 * time as 32 bit unsigned value, in network byte order, and in 352 seconds since 00:00:00 UTC, January 1, 1970. 354 * IPv6 address in network byte order. 356 * Interface-Id (8 octet string in network byte order) 358 * IPv6 prefix. 360 * string (i.e., binary data), totalling 253 octets or less in 361 length. This includes the opaque encapsulation of data 362 structures defined outside of RADIUS. See also Appendix A.1.3, 363 below, for additional discussion. 365 * UTF-8 text [RFC3629], totalling 253 octets or less in length. 367 Note that the length limitations for VSAs of type String and Text are 368 less than 253 octets, due to the additional overhead of the Vendor- 369 Specific encoding. 371 The following data also qualifies as "basic data types": 373 * Attributes grouped into a logical container, using the 374 [RFC2868] tagging mechanism. This approach is NOT RECOMMENDED 375 (see Section 3.2.2), but is permissible where the alternatives 376 are worse. 378 * Attributes requiring the transport of more than 253 octets of 379 Text or String data. This includes the opaque encapsulation 380 of data structures defined outside of RADIUS. 381 (e.g. EAP-Message) 383 All other data formats (including nested attributes) are defined to 384 be "complex data types", and are NOT RECOMMENDED for normal use. 385 Complex data types MAY be used in situations where they reduce 386 complexity in non-RADIUS systems, or where using the basic data types 387 would be awkward (such as where grouping would be required in order 388 to link related attributes). Since there are no "hard and fast" 389 rules for where complexity is best located, each situation has to be 390 decided on a case-by-case basis. Examples of this tradeoff are 391 discussed in Appendix B. Where a complex data type is selected, an 392 explanation SHOULD be offered as to why this was necessary. 394 2.2. Vendor-Specific Attribute Space 396 The Vendor-Specific Attribute space is defined to be the contents of 397 the "String" field of the Vendor-Specific Attribute ([RFC2865] 398 Section 5.26). As discussed there, it is intended for vendors and 399 SDOs to support their own attributes not suitable for general use. 401 While the encoding of attributes within the vendor space is under the 402 control of vendors and SDOs, following the guidelines described here 403 is advantageous since it enables maximum interoperability with 404 minimal changes to existing systems. 406 For example, RADIUS server support for new attributes using "basic 407 data types" can typically be accomplished by editing a RADIUS 408 dictionary, whereas "complex data types" typically require RADIUS 409 server code changes, which can add complexity and delays in 410 implementation. 412 Vendor RADIUS Attribute specifications SHOULD self-allocate 413 attributes from the vendor space, rather than requesting an 414 allocation from within the RADIUS standard attribute space. 416 VSA encodings that do not follow the [RFC2865] Section 5.26 encoding 417 scheme are NOT RECOMMENDED. Although [RFC2865] does not mandate it, 418 implementations commonly assume that the Vendor Id can be used as a 419 key to determine the on-the-wire encoding of a VSA. Vendors 420 therefore SHOULD NOT use multiple encodings for VSAs that are 421 associated with a particular Vendor Id. A vendor wishing to use 422 multiple VSA encodings SHOULD request one Vendor Id for each VSA 423 encoding that they will use. 425 2.3. Service definitions and RADIUS 427 RADIUS specifications define how an existing service or protocol can 428 be provisioned using RADIUS, usually via the Service-Type attribute. 429 Therefore, it is expected that a RADIUS attribute specification will 430 reference documents defining the protocol or service to be 431 provisioned. Within the IETF, a RADIUS attribute specification 432 SHOULD NOT be used to define the protocol or service being 433 provisioned. New services using RADIUS for provisioning SHOULD be 434 defined elsewhere and referenced in the RADIUS specification. 436 New attributes, or new values of existing attributes, SHOULD NOT be 437 used to define new RADIUS commands. RADIUS attributes are intended 438 to: 440 * authenticate users 442 * authorize users (i.e., service provisioning or changes to 443 provisioning) 445 * account for user activity (i.e., logging of session activity) 447 Requirements for allocation of new commands (i.e. the Code field in 448 the packet header) and new attributes within the standard space are 449 described in [RFC3575] Section 2.1. 451 2.4. Translation of Vendor Specifications 453 [RFC2865] Section 5.26 defines Vendor-Specific attributes as follows: 455 This Attribute is available to allow vendors to support their own 456 extended Attributes not suitable for general usage. It MUST NOT 457 affect the operation of the RADIUS protocol. 459 Servers not equipped to interpret the vendor-specific information 460 sent by a client MUST ignore it (although it may be reported). 462 Clients which do not receive desired vendor-specific information 463 SHOULD make an attempt to operate without it, although they may do 464 so (and report they are doing so) in a degraded mode. 466 The limitation on changes to the RADIUS protocol effectively 467 prohibits VSAs from changing fundamental aspects of RADIUS operation, 468 such as modifying RADIUS packet sequences, or adding new commands. 469 However, the requirement for clients and servers to be able to 470 operate in the absence of VSAs has proven to be less of a constraint, 471 since it is still possible for a RADIUS client and server to mutually 472 indicate support for VSAs, after which behavior expectations can be 473 reset. 475 Therefore, RFC 2865 provides considerable latitude for development of 476 new attributes within the vendor space, while prohibiting development 477 of protocol variants. This flexibility implies that RADIUS 478 attributes can often be developed within the vendor space without 479 loss (and possibly even with gain) in functionality. 481 As a result, translation of RADIUS attributes developed within the 482 vendor space into the standard space may provide only modest 483 benefits, while accelerating the exhaustion of the standard attribute 484 space. We do not expect that all RADIUS attribute specifications 485 requiring interoperability will be developed within the IETF, and 486 allocated from the standard space. A more scalable approach is to 487 recognize the flexibility of the vendor space, while working toward 488 improvements in the quality and availability of RADIUS attribute 489 specifications, regardless of where they are developed. 491 It is therefore NOT RECOMMENDED that specifications intended solely 492 for use by a vendor or SDO use be translated into the standard space. 494 3. Rationale 496 This section outlines the rationale behind the above recommendations. 498 3.1. RADIUS Operational Model 500 The RADIUS operational model includes several assumptions: 502 * The RADIUS protocol is stateless; 504 * Provisioning of services is not possible within an 505 Access-Reject or Disconnect-Request; 507 * There is a distinction between authorization checks and user 508 authentication; 510 * The protocol provides for authentication and integrity 511 protection of packets; 513 * The RADIUS protocol is a Request/Response protocol; 515 * The protocol defines packet length restrictions. 517 While RADIUS server implementations may keep state, the RADIUS 518 protocol is stateless, although information may be passed from one 519 protocol transaction to another via the State Attribute. As a 520 result, documents which require stateful protocol behavior without 521 use of the State Attribute are inherently incompatible with RADIUS as 522 defined in [RFC2865], and MUST be redesigned. See [RFC5080] Section 523 2.1.1 for additional discussion surrounding the use of the State 524 Attribute. 526 As noted in [RFC5080] Section 2.6, the intent of an Access-Reject is 527 to deny access to the requested service. As a result, RADIUS does 528 not allow the provisioning of services within an Access-Reject or 529 Disconnect-Request. Documents which include provisioning of services 530 within an Access-Reject or Disconnect-Request are inherently 531 incompatible with RADIUS, and need to be redesigned. 533 As noted in [RFC5176] Section 3: 535 A Disconnect-Request MUST contain only NAS and session 536 identification attributes. If other attributes are included in a 537 Disconnect- Request, implementations MUST send a Disconnect-NAK; 538 an Error-Cause Attribute with value "Unsupported Attribute" MAY be 539 included. 541 As a result, documents which include provisioning of services within 542 a Disconnect-Request are inherently incompatible with RADIUS, and 543 need to be redesigned. 545 As noted in [RFC5080] Section 2.1.1, a RADIUS Access-Request may not 546 contain user authentication attributes or a State Attribute linking 547 the Access-Request to an earlier user authentication. Such an 548 Access-Request, known as an authorization check, provides no 549 assurance that it corresponds to a live user. RADIUS specifications 550 defining attributes containing confidential information (such as 551 Tunnel-Password) should be careful to prohibit such attributes from 552 being returned in response to an authorization check. Also, 553 [RFC5080] Section 2.1.1 notes that authentication mechanisms need to 554 tie a sequence of Access-Request/Access-Challenge packets together 555 into one authentication session. The State Attribute is RECOMMENDED 556 for this purpose. 558 While [RFC2865] did not require authentication and integrity 559 protection of RADIUS Access-Request packets, subsequent 560 authentication mechanism specifications such as RADIUS/EAP [RFC3579] 561 and Digest Authentication [RFC5090] have mandated authentication and 562 integrity protection for certain RADIUS packets. [RFC5080] Section 563 2.1.1 makes this behavior RECOMMENDED for all Access-Request packets, 564 including Access-Request packets performing authorization checks. It 565 is expected that specifications for new RADIUS authentication 566 mechanisms will continue this practice. 568 The RADIUS protocol as defined in [RFC2865] is a request-response 569 protocol spoken between RADIUS clients and servers. A single RADIUS 570 request packet ([RFC2865], [RFC2866], or [RFC5176]) will solicit in 571 response at most a single response packet, sent to the IP address and 572 port of the RADIUS client that originated the request. Changes to 573 this model are likely to require major revisions to existing 574 implementations and so this practice is NOT RECOMMENDED. 576 The Length field in the RADIUS packet header is defined in [RFC2865] 577 Section 3. It is noted there that the maximum length of a RADIUS 578 packet is 4096 octets. As a result, attribute designers SHOULD NOT 579 assume that a RADIUS implementation can successfully process RADIUS 580 packets larger than 4096 octets. 582 Even when packets are less than 4096 octets, they may be larger than 583 the Path Maximum Transmission Unit (PMTU). Any packet larger than 584 the PMTU will be fragmented, making communications more brittle as 585 firewalls and filtering devices often discard fragments. Transport 586 of fragmented UDP packets appears to be a poorly tested code path on 587 network devices. Some devices appear to be incapable of transporting 588 fragmented UDP packets, making it difficult to deploy RADIUS in a 589 network where those devices are deployed. We RECOMMEND that RADIUS 590 messages be kept as small possible. 592 If a situation is envisaged where it may be necessary to carry 593 authentication, authorization or accounting data in a packet larger 594 than 4096 octets, then one of the following approaches is 595 RECOMMENDED: 597 1. Utilization of a sequence of packets. 598 For RADIUS authentication, a sequence of Access-Request/ Access- 599 Challenge packets would be used. For this to be feasible, 600 attribute designers need to enable inclusion of attributes that 601 can consume considerable space within Access-Challenge packets. 602 To maintain compatibility with existing NASes, either the use of 603 Access-Challenge packets needs to be permissible (as with 604 RADIUS/EAP, defined in [RFC3579]), or support for receipt of an 605 Access-Challenge needs to be indicated by the NAS (as in RADIUS 606 Location [RFC5580]). Also, the specification needs to clearly 607 describe how attribute splitting is to be signalled and how 608 attributes included within the sequence are to be interpreted, 609 without requiring stateful operation. Unfortunately, previous 610 specifications have not always exhibited the required foresight. 611 For example, even though very large filter rules are 612 conceivable, the NAS-Filter-Rule Attribute defined in [RFC4849] 613 is not permitted in an Access-Challenge packet, nor is a 614 mechanism specified to allow a set of NAS-Filter-Rule attributes 615 to be split across an Access-Request/Access-Challenge sequence. 617 In the case of RADIUS accounting, transporting large amounts of 618 data would require a sequence of Accounting-Request packets. 619 This is a non-trivial change to RADIUS, since RADIUS accounting 620 clients would need to be modified to split the attribute stream 621 across multiple Accounting-Requests, and billing servers would 622 need to be modified to re-assemble and interpret the attribute 623 stream. 625 2. Utilization of names rather than values. 626 Where an attribute relates to a policy that could conceivably be 627 pre-provisioned on the NAS, then the name of the pre-provisioned 628 policy can be transmitted in an attribute, rather than the 629 policy itself, which could be quite large. An example of this 630 is the Filter-Id Attribute defined in [RFC2865] Section 5.11, 631 which enables a set of pre-provisioned filter rules to be 632 referenced by name. 634 3. Utilization of Packetization Layer Path MTU Discovery 635 techniques, as specified in [RFC4821]. As a last resort, where 636 the above techniques cannot be made to work, it may be possible 637 to apply the techniques described in [RFC4821] to discover the 638 maximum supported RADIUS packet size on the path between a 639 RADIUS client and a home server. While such an approach can 640 avoid the complexity of utilization of a sequence of packets, 641 dynamic discovery is likely to be time consuming and cannot be 642 guaranteed to work with existing RADIUS implementations. As a 643 result, this technique is not generally applicable. 645 3.2. Data Model Issues 647 While [RFC2865] Section 5 defines basic data types, later 648 specifications did not follow this practice. This problem has led 649 implementations to define their own names for data types, resulting 650 in non-standard names for those types. 652 In addition, the number of vendors and SDOs creating new attributes 653 within the Vendor-Specific attribute space has grown, and this has 654 led to some divergence in approaches to RADIUS attribute design. For 655 example, vendors and SDOs have evolved the data model to support 656 functions such as new data types, along with attribute grouping and 657 attribute fragmentation, with different groups taking different 658 approaches. These approaches are often incompatible, leading to 659 additional complexity in RADIUS implementations. 661 In order to avoid repeating old mistakes, this section describes the 662 history of the RADIUS data model, and attempts to codify existing 663 practices. 665 3.2.1. Issues with Definitions of Types 667 [RFC2865] Section 5 explicitly defines five data types: text, string, 668 address, integer and time. Both the names and interpretations of the 669 types are given. 671 Subsequent RADIUS specifications defined attributes by using type 672 names not defined in [RFC2865], without defining the new names as 673 done in [RFC2865]. They did not consistently indicate the format of 674 the value field using the same conventions as [RFC2865]. As a 675 result, the data type is ambiguous in some cases, and may not be 676 consistent among different implementations. 678 It is out of the scope of this document to resolve all potential 679 ambiguities within existing RADIUS specifications. However in order 680 to prevent future ambiguities, it is RECOMMENDED that future RADIUS 681 attribute specifications explicitly define newly created data types 682 at the beginning of the document, and indicate clearly the data type 683 to be used for each attribute. 685 For example, [RFC3162] utilizes but does not explicitly define a type 686 which encapsulates an IPv6 address (Section 2.1 and 2.4), and another 687 type which encapsulates an IPv6 prefix (Section 2.3). The IPv6 688 address attributes confusingly are referenced as type "Address" in 689 the document. This is a similar name as the "address" type defined 690 in [RFC2865], which was defined to refer solely to IPv4 addresses. 692 While the Framed-Interface-Id attribute defined in [RFC3162] Section 693 2.2 included a value field of 8 octets, the data type was not 694 explicitly indicated, and therefore there is controversy over whether 695 the format of the data was intended to be an 8 octet String or 696 whether a special Interface-Id type was intended. 698 Given that attributes encapsulating an IPv6 address and an IPv6 699 prefix are already in use, it is RECOMMENDED that RADIUS server 700 implementations include support for these as basic types, in addition 701 to the types defined in [RFC2865]. Where the intent is to represent 702 a specific IPv6 address, an "IPv6 address" type SHOULD be used. 703 Although it is possible to use an "IPv6 Prefix" type with a prefix 704 length of 128 to represent an IPv6 address, this usage is NOT 705 RECOMMENDED. Implementations supporting the Framed-Interface-Id 706 attribute may select a data type of their choosing (most likely an 8 707 octet String or a special "Interface Id" data type). 709 It is worth noting that since RADIUS only supports unsigned integers 710 of 32 bits, attributes using signed integer data types or unsigned 711 integer types of other sizes will require code changes, and SHOULD be 712 avoided. 714 For [RFC2865] RADIUS VSAs, the length limitation of the String and 715 Text types is 247 octets instead of 253 octets, due to the additional 716 overhead of the Vendor-Specific Attribute. 718 3.2.2. Tagging Mechanism 720 [RFC2868] defines an attribute grouping mechanism based on the use of 721 a one octet tag value. Tunnel attributes that refer to the same 722 tunnel are grouped together by virtue of using the same tag value. 724 This tagging mechanism has some drawbacks. There are a limited 725 number of unique tags (31). The tags are not well suited for use 726 with arbitrary binary data values, because it is not always possible 727 to tell if the first byte after the Length is the tag or the first 728 byte of the untagged value (assuming the tag is optional). 730 Other limitations of the tagging mechanism are that when integer 731 values are tagged, the value portion is reduced to three bytes 732 meaning only 24-bit numbers can be represented. The tagging 733 mechanism does not offer an ability to create nested groups of 734 attributes. Some RADIUS implementations treat tagged attributes as 735 having additional data types tagged-string and tagged-integer. These 736 types increase the complexity of implementing and managing RADIUS 737 systems. 739 For these reasons, the tagging scheme described in RFC 2868 is NOT 740 RECOMMENDED for use as a generic grouping mechanism. 742 3.2.3. Complex Data Types 744 As described in this section, the creation of complex types can lead 745 to interoperability and deployment issues, so they need to be 746 introduced with care. For example, the RADIUS attribute encoding is 747 summarized in [RFC2865]: 749 0 1 2 750 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 752 | Type | Length | Value ... 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 755 However, some standard attributes pack multiple sub-fields into the 756 "Value" field, resulting in the creation a non-standard, i.e. complex 757 type. Separating these sub-fields into different attributes, each 758 with its own type and length, would have the following benefits: 760 * when manual data entry is required, it is easier for an 761 administator to enter the data as well-known types, rather than 762 as complex structures; 764 * it enables additional error checking by leveraging the 765 parsing and validation routines for well-known types; 767 * it simplifies implementations by eliminating special-case 768 attribute-specific parsing. 770 One of the fundamental goals of the RADIUS protocol design was to 771 allow RADIUS servers to be configured to support new attributes 772 without requiring server code changes. RADIUS server implementations 773 typically provide support for basic data types, and define attributes 774 in a data dictionary. This architecture enables a new attribute to 775 be supported by the addition of a dictionary entry, without requiring 776 other RADIUS server code changes. 778 Code changes can also be required in policy management systems and in 779 the RADIUS server's receive path. These changes are due to 780 limitations in RADIUS server policy languages, which commonly provide 781 for limited operations (such as comparisons or arithmetic operations) 782 on the existing data types. Many existing RADIUS policy languages 783 typically are not capable of parsing sub-elements, or providing more 784 sophisticated matching functionality. 786 On the RADIUS client, code changes are typically required in order to 787 implement a new attribute. The RADIUS client typically has to 788 compose the attribute dynamically when sending. When receiving, a 789 RADIUS client needs to be able to parse the attribute and carry out 790 the requested service. As a result, a detailed understanding of the 791 new attribute is required on clients, and data dictionaries are less 792 useful on clients than on servers. 794 Given these limitations, the introduction of new types can require 795 code changes on the RADIUS server which would be unnecessary if basic 796 data types had been used instead. In addition if "ad-hoc" types are 797 used, attribute-specific parsing is required, which means more 798 complex software to develop and maintain. More complexity can lead 799 to more error prone implementations, interoperability problems, and 800 even security vulnerabilities. These issues can increase costs to 801 network administrators as well as reducing reliability and 802 introducing deployment barriers. 804 3.2.4. Complex Data Type Exceptions 806 As described in Section 2.1, the introduction of complex data types 807 is discouraged where viable alternatives are available. A potential 808 exception is attributes that inherently require code changes on both 809 the client and server. For example, as described in Appendix B, 810 complex attributes have been used in situations involving 811 authentication and security attributes which need to be dynamically 812 computed and verified. Supporting this functionality requires code 813 changes on both the RADIUS client and server, regardless of the 814 attribute format. As a result, in most cases, the use of complex 815 attributes to represent these methods is acceptable, and does not 816 create additional interoperability or deployment issues. 818 Another exception to the recommendation against complex types is for 819 types that can be treated as opaque data by the RADIUS server. For 820 example, the EAP-Message attribute, defined in [RFC3579] Section 3.1 821 contains a complex data type that is an EAP packet. Since these 822 complex types do not need to be parsed by the RADIUS server, the 823 issues arising from server limitations do not arise. Similarly, 824 since attributes of these complex types can be configured on the 825 server using a data type of String, dictionary limitations are also 826 not encountered. Appendix A.1 below includes a series of checklists 827 that may be used to analyze a design for RECOMMENDED and NOT 828 RECOMMENDED behavior in relation to complex types. 830 If the RADIUS Server simply passes the contents of an attribute to 831 some non-RADIUS portion of the network, then the data is opaque to 832 RADIUS, and SHOULD be defined to be of type String. A concrete way 833 of judging this requirement is whether or not the attribute 834 definition in the RADIUS document contains delineated fields for sub- 835 parts of the data. If those fields need to be delineated in RADIUS, 836 then the data is not opaque to RADIUS, and it SHOULD be separated 837 into individual RADIUS attributes. 839 An examination of existing RADIUS RFCs discloses a number of complex 840 attributes that have already been defined. Appendix B includes a 841 listing of complex attributes used within [RFC2865], [RFC2868], 842 [RFC2869], [RFC3162], [RFC4818], and [RFC4675]. The discussion of 843 these attributes includes reasons why a complex type is acceptable, 844 or suggestions for how the attribute could have been defined to 845 follow the RADIUS data model. 847 In other cases, the data in the complex type are described textually 848 in a specification. This is possible because the data types are not 849 sent within the attributes, but are a matter for endpoint 850 interpretation. An implementation can define additional data types, 851 and use these data types today by matching them to the attributes 852 textual definition. 854 3.3. Vendor Space 856 The usage model for RADIUS VSAs is described in [RFC2865] Section 857 6.2: 859 Note that RADIUS defines a mechanism for Vendor-Specific 860 extensions (Attribute 26) and the use of that should be encouraged 861 instead of allocation of global attribute types, for functions 862 specific only to one vendor's implementation of RADIUS, where no 863 interoperability is deemed useful. 865 Nevertheless, many new attributes have been defined in the vendor 866 specific space in situations where interoperability is not only 867 useful, but is required. For example, SDOs outside the IETF (such as 868 the IEEE 802 and the 3rd Generation Partnership Project (3GPP)) have 869 been assigned Vendor-Ids, enabling them to define their own VSA 870 encoding and assign Vendor types within their own space. 872 The use of VSAs by SDOs outside the IETF has gained in popularity for 873 several reasons: 875 Efficiency 876 As with SNMP, which defines an "Enterprise" Object Identifier 877 (OID) space suitable for use by vendors as well as other SDOs, the 878 definition of Vendor-Specific RADIUS attributes has become a 879 common occurrence as part of standards activity outside the IETF. 880 For reasons of efficiency, it is easiest if the RADIUS attributes 881 required to manage a standard are developed within the same SDO 882 that develops the standard itself. As noted in "Transferring MIB 883 Work from IETF Bridge MIB WG to IEEE 802.1 WG" [RFC4663], today 884 few vendors are willing to simultaneously fund individuals to 885 participate within an SDO to complete a standard, as well as to 886 participate in the IETF in order to complete the associated RADIUS 887 attributes specification. 889 Attribute scarcity 890 The standard RADIUS attribute space is limited to 255 unique 891 attributes. Of these, only about half remain available for 892 allocation. In the vendor space, the number of attributes 893 available is a function of the encoding of the attribute (the size 894 of the Vendor type field). 896 3.3.1. Interoperability Considerations 898 Vendors and SDOs are reminded that the standard RADIUS attribute 899 space, and the enumerated value space for enumerated attributes, are 900 reserved for allocation through work published via the IETF, as noted 901 in [RFC3575] Section 2.1. Some vendors and SDOs have in the past 902 assigning vendor-specific meaning to "unused" values from the 903 standard space. This process results in interoperability issues, and 904 is counter-productive. Similarly, the Vendor-Specific enumeration 905 practice discussed in [RFC2882] Section 2.2.1 is NOT RECOMMENDED. 907 If it is not possible to follow the IETF process, vendors and SDOs 908 SHOULD self-allocate an attribute, which MUST be in their own vendor 909 space, as discussed in Sections 3.3.2 and 3.3.3, below. 911 The design and specification of VSAs for multi-vendor usage SHOULD be 912 undertaken with the same level of care as standard RADIUS attributes. 913 Specifically, the provisions of this document that apply to standard 914 RADIUS attributes also apply to VSAs for multi-vendor usage. 916 3.3.2. Vendor Allocations 918 As noted in [RFC3575] Section 2.1, vendors are encouraged to utilize 919 VSAs to define functions "specific only to one vendor's 920 implementation of RADIUS, where no interoperability is deemed useful. 921 For functions specific only to one vendor's implementation of RADIUS, 922 the use of that should be encouraged instead of the allocation of 923 global attribute types." 925 The recommendation for vendors to allocate attributes from a vendor 926 space rather than via the IETF process is a recognition that vendors 927 desire to assert change control over their own RADIUS specifications. 928 This change control can be obtained by requesting a PEN from the 929 Internet Assigned Number Authority (IANA), for use as a Vendor-Id 930 within a Vendor-Specific attribute. The vendor can then allocate 931 attributes within the VSA space defined by that Vendor-Id, at their 932 sole discretion. Similarly, the use of data types (complex or 933 otherwise) within that VSA space is solely under the discretion of 934 the vendor. 936 3.3.3. SDO Allocations 938 Given the expanded utilization of RADIUS, it has become apparent that 939 requiring SDOs to accomplish all their RADIUS work within the IETF is 940 inherently inefficient and unscalable. Is is therefore RECOMMENDED 941 that SDO RADIUS Attribute specifications allocate attributes from the 942 vendor space, rather than requesting an allocation from the RADIUS 943 standard attribute space, for attributes matching any of the 944 following criteria: 946 * attributes relying on data types not defined within RADIUS 948 * attributes intended primarily for use within an SDO 950 * attributes intended primarily for use within a group of SDOs. 952 Any new RADIUS attributes or values intended for interoperable use 953 across a broad spectrum of the Internet Community SHOULD follow the 954 allocation process defined in [RFC3575]. 956 The recommendation for SDOs to allocate attributes from a vendor 957 space rather than via the IETF process is a recognition that SDOs 958 desire to assert change control over their own RADIUS specifications. 959 This change control can be obtained by requesting a PEN from the 960 Internet Assigned Number Authority (IANA), for use as a Vendor-Id 961 within a Vendor-Specific attribute. The SDO can then allocate 962 attributes within the VSA space defined by that Vendor-Id, at their 963 sole discretion. Similarly, the use of data types (complex or 964 otherwise) within that VSA space is solely under the discretion of 965 the SDO. 967 3.4. Polymorphic Attributes 969 A polymorphic attribute is one whose format or meaning is dynamic. 970 For example, rather than using a fixed data format, an attribute's 971 format might change based on the contents of another attribute. Or, 972 the meaning of an attribute may depend on earlier packets in a 973 sequence. 975 RADIUS server dictionary entries are typically static, enabling the 976 user to enter the contents of an attribute without support for 977 changing the format based on dynamic conditions. However, this 978 limitation on static types does not prevent implementations from 979 implementing policies that return different attributes based on the 980 contents of received attributes; this is a common feature of existing 981 RADIUS implementations. 983 In general, polymorphism is NOT RECOMMENDED. Polymorphism rarely 984 enables capabilities that would not be available through use of 985 multiple attributes. Polymorphism requires code changes in the 986 RADIUS server in situations where attributes with fixed formats would 987 not require such changes. Thus, polymorphism increases complexity 988 while decreasing generality, without delivering any corresponding 989 benefits. 991 Note that changing an attribute's format dynamically is not the same 992 thing as using a fixed format and computing the attribute itself 993 dynamically. RADIUS authentication attributes such as User-Password, 994 EAP-Message, etc. while being computed dynamically, use a fixed 995 format. 997 4. IANA Considerations 999 This document has no action items for IANA. However, it does provide 1000 guidelines for Expert Reviewers appointed as described in [RFC3575]. 1002 5. Security Considerations 1004 This specification provides guidelines for the design of RADIUS 1005 attributes used in authentication, authorization and accounting. 1006 Threats and security issues for this application are described in 1007 [RFC3579] and [RFC3580]; security issues encountered in roaming are 1008 described in [RFC2607]. 1010 Obfuscation of RADIUS attributes on a per-attribute basis is 1011 necessary in some cases. The current standard mechanism for this is 1012 described in [RFC2865] Section 5.2 (for obscuring User-Password 1013 values) and is based on the MD5 algorithm specified in [RFC1321]. 1014 The MD5 and SHA-1 algorithms have recently become a focus of scrutiny 1015 and concern in security circles, and as a result, the use of these 1016 algorithms in new attributes is NOT RECOMMENDED. In addition, 1017 previous documents referred to this method as generating "encrypted" 1018 data. This terminology is no longer accepted within the 1019 cryptographic community. 1021 Where new RADIUS attributes use cryptographic algorithms, algorithm 1022 negotiation SHOULD be supported. Specification of a mandatory-to- 1023 implement algorithm is REQUIRED, and it is RECOMMENDED that the 1024 mandatory-to-implement algorithm be certifiable under FIPS 140 1025 [FIPS]. 1027 Where new RADIUS attributes encapsulate complex data types, or 1028 transport opaque data, the security considerations discussed in 1029 Section 5.1 SHOULD be addressed. 1031 Message authentication in RADIUS is provided largely via the Message- 1032 Authenticator attribute. See [RFC3579] Section 3.2, and also 1033 [RFC5080] 2.2.2, which says that client implementations SHOULD 1034 include a Message-Authenticator attribute in every Access-Request. 1036 In general, the security of the RADIUS protocol is poor. Robust 1037 deployments SHOULD support a secure communications protocol such as 1038 IPSec. See [RFC3579] Section 4, and [RFC3580] Section 5 for a more 1039 in-depth explanation of these issues. 1041 Implementations not following the suggestions outlined in this 1042 document may be subject to a problems such as ambiguous protocol 1043 decoding, packet loss leading to loss of billing information, and 1044 denial of service attacks. 1046 5.1. New Data Types and Complex Attributes 1048 The introduction of complex data types brings the potential for the 1049 introduction of new security vulnerabilities. Experience shows that 1050 the common data types have few security vulnerabilities, or else that 1051 all known issues have been found and fixed. New data types require 1052 new code, which may introduce new bugs, and therefore new attack 1053 vectors. 1055 Some systems permit complex attributes to be defined via a method 1056 that is more capable than traditional RADIUS dictionaries. These 1057 systems can reduce the security threat of new types significantly, 1058 but they do not remove it entirely. 1060 RADIUS servers are highly valued targets, as they control network 1061 access and interact with databases that store usernames and 1062 passwords. An extreme outcome of a vulnerability due to a new, 1063 complex type would be that an attacker is capable of taking complete 1064 control over the RADIUS server. 1066 The use of attributes representing opaque data does not reduce this 1067 threat. The threat merely moves from the RADIUS server to the system 1068 that consumes that opaque data. The threat is particularly severe 1069 when the opaque data originates from the user, and is not validated 1070 by the NAS. In those cases, the RADIUS server is potentially exposed 1071 to attack by malware residing on an unauthenticated host. 1073 Any system consuming opaque data that originates from a RADIUS system 1074 SHOULD be properly isolated from that RADIUS system, and SHOULD run 1075 with minimal privileges. Any potential vulnerabilities in the non- 1076 RADIUS system will then have minimal impact on the security of the 1077 system as a whole. 1079 6. References 1081 6.1. Normative References 1083 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1084 Requirement Levels", BCP 14, RFC 2119, March 1997. 1086 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 1087 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1088 2000. 1090 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1091 Authentication Dial In User Service)", RFC 3575, July 2003. 1093 6.2. Informative References 1095 [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of 1096 management information for TCP/IP-based internets", STD 16, 1097 RFC 1155, May 1990. 1099 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 1100 Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1101 1990. 1103 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1104 April 1992. 1106 [RFC2548] Zorn, Glen, "Microsoft Vendor-specific RADIUS Attributes", RFC 1107 2548, March 1999. 1109 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1110 Implementation in Roaming", RFC 2607, June 1999. 1112 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1114 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., 1115 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 1116 Support", RFC 2868, June 2000. 1118 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", 1119 RFC 2869, June 2000. 1121 [RFC2882] Mitton, D, "Network Access Servers Requirements: Extended 1122 RADIUS Practices", RFC 2882, July 2000. 1124 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 1125 3162, August 2001. 1127 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 1128 In User Service) Support For Extensible Authentication 1129 Protocol (EAP)", RFC 3579, September 2003. 1131 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE 1132 802.1X Remote Authentication Dial In User Service (RADIUS) 1133 Usage Guidelines", RFC3580, September 2003. 1135 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1136 RFC 3629, November 2003. 1138 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 1139 Documents", RFC 4181, September 2005. 1141 [RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge MIB WG 1142 to IEEE 802.1 WG", RFC 4663, September 2006. 1144 [RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for 1145 Virtual LAN and Priority Support", RFC 4675, September 2006. 1147 [RFC4679] Mammoliti, V., et al., "DSL Forum Vendor-Specific RADIUS 1148 Attributes", RFC 4679, September 2006. 1150 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 1151 Attribute", RFC 4818, April 2007. 1153 [RFC4821] Mathis, M. and Heffner, J, "Packetization Layer Path MTU 1154 Discovery", RFC 4821, March 2007. 1156 [RFC4849] Congdon, P. et al, "RADIUS Filter-Rule Attribute", RFC 4849, 1157 April 2007. 1159 [RFC5080] Nelson, D. and DeKok, A, "Common Remote Authentication Dial In 1160 User Service (RADIUS) Implementation Issues and Suggested 1161 Fixes", RFC 5080, December 2007. 1163 [RFC5090] Sterman, B. et al., "RADIUS Extension for Digest 1164 Authentication", RFC 5090, February 2008. 1166 [RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote 1167 Authentication Dial In User Service (RADIUS)", RFC 5176, 1168 January 2008. 1170 [DOCTORS] AAA Doctors Mailing list 1172 [FIPS] FIPS 140-3 (DRAFT), "Security Requirements for Cryptographic 1173 Modules", http://csrc.nist.gov/publications/fips/fips140-3/ 1175 [IEEE-802.1Q] 1176 IEEE Standards for Local and Metropolitan Area Networks: Draft 1177 Standard for Virtual Bridged Local Area Networks, 1178 P802.1Q-2003, January 2003. 1180 [RFC5580] Tschofenig, H. (Ed.), "Carrying Location Objects in RADIUS and 1181 Diameter", RFC 5580, August 2009. 1183 [AAA-SIP] Sterman, B. et al., "RADIUS Extension for Digest 1184 Authentication", draft-sterman-sip-aaa-00.txt, November 2001 1185 (expired). 1187 Appendix A - Design Guidelines 1189 The following text provides guidelines for the design of attributes 1190 used by the RADIUS protocol. Specifications that follow these 1191 guidelines are expected to achieve maximum interoperability with 1192 minimal changes to existing systems. 1194 A.1. Types matching the RADIUS data model 1196 A.1.1. Transport of basic data types 1198 Does the data fit within the basic data types described in Section 1199 2.1? If so, it SHOULD be encapsulated in a [RFC2865] format RADIUS 1200 attribute, or in a [RFC2865] format RADIUS VSA that uses one of the 1201 existing RADIUS data types. 1203 A.1.2. Transport of Authentication and Security Data 1205 Does the data provide authentication and/or security capabilities for 1206 the RADIUS protocol, as outlined below? If so, use of a complex data 1207 type is acceptable, under the following circumstances: 1209 * Complex data types that carry authentication methods which 1210 RADIUS servers are expected to parse and verify as part of 1211 an authentication process. 1213 * Complex data types that carry security information intended 1214 to increase the security of the RADIUS protocol itself. 1216 Any data type carrying authentication and/or security data that is 1217 not meant to be parsed by a RADIUS server is an "opaque data type", 1218 as defined below. 1220 A.1.3. Opaque data types 1222 Does the attribute encapsulate an existing data structure defined 1223 outside of the RADIUS specifications? Can the attribute be treated 1224 as opaque data by RADIUS servers (including proxies?) If both 1225 questions can be answered affirmatively, a complex structure MAY be 1226 used in a RADIUS specification. 1228 The specification of the attribute SHOULD define the encapsulating 1229 attribute to be of type String. The specification SHOULD refer to an 1230 external document defining the structure. The specification SHOULD 1231 NOT define or describe the structure, for reasons discussed above in 1232 Section 3.2.3. 1234 A.1.4. Pre-existing data types 1235 There is a trade-off in design between re-using existing formats for 1236 historical compatibility, or choosing new formats for a "better" 1237 design. This trade-off does not always require the "better" design 1238 to be used. As a result, pre-existing complex data types described 1239 in Appendix B MAY be used. 1241 A.2. Improper Data Types 1243 This section suggests alternatives to data types which do not fall 1244 within the "basic data type" definition. Section A.2.1 describes 1245 simple data types which should be replaced by basic data types. 1246 Section A.2.2 descibes more complex data types which should be 1247 replaced by multiple attributes using the basic data types. 1249 A.2.1. Simple Data Types 1251 Does the attribute use any of the following data types? If so, the 1252 data type SHOULD be replaced with the suggested alternatives, or it 1253 SHOULD NOT be used at all. 1255 * Signed integers of any size. 1256 SHOULD NOT be used. SHOULD be replaced with one or more 1257 unsigned integer attributes. The definition of the attribute 1258 can contain information that would otherwise go into the sign 1259 value of the integer. 1261 * 8 bit unsigned integers. 1262 SHOULD be replaced with 32-bit unsigned integer. There is 1263 insufficient justification to save three bytes. 1265 * 16 bit unsigned integers. 1266 SHOULD be replaced with 32-bit unsigned integer. There is 1267 insufficient justification to save two bytes. 1269 * Unsigned integers of size other than 32 bits. 1270 SHOULD be replaced by an unsigned integer of 32 bits. 1271 There is insufficient justification to define a new size of 1272 integer. 1274 * Integers of any size in non-network byte order 1275 SHOULD be replaced by unsigned integer of 32 bits in network 1276 There is no reason to transport integers in any format other 1277 than network byte order. 1279 * Multi-field text strings. 1280 Each field SHOULD be encapsulated in a separate attribute. 1282 * Polymorphic attributes. 1284 Multiple attributes, each with a static data type SHOULD be 1285 defined instead. 1287 * Nested AVPs. 1288 Attributes should be defined in a flat typespace. 1290 A.2.2. More Complex Data Types 1292 Does the attribute: 1294 * define a complex data type not described in Appendix B, 1296 * that a RADIUS server and/or client is expected to parse, 1297 validate, or create the contents of via a dynamic computation? 1298 i.e. A type that cannot be treated as opaque data (Section A.1.3) 1300 * involve functionality that could be implemented without code 1301 changes on both the client and server? (i.e. a type that doesn't 1302 require dynamic computation and verification, such as those 1303 performed for authentication or security attributes) 1305 If so, this data type SHOULD be replaced with simpler types, as 1306 discussed above in Appendix A.2.1. See also Section 2.1 for a 1307 discussion of why complex types are problematic. 1309 A.3. Vendor-Specific formats 1311 Does the specification contain Vendor-Specific attributes that match 1312 any of the following criteria? If so, the VSA encoding should be 1313 replaced with the [RFC2865] Section 5.26 encoding, or should not be 1314 used at all. 1316 * Vendor types of more than 8 bits. 1317 SHOULD NOT be used. Vendor types of 8 bits SHOULD be used 1318 instead. 1320 * Vendor lengths of less than 8 bits. (i.e., zero bits) 1321 SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used 1322 instead. 1324 * Vendor lengths of more than 8 bits. 1325 SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used 1326 instead. 1328 * Vendor-Specific contents that are not in Type-Length-Value 1329 format. 1330 SHOULD NOT be used. Vendor-Specific attributes SHOULD be in 1331 Type-Length-Value format. 1333 In general, Vendor-Specific attributes SHOULD follow the [RFC2865] 1334 Section 5.26 suggested encoding. Vendor extensions to non-standard 1335 encodings are NOT RECOMMENDED as they can negatively affect 1336 interoperability. 1338 A.4. Changes to the RADIUS Operational Model 1340 Does the specification change the RADIUS operation model, as outlined 1341 in the list below? If so, then another method of achieving the 1342 design objectives SHOULD be used. Potential problem areas include: 1344 * Defining new commands in RADIUS using attributes. 1345 The addition of new commands to RADIUS MUST be handled via 1346 allocation of a new Code, and not by the use of an attribute. 1347 This restriction includes new commands created by overloading 1348 the Service-Type attribute to define new values that modify 1349 the functionality of Access-Request packets. 1351 * Using RADIUS as a transport protocol for data unrelated to 1352 authentication, authorization, or accounting. Using RADIUS to 1353 transport authentication methods such as EAP is explicitly 1354 permitted, even if those methods require the transport of 1355 relatively large amounts of data. Transport of opaque data 1356 relating to AAA is also permitted, as discussed above in 1357 Section 3.2.3. However, if the specification does not relate 1358 to AAA, then RADIUS SHOULD NOT be used. 1360 * Assuming support for packet lengths greater than 4096 octets. 1361 Attribute designers cannot assume that RADIUS implementations 1362 can successfully handle packets larger than 4096 octets. 1363 If a specification could lead to a RADIUS packet larger than 1364 4096 octets, then the alternatives described in Section 3.3 1365 SHOULD be considered. 1367 * Stateless operation. The RADIUS protocol is stateless, and 1368 documents which require stateful protocol behavior without the 1369 use of the State Attribute need to be redesigned. 1371 * Provisioning of service in an Access-Reject. 1372 Such provisioning is not permitted, and MUST NOT be used. If 1373 limited access needs to be provided, then an Access-Accept with 1374 appropriate authorizations can be used instead. 1376 * Provisioning of service in a Disconnect-Request. 1377 Such provisioning is not permitted, and MUST NOT be used. 1378 If limited access needs to be provided, then a CoA-Request 1379 with appropriate authorizations can be used instead. 1381 * Lack of user authentication or authorization restrictions. 1382 In an authorization check, where there is no demonstration of a 1383 live user, confidential data cannot be returned. Where there 1384 is a link to a previous user authentication, the State attribute 1385 SHOULD be present. 1387 * Lack of per-packet integrity and authentication. 1388 It is expected that documents will support per-packet 1389 integrity and authentication. 1391 * Modification of RADIUS packet sequences. 1392 In RADIUS, each request is encapsulated in its own packet, and 1393 elicits a single response that is sent to the requester. Since 1394 changes to this paradigm are likely to require major 1395 modifications to RADIUS client and server implementations, they 1396 SHOULD be avoided if possible. 1397 For further details, see Section 3.1. 1399 A.5. Allocation of attributes 1401 Does the attribute have a limited scope of applicability, as outlined 1402 below? If so, then the attributes SHOULD be allocated from the 1403 vendor space, rather than requesting allocation from the standard 1404 space. 1406 * attributes intended for a vendor to support their own systems, 1407 and not suitable for general usage 1409 * attributes relying on data types not defined within RADIUS 1411 * attributes intended primarily for use within an SDO 1413 * attributes intended primarily for use within a group of SDOs. 1415 Note that the points listed above do not relax the recommendations 1416 discussed in this document. Instead, they recognize that the RADIUS 1417 data model has limitations. In certain situations where 1418 interoperability can be strongly constrained by the SDO or vendor, an 1419 expanded data model MAY be used. It is RECOMMENDED, however, that 1420 the RADIUS data model be used, even when it is marginally less 1421 efficient than alternatives. 1423 When attributes are used primarily within a group of SDOs, and are 1424 not applicable to the wider Internet community, we expect that one 1425 SDO will be responsible for allocation from their own private space. 1427 Appendix B - Complex Attributes 1429 This section summarizes RADIUS attributes with complex data types 1430 that are defined in existing RFCs. 1432 This appendix is published for informational purposes only, and 1433 reflects the usage of attributes with complex data types at the time 1434 of the publication of this document. 1436 B.1. CHAP-Password 1438 [RFC2865] Section 5.3 defines the CHAP-Password Attribute which is 1439 sent from the RADIUS client to the RADIUS server in an Access- 1440 Request. The data type of the CHAP Identifier is not given, only the 1441 one octet length: 1443 0 1 2 1444 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 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1446 | Type | Length | CHAP Ident | String ... 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1449 Since this is an authentication attribute, code changes are required 1450 on the RADIUS client and server to support it, regardless of the 1451 attribute format. Therefore, this complex data type is acceptable in 1452 this situation. 1454 B.2. CHAP-Challenge 1456 [RFC2865] Section 5.40 defines the CHAP-Challenge Attribute which is 1457 sent from the RADIUS client to the RADIUS server in an Access- 1458 Request. While the data type of the CHAP Identifier is given, the 1459 text also says: 1461 If the CHAP challenge value is 16 octets long it MAY be placed in 1462 the Request Authenticator field instead of using this attribute. 1464 Defining attributes to contain values taken from the RADIUS packet 1465 header is NOT RECOMMENDED. Attributes should have values that are 1466 packed into a RADIUS AVP. 1468 B.3. Tunnel-Password 1470 [RFC2868] Section 3.5 defines the Tunnel-Password Attribute, which is 1471 sent from the RADIUS server to the client in an Access-Accept. This 1472 attribute includes Tag and Salt fields, as well as a string field 1473 which consists of three logical sub-fields: the Data-Length (one 1474 octet) and Password sub-fields (both of which are required), and the 1475 optional Padding sub-field. The attribute appears as follows: 1477 0 1 2 3 1478 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 1479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 | Type | Length | Tag | Salt 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 Salt (cont) | String ... 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 Since this is a security attribute, code changes are required on the 1486 RADIUS client and server to support it, regardless of the attribute 1487 format. However, while use of a complex data type is acceptable in 1488 this situation, the design of the Tunnel-Password attribute is 1489 problematic from a security perspective, since it uses MD5 as a 1490 cipher, and provides a password to a NAS, potentially without proper 1491 authorization. 1493 B.4. ARAP-Password 1495 [RFC2869] Section 5.4 defines the ARAP-Password attribute, which is 1496 sent from the RADIUS client to the server in an Access-Request. It 1497 contains four 4 octet values, instead of having a single Value field: 1499 0 1 2 3 1500 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 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 | Type | Length | Value1 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 | Value2 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 | Value3 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 | Value4 1509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1510 | 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 As with the CHAP-Password attribute, this is an authentication 1514 attribute which would have required code changes on the RADIUS client 1515 and server regardless of format. 1517 B.5. ARAP-Features 1519 [RFC2869] Section 5.5 defines the ARAP-Features Attribute, which is 1520 sent from the RADIUS server to the client in an Access-Accept or 1521 Access-Challenge. It contains a compound string of two single octet 1522 values, plus three 4-octet values, which the RADIUS client 1523 encapsulates in a feature flags packet in the ARAP protocol: 1525 0 1 2 3 1526 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 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 | Type | Length | Value1 | Value2 | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 | Value3 | 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 | Value4 | 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 | Value5 | 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 Unlike the previous attributes, this attribute contains no encrypted 1538 component, nor is it directly involved in authentication. The 1539 individual sub-fields therefore could have been encapsulated in 1540 separate attributes. 1542 While the contents of this attribute is intended to be placed in an 1543 ARAP packet, the fields need to be set by the RADIUS server. Using 1544 standard RADIUS data types would have simplified RADIUS server 1545 implementations, and subsequent management. The current form of the 1546 attribute requires either the RADIUS server implementation, or the 1547 RADIUS server administrator, to understand the internals of the ARAP 1548 protocol. 1550 B.6. Connect-Info 1552 [RFC2869] Section 5.11 defines the Connect-Info attribute, which is 1553 used to indicate the nature of the connection. 1555 0 1 2 1556 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 | Type | Length | Text... 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 Even though the type is Text, the rest of the description indicates 1562 that it is a complex attribute: 1564 The Text field consists of UTF-8 encoded 10646 _8_ characters. 1565 The connection speed SHOULD be included at the beginning of the 1566 first Connect-Info attribute in the packet. If the transmit and 1567 receive connection speeds differ, they may both be included in the 1568 first attribute with the transmit speed first (the speed the NAS 1569 modem transmits at), a slash (/), the receive speed, then 1570 optionally other information. 1572 For example, "28800 V42BIS/LAPM" or "52000/31200 V90" 1574 More than one Connect-Info attribute may be present in an 1575 Accounting-Request packet to accommodate expected efforts by ITU 1576 to have modems report more connection information in a standard 1577 format that might exceed 252 octets. 1579 This attribute contains no encrypted component, and is it not 1580 directly involved in authentication. The individual sub-fields could 1581 therefore have been encapsulated in separate attributes. 1583 However, since the definition refers to potential standardization 1584 activity within ITU, the Connect-Info attribute can also be thought 1585 of as opaque data whose definition is provided elsewhere. The 1586 Connect-Info attribute could therefore qualify for an exception as 1587 described in Section 3.2.3. 1589 B.7. Framed-IPv6-Prefix 1591 [RFC3162] Section 2.3 defines the Framed-IPv6-Prefix Attribute and 1592 [RFC4818] Section 3 reuses this format for the Delegated-IPv6-Prefix 1593 Attribute; these attributes are sent from the RADIUS server to the 1594 client in an Access-Accept. 1596 0 1 2 3 1597 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 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 | Type | Length | Reserved | Prefix-Length | 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 Prefix 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 Prefix 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 Prefix 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 Prefix | 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1610 The sub-fields encoded in these attributes are strongly related, and 1611 there was no previous definition of this data structure that could be 1612 referenced. Support for this attribute requires code changes on both 1613 the client and server, due to a new data type being defined. In this 1614 case it appears to be acceptable to encode them in one attribute. 1616 B.8. Egress-VLANID 1618 [RFC4675] Section 2.1 defines the Egress-VLANID Attribute which can 1619 be sent by a RADIUS client or server. 1621 0 1 2 3 1622 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 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 | Type | Length | Value 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1626 Value (cont) | 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 While it appears superficially to be of type Integer, the Value field 1630 is actually a packed structure, as follows: 1632 0 1 2 3 1633 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 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | Tag Indic. | Pad | VLANID | 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 The length of the VLANID field is defined by the [IEEE-802.1Q] 1639 specification. The Tag indicator field is either 0x31 or 0x32, for 1640 compatibility with the Egress-VLAN-Name, as discussed below. The 1641 complex structure of Egress-VLANID overlaps with that of the base 1642 Integer data type, meaning that no code changes are required for a 1643 RADIUS server to support this attribute. Code changes are required 1644 on the NAS, if only to implement the VLAN ID enforcement. 1646 Given the IEEE VLAN requirements and the limited data model of 1647 RADIUS, the chosen method is likely the best of the possible 1648 alternatives. 1650 B.9. Egress-VLAN-Name 1652 [RFC4675] Section 2.3 defines the Egress-VLAN-Name Attribute which 1653 can be sent by a RADIUS client or server. 1655 0 1 2 3 1656 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 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 | Type | Length | Tag Indic. | String... 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 The Tag Indicator is either the character '1' or '2', which in ASCII 1662 map to the identical values for Tag Indicator in Egress-VLANID, 1663 above. The complex structure of this attribute is acceptable for 1664 reasons identical to those given for Egress-VLANID. 1666 B.10. Digest-* 1668 [RFC5090] attempts to standardize the functionality provided by an 1669 expired internet-draft [AAA-SIP] which improperly used two attributes 1670 from the standard space without being assigned them by IANA. This 1671 self-allocation is forbidden, as described above in Section 2. In 1672 addition, the draft uses nested attributes, which are discouraged in 1673 Section 2.1. The updated document uses basic data types, and 1674 allocates nearly 20 attributes in the process. 1676 However, the draft has seen wide-spread implementation, where 1677 [RFC5090] has not. One explanation may be that implementors 1678 disagreed with the trade-offs made in the updated specification. It 1679 may have been better to simply document the existing format, and 1680 request IANA allocation of two attributes. The resulting design 1681 would have used nested attributes, but may have gained more wide- 1682 spread implementation. 1684 Acknowledgments 1686 We would like to acknowledge David Nelson, Bernard Aboba, Emile van 1687 Bergen, Barney Wolff, Glen Zorn, Avi Lior, and Hannes Tschofenig for 1688 contributions to this document. 1690 Authors' Addresses 1692 Greg Weber 1693 Knoxville, TN 37932 1694 USA 1696 Email: gdweber@gmail.com 1698 Alan DeKok 1699 The FreeRADIUS Server Project 1700 http://freeradius.org/ 1702 Email: aland@freeradius.org