idnits 2.17.1 draft-ietf-radext-design-17.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 (26 July 2010) is 4994 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: February 26, 2011 7 26 July 2010 9 RADIUS Design Guidelines 10 draft-ietf-radext-design-17 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 February 26, 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 ...................... 10 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 ............... 15 86 3.2.2. Tagging Mechanism .............................. 17 87 3.2.3. Complex Data Types ............................. 17 88 3.2.4. Complex Data Type Exceptions ................... 18 89 3.3. Vendor Space ........................................ 19 90 3.3.1. Interoperability Considerations ................ 20 91 3.3.2. Vendor Allocations ............................. 21 92 3.3.3. SDO Allocations ................................ 21 93 3.4. Polymorphic Attributes .............................. 22 94 4. IANA Considerations ...................................... 22 95 5. Security Considerations .................................. 23 96 5.1. New Data Types and Complex Attributes ............... 23 97 6. References ............................................... 24 98 6.1. Normative References ................................ 24 99 6.2. Informative References .............................. 24 100 Appendix A - Design Guidelines ............................... 27 101 A.1. Types matching the RADIUS data model ................. 27 102 A.1.1. Transport of basic data types ................... 27 103 A.1.2. Transport of Authentication and Security Data ... 27 104 A.1.3. Opaque data types ............................... 27 105 A.1.4. Pre-existing data types ......................... 27 106 A.2. Improper Data Types .................................. 28 107 A.2.1. Simple Data Types ............................... 28 108 A.2.2. More Complex Data Types ......................... 29 109 A.3. Vendor-Specific formats .............................. 29 110 A.4. Changes to the RADIUS Operational Model .............. 30 111 A.5. Allocation of attributes ............................. 31 112 Appendix B - Complex Attributes .............................. 32 113 B.1. CHAP-Password ........................................ 32 114 B.2. CHAP-Challenge ....................................... 32 115 B.3. Tunnel-Password ...................................... 32 116 B.4. ARAP-Password ........................................ 33 117 B.5. ARAP-Features ........................................ 33 118 B.6. Connect-Info ......................................... 34 119 B.7. Framed-IPv6-Prefix ................................... 35 120 B.8. Egress-VLANID ........................................ 35 121 B.9. Egress-VLAN-Name ..................................... 36 122 B.10. Digest-* ............................................ 36 124 1. Introduction 126 This document provides guidelines for the design of RADIUS attributes 127 both within the IETF as well as within other SDOs. By articulating 128 RADIUS design guidelines, it is hoped that this document will 129 encourage the development and publication of high quality RADIUS 130 attribute specifications. 132 However, the advice in this document will not be helpful unless it is 133 put to use. As with "Guidelines for Authors and Reviewers of MIB 134 Documents" [RFC4181], it is expected that this document will be used 135 by authors to check their document against the guidelines prior to 136 publication, or requesting review (such as an "Expert Review" 137 described in [RFC3575]). Similarly, it is expected that this 138 document will used by reviewers (such as WG participants or the AAA 139 Doctors [DOCTORS]), resulting in an improvement in the consistency of 140 reviews. 142 In order to meet these objectives, this document needs to cover not 143 only the science of attribute design, but also the art. Therefore, 144 in addition to covering the most frequently encountered issues, this 145 document explains some of the considerations motivating the 146 guidelines. These considerations include complexity trade-offs that 147 make it difficult to provide "hard and fast" rules for attribute 148 design. This document explains those trade-offs through reviews of 149 current attribute usage. 151 1.1. Terminology 153 This document uses the following terms: 155 Network Access Server (NAS) 156 A device that provides an access service for a user to a network. 158 RADIUS server 159 A RADIUS authentication, authorization, and/or accounting (AAA) 160 server is an entity that provides one or more AAA services to a 161 NAS. 163 standard space 164 RADIUS attributes which are allocated by IANA and which follow the 165 format defined in RFC 2865 [RFC2865] Section 5. 167 vendor space 168 The contents of the "String" field of a Vendor-Specific Attribute 169 (VSA), as defined in [RFC2865] Section 5.26. These attributes 170 provide a unique attribute space for each vendor (identified by the 171 Vendor-Type field) which they can self-allocate. 173 1.2. Requirements Language 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in [RFC2119]. 179 1.3. Applicability 181 The advice in this document applies to attributes used to encode 182 service-provisioning, authentication, or accounting data, based on 183 the attribute encodings and data formats defined in RFC 2865 184 [RFC2865], RFC 2866 [RFC2866] and subsequent RADIUS RFCs. 186 Since this document represents a Best Current Practice, it does not 187 update or deprecate existing standards. As a result, uses of the 188 terms "MUST" and "MUST NOT" are limited to requirements already 189 present in existing documents. 191 It is RECOMMENDED that these guidelines be followed for all new 192 RADIUS specifications, whether they originate from a vendor, an SDO, 193 or the IETF. Doing so will ensure the widest possible applicability 194 and interoperability of the specifications, while requiring minimal 195 changes to existing systems. In particular, it is expected that 196 RADIUS specifications requesting allocation within the standards 197 space will follow these guidelines, and will explain why this is not 198 possible if they cannot. 200 However, there are situations in which vendors or SDOs can choose not 201 to follow these guidelines without major consequences. As noted in 202 [RFC2865] Section 5.26, Vendor-Specific Attributes (VSAs) are 203 "available to allow vendors to support their own extended Attributes 204 not suitable for general usage." Where vendors or SDOs develop 205 specifications "not suitable for general usage", limited 206 interoperability and inability to use existing implementations may be 207 acceptable and in these situations, vendors and SDOs MAY choose to 208 not conform to these guidelines. 210 Note that the RADEXT WG is currently (as of 2010) involved in 211 developing updates to RADIUS. Those updates will provide their own 212 usage guidelines that may over-ride some of the guidelines discussed 213 here. 215 RADIUS protocol changes, or specification of attributes (such as 216 Service-Type) that can, in effect, provide new RADIUS commands 217 require greater expertise and deeper review, as do changes to the 218 RADIUS operational model. As a result, such changes are outside the 219 scope of this document and MUST NOT be undertaken outside the IETF. 221 1.3.1. Reviews 223 For specifications utilizing attributes within the standards space, 224 conformance with the design guidelines in this document is expected 225 unless a good case can be made for an exception. Reviewers SHOULD 226 use the design guidelines as a review checklist. 228 While not required, IETF review may also be beneficial for 229 specifications utilizing the Vendor-Specific space. Experience has 230 shown that attributes not originally designed for general usage can 231 subsequently garner wide-spread deployment. An example is the 232 vendor-specific attributes defined in [RFC2548], which have been 233 widely implemented within IEEE 802.11 Access Points. 235 In order to assist in the development of specifications conforming to 236 these guidelines, authors can request review by sending email to the 237 AAA Doctors [DOCTORS] or equivalent mailing list. The IETF 238 Operations & Management Area Directors will then arrange for the 239 review to be completed and posted to the AAA Doctors mailing list 240 [DOCTORS], RADEXT WG mailing list, or other IETF mailing list. Since 241 reviews are handled by volunteers, responses are provided on a best- 242 effort basis, with no service level guarantees. Authors are 243 encouraged to seek review as early as possible, so as to avoid 244 potential delays. 246 As reviewers require access to the specification, vendors and SDOs 247 are encouraged to make them publicly available. Where the RADIUS 248 specification is embedded within a larger document which cannot be 249 made public, the RADIUS attribute and value definitions can be made 250 available on a public web site or can be published as an 251 Informational RFC, as with [RFC4679]. 253 The review process requires neither allocation of attributes within 254 the IETF standard attribute space nor publication of an IETF RFC. 255 Requiring SDOs or vendors to rehost VSAs into the IETF standards 256 attribute space solely for the purpose of obtaining review would put 257 pressure on the standards space, and may be harmful to 258 interoperability, since would create two ways to provision the same 259 service. Rehosting may also require changes to the RADIUS data model 260 which will affect implementations that do not intend to support the 261 SDO or vendor specifications. 263 Similarly, vendors are encouraged to make their specifications 264 publicly available, for maximum interoperability. However, it is not 265 necessary for a vendor to request publication of a VSA specification 266 as an Informational RFC by the IETF. 268 2. Guidelines 270 The Remote Authentication Dial In User Service (RADIUS) defined in 271 [RFC2865] and [RFC2866] uses elements known as attributes in order to 272 represent authentication, authorization and accounting data. 274 Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does 275 not define a formal data definition language. The data type of 276 RADIUS attributes is not transported on the wire. Rather, the data 277 type of a RADIUS attribute is fixed when an attribute is defined. 278 Based on the RADIUS attribute type code, RADIUS clients and servers 279 can determine the data type based on preconfigured entries within a 280 data dictionary. 282 To explain the implications of this early RADIUS design decision we 283 distinguish two kinds of data types, namely "basic" and "complex". 284 Basic data types use one of the existing RADIUS data types defined in 285 Section 2.1, encapsulated in a [RFC2865] RADIUS attribute, or in a 286 [RFC2865] RADIUS VSA. All other data formats are "complex types". 288 RADIUS attributes can be classified into one of three broad 289 categories: 291 * Attributes that are of interest to a single vendor, e.g., for a 292 product or product line. Minimal cross-vendor interoperability 293 is needed. 295 Vendor-Specific Attributes (VSAs) are appropriate for use in 296 this situation.. Code-point allocation is managed by the vendor 297 with the number space defined by their Private Enterprise Number 298 (PEN). 300 * Attributes that are of interest to an industry segment, where an 301 SDO defines the attributes for that industry. Multi-vendor 302 interoperability within an industry segment is expected. 304 Vendor-Specific Attributes (VSAs) MUST be used. Code-point 305 allocation is managed by the SDO with the number space defined 306 by the SDOs PEN, rather then the PEN of an individual vendor. 308 * Attributes that are of broad interest to the Internet Community. 309 Multi-vendor interoperability is expected. 311 Attributes within the standards space are appropriate for this 312 purpose, and are allocated via IANA as described in [RFC3575]. 313 Since the standards space represents a finite resource, and is 314 the only attribute space available for use by IETF working 315 groups, vendors and SDOs are encouraged to utilize the VSA 316 space, rather than requesting allocation of attributes from the 317 standards space. Self-allocation of standards attributes is 318 considered anti-social behavior and is strongly discouraged. 320 2.1. Data Types 322 RADIUS defines a limited set of data types, defined as "basic data 323 types". The following data qualifies as "basic data types": 325 * 32-bit unsigned integer, in network byte order. 327 * Enumerated data types, represented as a 32-bit unsigned integer 328 with a list of name to value mappings. (e.g. Service-Type) 330 * IPv4 address in network byte order. 332 * time as 32 bit unsigned value, in network byte order, and in 333 seconds since 00:00:00 UTC, January 1, 1970. 335 * IPv6 address in network byte order. 337 * Interface-Id (8 octet string in network byte order) 339 * IPv6 prefix. 341 * string (i.e., binary data), totalling 253 octets or less in 342 length. This includes the opaque encapsulation of data 343 structures defined outside of RADIUS. See also Appendix A.1.3, 344 below, for additional discussion. 346 * UTF-8 text [RFC3629], totalling 253 octets or less in length. 348 Note that the length limitations for VSAs of type String and Text are 349 less than 253 octets, due to the additional overhead of the Vendor- 350 Specific encoding. 352 The following data also qualifies as "basic data types": 354 * Attributes grouped into a logical container, using the 355 [RFC2868] tagging mechanism. This approach is NOT RECOMMENDED 356 (see Section 3.2.2), but is permissible where the alternatives 357 are worse. 359 * Attributes requiring the transport of more than 253 octets of 360 Text or String data. This includes the opaque encapsulation 361 of data structures defined outside of RADIUS. 362 (e.g. EAP-Message) 364 All other data formats (including nested attributes) are defined to 365 be "complex data types", and are NOT RECOMMENDED for normal use. 366 Complex data types MAY be used in situations where they reduce 367 complexity in non-RADIUS systems, or where using the basic data types 368 would be awkward (such as where grouping would be required in order 369 to link related attributes). Since there are no "hard and fast" 370 rules for where complexity is best located, each situation has to be 371 decided on a case-by-case basis. Examples of this tradeoff are 372 discussed in Appendix B. Where a complex data type is selected, an 373 explanation SHOULD be offered as to why this was necessary. 375 2.2. Vendor-Specific Attribute Space 377 The Vendor-Specific Attribute space is defined to be the contents of 378 the "String" field of the Vendor-Specific Attribute ([RFC2865] 379 Section 5.26). As discussed there, it is intended for vendors and 380 SDOs to support their own Attributes not suitable for general use. 382 While the encoding of attributes within the vendor space is under the 383 control of vendors and SDOs, following the guidelines described here 384 is advantageous since it enables maximum interoperability with 385 minimal changes to existing systems. 387 For example, RADIUS server support for new attributes using "basic 388 data types" can typically be accomplished by editing a RADIUS 389 dictionary, whereas "complex data types" typically require RADIUS 390 server code changes, which can add complexity and delays in 391 implementation. 393 Vendor RADIUS Attribute specifications SHOULD self-allocate 394 attributes from the vendor space, rather than requesting an 395 allocation (or self-allocating) from within the RADIUS standard 396 attribute space. 398 VSA encodings that do not follow the [RFC2865] Section 5.26 encoding 399 scheme are NOT RECOMMENDED. Although [RFC2865] does not mandate it, 400 implementations commonly assume that the Vendor Id can be used as a 401 key to determine the on-the-wire encoding of a VSA. Vendors 402 therefore SHOULD NOT use multiple encodings for VSAs that are 403 associated with a particular Vendor Id. A vendor wishing to use 404 multiple VSA encodings SHOULD request one Vendor Id for each VSA 405 encoding that they will use. 407 2.3. Service definitions and RADIUS 409 RADIUS specifications define how an existing service or protocol can 410 be provisioned using RADIUS, usually via the Service-Type attribute. 411 Therefore, it is expected that a RADIUS attribute specification will 412 reference documents defining the protocol or service to be 413 provisioned. Within the IETF, a RADIUS attribute specification 414 SHOULD NOT be used to define the protocol or service being 415 provisioned. New services using RADIUS for provisioning SHOULD be 416 defined elsewhere and referenced in the RADIUS specification. 418 New attributes, or new values of existing attributes, SHOULD NOT be 419 used to define new RADIUS commands. RADIUS attributes are intended 420 to: 422 * authenticate users 424 * authorize users (i.e., service provisioning or changes to 425 provisioning) 427 * account for user activity (i.e., logging of session activity) 429 Requirements for allocation of new commands (i.e. the Code field in 430 the packet header) and new attributes within the standards space are 431 described in [RFC3575] Section 2.1. 433 2.4. Translation of Vendor Specifications 435 [RFC2865] Section 5.26 defines Vendor-Specific attributes as follows: 437 This Attribute is available to allow vendors to support their own 438 extended Attributes not suitable for general usage. It MUST NOT 439 affect the operation of the RADIUS protocol. 441 Servers not equipped to interpret the vendor-specific information 442 sent by a client MUST ignore it (although it may be reported). 443 Clients which do not receive desired vendor-specific information 444 SHOULD make an attempt to operate without it, although they may do 445 so (and report they are doing so) in a degraded mode. 447 The limitation on changes to the RADIUS protocol effectively 448 prohibits VSAs from changing fundamental aspects of RADIUS operation, 449 such as modifying RADIUS packet sequences, or adding new commands. 450 However, the requirement for clients and servers to be able to 451 operate in the absence of VSAs has proven to be less of a constraint, 452 since it is still possible for a RADIUS client and server to mutually 453 indicate support for VSAs, after which behavior expectations can be 454 reset. 456 Therefore, RFC 2865 provides considerable latitude for development of 457 new attributes within the vendor space, while prohibiting development 458 of protocol variants. This flexibility implies that RADIUS 459 attributes can often be developed within the vendor space without 460 loss (and possibly even with gain) in functionality. 462 As a result, translation of RADIUS attributes developed within the 463 vendor space into the standard space may provide only modest 464 benefits, while accelerating the exhaustion of the standard attribute 465 space. We do not expect that all RADIUS attribute specifications 466 requiring interoperability will be developed within the IETF, and 467 allocated from the standards space. A more scalable approach is to 468 recognize the flexibility of the vendor space, while working toward 469 improvements in the quality and availability of RADIUS attribute 470 specifications, regardless of where they are developed. 472 It is therefore NOT RECOMMENDED that specifications intended solely 473 for use by a vendor or SDO use be translated into the standard space. 475 3. Rationale 477 This section outlines the rationale behind the above recommendations. 479 3.1. RADIUS Operational Model 481 The RADIUS operational model includes several assumptions: 483 * The RADIUS protocol is stateless; 485 * Provisioning of services is not possible within an 486 Access-Reject or Disconnect-Request; 488 * There is a distinction between authorization checks and user 489 authentication; 491 * The protocol provides for authentication and integrity 492 protection of packets; 494 * The RADIUS protocol is a Request/Response protocol; 496 * The protocol defines packet length restrictions. 498 While RADIUS server implementations may keep state, the RADIUS 499 protocol is stateless, although information may be passed from one 500 protocol transaction to another via the State Attribute. As a 501 result, documents which require stateful protocol behavior without 502 use of the State Attribute are inherently incompatible with RADIUS as 503 defined in [RFC2865], and MUST be redesigned. See [RFC5080] Section 504 2.1.1 for additional discussion surrounding the use of the State 505 Attribute. 507 As noted in [RFC5080] Section 2.6, the intent of an Access-Reject is 508 to deny access to the requested service. As a result, RADIUS does 509 not allow the provisioning of services within an Access-Reject or 510 Disconnect-Request. Documents which include provisioning of services 511 within an Access-Reject or Disconnect-Request are inherently 512 incompatible with RADIUS, and SHOULD be redesigned. 514 As noted in [RFC5176] Section 3: 516 A Disconnect-Request MUST contain only NAS and session 517 identification attributes. If other attributes are included in a 518 Disconnect- Request, implementations MUST send a Disconnect-NAK; 519 an Error-Cause Attribute with value "Unsupported Attribute" MAY be 520 included. 522 As a result, documents which include provisioning of services within 523 a Disconnect-Request are inherently incompatible with RADIUS, and 524 SHOULD be redesigned. 526 As noted in [RFC5080] Section 2.1.1, a RADIUS Access-Request may not 527 contain user authentication attributes or a State Attribute linking 528 the Access-Request to an earlier user authentication. Such an 529 Access-Request, known as an authorization check, provides no 530 assurance that it corresponds to a live user. RADIUS specifications 531 defining attributes containing confidential information (such as 532 Tunnel-Password) should be careful to prohibit such attributes from 533 being returned in response to an authorization check. Also, 534 [RFC5080] Section 2.1.1 notes that authentication mechanisms need to 535 tie a sequence of Access-Request/Access-Challenge packets together 536 into one authentication session. The State Attribute is RECOMMENDED 537 for this purpose. 539 While [RFC2865] did not require authentication and integrity 540 protection of RADIUS Access-Request packets, subsequent 541 authentication mechanism specifications such as RADIUS/EAP [RFC3579] 542 and Digest Authentication [RFC5090] have mandated authentication and 543 integrity protection for certain RADIUS packets. [RFC5080] Section 544 2.1.1 makes this behavior RECOMMENDED for all Access-Request packets, 545 including Access-Request packets performing authorization checks. It 546 is expected that specifications for new RADIUS authentication 547 mechanisms will continue this practice. 549 The RADIUS protocol as defined in [RFC2865] is a request-response 550 protocol spoken between RADIUS clients and servers. A single RADIUS 551 request packet ([RFC2865], [RFC2866], or [RFC5176]) will solicit in 552 response at most a single response packet, sent to the IP address and 553 port of the RADIUS client that originated the request. Changes to 554 this model are likely to require major revisions to existing 555 implementations and so this practice is NOT RECOMMENDED. 557 The Length field in the RADIUS packet header is defined in [RFC2865] 558 Section 3. It is noted there that the maximum length of a RADIUS 559 packet is 4096 octets. As a result, attribute designers SHOULD NOT 560 assume that a RADIUS implementation can successfully process RADIUS 561 packets larger than 4096 octets. 563 Even when packets are less than 4096 octets, they may be larger than 564 the Path Maximum Transmission Unit (PMTU). Any packet larger than 565 the PMTU will be fragmented, making communications more brittle as 566 firewalls and filtering devices often discard fragments. Transport 567 of fragmented UDP packets appears to be a poorly tested code path on 568 network devices. Some devices appear to be incapable of transporting 569 fragmented UDP packets, making it difficult to deploy RADIUS in a 570 network where those devices are deployed. We RECOMMEND that RADIUS 571 messages be kept as small possible. 573 If a situation is envisaged where it may be necessary to carry 574 authentication, authorization or accounting data in a packet larger 575 than 4096 octets, then one of the following approaches is 576 RECOMMENDED: 578 1. Utilization of a sequence of packets. 579 For RADIUS authentication, a sequence of Access-Request/ Access- 580 Challenge packets would be used. For this to be feasible, 581 attribute designers need to enable inclusion of attributes that 582 can consume considerable space within Access-Challenge packets. 583 To maintain compatibility with existing NASes, either the use of 584 Access-Challenge packets needs to be permissible (as with 585 RADIUS/EAP, defined in [RFC3579]), or support for receipt of an 586 Access-Challenge needs to be indicated by the NAS (as in RADIUS 587 Location [RFC5580]). Also, the specification needs to clearly 588 describe how attribute splitting is to be signalled and how 589 attributes included within the sequence are to be interpreted, 590 without requiring stateful operation. Unfortunately, previous 591 specifications have not always exhibited the required foresight. 592 For example, even though very large filter rules are 593 conceivable, the NAS-Filter-Rule Attribute defined in [RFC4849] 594 is not permitted in an Access-Challenge packet, nor is a 595 mechanism specified to allow a set of NAS-Filter-Rule attributes 596 to be split across an Access-Request/Access-Challenge sequence. 598 In the case of RADIUS accounting, transporting large amounts of 599 data would require a sequence of Accounting-Request packets. 600 This is a non-trivial change to RADIUS, since RADIUS accounting 601 clients would need to be modified to split the attribute stream 602 across multiple Accounting-Requests, and billing servers would 603 need to be modified to re-assemble and interpret the attribute 604 stream. 606 2. Utilization of names rather than values. 607 Where an attribute relates to a policy that could conceivably be 608 pre-provisioned on the NAS, then the name of the pre-provisioned 609 policy can be transmitted in an attribute, rather than the 610 policy itself, which could be quite large. An example of this 611 is the Filter-Id Attribute defined in [RFC2865] Section 5.11, 612 which enables a set of pre-provisioned filter rules to be 613 referenced by name. 615 3. Utilization of Packetization Layer Path MTU Discovery 616 techniques, as specified in [RFC4821]. As a last resort, where 617 the above techniques cannot be made to work, it may be possible 618 to apply the techniques described in [RFC4821] to discover the 619 maximum supported RADIUS packet size on the path between a 620 RADIUS client and a home server. While such an approach can 621 avoid the complexity of utilization of a sequence of packets, 622 dynamic discovery is likely to be time consuming and cannot be 623 guaranteed to work with existing RADIUS implementations. As a 624 result, this technique is not generally applicable. 626 3.2. Data Model Issues 628 While [RFC2865] Section 5 defines basic data types, later 629 specifications did not follow this practice. This problem has led 630 implementations to define their own names for data types, resulting 631 in non-standard names for those types. 633 In addition, the number of vendors and SDOs creating new attributes 634 within the Vendor-Specific attribute space has grown, and this has 635 lead to some divergence in approaches to RADIUS attribute design. 636 For example, vendors and SDOs have evolved the data model to support 637 functions such as new data types, along with attribute grouping and 638 attribute fragmentation, with different groups taking different 639 approaches. These approaches are often incompatible, leading to 640 additional complexity in RADIUS implementations. 642 In order to avoid repeating old mistakes, this section describes the 643 history of the RADIUS data model, and attempts to codify existing 644 practices. 646 3.2.1. Issues with Definitions of Types 648 [RFC2865] Section 5 explicitly defines five data types: text, string, 649 address, integer and time. Both the names and interpretations of the 650 types are given. 652 Subsequent RADIUS specifications defined attributes by using type 653 names not defined in [RFC2865], without defining the new names as was 654 done in [RFC2865]. They did not consistently indicate the format of 655 the value field using the same conventions as [RFC2865]. As a 656 result, the data type is ambiguous in some cases, and may not be 657 consistent among different implementations. 659 It is out of the scope of this document to resolve all potential 660 ambiguities within existing RADIUS specifications. However in order 661 to prevent future ambiguities, it is RECOMMENDED that future RADIUS 662 attribute specifications explicitly define newly created data types 663 at the beginning of the document, and indicate clearly the data type 664 to be used for each attribute. 666 For example, [RFC3162] utilizes but does not explicitly define a type 667 which encapsulates an IPv6 address (Section 2.1 and 2.4), and another 668 type which encapsulates an IPv6 prefix (Section 2.3). The IPv6 669 address attributes confusingly are referenced as type "Address" in 670 the document. This is a similar name as the "address" type defined 671 in [RFC2865], which was defined to refer solely to IPv4 addresses. 673 While the Framed-Interface-Id attribute defined in [RFC3162] Section 674 2.2 included a value field of 8 octets, the data type was not 675 explicitly indicated, and therefore there is controversy over whether 676 the format of the data was intended to be an 8 octet String or 677 whether a special Interface-Id type was intended. 679 Given that attributes encapsulating an IPv6 address and an IPv6 680 prefix are already in use, it is RECOMMENDED that RADIUS server 681 implementations include support for these as basic types, in addition 682 to the types defined in [RFC2865]. Where the intent is to represent 683 a specific IPv6 address, an "IPv6 address" type SHOULD be used. 684 Although it is possible to use an "IPv6 Prefix" type with a prefix 685 length of 128 to represent an IPv6 address, this usage is NOT 686 RECOMMENDED. Implementations supporting the Framed-Interface-Id 687 attribute may select a data type of their choosing (most likely an 8 688 octet String or a special "Interface Id" data type). 690 It is worth noting that since RADIUS only supports unsigned integers 691 of 32 bits, attributes using signed integer data types or unsigned 692 integer types of other sizes will require code changes, and SHOULD be 693 avoided. 695 For [RFC2865] RADIUS VSAs, the length limitation of the String and 696 Text types is 247 octets instead of 253 octets, due to the additional 697 overhead of the Vendor-Specific Attribute. 699 3.2.2. Tagging Mechanism 701 [RFC2868] defines an attribute grouping mechanism based on the use of 702 a one octet tag value. Tunnel attributes that refer to the same 703 tunnel are grouped together by virtue of using the same tag value. 705 This tagging mechanism has some drawbacks. There are a limited 706 number of unique tags (31). The tags are not well suited for use 707 with arbitrary binary data values, because it is not always possible 708 to tell if the first byte after the Length is the tag or the first 709 byte of the untagged value (assuming the tag is optional). 711 Other limitations of the tagging mechanism are that when integer 712 values are tagged, the value portion is reduced to three bytes 713 meaning only 24-bit numbers can be represented. The tagging 714 mechanism does not offer an ability to create nested groups of 715 attributes. Some RADIUS implementations treat tagged attributes as 716 having additional data types tagged-string and tagged-integer. These 717 types increase the complexity of implementing and managing RADIUS 718 systems. 720 For these reasons, the tagging scheme described in RFC 2868 is NOT 721 RECOMMENDED for use as a generic grouping mechanism. 723 3.2.3. Complex Data Types 725 As described in this section, the creation of complex types can lead 726 to interoperability and deployment issues, so they need to be 727 introduced with care. For example, the RADIUS attribute encoding is 728 summarized in [RFC2865]: 730 0 1 2 731 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 733 | Type | Length | Value ... 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 736 However, some standard attributes pack multiple sub-fields into the 737 "Value" field, resulting in the creation of a complex type. 738 Separating these sub-fields into different attributes, each with its 739 own type and length, would have the following benefits: 741 * when manual data entry is required, it is easier for an 742 administator to enter the data as well-known types, rather than 743 as complex structures; 745 * it enables additional error checking by leveraging the 746 parsing and validation routines for well-known types; 748 * it simplifies implementations by eliminating special-case 749 attribute-specific parsing. 751 One of the fundamental goals of the RADIUS protocol design was to 752 allow RADIUS servers to be configured to support new attributes 753 without requiring server code changes. RADIUS server implementations 754 typically provide support for basic data types, and define attributes 755 in a data dictionary. This architecture enables a new attribute to 756 be supported by the addition of a dictionary entry, without requiring 757 other RADIUS server code changes. 759 Code changes can also be required in policy management systems and in 760 the RADIUS server's receive path. These changes are due to 761 limitations in RADIUS server policy languages, which commonly provide 762 for limited operations (such as comparisons or arithmetic operations) 763 on the existing data types. Many existing RADIUS policy languages 764 typically are not capable of parsing sub-elements, or providing more 765 sophisticated matching functionality. 767 On the RADIUS client, code changes are typically required in order to 768 implement a new attribute. The RADIUS client typically has to 769 compose the attribute dynamically when sending. When receiving, a 770 RADIUS client needs to be able to parse the attribute and carry out 771 the requested service. As a result, a detailed understanding of the 772 new attribute is required on clients, and data dictionaries are less 773 useful on clients than on servers. 775 Given these limitations, the introduction of new types can require 776 code changes on the RADIUS server which would be unnecessary if basic 777 data types had been used instead. In addition if "ad-hoc" types are 778 used, attribute-specific parsing is required, which means more 779 complex software to develop and maintain. More complexity can lead 780 to more error prone implementations, interoperability problems, and 781 even security vulnerabilities. These issues can increase costs to 782 network administrators as well as reducing reliability and 783 introducing deployment barriers. 785 3.2.4. Complex Data Type Exceptions 787 As described in Section 2.1, the introduction of complex data types 788 is discouraged where viable alternatives are available. A potential 789 exception is attributes that inherently require code changes on both 790 the client and server. For example, as described in Appendix B, 791 complex attributes have been used in situations involving 792 authentication and security attributes which need to be dynamically 793 computed and verified. Supporting this functionality requires code 794 changes on both the RADIUS client and server, regardless of the 795 attribute format. As a result, in most cases, the use of complex 796 attributes to represent these methods is acceptable, and does not 797 create additional interoperability or deployment issues. 799 Another exception to the recommendation against complex types is for 800 types that can be treated as opaque data by the RADIUS server. For 801 example, the EAP-Message attribute, defined in [RFC3579] Section 3.1 802 contains a complex data type that is an EAP packet. Since these 803 complex types do not need to be parsed by the RADIUS server, the 804 issues arising from server limitations do not arise. Similarly, 805 since attributes of these complex types can be configured on the 806 server using a data type of String, dictionary limitations are also 807 not encountered. Appendix A.1 below includes a series of checklists 808 that may be used to analyze a design for RECOMMENDED and NOT 809 RECOMMENDED behavior in relation to complex types. 811 If the RADIUS Server simply passes the contents of an attribute to 812 some non-RADIUS portion of the network, then the data is opaque to 813 RADIUS, and SHOULD be defined to be of type String. A concrete way 814 of judging this requirement is whether or not the attribute 815 definition in the RADIUS document contains delineated fields for sub- 816 parts of the data. If those fields need to be delineated in RADIUS, 817 then the data is not opaque to RADIUS, and it SHOULD be separated 818 into individual RADIUS attributes. 820 An examination of existing RADIUS RFCs discloses a number of complex 821 attributes that have already been defined. Appendix B includes a 822 listing of complex attributes used within [RFC2865], [RFC2868], 823 [RFC2869], [RFC3162], [RFC4818], and [RFC4675]. The discussion of 824 these attributes includes reasons why a complex type is acceptable, 825 or suggestions for how the attribute could have been defined to 826 follow the RADIUS data model. 828 In other cases, the data in the complex type are described textually. 829 This is possible because the data types are not sent within the 830 attributes, but are a matter for endpoint interpretation. An 831 implementation can define additional data types, and use these data 832 types today by matching them to the attribute's textual description. 834 3.3. Vendor Space 836 The usage model for RADIUS VSAs is described in [RFC2865] Section 837 6.2: 839 Note that RADIUS defines a mechanism for Vendor-Specific 840 extensions (Attribute 26) and the use of that should be encouraged 841 instead of allocation of global attribute types, for functions 842 specific only to one vendor's implementation of RADIUS, where no 843 interoperability is deemed useful. 845 Nevertheless, many new attributes have been defined in the vendor 846 specific space in situations where interoperability is not only 847 useful, but is required. For example, SDOs outside the IETF (such as 848 the IEEE 802 and the 3rd Generation Partnership Project (3GPP)) have 849 been assigned Vendor-Ids, enabling them to define their own VSA 850 encoding and assign Vendor types within their own space. 852 The use of VSAs by SDOs outside the IETF has gained in popularity for 853 several reasons: 855 Efficiency 856 As with SNMP, which defines an "Enterprise" Object Identifier 857 (OID) space suitable for use by vendors as well as other SDOs, the 858 definition of Vendor-Specific RADIUS attributes has become a 859 common occurrence as part of standards activity outside the IETF. 860 For reasons of efficiency, it is easiest if the RADIUS attributes 861 required to manage a standard are developed within the same SDO 862 that develops the standard itself. As noted in "Transferring MIB 863 Work from IETF Bridge MIB WG to IEEE 802.1 WG" [RFC4663], today 864 few vendors are willing to simultaneously fund individuals to 865 participate within an SDO to complete a standard, as well as to 866 participate in the IETF in order to complete the associated RADIUS 867 attributes specification. 869 Attribute scarcity 870 The standard RADIUS attribute space is limited to 255 unique 871 attributes. Of these, only about half remain available for 872 allocation. In the vendor space, the number of attributes 873 available is a function of the encoding of the attribute (the size 874 of the Vendor type field). 876 3.3.1. Interoperability Considerations 878 Vendors and SDOs are reminded that the standard RADIUS attribute 879 space, and the enumerated value space for enumerated attributes, are 880 reserved for allocation through work published via the IETF, as noted 881 in [RFC3575] Section 2.1. Some vendors and SDOs have in the past 882 performed self-allocation by assigning vendor-specific meaning to 883 "unused" values from the standard RADIUS attribute ID or enumerated 884 value space. This self-allocation results in interoperability 885 issues, and is counter-productive. Similarly, the Vendor-Specific 886 enumeration practice discussed in [RFC2882] Section 2.2.1 is NOT 887 RECOMMENDED. 889 If it is not possible to follow the IETF process, vendors and SDOs 890 SHOULD self-allocate an attribute, which MUST be in vendor space, as 891 discussed in Sections 3.3.2 and 3.3.3, below. 893 The design and specification of VSAs for multi-vendor usage SHOULD be 894 undertaken with the same level of care as standard RADIUS attributes. 895 Specifically, the provisions of this document that apply to standard 896 RADIUS attributes also apply to VSAs for multi-vendor usage. 898 3.3.2. Vendor Allocations 900 As noted in [RFC3575] Section 2.1, vendors are encouraged to utilize 901 VSAs to define functions "specific only to one vendor's 902 implementation of RADIUS, where no interoperability is deemed useful. 903 For functions specific only to one vendor's implementation of RADIUS, 904 the use of that should be encouraged instead of the allocation of 905 global attribute types." 907 The recommendation for vendors to allocate attributes from a vendor 908 space rather than via the IETF process is a recognition that vendors 909 desire to assert change control over their own RADIUS specifications. 910 This change control can be obtained by requesting a PEC from the 911 Internet Assigned Number Authority (IANA), for use as a Vendor-Id 912 within a Vendor-Specific attribute. The vendor can then allocate 913 attributes within the VSA space defined by that Vendor-Id, at their 914 sole discretion. Similarly, the use of data types (complex or 915 otherwise) within that VSA space is solely under the discretion of 916 the vendor. 918 3.3.3. SDO Allocations 920 Given the expanded utilization of RADIUS, it has become apparent that 921 requiring SDOs to accomplish all their RADIUS work within the IETF is 922 inherently inefficient and unscalable. Is is therefore RECOMMENDED 923 that SDO RADIUS Attribute specifications allocate attributes from the 924 vendor space, rather than requesting an allocation from the RADIUS 925 standard attribute space, for attributes matching any of the 926 following criteria: 928 * attributes relying on data types not defined within RADIUS 930 * attributes intended primarily for use within an SDO 932 * attributes intended primarily for use within a group of SDOs. 934 Any new RADIUS attributes or values intended for interoperable use 935 across a broad spectrum of the Internet Community SHOULD follow the 936 allocation process defined in [RFC3575]. 938 The recommendation for SDOs to allocate attributes from a vendor 939 space rather than via the IETF process is a recognition that SDOs 940 desire to assert change control over their own RADIUS specifications. 941 This change control can be obtained by requesting a PEC from the 942 Internet Assigned Number Authority (IANA), for use as a Vendor-Id 943 within a Vendor-Specific attribute. The SDO can then allocate 944 attributes within the VSA space defined by that Vendor-Id, at their 945 sole discretion. Similarly, the use of data types (complex or 946 otherwise) within that VSA space is solely under the discretion of 947 the SDO. 949 3.4. Polymorphic Attributes 951 A polymorphic attribute is one whose format or meaning is dynamic. 952 For example, rather than using a fixed data format, an attribute's 953 format might change based on the contents of another attribute. Or, 954 the meaning of an attribute may depend on earlier packets in a 955 sequence. 957 RADIUS server dictionary entries are typically static, enabling the 958 user to enter the contents of an attribute without support for 959 changing the format based on dynamic conditions. However, this 960 limitation on static types does not prevent implementations from 961 implementing policies that return different attributes based on the 962 contents of received attributes; this is a common feature of existing 963 RADIUS implementations. 965 In general, polymorphism is NOT RECOMMENDED. Polymorphism rarely 966 enables capabilities that would not be available through use of 967 multiple attributes. Polymorphism requires code changes in the 968 RADIUS server in situations where attributes with fixed formats would 969 not require such changes. Thus, polymorphism increases complexity 970 while decreasing generality, without delivering any corresponding 971 benefits. 973 Note that changing an attribute's format dynamically is not the same 974 thing as using a fixed format and computing the attribute itself 975 dynamically. RADIUS authentication attributes such as User-Password, 976 EAP-Message, etc. while being computed dynamically, use a fixed 977 format. 979 4. IANA Considerations 981 This document has no action items for IANA. However, it does provide 982 guidelines for Expert Reviewers appointed as described in [RFC3575]. 984 5. Security Considerations 986 This specification provides guidelines for the design of RADIUS 987 attributes used in authentication, authorization and accounting. 988 Threats and security issues for this application are described in 989 [RFC3579] and [RFC3580]; security issues encountered in roaming are 990 described in [RFC2607]. 992 Obfuscation of RADIUS attributes on a per-attribute basis is 993 necessary in some cases. The current standard mechanism for this is 994 described in [RFC2865] Section 5.2 (for obscuring User-Password 995 values) and is based on the MD5 algorithm specified in [RFC1321]. 996 The MD5 and SHA-1 algorithms have recently become a focus of scrutiny 997 and concern in security circles, and as a result, the use of these 998 algorithms in new attributes is NOT RECOMMENDED. In addition, 999 previous documents referred to this method as generating "encrypted" 1000 data. This terminology is no longer accepted within the 1001 cryptographic community. 1003 Where new RADIUS attributes use cryptographic algorithms, algorithm 1004 negotiation SHOULD be supported. Specification of a mandatory-to- 1005 implement algorithm is REQUIRED, and it is RECOMMENDED that the 1006 mandatory-to-implement algorithm be certifiable under FIPS 140 1007 [FIPS]. 1009 Where new RADIUS attributes encapsulate complex data types, or 1010 transport opaque data, the security considerations discussed in 1011 Section 5.1 SHOULD be addressed. 1013 Message authentication in RADIUS is provided largely via the Message- 1014 Authenticator attribute. See [RFC3579] Section 3.2, and also 1015 [RFC5080] 2.2.2, which says that client implementations SHOULD 1016 include a Message-Authenticator attribute in every Access-Request. 1018 In general, the security of the RADIUS protocol is poor. Robust 1019 deployments SHOULD support a secure communications protocol such as 1020 IPSec. See [RFC3579] Section 4, and [RFC3580] Section 5 for a more 1021 in-depth explanation of these issues. 1023 Implementations not following the suggestions outlined in this 1024 document may be subject to a problems such as ambiguous protocol 1025 decoding, packet loss leading to loss of billing information, and 1026 denial of service attacks. 1028 5.1. New Data Types and Complex Attributes 1030 The introduction of complex data types brings the potential for the 1031 introduction of new security vulnerabilities. Experience shows that 1032 the common data types have few security vulnerabilities, or else that 1033 all known issues have been found and fixed. New data types require 1034 new code, which may introduce new bugs, and therefore new attack 1035 vectors. 1037 Some systems permit complex attributes to be defined via a method 1038 that is more capable than traditional RADIUS dictionaries. These 1039 systems can reduce the security threat of new types significantly, 1040 but they do not remove it entirely. 1042 RADIUS servers are highly valued targets, as they control network 1043 access and interact with databases that store usernames and 1044 passwords. An extreme outcome of a vulnerability due to a new, 1045 complex type would be that an attacker is capable of taking complete 1046 control over the RADIUS server. 1048 The use of attributes representing opaque data does not reduce this 1049 threat. The threat merely moves from the RADIUS server to the system 1050 that consumes that opaque data. The threat is particularly severe 1051 when the opaque data originates from the user, and is not validated 1052 by the NAS. In those cases, the RADIUS server is potentially exposed 1053 to attack by malware residing on an unauthenticated host. 1055 Any system consuming opaque data that originates from a RADIUS system 1056 SHOULD be properly isolated from that RADIUS system, and SHOULD run 1057 with minimal privileges. Any potential vulnerabilities in the non- 1058 RADIUS system will then have minimal impact on the security of the 1059 system as a whole. 1061 6. References 1063 6.1. Normative References 1065 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1066 Requirement Levels", BCP 14, RFC 2119, March 1997. 1068 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 1069 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1070 2000. 1072 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1073 Authentication Dial In User Service)", RFC 3575, July 2003. 1075 6.2. Informative References 1077 [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of 1078 management information for TCP/IP-based internets", STD 16, 1079 RFC 1155, May 1990. 1081 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 1082 Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1083 1990. 1085 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1086 April 1992. 1088 [RFC2548] Zorn, Glen, "Microsoft Vendor-specific RADIUS Attributes", RFC 1089 2548, March 1999. 1091 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1092 Implementation in Roaming", RFC 2607, June 1999. 1094 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1096 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., 1097 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 1098 Support", RFC 2868, June 2000. 1100 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", 1101 RFC 2869, June 2000. 1103 [RFC2882] Mitton, D, "Network Access Servers Requirements: Extended 1104 RADIUS Practices", RFC 2882, July 2000. 1106 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 1107 3162, August 2001. 1109 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 1110 In User Service) Support For Extensible Authentication 1111 Protocol (EAP)", RFC 3579, September 2003. 1113 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE 1114 802.1X Remote Authentication Dial In User Service (RADIUS) 1115 Usage Guidelines", RFC3580, September 2003. 1117 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1118 RFC 3629, November 2003. 1120 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 1121 Documents", RFC 4181, September 2005. 1123 [RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge MIB WG 1124 to IEEE 802.1 WG", RFC 4663, September 2006. 1126 [RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for 1127 Virtual LAN and Priority Support", RFC 4675, September 2006. 1129 [RFC4679] Mammoliti, V., et al., "DSL Forum Vendor-Specific RADIUS 1130 Attributes", RFC 4679, September 2006. 1132 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 1133 Attribute", RFC 4818, April 2007. 1135 [RFC4821] Mathis, M. and Heffner, J, "Packetization Layer Path MTU 1136 Discovery", RFC 4821, March 2007. 1138 [RFC4849] Congdon, P. et al, "RADIUS Filter-Rule Attribute", RFC 4849, 1139 April 2007. 1141 [RFC5080] Nelson, D. and DeKok, A, "Common Remote Authentication Dial In 1142 User Service (RADIUS) Implementation Issues and Suggested 1143 Fixes", RFC 5080, December 2007. 1145 [RFC5090] Sterman, B. et al., "RADIUS Extension for Digest 1146 Authentication", RFC 5090, February 2008. 1148 [RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote 1149 Authentication Dial In User Service (RADIUS)", RFC 5176, 1150 January 2008. 1152 [DOCTORS] AAA Doctors Mailing list 1154 [FIPS] FIPS 140-3 (DRAFT), "Security Requirements for Cryptographic 1155 Modules", http://csrc.nist.gov/publications/fips/fips140-3/ 1157 [IEEE-802.1Q] 1158 IEEE Standards for Local and Metropolitan Area Networks: Draft 1159 Standard for Virtual Bridged Local Area Networks, 1160 P802.1Q-2003, January 2003. 1162 [RFC5580] Tschofenig, H. (Ed.), "Carrying Location Objects in RADIUS and 1163 Diameter", RFC 5580, August 2009. 1165 [AAA-SIP] Sterman, B. et al., "RADIUS Extension for Digest 1166 Authentication", draft-sterman-sip-aaa-00.txt, November 2001 1167 (expired). 1169 Appendix A - Design Guidelines 1171 The following text provides guidelines for the design of attributes 1172 used by the RADIUS protocol. Specifications that follow these 1173 guidelines are expected to achieve maximum interoperability with 1174 minimal changes to existing systems. 1176 A.1. Types matching the RADIUS data model 1178 A.1.1. Transport of basic data types 1180 Does the data fit within the basic data types described in Section 1181 2.1? If so, it SHOULD be encapsulated in a [RFC2865] format RADIUS 1182 attribute, or in a [RFC2865] format RADIUS VSA that uses one of the 1183 existing RADIUS data types. 1185 A.1.2. Transport of Authentication and Security Data 1187 Does the data provide authentication and/or security capabilities for 1188 the RADIUS protocol, as outlined below? If so, use of a complex data 1189 type is acceptable, under the following circumstances: 1191 * Complex data types that carry authentication methods which 1192 RADIUS servers are expected to parse and verify as part of 1193 an authentication process. 1195 * Complex data types that carry security information intended 1196 to increase the security of the RADIUS protocol itself. 1198 Any data type carrying authentication and/or security data that is 1199 not meant to be parsed by a RADIUS server is an "opaque data type", 1200 as defined below. 1202 A.1.3. Opaque data types 1204 Does the attribute encapsulate an existing data structure defined 1205 outside of the RADIUS specifications? Can the attribute be treated 1206 as opaque data by RADIUS servers (including proxies?) If both 1207 questions can be answered affirmatively, a complex structure MAY be 1208 used in a RADIUS specification. 1210 The specification of the attribute SHOULD define the encapsulating 1211 attribute to be of type String. The specification SHOULD refer to an 1212 external document defining the structure. The specification SHOULD 1213 NOT define or describe the structure, for reasons discussed above in 1214 Section 3.2.3. 1216 A.1.4. Pre-existing data types 1217 There is a trade-off in design between re-using existing formats for 1218 historical compatibility, or choosing new formats for a "better" 1219 design. This trade-off does not always require the "better" design 1220 to be used. As a result. pre-existing complex data types described 1221 in Appendix B MAY be used. 1223 A.2. Improper Data Types 1225 This section suggests alternatives to data types which do not fall 1226 within the "basic data type" definition. Section A.2.1 describes 1227 simple data types which should be replaced by basic data types. 1228 Section A.2.2 descibes more complex data types which should be 1229 replaced by multiple attributes using the basic data types. 1231 A.2.1. Simple Data Types 1233 Does the attribute use any of the following data types? If so, the 1234 data type SHOULD be replaced with the suggested alternatives, or it 1235 SHOULD NOT be used at all. 1237 * Signed integers of any size. 1238 SHOULD NOT be used. SHOULD be replaced with one or more 1239 unsigned integer attributes. The definition of the attribute 1240 can contain information that would otherwise go into the sign 1241 value of the integer. 1243 * 8 bit unsigned integers. 1244 SHOULD be replaced with 32-bit unsigned integer. There is 1245 insufficient justification to save three bytes. 1247 * 16 bit unsigned integers. 1248 SHOULD be replaced with 32-bit unsigned integer. There is 1249 insufficient justification to save two bytes. 1251 * Unsigned integers of size other than 32 bits. 1252 SHOULD be replaced by an unsigned integer of 32 bits. 1253 There is insufficient justification to define a new size of 1254 integer. 1256 * Integers of any size in non-network byte order 1257 SHOULD be replaced by unsigned integer of 32 bits in network 1258 There is no reason to transport integers in any format other 1259 than network byte order. 1261 * Multi-field text strings. 1262 Each field SHOULD be encapsulated in a separate attribute. 1264 * Polymorphic attributes. 1266 Multiple attributes, each with a static data type SHOULD be 1267 defined instead. 1269 * Nested AVPs. 1270 Attributes should be defined in a flat typespace. 1272 A.2.2. More Complex Data Types 1274 Does the attribute: 1276 * define a complex data type not described in Appendix B, 1278 * that a RADIUS server and/or client is expected to parse, 1279 validate, or create the contents of via a dynamic computation? 1280 i.e. A type that cannot be treated as opaque data (Section A.1.3) 1282 * involve functionality that could be implemented without code 1283 changes on both the client and server? (i.e. a type that doesn't 1284 require dynamic computation and verification, such as those 1285 performed for authentication or security attributes) 1287 If so, this data type SHOULD be replaced with simpler types, as 1288 discussed above in Appendix A.2.1. See also Section 2.1 for a 1289 discussion of why complex types are problematic. 1291 A.3. Vendor-Specific formats 1293 Does the specification contain Vendor-Specific attributes that match 1294 any of the following criteria? If so, the VSA encoding should be 1295 replaced with the [RFC2865] Section 5.26 encoding, or should not be 1296 used at all. 1298 * Vendor types of more than 8 bits. 1299 SHOULD NOT be used. Vendor types of 8 bits SHOULD be used 1300 instead. 1302 * Vendor lengths of less than 8 bits. (i.e., zero bits) 1303 SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used 1304 instead. 1306 * Vendor lengths of more than 8 bits. 1307 SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used 1308 instead. 1310 * Vendor-Specific contents that are not in Type-Length-Value 1311 format. 1312 SHOULD NOT be used. Vendor-Specific attributes SHOULD be in 1313 Type-Length-Value format. 1315 In general, Vendor-Specific attributes SHOULD follow the [RFC2865] 1316 Section 5.26 suggested encoding. Vendor extensions to non-standard 1317 encodings are NOT RECOMMENDED as they can negatively affect 1318 interoperability. 1320 A.4. Changes to the RADIUS Operational Model 1322 Does the specification change the RADIUS operation model, as outlined 1323 in the list below? If so, then another method of achieving the 1324 design objectives SHOULD be used. Potential problem areas include: 1326 * Defining new commands in RADIUS using attributes. 1327 The addition of new commands to RADIUS MUST be handled via 1328 allocation of a new Code, and not by the use of an attribute. 1329 This restriction includes new commands created by overloading 1330 the Service-Type attribute to define new values that modify 1331 the functionality of Access-Request packets. 1333 * Using RADIUS as a transport protocol for data unrelated to 1334 authentication, authorization, or accounting. Using RADIUS to 1335 transport authentication methods such as EAP is explicitly 1336 permitted, even if those methods require the transport of 1337 relatively large amounts of data. Transport of opaque data 1338 relating to AAA is also permitted, as discussed above in 1339 Section 3.2.3. However, if the specification does not relate 1340 to AAA, then RADIUS SHOULD NOT be used. 1342 * Assuming support for packet lengths greater than 4096 octets. 1343 Attribute designers cannot assume that RADIUS implementations 1344 can successfully handle packets larger than 4096 octets. 1345 If a specification could lead to a RADIUS packet larger than 1346 4096 octets, then the alternatives described in Section 3.3 1347 SHOULD be considered. 1349 * Stateless operation. The RADIUS protocol is stateless, and 1350 documents which require stateful protocol behavior without the 1351 use of the State Attribute need to be redesigned. 1353 * Provisioning of service in an Access-Reject or 1354 Disconnect-Request. Such provisioning is not permitted, and 1355 MUST NOT be used. If limited access needs to be provided, then 1356 an Access-Accept with appropriate authorizations can be used 1357 instead. 1359 * Provisioning of service in a Disconnect-Request. 1360 Such provisioning is not permitted, and MUST NOT be used. 1361 If limited access needs to be provided, then a CoA-Request 1362 with appropriate authorizations can be used instead. 1364 * Lack of user authentication or authorization restrictions. 1365 In an authorization check, where there is no demonstration of a 1366 live user, confidential data cannot be returned. Where there 1367 is a link to a previous user authentication, the State attribute 1368 SHOULD be present. 1370 * Lack of per-packet integrity and authentication. 1371 It is expected that documents will support per-packet 1372 integrity and authentication. 1374 * Modification of RADIUS packet sequences. 1375 In RADIUS, each request is encapsulated in its own packet, and 1376 elicits a single response that is sent to the requester. Since 1377 changes to this paradigm are likely to require major 1378 modifications to RADIUS client and server implementations, they 1379 SHOULD be avoided if possible. 1380 For further details, see Section 3.1. 1382 A.5. Allocation of attributes 1384 Does the attribute have a limited scope of applicability, as outlined 1385 below? If so, then the attributes SHOULD be allocated from the 1386 vendor space, rather than requesting allocation from the standard 1387 space. 1389 * attributes intended for a vendor to support their own systems, 1390 and not suitable for general usage 1392 * attributes relying on data types not defined within RADIUS 1394 * attributes intended primarily for use within an SDO 1396 * attributes intended primarily for use within a group of SDOs. 1398 Note that the points listed above do not relax the recommendations 1399 discussed in this document. Instead, they recognize that the RADIUS 1400 data model has limitations. In certain situations where 1401 interoperability can be strongly constrained by the SDO or vendor, an 1402 expanded data model MAY be used. It is RECOMMENDED, however, that 1403 the RADIUS data model be used, even when it is marginally less 1404 efficient than alternatives. 1406 When attributes are used primarily within a group of SDOs, and are 1407 not applicable to the wider Internet community, we expect that one 1408 SDO will be responsible for allocation from their own private space. 1410 Appendix B - Complex Attributes 1412 This section summarizes RADIUS attributes with complex data types 1413 that are defined in existing RFCs. 1415 This appendix is published for informational purposes only, and 1416 reflects the usage of attributes with complex data types at the time 1417 of the publication of this document. 1419 B.1. CHAP-Password 1421 [RFC2865] Section 5.3 defines the CHAP-Password Attribute which is 1422 sent from the RADIUS client to the RADIUS server in an Access- 1423 Request. The data type of the CHAP Identifier is not given, only the 1424 one octet length: 1426 0 1 2 1427 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 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1429 | Type | Length | CHAP Ident | String ... 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1432 Since this is an authentication attribute, code changes are required 1433 on the RADIUS client and server to support it, regardless of the 1434 attribute format. Therefore, this complex data type is acceptable in 1435 this situation. 1437 B.2. CHAP-Challenge 1439 [RFC2865] Section 5.40 defines the CHAP-Challenge Attribute which is 1440 sent from the RADIUS client to the RADIUS server in an Access- 1441 Request. While the data type of the CHAP Identifier is given, the 1442 text also says: 1444 If the CHAP challenge value is 16 octets long it MAY be placed in 1445 the Request Authenticator field instead of using this attribute. 1447 Defining attributes to contain values taken from the RADIUS packet 1448 header is NOT RECOMMENDED. Attributes should have values that are 1449 packed into a RADIUS AVP. 1451 B.3. Tunnel-Password 1453 [RFC2868] Section 3.5 defines the Tunnel-Password Attribute, which is 1454 sent from the RADIUS server to the client in an Access-Accept. This 1455 attribute includes Tag and Salt fields, as well as a string field 1456 which consists of three logical sub-fields: the Data-Length (one 1457 octet) and Password sub-fields (both of which are required), and the 1458 optional Padding sub-field. The attribute appears as follows: 1460 0 1 2 3 1461 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 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 | Type | Length | Tag | Salt 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 Salt (cont) | String ... 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 Since this is a security attribute, code changes are required on the 1469 RADIUS client and server to support it, regardless of the attribute 1470 format. However, while use of a complex data type is acceptable in 1471 this situation, the design of the Tunnel-Password attribute is 1472 problematic from a security perspective, since it uses MD5 as a 1473 cipher, and provides a password to a NAS, potentially without proper 1474 authorization. 1476 B.4. ARAP-Password 1478 [RFC2869] Section 5.4 defines the ARAP-Password attribute, which is 1479 sent from the RADIUS client to the server in an Access-Request. It 1480 contains four 4 octet values, instead of having a single Value field: 1482 0 1 2 3 1483 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 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 | Type | Length | Value1 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1487 | Value2 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | Value3 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 | Value4 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 | 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 As with the CHAP-Password attribute, this is an authentication 1497 attribute which would have required code changes on the RADIUS client 1498 and server regardless of format. 1500 B.5. ARAP-Features 1502 [RFC2869] Section 5.5 defines the ARAP-Features Attribute, which is 1503 sent from the RADIUS server to the client in an Access-Accept or 1504 Access-Challenge. It contains a compound string of two single octet 1505 values, plus three 4-octet values, which the RADIUS client 1506 encapsulates in a feature flags packet in the ARAP protocol: 1508 0 1 2 3 1509 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 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | Type | Length | Value1 | Value2 | 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 | Value3 | 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 | Value4 | 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 | Value5 | 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 Unlike the previous attributes, this attribute contains no encrypted 1521 component, nor is it directly involved in authentication. The 1522 individual sub-fields therefore could have been encapsulated in 1523 separate attributes. 1525 While the contents of this attribute is intended to be placed in an 1526 ARAP packet, the fields need to be set by the RADIUS server. Using 1527 standard RADIUS data types would have simplified RADIUS server 1528 implementations, and subsequent management. The current form of the 1529 attribute requires either the RADIUS server implementation, or the 1530 RADIUS server administrator, to understand the internals of the ARAP 1531 protocol. 1533 B.6. Connect-Info 1535 [RFC2869] Section 5.11 defines the Connect-Info attribute, which is 1536 used to indicate the nature of the connection. 1538 0 1 2 1539 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 | Type | Length | Text... 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1544 Even though the type is Text, the rest of the description indicates 1545 that it is a complex attribute: 1547 The Text field consists of UTF-8 encoded 10646 _8_ characters. 1548 The connection speed SHOULD be included at the beginning of the 1549 first Connect-Info attribute in the packet. If the transmit and 1550 receive connection speeds differ, they may both be included in the 1551 first attribute with the transmit speed first (the speed the NAS 1552 modem transmits at), a slash (/), the receive speed, then 1553 optionally other information. 1555 For example, "28800 V42BIS/LAPM" or "52000/31200 V90" 1557 More than one Connect-Info attribute may be present in an 1558 Accounting-Request packet to accommodate expected efforts by ITU 1559 to have modems report more connection information in a standard 1560 format that might exceed 252 octets. 1562 This attribute contains no encrypted component, and is it not 1563 directly involved in authentication. The individual sub-fields could 1564 therefore have been encapsulated in separate attributes. 1566 However, since the definition refers to potential standardization 1567 activity within ITU, the Connect-Info attribute can also be thought 1568 of as opaque data whose definition is provided elsewhere. The 1569 Connect-Info attribute could therefore qualify for an exception as 1570 described in Section 3.2.3. 1572 B.7. Framed-IPv6-Prefix 1574 [RFC3162] Section 2.3 defines the Framed-IPv6-Prefix Attribute and 1575 [RFC4818] Section 3 reuses this format for the Delegated-IPv6-Prefix 1576 Attribute; these attributes are sent from the RADIUS server to the 1577 client in an Access-Accept. 1579 0 1 2 3 1580 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 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 | Type | Length | Reserved | Prefix-Length | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 Prefix 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 Prefix 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 Prefix 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 Prefix | 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 The sub-fields encoded in these attributes are strongly related, and 1594 there was no previous definition of this data structure that could be 1595 referenced. Support for this attribute requires code changes on both 1596 the client and server, due to a new data type being defined. In this 1597 case it appears to be acceptable to encode them in one attribute. 1599 B.8. Egress-VLANID 1601 [RFC4675] Section 2.1 defines the Egress-VLANID Attribute which can 1602 be sent by a RADIUS client or server. 1604 0 1 2 3 1605 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 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 | Type | Length | Value 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 Value (cont) | 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 While it appears superficially to be of type Integer, the Value field 1613 is actually a packed structure, as follows: 1615 0 1 2 3 1616 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 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 | Tag Indic. | Pad | VLANID | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 The length of the VLANID field is defined by the [IEEE-802.1Q] 1622 specification. The Tag indicator field is either 0x31 or 0x32, for 1623 compatibility with the Egress-VLAN-Name, as discussed below. The 1624 complex structure of Egress-VLANID overlaps with that of the base 1625 Integer data type, meaning that no code changes are required for a 1626 RADIUS server to support this attribute. Code changes are required 1627 on the NAS, if only to implement the VLAN ID enforcement. 1629 Given the IEEE VLAN requirements and the limited data model of 1630 RADIUS, the chosen method is likely the best of the possible 1631 alternatives. 1633 B.9. Egress-VLAN-Name 1635 [RFC4675] Section 2.3 defines the Egress-VLAN-Name Attribute which 1636 can be sent by a RADIUS client or server. 1638 0 1 2 3 1639 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 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 | Type | Length | Tag Indic. | String... 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 The Tag Indicator is either the character '1' or '2', which in ASCII 1645 map to the identical values for Tag Indicator in Egress-VLANID, 1646 above. The complex structure of this attribute is acceptable for 1647 reasons identical to those given for Egress-VLANID. 1649 B.10. Digest-* 1651 [RFC5090] attempts to standardize the functionality provided by an 1652 expired internet-draft [AAA-SIP] which improperly used two attributes 1653 from the standard space without being assigned them by IANA. This 1654 self-allocation is forbidden, as described above in Section 2. In 1655 addition, the draft uses nested attributes, which are discouraged in 1656 Section 2.1. The updated document uses basic data types, and 1657 allocates nearly 20 attributes in the process. 1659 However, the draft has seen wide-spread implementation, where 1660 [RFC5090] has not. One explanation may be that implementors 1661 disagreed with the trade-offs made in the updated specification. It 1662 may have been better to simply document the existing format, and 1663 request IANA allocation of two attributes. The resulting design 1664 would have used nested attributes, but may have gained more wide- 1665 spread implementation. 1667 Acknowledgments 1669 We would like to acknowledge David Nelson, Bernard Aboba, Emile van 1670 Bergen, Barney Wolff, Glen Zorn, Avi Lior, and Hannes Tschofenig for 1671 contributions to this document. 1673 Authors' Addresses 1675 Greg Weber 1676 Knoxville, TN 37932 1677 USA 1679 Email: gdweber@gmail.com 1681 Alan DeKok 1682 The FreeRADIUS Server Project 1683 http://freeradius.org/ 1685 Email: aland@freeradius.org