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