idnits 2.17.1 draft-ietf-radext-design-12.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 (22 March 2010) is 5142 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 issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 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: September 22, 2010 7 22 March 2010 9 RADIUS Design Guidelines 10 draft-ietf-radext-design-12 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 22, 2010. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info/) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 This document may contain material from IETF Documents or IETF 51 Contributions published or made publicly available before November 52 10, 2008. The person(s) controlling the copyright in some of this 53 material may not have granted the IETF Trust the right to allow 54 modifications of such material outside the IETF Standards Process. 55 Without obtaining an adequate license from the person(s) controlling 56 the copyright in such materials, this document may not be modified 57 outside the IETF Standards Process, and derivative works of it may 58 not be created outside the IETF Standards Process, except to format 59 it for publication as an RFC or to translate it into languages other 60 than English. 62 Abstract 64 This document provides guidelines for the design of attributes used 65 by the Remote Authentication Dial In User Service (RADIUS) protocol. 66 It is expected that these guidelines will prove useful to authors and 67 reviewers of future RADIUS attribute specifications, both within the 68 IETF as well as other Standards Development Organizations (SDOs). 70 Table of Contents 72 1. Introduction ............................................. 5 73 1.1. Terminology ......................................... 5 74 1.2. Requirements Language ............................... 5 75 1.3. Applicability ....................................... 6 76 2. Guidelines ............................................... 7 77 2.1. Data Types .......................................... 8 78 2.2. Vendor-Specific Space ............................... 9 79 2.3. Service definitions and RADIUS ...................... 10 80 2.4. Translation of Vendor Specifications ................ 10 81 3. Rationale ................................................ 11 82 3.1. RADIUS Operational Model ............................ 11 83 3.2. Data Model Issues ................................... 14 84 3.2.1. Basic Data Types ............................... 14 85 3.2.2. Tagging Mechanism .............................. 16 86 3.2.3. Complex Data Types ............................. 16 87 3.3. Vendor Space ........................................ 19 88 3.3.1. Interoperability Considerations ................ 20 89 3.3.2. Vendor Allocations ............................. 21 90 3.3.3. SDO Allocations ................................ 21 91 3.3.4. Publication of specifications .................. 22 92 3.4. Polymorphic Attributes .............................. 22 93 4. IANA Considerations ...................................... 23 94 5. Security Considerations .................................. 23 95 5.1. New Data Types and Complex Attributes ............... 24 96 6. References ............................................... 25 97 6.1. Normative References ................................ 25 98 6.2. Informative References .............................. 25 99 Appendix A - Design Guidelines ............................... 28 100 A.1. Types matching the RADIUS data model ................. 28 101 A.1.1. Transport of basic data types ................... 28 102 A.1.2. Transport of Authentication and Security Data ... 29 103 A.1.3. Opaque data types ............................... 29 104 A.2. Improper Data Types .................................. 29 105 A.2.1. Basic Data Types ................................ 30 106 A.2.2. Complex Data Types .............................. 30 107 A.3. Vendor-Specific formats .............................. 31 108 A.4. Changes to the RADIUS Operational Model .............. 31 109 A.5. Allocation of attributes ............................. 33 110 Appendix B - Complex Attributes .............................. 34 111 B.1. CHAP-Password ........................................ 34 112 B.2. CHAP-Challenge ....................................... 34 113 B.3. Tunnel-Password ...................................... 34 114 B.4. ARAP-Password ........................................ 35 115 B.5. ARAP-Features ........................................ 35 116 B.6. Connect-Info ......................................... 36 117 B.7. Framed-IPv6-Prefix ................................... 37 118 B.8. Egress-VLANID ........................................ 37 119 B.9. Egress-VLAN-Name ..................................... 38 121 1. Introduction 123 This document provides guidelines for the design of RADIUS attributes 124 both within the IETF as well as within other SDOs. By articulating 125 RADIUS design guidelines, it is hoped that this document will 126 encourage the development and publication of high quality RADIUS 127 attribute specifications. 129 However, the advice in this document will not be helpful unless it is 130 put to use. As with "Guidelines for Authors and Reviewers of MIB 131 Documents" [RFC4181], it is expected that this document will be used 132 by authors to check their document against the guidelines prior to 133 requesting review (such as an "Expert Review" described in 134 [RFC3575]). Similarly, it is expected that this document will used 135 by reviewers (such as WG participants or the AAA Doctors [DOCTORS]), 136 resulting in an improvement in the consistency of reviews. 138 In order to meet these objectives, this document needs to cover not 139 only the science of attribute design, but also the art. Therefore, 140 in addition to covering the most frequently encountered issues, this 141 document attempts to provide some of the considerations motivating 142 the guidelines. 144 In order to characterize current attribute usage, both the basic and 145 complex data types defined in the existing RADIUS RFCs are reviewed. 147 1.1. Terminology 149 This document uses the following terms: 151 Network Access Server (NAS) 152 A device that provides an access service for a user to a network. 154 RADIUS server 155 A RADIUS authentication, authorization, and/or accounting (AAA) 156 server is an entity that provides one or more AAA services to a 157 NAS. 159 1.2. Requirements Language 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in [RFC2119]. 165 The uses of "MUST" and "MUST NOT" in this document are limited to (a) 166 requirements to follow the IETF process for IETF standards, and (b) 167 quotes from other documents. As a result, the uses of "MUST" and 168 "MUST NOT" in this document do not prescribe new mandatory behavior 169 within implementations. 171 1.3. Applicability 173 As RADIUS has become more widely accepted as a management protocol, 174 its usage has become more prevalent, both within the IETF as well as 175 within other SDOs. Given the expanded utilization of RADIUS, it has 176 become apparent that requiring SDOs to accomplish all their RADIUS 177 work within the IETF is inherently inefficient and unscalable. By 178 articulating guidelines for RADIUS attribute design, this document 179 enables SDOs out of the IETF to design their own RADIUS attributes 180 within the Vendor-Specific Attribute (VSA) space. 182 It is RECOMMENDED that SDOs follow the guidelines articulated in this 183 document. Doing so will ensure the widest possible applicability and 184 interoperability of the specifications, while requiring minimal 185 changes to existing systems. Specifications that do not follow the 186 guidelines articulated herein are NOT RECOMMENDED. However, we 187 recognize that there are some situations where SDOs or vendors 188 require the creation of specifications not following these 189 guidelines. We do not forbid these specifications, but it is 190 RECOMMENDED that they are created only if they have a limited scope 191 of applicability, and all attributes defined in those specifications 192 are VSAs, as discussed Appendix A.5, below. 194 It is RECOMMENDED that SDOs and vendors seek review of RADIUS 195 attribute specifications from the IETF. However, when specifications 196 are SDO specific, re-use existing data types, and follow these 197 guidelines, they do not require IETF review. 199 In order to enable IETF review of such specifications, the authors 200 recommend that: 202 * SDOs make their RADIUS attribute specifications publicly 203 available; 205 * SDOs request review of RADIUS attribute specifications by 206 sending email to the AAA Doctors [DOCTORS] or equivalent mailing 207 list; 209 * IETF and SDO RADIUS attribute specifications are reviewed 210 according to the guidelines proposed in this document; 212 * Reviews of specifications are posted to the RADEXT WG mailing 213 list, the AAA Doctors mailing list [DOCTORS] or another IETF 214 mailing list suggested by the Operations & Management Area 215 Directors of the IETF. 217 These reviews can assist with creation of specifications that meet 218 the SDO requirements, and which are also compatible with the 219 traditional data model and uses of RADIUS. While these reviews 220 require access to public specifications, the review process does not 221 require publication of an IETF RFC. 223 The advice in this document applies to attributes used to encode 224 service-provisioning or authentication data. RADIUS protocol 225 changes, or specification of attributes (such as Service-Type) that 226 can be used to, in effect, provide new RADIUS commands require 227 greater expertise and deeper review, as do changes to the RADIUS 228 operational model as discussed below in Section ZZZ. Such changes 229 MUST NOT be undertaken outside the IETF and when handled within the 230 IETF require "IETF Consensus" for adoption, as noted in [RFC3575] 231 Section 2.1. 233 2. Guidelines 235 The Remote Authentication Dial In User Service (RADIUS) defined in 236 [RFC2865] and [RFC2866] uses elements known as attributes in order to 237 represent authentication, authorization and accounting data. 239 Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does 240 not define a formal data definition language. The data type of 241 RADIUS attributes is not transported on the wire. Rather, the data 242 type of a RADIUS attribute is fixed when an attribute is defined. 243 Based on the RADIUS attribute type code, RADIUS clients and servers 244 can determine the data type based on preconfigured entries within a 245 data dictionary. 247 To explain the implications of this early RADIUS design decision we 248 distinguish two types of data types, namely "basic" and "complex". 249 Basic data types use one of the existing RADIUS data types as defined 250 below, encapsulated in a [RFC2865] format RADIUS attribute, or in a 251 [RFC2865] format RADIUS VSA. All other data formats are "complex 252 types". 254 RADIUS attributes are also divided into two distinct attribute 255 spaces: the standard space, and a Vendor-Specific space. Attributes 256 in the standard space follow the [RFC2865] attribute format, with 257 allocation managed by the Internet Assigned Number Authority (IANA). 259 The Vendor-Specific space is defined to be the contents of the 260 "String" field of the Vendor-Specific Attribute ([RFC2865] Section 261 5.26). See Section 2.2, below, for a more in-depth discussion. 263 2.1. Data Types 265 RADIUS defines a limited set of data types, defined as "basic data 266 types". The following data qualifies as "basic data types": 267 * 32-bit unsigned integer, in network byte order. 269 * Enumerated data types, represented as a 32-bit unsigned integer 270 with a list of name to value mappings. (e.g., Service-Type) 272 * Interface-Id (8 octet string in network byte order) 274 * IPv4 address in network byte order. 276 * IPv6 address in network byte order. 278 * IPv6 prefix. 280 * time as 32 bit unsigned value, in network byte order, and in 281 seconds since 00:00:00 UTC, January 1, 1970. 283 * string (i.e., binary data), totalling 253 octets or less in 284 length. This includes the opaque encapsulation of data 285 structures defined outside of RADIUS. See also Appendix A.1.3, 286 below. 288 * UTF-8 text, totalling 253 octets or less in length. 290 Note that the length limitations for VSAs of type String and Text are 291 less than 253 octets, due to the additional overhead of the Vendor- 292 Specific format. 294 The following data also qualifies as "basic data types": 296 * Attributes grouped into a logical container, using the 297 [RFC2868] tagging mechanism. This approach is NOT RECOMMENDED, 298 but is permissible where the alternatives are worse. 300 * Attributes requiring the transport of more than 247 octets of 301 Text or String data. This includes the opaque encapsulation 302 of data structures defined outside of RADIUS. 304 Nested groups or attributes do not qualify as "basic data types", and 305 SHOULD NOT be used. 307 All other data formats are defined to be "complex data types", and 308 are NOT RECOMMENDED. However, there may be situations where complex 309 attributes are beneficial because they reduce complexity in the non- 310 RADIUS systems. Unfortunately, there are no "hard and fast" rules 311 for where the complexity would best be located. Each situation has 312 to be decided on a case-by-case basis. 314 See Appendix B for an audit of existing attributes of complex data 315 types, including a discussion of benefits and drawbacks. 317 2.2. Vendor-Specific Space 319 The Vendor-Specific space is defined to be the contents of the 320 "String" field of the Vendor-Specific Attribute ([RFC2865] Section 321 5.26). As discussed there, it is intended for vendors to support 322 their own Attributes not suitable for general use. It is RECOMMENDED 323 that vendors follow the guidelines outlined here, which are intended 324 to enable maximum interoperability with minimal changes to existing 325 systems. 327 Following these guidelines means that RADIUS servers can be updated 328 to support the vendor's equipment by editing a RADIUS dictionary. If 329 these guidelines are not followed, then the vendor's equipment can 330 only be supported via code changes in RADIUS server implementations. 331 Such code changes add complexity and delay to implementations. 333 Vendor RADIUS Attribute specifications SHOULD allocate attributes 334 from the vendor space, rather than requesting an allocation from the 335 RADIUS standard attribute space. 337 All VSA schemes that do not follow the [RFC2865] recommendations are 338 NOT RECOMMENDED. All data formats other than described above as 339 "basic data types" are NOT RECOMMENDED. These non-standard formats 340 will typically not be implementable without RADIUS server code 341 changes. 343 Although [RFC2865] does not mandate it, implementations commonly 344 assume that the Vendor Id can be used as a key to determine the on- 345 the-wire format of a VSA. Vendors therefore SHOULD NOT use multiple 346 formats for VSAs that are associated with a particular Vendor Id. A 347 vendor wishing to use multiple VSA formats SHOULD request one Vendor 348 Id for each VSA format that they will use. 350 Notwithstanding the above recommendations, the format of the Vendor- 351 Specific space is under the complete control of individual vendors 352 and SDOs. The guidelines outlined here are only recommendations, and 353 do not define any requirements or restrictions on the Vendor-Specific 354 space. 356 2.3. Service definitions and RADIUS 358 RADIUS specifications define how an existing service or protocol can 359 be provisioned using RADIUS. Therefore, it is expected that a RADIUS 360 attribute specification will reference documents defining the 361 protocol or service to be provisioned. Within the IETF, a RADIUS 362 attribute specification SHOULD NOT be used to define the protocol or 363 service being provisioned. New services using RADIUS for 364 provisioning SHOULD be defined elsewhere and referenced in the RADIUS 365 specification. 367 New attributes, or new values of existing attributes, SHOULD NOT be 368 used to define new RADIUS commands. RADIUS attributes are intended 369 to: 371 * authenticate users 373 * authorize users (i.e., service provisioning or changes to 374 provisioning) 376 * account for user activity (i.e., logging of session activity) 378 New commands (i.e., the Code field in the packet header) are 379 allocated only through "IETF Consensus" as noted in [RFC3575] Section 380 2.1. Specifications also SHOULD NOT use new attributes to modify the 381 interpretation of existing RADIUS commands. 383 2.4. Translation of Vendor Specifications 385 The limitation on changes to the RADIUS protocol effectively 386 prohibits VSAs from changing fundamental aspects of RADIUS operation, 387 such as modifying RADIUS packet sequences, or adding new commands. 388 However, the requirement for clients and servers to be able to 389 operate in the absence of VSAs has proven to be less of a constraint, 390 since it is still possible for a RADIUS client and server to mutually 391 indicate support for VSAs, after which behavior expectations can be 392 reset. 394 Therefore, RFC 2865 provides considerable latitude for development of 395 new attributes within the vendor space, while prohibiting development 396 of protocol variants. This flexibility implies that RADIUS 397 attributes can often be developed within the vendor space without 398 loss (and possibly even with gain) in functionality. 400 As a result, translation of RADIUS attributes developed within the 401 vendor space into the standard space may provide only modest 402 benefits, while accelerating the exhaustion of the standard attribute 403 space. We do not expect that all RADIUS attribute specifications 404 requiring interoperability will be developed within the IETF, and 405 allocated from the standards space. A more scalable approach is to 406 recognize the flexibility of the vendor space, while working toward 407 improvements in the quality and availability of RADIUS attribute 408 specifications, regardless of where they are developed. 410 It is therefore NOT RECOMMENDED that specifications intended solely 411 for use by a vendor or SDO use be translated into the standard space. 413 3. Rationale 415 This section outlines the rationale behind the above recommendations. 417 3.1. RADIUS Operational Model 419 The RADIUS operational model includes several assumptions: 421 * The RADIUS protocol is stateless; 423 * Provisioning of services is not possible within an 424 Access-Reject; 426 * There is a distinction between authorization checks and user 427 authentication; 429 * The protocol provices for authentication and integrity 430 protection of packets; 432 * The RADIUS protocol is a Request/Response protocol; 434 * The protocol defines packet length restrictions. 436 While RADIUS server implementations may keep state, the RADIUS 437 protocol is stateless, although information may be passed from one 438 protocol transaction to another via the State Attribute. As a 439 result, documents which require stateful protocol behavior without 440 use of the State Attribute are inherently incompatible with RADIUS as 441 defined in [RFC2865], and need to be redesigned. See [RFC5080] 442 Section 2.1.1 for a more in-depth discussion of the use of the State 443 Attribute. 445 As noted in [RFC5080] Section 2.6, the intent of an Access-Reject is 446 to deny access to the requested service. As a result, RADIUS does 447 not allow the provisioning of services within an Access-Reject. 448 Documents which include provisioning of services within an Access- 449 Reject are inherently incompatible with RADIUS, and need to be 450 redesigned. 452 As noted in [RFC5080] Section 2.1.1, a RADIUS Access-Request may not 453 contain user authentication attributes or a State Attribute linking 454 the Access-Request to an earlier user authentication. Such an 455 Access-Request, known as an authorization check, provides no 456 assurance that it corresponds to a live user. RADIUS specifications 457 defining attributes containing confidential information (such as 458 Tunnel-Password) should be careful to prohibit such attributes from 459 being returned in response to an authorization check. Also, 460 [RFC5080] Section 2.1.1 notes that authentication mechanisms need to 461 tie a sequence of Access-Request/Access-Challenge packets together 462 into one authentication session. The State Attribute is RECOMMENDED 463 for this purpose. 465 While [RFC2865] did not require authentication and integrity 466 protection of RADIUS Access-Request packets, subsequent 467 authentication mechanism specifications such as RADIUS/EAP [RFC3579] 468 and Digest Authentication [RFC5090] have mandated authentication and 469 integrity protection for certain RADIUS packets. [RFC5080] Section 470 2.1.1 makes this behavior RECOMMENDED for all Access-Request packets, 471 including Access-Request packets performing authorization checks. It 472 is expected that specifications for new RADIUS authentication 473 mechanisms will continue this practice. 475 The RADIUS protocol as defined in [RFC2865] is a request-response 476 protocol spoken between RADIUS clients and servers. A single RADIUS 477 Access-Request packet will solicit in response at most a single 478 Access-Accept, Access-Reject or Access-Challenge packet, sent to the 479 IP address and port of the RADIUS Client that originated the Access- 480 Request. Similarly, a single Change-of-Authorization (CoA)-Request 481 packet [RFC5176] will solicit in response at most a single CoA-ACK or 482 CoA-NAK packet, sent to the IP address and port of the Dynamic 483 Authorization Client (DAC) that originated the CoA-Request. A single 484 Disconnect-Request packet will solicit in response at most a single 485 Disconnect-ACK or Disconnect-NAK packet, sent to the IP address and 486 port of the Dynamic Authorization Client (DAC) that originated the 487 Disconnect-Request. Changes to this model are likely to require 488 major revisions to existing implementations and so this practice is 489 NOT RECOMMENDED. 491 The Length field in the RADIUS packet header is defined in [RFC2865] 492 Section 3. It is noted there that the maximum length of a RADIUS 493 packet is 4096 octets. As a result, attribute designers SHOULD NOT 494 assume that a RADIUS implementation can successfully process RADIUS 495 packets larger than 4096 octets. 497 Even when packets are less than 4096 octets, they may be larger than 498 the Path Maximum Transmission Unit (PMTU). Any packet larger than 499 the PMTU will be fragmented, making communications more brittle as 500 firewalls and filtering devices often discard fragments. Transport 501 of fragmented UDP packets appears to be a poorly tested code path on 502 network devices. Some devices appear to be incapable of transporting 503 fragmented UDP packets, making it difficult to deploy RADIUS in a 504 network where those devices are deployed. We RECOMMEND that RADIUS 505 messages be kept as small possible. 507 If a situation is envisaged where it may be necessary to carry 508 authentication, authorization or accounting data in a packet larger 509 than 4096 octets, then one of the following approaches is 510 RECOMMENDED: 512 1. Utilization of a sequence of packets. 513 For RADIUS authentication, a sequence of Access-Request/ Access- 514 Challenge packets would be used. For this to be feasible, 515 attribute designers need to enable inclusion of attributes that 516 can consume considerable space within Access-Challenge packets. 517 To maintain compatibility with existing NASes, either the use of 518 Access-Challenge packets needs to be permissible (as with 519 RADIUS/EAP, defined in [RFC3579]), or support for receipt of an 520 Access-Challenge needs to be indicated by the NAS (as in RADIUS 521 Location [RFC5580]). Also, the specification needs to clearly 522 describe how attribute splitting is to be signalled and how 523 attributes included within the sequence are to be interpreted, 524 without requiring stateful operation. Unfortunately, previous 525 specifications have not always exhibited the required foresight. 526 For example, even though very large filter rules are 527 conceivable, the NAS-Filter-Rule Attribute defined in [RFC4849] 528 is not permitted in an Access-Challenge packet, nor is a 529 mechanism specified to allow a set of NAS-Filter-Rule attributes 530 to be split across an Access-Request/Access-Challenge sequence. 532 In the case of RADIUS accounting, transporting large amounts of 533 data would require a sequence of Accounting-Request packets. 534 This is a non-trivial change to RADIUS, since RADIUS accounting 535 clients would need to be modified to split the attribute stream 536 across multiple Accounting-Requests, and billing servers would 537 need to be modified to re-assemble and interpret the attribute 538 stream. 540 2. Utilization of names rather than values. 541 Where an attribute relates to a policy that could conceivably be 542 pre-provisioned on the NAS, then the name of the pre-provisioned 543 policy can be transmitted in an attribute, rather than the 544 policy itself, which could be quite large. An example of this 545 is the Filter-Id Attribute defined in [RFC2865] Section 5.11, 546 which enables a set of pre-provisioned filter rules to be 547 referenced by name. 549 3. Utilization of Packetization Layer Path MTU Discovery 550 techniques, as specified in [RFC4821]. As a last resort, where 551 the above techniques cannot be made to work, it may be possible 552 to apply the techniques described in [RFC4821] to discover the 553 maximum supported RADIUS packet size on the path between a 554 RADIUS client and a home server. While such an approach can 555 avoid the complexity of utilization of a sequence of packets, 556 dynamic discovery is likely to be time consuming and cannot be 557 guaranteed to work with existing RADIUS implementations. As a 558 result, this technique is not generally applicable. 560 3.2. Data Model Issues 562 The RADIUS data types are poorly defined. While [RFC2865] Section 5 563 defines basic data types, later specifications did not follow this 564 practice. This led implementations to define their own names for 565 data types, leading to non-standard names for those types. 567 In addition, the number of vendors and SDOs creating new attributes 568 within the Vendor-Specific attribute space has grown, and this has 569 lead to some divergence in approaches to RADIUS attribute design. 570 For example, vendors and SDOs have evolved the data model to support 571 new functions such as more data types, along with attribute grouping 572 and attribute fragmentation, with different groups taking different 573 approaches. These approaches are often incompatible, leading to 574 additional complexity in RADIUS implementations. 576 This section describes the history of the RADIUS data model, in an 577 attempt to codify existing practices, and to avoid repeating old 578 mistakes. 580 3.2.1. Basic Data Types 582 [RFC2865] and [RFC2866] utilize data types defined in [RFC2865] 583 Section 5, which states the following: 585 The format of the value field is one of five data types. Note 586 that type "text" is a subset of type "string". 588 text 1-253 octets containing UTF-8 encoded 10646 [RFC3629] 589 characters. Text of length zero (0) MUST NOT be sent; 590 omit the entire attribute instead. 592 string 1-253 octets containing binary data (values 0 through 593 255 decimal, inclusive). Strings of length zero (0) 594 MUST NOT be sent; omit the entire attribute instead. 596 address 32 bit value, most significant octet first. 598 integer 32 bit unsigned value, most significant octet first. 600 time 32 bit unsigned value, most significant octet first -- 601 seconds since 00:00:00 UTC, January 1, 1970. The 602 standard Attributes do not use this data type but it is 603 presented here for possible use in future attributes. 605 Subsequent RADIUS specifications also defined attributes using new 606 data types. These specifications did not explicitly define those 607 data types as was done in [RFC2865]. They did not consistently 608 indicate the format of the value field using the same conventions as 609 [RFC2865]. As a result, the data type is ambiguous in some cases, 610 and may not be consistent among different implementations. 612 It is out of the scope of this document to resolve all potential 613 ambiguities within existing RADIUS specifications. However in order 614 to prevent future ambiguities, it is recommended that future RADIUS 615 attribute specifications explicitly define newly created data types 616 at the beginning of the document, and indicate clearly the data type 617 to be used for each attribute. 619 [RFC3162] utilizes but does not explicitly define the following data 620 types: 622 IPv6 address 128 bit value, in network byte order. 623 IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to 624 128 bits of value, in network byte order. 626 Examples of the IPv6 address type include NAS-IPv6-Address defined in 627 [RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162] 628 Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3, 629 and in [RFC4818] Section 3. 631 While the Framed-Interface-Id attribute defined in [RFC3162] Section 632 2.2 included a value field of 8 octets, the data type was not 633 explicitly indicated, and therefore there is controversy over whether 634 the format of this attribute was intended to be an 8 octet String or 635 whether a special Interface-Id type was intended. 637 Given that attributes of type "IPv6 address" and "IPv6 prefix" are 638 already in use, it is RECOMMENDED that RADIUS server implementations 639 include support for these additional basic types, in addition to the 640 types defined in [RFC2865]. Where the intent is to represent a 641 specific IPv6 address, the "IPv6 address" type SHOULD be used. 642 Although it is possible to use the "IPv6 Prefix" type with a prefix 643 length of 128 to represent an IPv6 address, this usage is NOT 644 RECOMMENDED. Implementations supporting the Framed-Interface-Id 645 attribute may select a data type of their choosing (most likely an 8 646 octet String or a special Interface-Id data type). 648 It is worth noting that since RADIUS only supports unsigned integers 649 of 32 bits, attributes using signed integer data types or unsigned 650 integer types of other sizes will require code changes, and SHOULD be 651 avoided. 653 For [RFC2865] RADIUS VSAs, the length limitation of the String and 654 Text types is 247 octets instead of 253 octets, due to the additional 655 overhead of the Vendor-Specific Attribute. 657 3.2.2. Tagging Mechanism 659 [RFC2868] defines an attribute grouping mechanism based on the use of 660 a one octet tag value. Tunnel attributes that refer to the same 661 tunnel are grouped together by virtue of using the same tag value. 663 This tagging mechanism has some drawbacks. There are a limited 664 number of unique tags (31). The tags are not well suited for use 665 with arbitrary binary data values, because it is not always possible 666 to tell if the first byte after the Length is the tag or the first 667 byte of the untagged value (assuming the tag is optional). 669 Other limitations of the tagging mechanism are that when integer 670 values are tagged, the value portion is reduced to three bytes 671 meaning only 24-bit numbers can be represented. The tagging 672 mechanism does not offer an ability to create nested groups of 673 attributes. Some RADIUS implementations treat tagged attributes as 674 having additional data types tagged-string and tagged-integer. These 675 types increase the complexity of implementing and managing RADIUS 676 systems. 678 For these reasons, the tagging scheme described in RFC 2868 is NOT 679 RECOMMENDED for use as a generic grouping mechanism. 681 3.2.3. Complex Data Types 683 The RADIUS attribute encoding is summarized in [RFC2865]: 685 0 1 2 686 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 688 | Type | Length | Value ... 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 691 However, some standard attributes do not follow this format. 692 Attributes that use sub-fields instead of using a basic data type as 693 discussed in the above sections are defined to be "complex types". 694 As described below in this section the creation of complex types can 695 lead to interoperability and deployment issues, so they need to be 696 introduced with care. 698 In general, complex types sent from the RADIUS server to the client 699 can be supported by concatenating the values into a String data type 700 field. However, separating these values into different attributes, 701 each with its own type and length, would have the following benefits: 703 * it is easier for the user to enter the data as well-known 704 types, rather than complex structures; 706 * it enables additional error checking by leveraging the 707 parsing and validation routines for well-known types; 709 * it simplifies implementations by eliminating special-case 710 attribute-specific parsing. 712 One of the fundamental goals of the RADIUS protocol design was to 713 allow RADIUS servers to be configured to support new attributes 714 without requiring server code changes. RADIUS server implementations 715 typically provide support for basic data types, and define attributes 716 in a data dictionary. This architecture enables a new attribute to 717 be supported by the addition of a dictionary entry, without requiring 718 other RADIUS server code changes. 720 On the RADIUS client, code changes are typically required in order to 721 implement a new attribute. The RADIUS client typically has to 722 compose the attribute dynamically when sending. When receiving, a 723 RADIUS client needs to be able to parse the attribute and carry out 724 the requested service. As a result, a detailed understanding of the 725 new attribute is required on clients, and data dictionaries are less 726 useful on clients than on servers. 728 Given these considerations, the introduction of a new basic or 729 complex attribute will typically require code changes on the RADIUS 730 client. The magnitude of changes for the complex attribute could be 731 greater, due to the potential need for custom parsing logic. 733 The RADIUS server can be configured to send a new static attribute by 734 entering its type and data format in the RADIUS server dictionary, 735 and then filling in the value within a policy based on the attribute 736 name, data type and type-specific value. For data types not 737 supported by current RADIUS server dictionaries, changes to the 738 dictionary code can be required in order to allow the new type to be 739 supported by and configured on the RADIUS server. 741 Code changes can also be required in policy management and in the 742 RADIUS server's receive path. These changes are due to limitations 743 in RADIUS server policy languages, which typically only provide for 744 limited operations (such as comparisons or arithmetic operations) on 745 the existing data types. Many existing RADIUS policy languages 746 typically are not capable of parsing sub-elements, or providing 747 sophisticated matching functionality. 749 Given these limitations, the introduction of new types can require 750 code changes on the RADIUS server which would be unnecessary if basic 751 data types had been used instead. In addition if "ad-hoc" types are 752 used, attribute-specific parsing means more complex software to 753 develop and maintain. More complexity can lead to more error prone 754 implementations, interoperability problems, and even security 755 vulnerabilities. These issues can increase costs to network 756 administrators as well as reducing reliability and introducing 757 deployment barriers. We therefore RECOMMEND that the introduction of 758 new types and complex data types within RADIUS attribute 759 specifications be avoided. A potential exception to this 760 recommendation occurs for attributes that inherently require code 761 changes on both the client and server. For example, as described in 762 Appendix B, complex attributes have been used in situations involving 763 authentication and security attributes that need to be dynamically 764 computed and verified. 766 As can be seen in Appendix B, most of the existing complex attributes 767 involve authentication or security functionality. Supporting this 768 functionality requires code changes on both the RADIUS client and 769 server, regardless of the attribute format. As a result, in most 770 cases, the use of complex attributes to represent these methods is 771 acceptable, and does not create additional interoperability or 772 deployment issues. 774 The only other exception to the recommendation against complex types 775 is for types that can be treated as opaque data by the RADIUS server. 776 For example, the EAP-Message attribute, defined in [RFC3579] Section 777 3.1 contains a complex data type that is an EAP packet. Since these 778 complex types do not need to be parsed by the RADIUS server, the 779 issues arising from policy language limitations do not arise. 780 Similarly, since attributes of these complex types can be configured 781 on the server using a data type of String, dictionary limitations are 782 also not encountered. Appendix A.1 below includes a series of 783 checklists that may be used to analyze a design for RECOMMENDED and 784 NOT RECOMMENDED behavior in relation to complex types. 786 If the RADIUS Server simply passes the contents of an attribute to 787 some non-RADIUS portion of the network, then the data is opaque, and 788 SHOULD be defined to be of type String. A concrete way of judging 789 this requirement is whether or not the attribute definition in the 790 RADIUS document contains delineated fields for sub-parts of the data. 791 If those fields need to be delineated in RADIUS, then the data is not 792 opaque, and it SHOULD be separated into individual RADIUS attributes. 794 An examination of existing RADIUS RFCs discloses a number of complex 795 attributes that have already been defined. Appendix B includes a 796 listing of complex attributes used within [RFC2865], [RFC2868], 797 [RFC2869], [RFC3162], [RFC4818], and [RFC4675]. The discussion of 798 these attributes includes reasons why a complex type is acceptable, 799 or suggestions for how the attribute could have been defined to 800 follow the RADIUS data model. 802 In other cases, the data in the complex type are described textually. 803 This is possible because the data types are not sent within the 804 attributes, but are a matter for endpoint interpretation. An 805 implementation can define additional data types, and use these data 806 types today by matching them to the attribute's textual description. 808 Despite the above caveats, there may be situations where complex 809 attributes are beneficial because they reduce complexity in the non- 810 RADIUS systems. Unfortunately, there are no "hard and fast" rules 811 for where the complexity would best be located. Each situation has 812 to be decided on a case-by-case basis. 814 3.3. Vendor Space 816 The usage model for RADIUS VSAs is described in [RFC2865] Section 817 6.2: 819 Note that RADIUS defines a mechanism for Vendor-Specific 820 extensions (Attribute 26) and the use of that should be encouraged 821 instead of allocation of global attribute types, for functions 822 specific only to one vendor's implementation of RADIUS, where no 823 interoperability is deemed useful. 825 Nevertheless, many new attributes have been defined in the vendor 826 specific space in situations where interoperability is not only 827 useful, but is required. For example, SDOs outside the IETF (such as 828 the IEEE 802 and the 3rd Generation Partnership Project (3GPP)) have 829 been assigned Vendor-Ids, enabling them to define their own VSA 830 format and assign Vendor types within their own space. 832 The use of VSAs by SDOs outside the IETF has gained in popularity for 833 several reasons: 835 Efficiency 836 As with SNMP, which defines an "Enterprise" Object Identifier (OID) 837 space suitable for use by vendors as well as other SDOs, the 838 definition of Vendor-Specific RADIUS attributes has become a common 839 occurrence as part of standards activity outside the IETF. For 840 reasons of efficiency, it is easiest if the RADIUS attributes 841 required to manage a standard are developed within the same SDO 842 that develops the standard itself. As noted in "Transferring MIB 843 Work from IETF Bridge MIB WG to IEEE 802.1 WG" [RFC4663], today few 844 vendors are willing to simultaneously fund individuals to 845 participate within an SDO to complete a standard, as well as to 846 participate in the IETF in order to complete the associated RADIUS 847 attributes specification. 849 Attribute scarcity 850 The standard RADIUS attribute space is limited to 255 unique 851 attributes. Of these, only about half remain available for 852 allocation. In the Vendor-Specific space, the number of attributes 853 available is a function of the format of the attribute (the size of 854 the Vendor type field). 856 Along with these advantages, some limitations of VSA usage are noted 857 in [RFC2865] Section 5.26: 859 This Attribute is available to allow vendors to support their own 860 extended Attributes not suitable for general usage. It MUST NOT 861 affect the operation of the RADIUS protocol. 863 Servers not equipped to interpret the vendor-specific information 864 sent by a client MUST ignore it (although it may be reported). 865 Clients which do not receive desired vendor-specific information 866 SHOULD make an attempt to operate without it, although they may do 867 so (and report they are doing so) in a degraded mode. 869 3.3.1. Interoperability Considerations 871 Vendors and SDOs are reminded that the standard RADIUS attribute 872 space, and the enumerated value space for enumerated attributes, are 873 reserved for allocation through work published via the IETF, as noted 874 in [RFC3575] Section 2.1. Some vendors and SDOs have in the past 875 performed self-allocation by assigning vendor-specific meaning to 876 "unused" values from the standard RADIUS attribute ID or enumerated 877 value space. This self-allocation results in interoperability 878 issues, and is counter-productive. Similarly, the Vendor-Specific 879 enumeration practice discussed in [RFC2882] Section 2.2.1 is NOT 880 RECOMMENDED. 882 If it is not possible to follow the IETF process, vendors and SDOs 883 SHOULD self-allocate an attribute from their Vendor-Specific space, 884 and define an appropriate value for it. 886 As a side note, [RFC2865] Section 5.26 uses the term "Vendor-Specific 887 Attribute" to refer to an encoding format which can be used by 888 individual vendors to define attributes not suitable for general 889 usage. However, since then VSAs have also become widely used by SDOs 890 defining attributes intended for multi-vendor interoperability. As 891 such, these attributes are not specific to any single vendor, and the 892 term "Vendor-Specific" may be misleading. An alternate term which 893 better describes this use case is SDO-Specific Attribute (SSA). 895 The design and specification of VSAs for multi-vendor usage SHOULD be 896 undertaken with the same level of care as standard RADIUS attributes. 897 Specifically, the provisions of this document that apply to standard 898 RADIUS attributes also apply to SSAs or VSAs for multi-vendor usage. 900 3.3.2. Vendor Allocations 902 3.3.3. SDO Allocations 904 SDO RADIUS Attribute specifications SHOULD allocate attributes from 905 the vendor space, rather than requesting an allocation from the 906 RADIUS standard attribute space, for attributes matching any of the 907 following criteria: 909 * attributes relying on data types not defined within RADIUS 911 * attributes intended primarily for use within an SDO 913 * attributes intended primarily for use within a group of SDOs. 915 Any new RADIUS attributes or values intended for interoperable use 916 across a broad spectrum of the Internet Community SHOULD follow the 917 normal IETF process, and SHOULD result in allocations from the RADIUS 918 standard space. 920 The recommendation for SDOs to allocate attributes from a vendor 921 space rather than via the IETF process is a recognition that SDOs may 922 desire to assert change control over their own RADIUS specifications. 923 This change control can be obtained by requesting a PEC from the 924 Internet Assigned Number Authority (IANA), for use as a Vendor-Id 925 within a Vendor-Specific attribute. Further allocation of attributes 926 inside of the VSA space defined by that Vendor-Id is subject solely 927 to the discretion of the SDO. Similarly, the use of data types 928 (complex or not) within that VSA space is solely under the discretion 929 of the SDO. It is RECOMMENDED that SDOs follow the guidelines 930 outlined here, which are intended to enable maximum interoperability 931 with minimal changes to existing systems. 933 It should be understood that SDOs do not have to rehost VSAs into the 934 standards space solely for the purpose of obtaining IETF review. 935 Rehosting puts pressure on the standards space, and may be harmful to 936 interoperability, since it can create two ways to provision the same 937 service. Rehosting may also require changes to the RADIUS data model 938 which will affect implementations that do not intend to support the 939 SDO specifications. 941 3.3.4. Publication of specifications 943 SDOs are encouraged to seek early review of SSA specifications by the 944 IETF. This review may be initiated by sending mail to the AAA 945 Doctors list [DOCTORS], with the understanding that this review is a 946 voluntary-based service offered on best-effort basis. Since the IETF 947 is not a membership organization, in order to enable the RADIUS SSA 948 specification to be reviewed, it is RECOMMENDED that it be made 949 publicly available; this also encourages interoperability. Where the 950 RADIUS SSA specification is embedded within a larger document which 951 cannot be made public, the RADIUS attribute and value definitions 952 SHOULD be published instead as an Informational RFC, as with 953 [RFC4679]. This process SHOULD be followed instead of requesting 954 IANA allocations from within the standard RADIUS attribute space. 956 Similarly, vendors are encouraged to make their specifications 957 publicly available, for maximum interoperability. However, it is not 958 necessary for them to request publication of their VSA specifications 959 as Informational RFCs by the IETF. 961 All other specifications, including new authentication, 962 authorization, and/or security mechanisms SHOULD be allocated via the 963 standard RADIUS space, as noted in [RFC3575] Section 2.1. 965 3.4. Polymorphic Attributes 967 A polymorphic attribute is one whose format or meaning is dynamic. 968 For example, rather than using a fixed data format, an attribute's 969 format might change based on the contents of another attribute. Or, 970 the meaning of an attribute may depend on earlier packets in a 971 sequence. 973 RADIUS server dictionary entries are typically static, enabling the 974 user to enter the contents of an attribute without support for 975 changing the format based on dynamic conditions. However, this 976 limitation on static types does not prevent implementations from 977 implementing policies that return different attributes based on the 978 contents of received attributes; this is a common feature of existing 979 RADIUS implementations. 981 In general, polymorphism is NOT RECOMMENDED. Polymorphism rarely 982 enables capabilities that would not be available through use of 983 multiple attributes. Polymorphism requires code changes in the 984 RADIUS server in situations where attributes with fixed formats would 985 not require such changes. Thus, polymorphism increases complexity 986 while decreasing generality, without delivering any corresponding 987 benefits. 989 Note that changing an attribute's format dynamically is not the same 990 thing as using a fixed format and computing the attribute itself 991 dynamically. RADIUS authentication attributes such as User-Password, 992 EAP-Message, etc. while being computed dynamically, use a fixed 993 format. 995 4. IANA Considerations 997 This document does not require that the IANA update any existing 998 registry or create any new registry, but includes information that 999 affects the IANA, which: 1001 * includes specific guidelines for Expert Reviewers appointed 1002 under the IANA considerations of [RFC3575] 1004 * includes guidelines that recommend against self allocation from 1005 the RADIUS standard attribute space in other SDO RADIUS 1006 Attribute specifications. 1008 * recommends that SDOs request a Private Enterprise Code (PEC) 1009 from the IANA, for use as a Vendor-Id within a Vendor-Specific 1010 attribute. 1012 5. Security Considerations 1014 This specification provides guidelines for the design of RADIUS 1015 attributes used in authentication, authorization and accounting. 1016 Threats and security issues for this application are described in 1017 [RFC3579] and [RFC3580]; security issues encountered in roaming are 1018 described in [RFC2607]. 1020 Obfuscation of RADIUS attributes on a per-attribute basis is 1021 necessary in some cases. The current standard mechanism for this is 1022 described in [RFC2865] Section 5.2 (for obscuring User-Password 1023 values) and is based on the MD5 algorithm specified in [RFC1321]. 1024 The MD5 and SHA-1 algorithms have recently become a focus of scrutiny 1025 and concern in security circles, and as a result, the use of these 1026 algorithms in new attributes is NOT RECOMMENDED. In addition, 1027 previous documents referred to this method as generating "encrypted" 1028 data. This terminology is no longer accepted within the 1029 cryptographic community. 1031 Where new RADIUS attributes use cryptographic algorithms, algorithm 1032 negotiation SHOULD be supported. Specification of a mandatory-to- 1033 implement algorithm is REQUIRED, and it is RECOMMENDED that the 1034 mandatory-to-implement algorithm be certifiable under FIPS 140 1035 [FIPS]. 1037 Where new RADIUS attributes encapsulate complex data types, or 1038 transport opaque data, the security considerations discussed in 1039 Section 5.1 SHOULD be addressed. 1041 Message authentication in RADIUS is provided largely via the Message- 1042 Authenticator attribute. See [RFC3579] Section 3.2, and also 1043 [RFC5080] 2.2.2, which says that client implementations SHOULD 1044 include a Message-Authenticator attribute in every Access-Request. 1046 In general, the security of the RADIUS protocol is poor. Robust 1047 deployments SHOULD support a secure communications protocol such as 1048 IPSec. See [RFC3579] Section 4, and [RFC3580] Section 5 for a more 1049 in-depth explanation of these issues. 1051 Implementations not following the suggestions outlined in this 1052 document may be subject to a problems such as ambiguous protocol 1053 decoding, packet loss leading to loss of billing information, and 1054 denial of service attacks. 1056 5.1. New Data Types and Complex Attributes 1058 The introduction of complex data types brings the potential for the 1059 introduction of new security vulnerabilities. Experience shows that 1060 the common data types have few security vulnerabilities, or else that 1061 all known issues have been found and fixed. New data types require 1062 new code, which may introduce new bugs, and therefore new attack 1063 vectors. 1065 Some systems permit complex attributes to be defined via a method 1066 that is more capable than traditional RADIUS dictionaries. These 1067 systems can reduce the security threat of new types significantly, 1068 but they do not remove it entirely. 1070 RADIUS servers are highly valued targets, as they control network 1071 access and interact with databases that store usernames and 1072 passwords. An extreme outcome of a vulnerability due to a new, 1073 complex type would be that an attacker is capable of taking complete 1074 control over the RADIUS server. 1076 The use of attributes representing opaque data does not reduce this 1077 threat. The threat merely moves from the RADIUS server to the system 1078 that consumes that opaque data. 1080 The threat is particularly severe when the opaque data originates 1081 from the user, and is not validated by the NAS. In those cases, the 1082 RADIUS server is potentially exposed to attack by malware residing on 1083 an unauthenticated host. 1085 Any system consuming opaque data that originates from a RADIUS system 1086 SHOULD be properly isolated from that RADIUS system, and SHOULD run 1087 with minimal privileges. Any potential vulnerabilities in the non- 1088 RADIUS system will then have minimal impact on the security of the 1089 system as a whole. 1091 6. References 1093 6.1. Normative References 1095 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1096 Requirement Levels", BCP 14, RFC 2119, March 1997. 1098 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 1099 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1100 2000. 1102 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1103 Authentication Dial In User Service)", RFC 3575, July 2003. 1105 6.2. Informative References 1107 [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of 1108 management information for TCP/IP-based internets", STD 16, 1109 RFC 1155, May 1990. 1111 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 1112 Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1113 1990. 1115 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1116 April 1992. 1118 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1119 Implementation in Roaming", RFC 2607, June 1999. 1121 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1123 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., 1124 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 1125 Support", RFC 2868, June 2000. 1127 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", 1128 RFC 2869, June 2000. 1130 [RFC2882] Mitton, D, "Network Access Servers Requirements: Extended 1131 RADIUS Practices", RFC 2882, July 2000. 1133 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 1134 3162, August 2001. 1136 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 1137 In User Service) Support For Extensible Authentication 1138 Protocol (EAP)", RFC 3579, September 2003. 1140 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE 1141 802.1X Remote Authentication Dial In User Service (RADIUS) 1142 Usage Guidelines", RFC3580, September 2003. 1144 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1145 RFC 3629, November 2003. 1147 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 1148 Documents", RFC 4181, September 2005. 1150 [RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge MIB WG 1151 to IEEE 802.1 WG", RFC 4663, September 2006. 1153 [RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for 1154 Virtual LAN and Priority Support", RFC 4675, September 2006. 1156 [RFC4679] Mammoliti, V., et al., "DSL Forum Vendor-Specific RADIUS 1157 Attributes", RFC 4679, September 2006. 1159 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 1160 Attribute", RFC 4818, April 2007. 1162 [RFC4821] Mathis, M. and Heffner, J, "Packetization Layer Path MTU 1163 Discovery", RFC 4821, March 2007. 1165 [RFC4849] Congdon, P. et al, "RADIUS Filter-Rule Attribute", RFC 4849, 1166 April 2007. 1168 [RFC5080] Nelson, D. and DeKok, A, "Common Remote Authentication Dial In 1169 User Service (RADIUS) Implementation Issues and Suggested 1170 Fixes", RFC 5080, December 2007. 1172 [RFC5090] Sterman, B. et al., "RADIUS Extension for Digest 1173 Authentication", RFC 5090, February 2008. 1175 [RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote 1176 Authentication Dial In User Service (RADIUS)", RFC 5176, 1177 January 2008. 1179 [DOCTORS] AAA Doctors Mailing list 1181 [FIPS] FIPS 140-3 (DRAFT), "Security Requirements for Cryptographic 1182 Modules", http://csrc.nist.gov/publications/fips/fips140-3/ 1184 [IEEE-802.1Q] 1185 IEEE Standards for Local and Metropolitan Area Networks: Draft 1186 Standard for Virtual Bridged Local Area Networks, 1187 P802.1Q-2003, January 2003. 1189 [RFC5580] Tschofenig, H. (Ed.), "Carrying Location Objects in RADIUS and 1190 Diameter", RFC 5580, August 2009. 1192 Appendix A - Design Guidelines 1194 The following text provides guidelines for the design of attributes 1195 used by the RADIUS protocol. Specifications that follow these 1196 guidelines are expected to achieve maximum interoperability with 1197 minimal changes to existing systems. 1199 A.1. Types matching the RADIUS data model 1201 A.1.1. Transport of basic data types 1203 Does the data fit within the basic data types described in Section 1204 2.1.1, as outlined below? If so, it SHOULD be encapsulated in a 1205 [RFC2865] format RADIUS attribute, or in a [RFC2865] format RADIUS 1206 VSA that uses one of the existing RADIUS data types: 1208 * 32-bit unsigned integer, in network byte order. 1210 * Enumerated data types, represented as a 32-bit unsigned integer 1211 with a list of name to value mappings. (e.g., Service-Type) 1213 * Interface-Id (8 octet string in network byte order) 1215 * IPv4 address in network byte order. 1217 * IPv6 address in network byte order. 1219 * IPv6 prefix. 1221 * time as 32 bit unsigned value, in network byte order, and in 1222 seconds since 00:00:00 UTC, January 1, 1970. 1224 * string (i.e., binary data), totalling 253 octets or less in 1225 length. This includes the opaque encapsulation of data 1226 structures defined outside of RADIUS. See also Appendix A.1.3, 1227 below. 1229 * UTF-8 text, totalling 253 octets or less in length. 1231 Note that the length limitations for VSAs of type String and Text are 1232 less than 253 octets, due to the additional overhead of the Vendor- 1233 Specific format. 1235 The following data also qualifies as "basic data types": 1237 * Attributes grouped into a logical container, using the 1238 [RFC2868] tagging mechanism. This approach is NOT 1239 RECOMMENDED (see Section 2.1.2), but is permissible where 1240 the alternatives are worse. 1242 * Attributes requiring the transport of more than 247 octets of 1243 Text or String data. This includes the opaque encapsulation 1244 of data structures defined outside of RADIUS. See also Section 1245 A.1.3, below. 1247 Nested groups or attributes do not qualify as "basic data types", and 1248 SHOULD NOT be used. 1250 A.1.2. Transport of Authentication and Security Data 1252 Does the data provide authentication and/or security capabilities for 1253 the RADIUS protocol, as outlined below? If so, it SHOULD be 1254 encapsulated in a [RFC2865] format RADIUS attribute. It SHOULD NOT 1255 be encapsulated in a [RFC2865] format RADIUS VSA. 1257 * Complex data types that carry authentication methods which 1258 RADIUS servers are expected to parse and verify as part of 1259 an authentication process. 1261 * Complex data types that carry security information intended 1262 to increase the security of the RADIUS protocol itself. 1264 Any data type carrying authentication and/or security data that is 1265 not meant to be parsed by a RADIUS server is an "opaque data type", 1266 as defined below. 1268 A.1.3. Opaque data types 1270 Does the attribute encapsulate an existing data structure defined 1271 outside of the RADIUS specifications? Can the attribute be treated 1272 as opaque data by RADIUS servers (including proxies?) If both 1273 questions can be answered affirmatively, a complex structure MAY be 1274 used in a RADIUS specification. 1276 The specification of the attribute SHOULD define the encapsulating 1277 attribute to be of type String. The specification SHOULD refer to an 1278 external document defining the structure. The specification SHOULD 1279 NOT define or describe the structure, as discussed above in Section 1280 2.1.3. 1282 A.2. Improper Data Types 1284 All data types other than the ones described above in Appendix A.1 1285 and Appendix B SHOULD NOT be used. This section describes in detail 1286 a number of data types that are NOT RECOMMENDED in new RADIUS 1287 specifications. Where possible, replacement data types are 1288 suggested. 1290 A.2.1. Basic Data Types 1292 Does the attribute use any of the following data types? If so, the 1293 data type SHOULD be replaced with the suggested alternatives, or it 1294 SHOULD NOT be used at all. 1296 * Signed integers of any size. 1297 SHOULD NOT be used. SHOULD be replaced with one or more 1298 unsigned integer attributes. The definition of the attribute 1299 can contain information that would otherwise go into the sign 1300 value of the integer. 1302 * 8 bit unsigned integers. 1303 SHOULD be replaced with 32-bit unsigned integer. There is 1304 insufficient justification to save three bytes. 1306 * 16 bit unsigned integers. 1307 SHOULD be replaced with 32-bit unsigned integer. There is 1308 insufficient justification to save two bytes. 1310 * Unsigned integers of size other than 32 1311 SHOULD be replaced by an unsigned integer of 32 bits. 1312 There is insufficient justification to define a new size of 1313 integer. 1315 * Integers of any size in non-network byte order 1316 SHOULD be replaced by unsigned integer of 32 bits in network 1317 There is no reason to transport integers in any format other 1318 than network byte order. 1320 * Multi-field text strings. 1321 Each field SHOULD be encapsulated in a separate attribute. 1323 * Polymorphic attributes. 1324 Multiple attributes, each with a static data type SHOULD be 1325 defined instead. 1327 * Nested AVPs. 1328 Attributes should be defined in a flat typespace. 1330 A.2.2. Complex Data Types 1332 Does the attribute: 1334 * define a complex data type not described in Appendix B, 1335 * that a RADIUS server and/or client is expected to parse, 1336 validate, or create the contents of via a dynamic computation? 1337 i.e. A type that cannot be treated as opaque data (Section A.1.3) 1339 * involve functionality that could be implemented without code 1340 changes on both the client and server? (i.e. a type that doesn't 1341 require dynamic computation and verification, such as those 1342 performed for authentication or security attributes) 1344 If so, this data type SHOULD be replaced with simpler types, as 1345 discussed above in Appendix A.2.1. Also see Section 2.1.3 for a 1346 discussion of why complex types are problematic. 1348 A.3. Vendor-Specific formats 1350 Does the specification contain Vendor-Specific attributes that match 1351 any of the following criteria? If so, the data type should be 1352 replaced with the suggested alternatives, or should not be used at 1353 all. 1355 * Vendor types of more than 8 bits. 1356 SHOULD NOT be used. Vendor types of 8 bits SHOULD be used 1357 instead. 1359 * Vendor lengths of less than 8 bits. (i.e., zero bits) 1360 SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used 1361 instead. 1363 * Vendor lengths of more than 8 bits. 1364 SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used 1365 instead. 1367 * Vendor-Specific contents that are not in Type-Length-Value 1368 format. 1369 SHOULD NOT be used. Vendor-Specific attributes SHOULD be in 1370 Type-Length-Value format. 1372 In general, Vendor-Specific attributes SHOULD follow the [RFC2865] 1373 suggested format. Vendor extensions to non-standard formats are NOT 1374 RECOMMENDED as they can negatively affect interoperability. 1376 A.4. Changes to the RADIUS Operational Model 1378 Does the specification change the RADIUS operation model, as outlined 1379 in the list below? If so, then another method of achieving the 1380 design objectives SHOULD be used. Potential problem areas include: 1382 * Defining new commands in RADIUS using attributes. 1384 The addition of new commands to RADIUS MUST be handled via 1385 allocation of a new Code, and not by the use of an attribute. 1386 This restriction includes new commands created by overloading 1387 the Service-Type attribute to define new values that modify 1388 the functionality of Access-Request packets. 1390 * Using RADIUS as a transport protocol for data unrelated to 1391 authentication, authorization, or accounting. Using RADIUS to 1392 transport authentication methods such as EAP is explicitly 1393 permitted, even if those methods require the transport of 1394 relatively large amounts of data. Transport of opaque data 1395 relating to AAA is also permitted, as discussed above in 1396 Section 2.1.3. However, if the specification does not relate 1397 to AAA, then RADIUS SHOULD NOT be used. 1399 * Assuming support for packet lengths greater than 4096 octets. 1400 Attribute designers cannot assume that RADIUS implementations 1401 can successfully handle packets larger than 4096 octets. 1402 If a specification could lead to a RADIUS packet larger than 1403 4096 octets, then the alternatives described in Section 3.3 1404 SHOULD be considered. 1406 * Stateless operation. The RADIUS protocol is stateless, and 1407 documents which require stateful protocol behavior without the 1408 use of the State Attribute need to be redesigned. 1410 * Provisioning of service in an Access-Reject. Such provisioning 1411 is not permitted, and MUST NOT be used. If limited access needs 1412 to be provided, then an Access-Accept with appropriate 1413 authorizations can be used instead. 1415 * Lack of user authentication or authorization restrictions. 1416 In an authorization check, where there is no demonstration of a 1417 live user, confidential data cannot be returned. Where there 1418 is a link to a previous user authentication, the State attribute 1419 needs to be present. 1421 * Lack of per-packet integrity and authentication. 1422 It is expected that documents will support per-packet 1423 integrity and authentication. 1425 * Modification of RADIUS packet sequences. 1426 In RADIUS, each request is encapsulated in it's own packet, and 1427 elicits a single response that is sent to the requester. Since 1428 changes to this paradigm are likely to require major 1429 modifications to RADIUS client and server implementations, they 1430 SHOULD be avoided if possible. 1431 For further details, see Section 3.3. 1433 A.5. Allocation of attributes 1435 Does the attribute have a limited scope of applicability, as outlined 1436 below? If so, then the attributes SHOULD be allocated from the 1437 Vendor-Specific space. 1439 * attributes intended for a vendor to support their own systems, 1440 and not suitable for general usage 1442 * attributes relying on data types not defined within RADIUS 1444 * attributes intended primarily for use within an SDO 1446 * attributes intended primarily for use within a group of SDOs. 1448 Note that the points listed above do not relax the recommendations 1449 discussed in this document. Instead, they recognize that the RADIUS 1450 data model has limitations. In certain situations where 1451 interoperability can be strongly constrained by the SDO or vendor, an 1452 expanded data model MAY be used. We recommend, however, that the 1453 RADIUS data model SHOULD be used, even if it is marginally less 1454 efficient than alternatives. 1456 When attributes are used primarily within a group of SDOs, and are 1457 not applicable to the wider Internet community, we expect that one 1458 SDO will be responsible for allocation from their own private space. 1460 Appendix B - Complex Attributes 1462 This section summarizes RADIUS attributes with complex data types 1463 that are defined in existing RFCs. 1465 This appendix is published for informational purposes only, and 1466 reflects the usage of attributes with complex data types at the time 1467 of the publication of this document. 1469 B.1. CHAP-Password 1471 [RFC2865] Section 5.3 defines the CHAP-Password Attribute which is 1472 sent from the RADIUS client to the RADIUS server in an Access- 1473 Request. The data type of the CHAP Identifier is not given, only the 1474 one octet length: 1476 0 1 2 1477 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 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1479 | Type | Length | CHAP Ident | String ... 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1482 Since this is an authentication attribute, code changes are required 1483 on the RADIUS client and server to support it, regardless of the 1484 attribute format. Therefore, this complex data type is acceptable in 1485 this situation. 1487 B.2. CHAP-Challenge 1489 [RFC2865] Section 5.40 defines the CHAP-Challenge Attribute which is 1490 sent from the RADIUS client to the RADIUS server in an Access- 1491 Request. While the data type of the CHAP Identifier is given, the 1492 text also says: 1494 If the CHAP challenge value is 16 octets long it MAY be placed in 1495 the Request Authenticator field instead of using this attribute. 1497 Defining attributes to contain values taken from the RADIUS packet 1498 header is NOT RECOMMENDED. Attributes should have values that are 1499 packed into a RADIUS AVP. 1501 B.3. Tunnel-Password 1503 [RFC2868] Section 3.5 defines the Tunnel-Password Attribute, which is 1504 sent from the RADIUS server to the client in an Access-Accept. This 1505 attribute includes Tag and Salt fields, as well as a string field 1506 which consists of three logical sub-fields: the Data-Length (one 1507 octet) and Password sub-fields (both of which are required), and the 1508 optional Padding sub-field. The attribute appears as follows: 1510 0 1 2 3 1511 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 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 | Type | Length | Tag | Salt 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 Salt (cont) | String ... 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 Since this is a security attribute and is encrypted, code changes are 1519 required on the RADIUS client and server to support it, regardless of 1520 the attribute format. Therefore, this complex data type is 1521 acceptable in this situation. 1523 B.4. ARAP-Password 1525 [RFC2869] Section 5.4 defines the ARAP-Password attribute, which is 1526 sent from the RADIUS client to the server in an Access-Request. It 1527 contains four 4 octet values, instead of having a single Value field: 1529 0 1 2 3 1530 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 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 | Type | Length | Value1 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 | Value2 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 | Value3 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 | Value4 1539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1540 | 1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 As with the CHAP-Password attribute, this is an authentication 1544 attribute which would have required code changes on the RADIUS client 1545 and server regardless of format. 1547 B.5. ARAP-Features 1549 [RFC2869] Section 5.5 defines the ARAP-Features Attribute, which is 1550 sent from the RADIUS server to the client in an Access-Accept or 1551 Access-Challenge. It contains a compound string of two single octet 1552 values, plus three 4-octet values, which the RADIUS client 1553 encapsulates in a feature flags packet in the ARAP protocol: 1555 0 1 2 3 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 4 5 6 7 8 9 0 1 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 | Type | Length | Value1 | Value2 | 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 | Value3 | 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 | Value4 | 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 | Value5 | 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1567 Unlike the previous attributes, this attribute contains no encrypted 1568 component, nor is it directly involved in authentication. The 1569 individual sub-fields therefore could have been encapsulated in 1570 separate attributes. 1572 While the contents of this attribute is intended to be placed in an 1573 ARAP packet, the fields need to be set by the RADIUS server. Using 1574 standard RADIUS data types would have simplified RADIUS server 1575 implementations, and subsequent management. The current form of the 1576 attribute requires either the RADIUS server implementation, or the 1577 RADIUS server administrator, to understand the internals of the ARAP 1578 protocol. 1580 B.6. Connect-Info 1582 [RFC2869] Section 5.11 defines the Connect-Info attribute, which is 1583 used to indicate the nature of the connection. 1585 0 1 2 1586 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 | Type | Length | Text... 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 Even though the type is Text, the rest of the description indicates 1592 that it is a complex attribute: 1594 The Text field consists of UTF-8 encoded 10646 _8_ characters. 1595 The connection speed SHOULD be included at the beginning of the 1596 first Connect-Info attribute in the packet. If the transmit and 1597 receive connection speeds differ, they may both be included in the 1598 first attribute with the transmit speed first (the speed the NAS 1599 modem transmits at), a slash (/), the receive speed, then 1600 optionally other information. 1601 For example, "28800 V42BIS/LAPM" or "52000/31200 V90" 1603 More than one Connect-Info attribute may be present in an 1604 Accounting-Request packet to accommodate expected efforts by ITU 1605 to have modems report more connection information in a standard 1606 format that might exceed 252 octets. 1608 This attribute contains no encrypted component, and is it not 1609 directly involved in authentication. The individual sub-fields could 1610 therefore have been encapsulated in separate attributes. 1612 Since the form of the text string is well defined, there is no 1613 benefit in using a text string. Instead, an integer attribute should 1614 have been assigned for each of the transmit speed and the receive 1615 speed. A separate enumerated integer should have been assigned for 1616 the additional information, as is done for the NAS-Port-Type 1617 attribute. 1619 B.7. Framed-IPv6-Prefix 1621 [RFC3162] Section 2.3 defines the Framed-IPv6-Prefix Attribute and 1622 [RFC4818] Section 3 reuses this format for the Delegated-IPv6-Prefix 1623 Attribute; these attributes are sent from the RADIUS server to the 1624 client in an Access-Accept. 1626 0 1 2 3 1627 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 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 | Type | Length | Reserved | Prefix-Length | 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 Prefix 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 Prefix 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 Prefix 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 Prefix | 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 The sub-fields encoded in these attributes are strongly related, and 1641 there was no previous definition of this data structure that could be 1642 referenced. Support for this attribute requires code changes on both 1643 the client and server, due to a new data type being defined. In this 1644 case it appears to be acceptable to encode them in one attribute. 1646 B.8. Egress-VLANID 1648 [RFC4675] Section 2.1 defines the Egress-VLANID Attribute which can 1649 be sent by a RADIUS client or server. 1651 0 1 2 3 1652 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 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 | Type | Length | Value 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 Value (cont) | 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1659 While it appears superficially to be of type Integer, the Value field 1660 is actually a packed structure, as follows: 1662 0 1 2 3 1663 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 1664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1665 | Tag Indic. | Pad | VLANID | 1666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1668 The length of the VLANID field is defined by the [IEEE-802.1Q] 1669 specification. The Tag indicator field is either 0x31 or 0x32, for 1670 compatibility with the Egress-VLAN-Name, as discussed below. The 1671 complex structure of Egress-VLANID overlaps with that of the base 1672 Integer data type, meaning that no code changes are required for a 1673 RADIUS server to support this attribute. Code changes are required 1674 on the NAS, if only to implement the VLAN ID enforcement. 1676 Given the IEEE VLAN requirements and the limited data model of 1677 RADIUS, the chosen method is likely the best of the possible 1678 alternatives. 1680 B.9. Egress-VLAN-Name 1682 [RFC4675] Section 2.3 defines the Egress-VLAN-Name Attribute which 1683 can be sent by a RADIUS client or server. 1685 0 1 2 3 1686 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 1687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1688 | Type | Length | Tag Indic. | String... 1689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1691 The Tag Indicator is either the character '1' or '2', which in ASCII 1692 map to the identical values for Tag Indicator in Egress-VLANID, 1693 above. The complex structure of this attribute is acceptable for 1694 reasons identical to those given for Egress-VLANID. 1696 Acknowledgments 1698 We would like to acknowledge David Nelson, Bernard Aboba, Emile van 1699 Bergen, Barney Wolff and Glen Zorn for contributions to this 1700 document. 1702 Authors' Addresses 1704 Greg Weber 1705 Knoxville, TN 37932 1706 USA 1708 Email: gdweber@gmail.com 1710 Alan DeKok 1711 The FreeRADIUS Server Project 1712 http://freeradius.org/ 1714 Email: aland@freeradius.org