idnits 2.17.1 draft-ietf-radext-design-13.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 (14 April 2010) is 5125 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: October 14, 2010 7 14 April 2010 9 RADIUS Design Guidelines 10 draft-ietf-radext-design-13 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 October 14, 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 1.3.1. Impact on SDOs ................................. 7 77 2. Guidelines ............................................... 7 78 2.1. Data Types .......................................... 8 79 2.2. Vendor-Specific Attribute Space ..................... 9 80 2.3. Service definitions and RADIUS ...................... 10 81 2.4. Translation of Vendor Specifications ................ 11 82 3. Rationale ................................................ 11 83 3.1. RADIUS Operational Model ............................ 11 84 3.2. Data Model Issues ................................... 14 85 3.2.1. Basic Data Types ............................... 15 86 3.2.2. Tagging Mechanism .............................. 16 87 3.2.3. Complex Data Types ............................. 17 88 3.3. Vendor Space ........................................ 20 89 3.3.1. Interoperability Considerations ................ 21 90 3.3.2. Vendor Allocations ............................. 21 91 3.3.3. SDO Allocations ................................ 22 92 3.3.4. Publication of specifications .................. 22 93 3.4. Polymorphic Attributes .............................. 24 94 4. IANA Considerations ...................................... 24 95 5. Security Considerations .................................. 25 96 5.1. New Data Types and Complex Attributes ............... 26 97 6. References ............................................... 26 98 6.1. Normative References ................................ 26 99 6.2. Informative References .............................. 27 100 Appendix A - Design Guidelines ............................... 29 101 A.1. Types matching the RADIUS data model ................. 29 102 A.1.1. Transport of basic data types ................... 29 103 A.1.2. Transport of Authentication and Security Data ... 30 104 A.1.3. Opaque data types ............................... 30 105 A.2. Improper Data Types .................................. 30 106 A.2.1. Basic Data Types ................................ 31 107 A.2.2. Complex Data Types .............................. 31 108 A.3. Vendor-Specific formats .............................. 32 109 A.4. Changes to the RADIUS Operational Model .............. 32 110 A.5. Allocation of attributes ............................. 34 111 Appendix B - Complex Attributes .............................. 35 112 B.1. CHAP-Password ........................................ 35 113 B.2. CHAP-Challenge ....................................... 35 114 B.3. Tunnel-Password ...................................... 35 115 B.4. ARAP-Password ........................................ 36 116 B.5. ARAP-Features ........................................ 36 117 B.6. Connect-Info ......................................... 37 118 B.7. Framed-IPv6-Prefix ................................... 38 119 B.8. Egress-VLANID ........................................ 38 120 B.9. Egress-VLAN-Name ..................................... 39 121 B.9. Digest-* ............................................. 39 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 1.2. Requirements Language 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119]. 168 The uses of "MUST" and "MUST NOT" in this document are limited to (a) 169 requirements to follow the IETF process for IETF standards, and (b) 170 quotes from other documents. As a result, the uses of "MUST" and 171 "MUST NOT" in this document do not prescribe new mandatory behavior 172 within implementations. 174 1.3. Applicability 176 The reviews and advice in this document applies to attributes used to 177 encode service-provisioning, authentication, or accounting data, 178 based on the attribute formats and data encodings defined in RFC 2865 179 and subsequent RADIUS RFCs. It is RECOMMENDED that these guidelines 180 be applied to reviews of documents that request allocations within 181 the IETF standard attribute space defined in [RFC2865]. Doing so 182 will ensure the widest possible applicability and interoperability of 183 the specifications, while requiring minimal changes to existing 184 systems. 186 These guidelines may also prove useful in the design of attributes 187 within the Vendor-Specific Attribute (VSA) space. As noted in RFC 188 2865 Section 5.26, RADIUS VSAs were created "to allow vendors to 189 support their own extended Attributes not suitable for general 190 usage." Rather than requesting allocation of standard attributes for 191 those uses, [RFC2865] Section 6.2 notes that utilization of VSAs 192 "should be encouraged instead of allocation of global attribute 193 types, for functions specific only to one vendor's implementation of 194 RADIUS, where no interoperability is deemed useful." 196 However, experience has shown that attributes not originally designed 197 for general usage can subsequently garner wide-spread deployment. An 198 example is the vendor-specific attributes defined in [RFC2548], which 199 have been widely implemented within IEEE 802.11 Access Points. 201 While SDOs and vendors MAY choose to create specifications not 202 following these guidelines, this should be done only when those 203 specifications are intended for use in scenarios within a limited 204 scope of applicability. Where general usage is possible, adhering to 205 these guidelines is RECOMMENDED. 207 Guidelines are provided for vendor allocations in Section 3.3.2; and 208 for SDO allocations in Section 3.3.3. SDOs and vendors desiring 209 review of their specifications by the IETF are encouraged to follow 210 the advice presented in Section 3.3.4. 212 RADIUS protocol changes, or specification of attributes (such as 213 Service-Type) that can, in effect, provide new RADIUS commands 214 require greater expertise and deeper review, as do changes to the 215 RADIUS operational model. As a result, such changes are outside the 216 scope of this document and MUST NOT be undertaken outside the IETF. 218 1.3.1. Impact on SDOs 220 As RADIUS has become more widely accepted as a management protocol, 221 its usage has become more prevalent, both within the IETF as well as 222 within other SDOs. Given the expanded utilization of RADIUS, it has 223 become apparent that requiring SDOs to accomplish all their RADIUS 224 work within the IETF is inherently inefficient and unscalable. By 225 articulating guidelines for RADIUS attribute design, this document 226 enables SDOs out of the IETF to design their own RADIUS attributes 227 within the Vendor-Specific Attribute (VSA) space. 229 It is RECOMMENDED that SDOs follow the guidelines articulated in this 230 document. However, we recognize that there are some situations where 231 SDOs or vendors require the creation of specifications not following 232 these guidelines. We do not forbid these specifications, but it is 233 RECOMMENDED that they are created only if they have a limited scope 234 of applicability, and all new attributes defined in those 235 specifications are VSAs. See Section 3, below, for additional 236 discussion of this topic. 238 It is RECOMMENDED that SDOs and vendors seek review of RADIUS 239 attribute specifications from the IETF. However, specifications do 240 not require IETF review when they satisfy all of the following 241 criteria: 243 * are SDO specific; 245 * reference attributes from pre-existing IETF or SDO 246 specifications; 248 * define new attributes only in the VSA space; 250 * use only the "basic data types" (see below) for all VSAs; 252 * follow the guidelines given in this document. 254 2. Guidelines 256 The Remote Authentication Dial In User Service (RADIUS) defined in 257 [RFC2865] and [RFC2866] uses elements known as attributes in order to 258 represent authentication, authorization and accounting data. 260 Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does 261 not define a formal data definition language. The data type of 262 RADIUS attributes is not transported on the wire. Rather, the data 263 type of a RADIUS attribute is fixed when an attribute is defined. 264 Based on the RADIUS attribute type code, RADIUS clients and servers 265 can determine the data type based on preconfigured entries within a 266 data dictionary. 268 To explain the implications of this early RADIUS design decision we 269 distinguish two types of data types, namely "basic" and "complex". 270 Basic data types use one of the existing RADIUS data types as defined 271 below, encapsulated in a [RFC2865] format RADIUS attribute, or in a 272 [RFC2865] format RADIUS VSA. All other data formats are "complex 273 types". 275 RADIUS attributes are also divided into two distinct attribute 276 spaces: the "standard space", and a "Vendor-Specific Attribute 277 space". Attributes in the "standard space" follow the [RFC2865] 278 attribute format, with allocation managed by the Internet Assigned 279 Number Authority (IANA). Vendors MUST NOT "self-allocate" attributes 280 in this space, as they are not authoritative for it. 282 The VSA space is defined to be the contents of the "String" field of 283 the Vendor-Specific Attribute ([RFC2865] Section 5.26). Allocation 284 in this space is managed independently by each vendor. See Section 285 2.2, below, for a more in-depth discussion. 287 2.1. Data Types 289 RADIUS defines a limited set of data types, defined as "basic data 290 types". The following data qualifies as "basic data types": 292 * 32-bit unsigned integer, in network byte order. 294 * Enumerated data types, represented as a 32-bit unsigned integer 295 with a list of name to value mappings. (e.g. Service-Type) 297 * IPv4 address in network byte order. 299 * time as 32 bit unsigned value, in network byte order, and in 300 seconds since 00:00:00 UTC, January 1, 1970. 302 * IPv6 address in network byte order. 304 * Interface-Id (8 octet string in network byte order) 306 * IPv6 prefix. 308 * string (i.e., binary data), totalling 253 octets or less in 309 length. This includes the opaque encapsulation of data 310 structures defined outside of RADIUS. See also Appendix A.1.3, 311 below. 313 * UTF-8 text, totalling 253 octets or less in length. 315 Note that the length limitations for VSAs of type String and Text are 316 less than 253 octets, due to the additional overhead of the Vendor- 317 Specific format. 319 The following data also qualifies as "basic data types": 321 * Attributes grouped into a logical container, using the 322 [RFC2868] tagging mechanism. This approach is NOT RECOMMENDED, 323 but is permissible where the alternatives are worse. 325 * Attributes requiring the transport of more than 247 octets of 326 Text or String data. This includes the opaque encapsulation 327 of data structures defined outside of RADIUS. 328 (e.g. EAP-Message) 330 All other data formats are defined to be "complex data types", and 331 are NOT RECOMMENDED for normal use. Nested attributes, or attributes 332 grouped via methods other than defined in [RFC2868] do not qualify as 333 "basic data types", and SHOULD NOT be used. 335 There may be situations where complex attributes are acceptable 336 because they reduce complexity in non-RADIUS systems, or because 337 leveraging the basic data types would be awkward. Unfortunately, 338 there are no "hard and fast" rules for where the complexity would 339 best be located. Each situation has to be decided on a case-by-case 340 basis. The cost-benefit trade-off may result in a "complex data 341 type" being defined in RADIUS, as discussed in Appendix B. When this 342 is done, an explanation SHOULD be offered as to why the complex data 343 type was used. 345 2.2. Vendor-Specific Attribute Space 347 The Vendor-Specific Attribute space is defined to be the contents of 348 the "String" field of the Vendor-Specific Attribute ([RFC2865] 349 Section 5.26). As discussed there, it is intended for vendors to 350 support their own Attributes not suitable for general use. It is 351 RECOMMENDED that vendors follow the guidelines outlined here, which 352 are intended to enable maximum interoperability with minimal changes 353 to existing systems. 355 Following these guidelines means that RADIUS servers can be updated 356 to support the vendor's equipment by editing a RADIUS dictionary. If 357 these guidelines are not followed, then the vendor's equipment can 358 only be supported via code changes in RADIUS server implementations. 359 Such code changes add complexity and delay to implementations. 361 Vendor RADIUS Attribute specifications SHOULD allocate attributes 362 from the vendor space, rather than requesting an allocation from the 363 RADIUS standard attribute space. 365 All VSA schemes that do not follow the [RFC2865] recommendations are 366 NOT RECOMMENDED. All data formats other than described above as 367 "basic data types" are NOT RECOMMENDED. These non-standard formats 368 will typically not be implementable without RADIUS server code 369 changes. 371 Although [RFC2865] does not mandate it, implementations commonly 372 assume that the Vendor Id can be used as a key to determine the on- 373 the-wire format of a VSA. Vendors therefore SHOULD NOT use multiple 374 formats for VSAs that are associated with a particular Vendor Id. A 375 vendor wishing to use multiple VSA formats SHOULD request one Vendor 376 Id for each VSA format that they will use. 378 Notwithstanding the above recommendations, the format of the Vendor- 379 Specific space is under the complete control of individual vendors 380 and SDOs. The guidelines outlined here are only recommendations, and 381 do not define any requirements or restrictions on the Vendor-Specific 382 space. 384 2.3. Service definitions and RADIUS 386 RADIUS specifications define how an existing service or protocol can 387 be provisioned using RADIUS. Therefore, it is expected that a RADIUS 388 attribute specification will reference documents defining the 389 protocol or service to be provisioned. Within the IETF, a RADIUS 390 attribute specification SHOULD NOT be used to define the protocol or 391 service being provisioned. New services using RADIUS for 392 provisioning SHOULD be defined elsewhere and referenced in the RADIUS 393 specification. 395 New attributes, or new values of existing attributes, SHOULD NOT be 396 used to define new RADIUS commands. RADIUS attributes are intended 397 to: 399 * authenticate users 401 * authorize users (i.e., service provisioning or changes to 402 provisioning) 404 * account for user activity (i.e., logging of session activity) 406 New commands (i.e., the Code field in the packet header) and new 407 attributes in the "standard space" are allocated only through "IETF 408 Consensus" as noted in [RFC3575] Section 2.1. 410 2.4. Translation of Vendor Specifications 412 The limitation on changes to the RADIUS protocol effectively 413 prohibits VSAs from changing fundamental aspects of RADIUS operation, 414 such as modifying RADIUS packet sequences, or adding new commands. 415 However, the requirement for clients and servers to be able to 416 operate in the absence of VSAs has proven to be less of a constraint, 417 since it is still possible for a RADIUS client and server to mutually 418 indicate support for VSAs, after which behavior expectations can be 419 reset. 421 Therefore, RFC 2865 provides considerable latitude for development of 422 new attributes within the vendor space, while prohibiting development 423 of protocol variants. This flexibility implies that RADIUS 424 attributes can often be developed within the vendor space without 425 loss (and possibly even with gain) in functionality. 427 As a result, translation of RADIUS attributes developed within the 428 vendor space into the standard space may provide only modest 429 benefits, while accelerating the exhaustion of the standard attribute 430 space. We do not expect that all RADIUS attribute specifications 431 requiring interoperability will be developed within the IETF, and 432 allocated from the standards space. A more scalable approach is to 433 recognize the flexibility of the vendor space, while working toward 434 improvements in the quality and availability of RADIUS attribute 435 specifications, regardless of where they are developed. 437 It is therefore NOT RECOMMENDED that specifications intended solely 438 for use by a vendor or SDO use be translated into the standard space. 440 3. Rationale 442 This section outlines the rationale behind the above recommendations. 444 3.1. RADIUS Operational Model 446 The RADIUS operational model includes several assumptions: 448 * The RADIUS protocol is stateless; 450 * Provisioning of services is not possible within an 451 Access-Reject; 453 * There is a distinction between authorization checks and user 454 authentication; 456 * The protocol provides for authentication and integrity 457 protection of packets; 459 * The RADIUS protocol is a Request/Response protocol; 461 * The protocol defines packet length restrictions. 463 While RADIUS server implementations may keep state, the RADIUS 464 protocol is stateless, although information may be passed from one 465 protocol transaction to another via the State Attribute. As a 466 result, documents which require stateful protocol behavior without 467 use of the State Attribute are inherently incompatible with RADIUS as 468 defined in [RFC2865], and need to be redesigned. See [RFC5080] 469 Section 2.1.1 for a more in-depth discussion of the use of the State 470 Attribute. 472 As noted in [RFC5080] Section 2.6, the intent of an Access-Reject is 473 to deny access to the requested service. As a result, RADIUS does 474 not allow the provisioning of services within an Access-Reject. 475 Documents which include provisioning of services within an Access- 476 Reject are inherently incompatible with RADIUS, and need to be 477 redesigned. 479 As noted in [RFC5080] Section 2.1.1, a RADIUS Access-Request may not 480 contain user authentication attributes or a State Attribute linking 481 the Access-Request to an earlier user authentication. Such an 482 Access-Request, known as an authorization check, provides no 483 assurance that it corresponds to a live user. RADIUS specifications 484 defining attributes containing confidential information (such as 485 Tunnel-Password) should be careful to prohibit such attributes from 486 being returned in response to an authorization check. Also, 487 [RFC5080] Section 2.1.1 notes that authentication mechanisms need to 488 tie a sequence of Access-Request/Access-Challenge packets together 489 into one authentication session. The State Attribute is RECOMMENDED 490 for this purpose. 492 While [RFC2865] did not require authentication and integrity 493 protection of RADIUS Access-Request packets, subsequent 494 authentication mechanism specifications such as RADIUS/EAP [RFC3579] 495 and Digest Authentication [RFC5090] have mandated authentication and 496 integrity protection for certain RADIUS packets. [RFC5080] Section 497 2.1.1 makes this behavior RECOMMENDED for all Access-Request packets, 498 including Access-Request packets performing authorization checks. It 499 is expected that specifications for new RADIUS authentication 500 mechanisms will continue this practice. 502 The RADIUS protocol as defined in [RFC2865] is a request-response 503 protocol spoken between RADIUS clients and servers. A single RADIUS 504 Access-Request packet will solicit in response at most a single 505 Access-Accept, Access-Reject or Access-Challenge packet, sent to the 506 IP address and port of the RADIUS Client that originated the Access- 507 Request. Similarly, a single Change-of-Authorization (CoA)-Request 508 packet [RFC5176] will solicit in response at most a single CoA-ACK or 509 CoA-NAK packet, sent to the IP address and port of the Dynamic 510 Authorization Client (DAC) that originated the CoA-Request. A single 511 Disconnect-Request packet will solicit in response at most a single 512 Disconnect-ACK or Disconnect-NAK packet, sent to the IP address and 513 port of the Dynamic Authorization Client (DAC) that originated the 514 Disconnect-Request. Changes to this model are likely to require 515 major revisions to existing implementations and so this practice is 516 NOT RECOMMENDED. 518 The Length field in the RADIUS packet header is defined in [RFC2865] 519 Section 3. It is noted there that the maximum length of a RADIUS 520 packet is 4096 octets. As a result, attribute designers SHOULD NOT 521 assume that a RADIUS implementation can successfully process RADIUS 522 packets larger than 4096 octets. 524 Even when packets are less than 4096 octets, they may be larger than 525 the Path Maximum Transmission Unit (PMTU). Any packet larger than 526 the PMTU will be fragmented, making communications more brittle as 527 firewalls and filtering devices often discard fragments. Transport 528 of fragmented UDP packets appears to be a poorly tested code path on 529 network devices. Some devices appear to be incapable of transporting 530 fragmented UDP packets, making it difficult to deploy RADIUS in a 531 network where those devices are deployed. We RECOMMEND that RADIUS 532 messages be kept as small possible. 534 If a situation is envisaged where it may be necessary to carry 535 authentication, authorization or accounting data in a packet larger 536 than 4096 octets, then one of the following approaches is 537 RECOMMENDED: 539 1. Utilization of a sequence of packets. 540 For RADIUS authentication, a sequence of Access-Request/ Access- 541 Challenge packets would be used. For this to be feasible, 542 attribute designers need to enable inclusion of attributes that 543 can consume considerable space within Access-Challenge packets. 544 To maintain compatibility with existing NASes, either the use of 545 Access-Challenge packets needs to be permissible (as with 546 RADIUS/EAP, defined in [RFC3579]), or support for receipt of an 547 Access-Challenge needs to be indicated by the NAS (as in RADIUS 548 Location [RFC5580]). Also, the specification needs to clearly 549 describe how attribute splitting is to be signalled and how 550 attributes included within the sequence are to be interpreted, 551 without requiring stateful operation. Unfortunately, previous 552 specifications have not always exhibited the required foresight. 553 For example, even though very large filter rules are 554 conceivable, the NAS-Filter-Rule Attribute defined in [RFC4849] 555 is not permitted in an Access-Challenge packet, nor is a 556 mechanism specified to allow a set of NAS-Filter-Rule attributes 557 to be split across an Access-Request/Access-Challenge sequence. 559 In the case of RADIUS accounting, transporting large amounts of 560 data would require a sequence of Accounting-Request packets. 561 This is a non-trivial change to RADIUS, since RADIUS accounting 562 clients would need to be modified to split the attribute stream 563 across multiple Accounting-Requests, and billing servers would 564 need to be modified to re-assemble and interpret the attribute 565 stream. 567 2. Utilization of names rather than values. 568 Where an attribute relates to a policy that could conceivably be 569 pre-provisioned on the NAS, then the name of the pre-provisioned 570 policy can be transmitted in an attribute, rather than the 571 policy itself, which could be quite large. An example of this 572 is the Filter-Id Attribute defined in [RFC2865] Section 5.11, 573 which enables a set of pre-provisioned filter rules to be 574 referenced by name. 576 3. Utilization of Packetization Layer Path MTU Discovery 577 techniques, as specified in [RFC4821]. As a last resort, where 578 the above techniques cannot be made to work, it may be possible 579 to apply the techniques described in [RFC4821] to discover the 580 maximum supported RADIUS packet size on the path between a 581 RADIUS client and a home server. While such an approach can 582 avoid the complexity of utilization of a sequence of packets, 583 dynamic discovery is likely to be time consuming and cannot be 584 guaranteed to work with existing RADIUS implementations. As a 585 result, this technique is not generally applicable. 587 3.2. Data Model Issues 589 The RADIUS data types are poorly defined. While [RFC2865] Section 5 590 defines basic data types, later specifications did not follow this 591 practice. This problem has led implementations to define their own 592 names for data types, resulting in non-standard names for those 593 types. 595 In addition, the number of vendors and SDOs creating new attributes 596 within the Vendor-Specific attribute space has grown, and this has 597 lead to some divergence in approaches to RADIUS attribute design. 598 For example, vendors and SDOs have evolved the data model to support 599 functions such as new data types, along with attribute grouping and 600 attribute fragmentation, with different groups taking different 601 approaches. These approaches are often incompatible, leading to 602 additional complexity in RADIUS implementations. 604 In order to avoid repeating old mistakes, his section describes the 605 history of the RADIUS data model, and attempts to codify existing 606 practices. 608 3.2.1. Basic Data Types 610 [RFC2865] and [RFC2866] utilize data types defined in [RFC2865] 611 Section 5, which states the following: 613 The format of the value field is one of five data types. Note 614 that type "text" is a subset of type "string". 616 text 1-253 octets containing UTF-8 encoded 10646 [RFC3629] 617 characters. Text of length zero (0) MUST NOT be sent; 618 omit the entire attribute instead. 620 string 1-253 octets containing binary data (values 0 through 621 255 decimal, inclusive). Strings of length zero (0) 622 MUST NOT be sent; omit the entire attribute instead. 624 address 32 bit value, most significant octet first. 626 integer 32 bit unsigned value, most significant octet first. 628 time 32 bit unsigned value, most significant octet first -- 629 seconds since 00:00:00 UTC, January 1, 1970. The 630 standard Attributes do not use this data type but it is 631 presented here for possible use in future attributes. 633 Subsequent RADIUS specifications also defined attributes using new 634 data types. These specifications did not explicitly define those 635 data types as was done in [RFC2865]. They did not consistently 636 indicate the format of the value field using the same conventions as 637 [RFC2865]. As a result, the data type is ambiguous in some cases, 638 and may not be consistent among different implementations. 640 It is out of the scope of this document to resolve all potential 641 ambiguities within existing RADIUS specifications. However in order 642 to prevent future ambiguities, it is recommended that future RADIUS 643 attribute specifications explicitly define newly created data types 644 at the beginning of the document, and indicate clearly the data type 645 to be used for each attribute. 647 For example, [RFC3162] utilizes but does not explicitly define the 648 following data types: 650 IPv6 address 128 bit value, in network byte order. 652 IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to 653 128 bits of value, in network byte order. 655 The IPv6 address type is used for the NAS-IPv6-Address defined in 656 [RFC3162] Section 2.1 and the Login-IPv6-Host defined in [RFC3162] 657 Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3, 658 and in [RFC4818] Section 3. 660 While the Framed-Interface-Id attribute defined in [RFC3162] Section 661 2.2 included a value field of 8 octets, the data type was not 662 explicitly indicated, and therefore there is controversy over whether 663 the format of this attribute was intended to be an 8 octet String or 664 whether a special Interface-Id type was intended. 666 Given that attributes of type "IPv6 address" and "IPv6 prefix" are 667 already in use, it is RECOMMENDED that RADIUS server implementations 668 include support for these additional basic types, in addition to the 669 types defined in [RFC2865]. Where the intent is to represent a 670 specific IPv6 address, the "IPv6 address" type SHOULD be used. 671 Although it is possible to use the "IPv6 Prefix" type with a prefix 672 length of 128 to represent an IPv6 address, this usage is NOT 673 RECOMMENDED. Implementations supporting the Framed-Interface-Id 674 attribute may select a data type of their choosing (most likely an 8 675 octet String or a special Interface-Id data type). 677 It is worth noting that since RADIUS only supports unsigned integers 678 of 32 bits, attributes using signed integer data types or unsigned 679 integer types of other sizes will require code changes, and SHOULD be 680 avoided. 682 For [RFC2865] RADIUS VSAs, the length limitation of the String and 683 Text types is 247 octets instead of 253 octets, due to the additional 684 overhead of the Vendor-Specific Attribute. 686 3.2.2. Tagging Mechanism 688 [RFC2868] defines an attribute grouping mechanism based on the use of 689 a one octet tag value. Tunnel attributes that refer to the same 690 tunnel are grouped together by virtue of using the same tag value. 692 This tagging mechanism has some drawbacks. There are a limited 693 number of unique tags (31). The tags are not well suited for use 694 with arbitrary binary data values, because it is not always possible 695 to tell if the first byte after the Length is the tag or the first 696 byte of the untagged value (assuming the tag is optional). 698 Other limitations of the tagging mechanism are that when integer 699 values are tagged, the value portion is reduced to three bytes 700 meaning only 24-bit numbers can be represented. The tagging 701 mechanism does not offer an ability to create nested groups of 702 attributes. Some RADIUS implementations treat tagged attributes as 703 having additional data types tagged-string and tagged-integer. These 704 types increase the complexity of implementing and managing RADIUS 705 systems. 707 For these reasons, the tagging scheme described in RFC 2868 is NOT 708 RECOMMENDED for use as a generic grouping mechanism. 710 3.2.3. Complex Data Types 712 The RADIUS attribute encoding is summarized in [RFC2865]: 714 0 1 2 715 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 717 | Type | Length | Value ... 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 720 However, some standard attributes do not follow this format. 721 Attributes that use a format other than the basic data types as 722 discussed above are defined to be "complex types". As described 723 below in this section, the creation of complex types can lead to 724 interoperability and deployment issues, so they need to be introduced 725 with care. 727 In general, complex types containing multiple sub-fields can be 728 supported by concatenating the sub-fields into a String data type 729 field. However, separating these sub-fields into different 730 attributes, each with its own type and length, would have the 731 following benefits: 733 * it is easier for the user to enter the data as well-known 734 types, rather than complex structures; 736 * it enables additional error checking by leveraging the 737 parsing and validation routines for well-known types; 739 * it simplifies implementations by eliminating special-case 740 attribute-specific parsing. 742 One of the fundamental goals of the RADIUS protocol design was to 743 allow RADIUS servers to be configured to support new attributes 744 without requiring server code changes. RADIUS server implementations 745 typically provide support for basic data types, and define attributes 746 in a data dictionary. This architecture enables a new attribute to 747 be supported by the addition of a dictionary entry, without requiring 748 other RADIUS server code changes. 750 On the RADIUS client, code changes are typically required in order to 751 implement a new attribute. The RADIUS client typically has to 752 compose the attribute dynamically when sending. When receiving, a 753 RADIUS client needs to be able to parse the attribute and carry out 754 the requested service. As a result, a detailed understanding of the 755 new attribute is required on clients, and data dictionaries are less 756 useful on clients than on servers. 758 Given these considerations, the introduction of a new basic or 759 complex attribute will typically require code changes on the RADIUS 760 client. The magnitude of changes for the complex attribute could be 761 greater, due to the potential need for custom parsing logic. 763 The RADIUS server can be configured to send a new static attribute by 764 entering its type and data format in the RADIUS server dictionary, 765 and then filling in the value within a policy based on the attribute 766 name, data type and type-specific value. For data types not 767 supported by current RADIUS server dictionaries, changes to the 768 dictionary code can be required in order to allow the new type to be 769 supported by and configured on the RADIUS server. 771 Code changes can also be required in policy management and in the 772 RADIUS server's receive path. These changes are due to limitations 773 in RADIUS server policy languages, which typically only provide for 774 limited operations (such as comparisons or arithmetic operations) on 775 the existing data types. Many existing RADIUS policy languages 776 typically are not capable of parsing sub-elements, or providing 777 sophisticated matching functionality. 779 Given these limitations, the introduction of new types can require 780 code changes on the RADIUS server which would be unnecessary if basic 781 data types had been used instead. In addition if "ad-hoc" types are 782 used, attribute-specific parsing means more complex software to 783 develop and maintain. More complexity can lead to more error prone 784 implementations, interoperability problems, and even security 785 vulnerabilities. These issues can increase costs to network 786 administrators as well as reducing reliability and introducing 787 deployment barriers. We therefore RECOMMEND that the introduction of 788 new types and complex data types within RADIUS attribute 789 specifications be avoided. A potential exception to this 790 recommendation occurs for attributes that inherently require code 791 changes on both the client and server. For example, as described in 792 Appendix B, complex attributes have been used in situations involving 793 authentication and security attributes that need to be dynamically 794 computed and verified. 796 As can be seen in Appendix B, most of the existing complex attributes 797 involve authentication or security functionality. Supporting this 798 functionality requires code changes on both the RADIUS client and 799 server, regardless of the attribute format. As a result, in most 800 cases, the use of complex attributes to represent these methods is 801 acceptable, and does not create additional interoperability or 802 deployment issues. 804 The only other exception to the recommendation against complex types 805 is for types that can be treated as opaque data by the RADIUS server. 806 For example, the EAP-Message attribute, defined in [RFC3579] Section 807 3.1 contains a complex data type that is an EAP packet. Since these 808 complex types do not need to be parsed by the RADIUS server, the 809 issues arising from policy language limitations do not arise. 810 Similarly, since attributes of these complex types can be configured 811 on the server using a data type of String, dictionary limitations are 812 also not encountered. Appendix A.1 below includes a series of 813 checklists that may be used to analyze a design for RECOMMENDED and 814 NOT RECOMMENDED behavior in relation to complex types. 816 If the RADIUS Server simply passes the contents of an attribute to 817 some non-RADIUS portion of the network, then the data is opaque, and 818 SHOULD be defined to be of type String. A concrete way of judging 819 this requirement is whether or not the attribute definition in the 820 RADIUS document contains delineated fields for sub-parts of the data. 821 If those fields need to be delineated in RADIUS, then the data is not 822 opaque, and it SHOULD be separated into individual RADIUS attributes. 824 An examination of existing RADIUS RFCs discloses a number of complex 825 attributes that have already been defined. Appendix B includes a 826 listing of complex attributes used within [RFC2865], [RFC2868], 827 [RFC2869], [RFC3162], [RFC4818], and [RFC4675]. The discussion of 828 these attributes includes reasons why a complex type is acceptable, 829 or suggestions for how the attribute could have been defined to 830 follow the RADIUS data model. 832 In other cases, the data in the complex type are described textually. 833 This is possible because the data types are not sent within the 834 attributes, but are a matter for endpoint interpretation. An 835 implementation can define additional data types, and use these data 836 types today by matching them to the attribute's textual description. 838 Despite the above caveats, there may be situations where complex 839 attributes are beneficial because they reduce complexity in the non- 840 RADIUS systems. Unfortunately, there are no "hard and fast" rules 841 for where the complexity would best be located. Each situation has 842 to be decided on a case-by-case basis. 844 3.3. Vendor Space 846 The usage model for RADIUS VSAs is described in [RFC2865] Section 847 6.2: 849 Note that RADIUS defines a mechanism for Vendor-Specific 850 extensions (Attribute 26) and the use of that should be encouraged 851 instead of allocation of global attribute types, for functions 852 specific only to one vendor's implementation of RADIUS, where no 853 interoperability is deemed useful. 855 Nevertheless, many new attributes have been defined in the vendor 856 specific space in situations where interoperability is not only 857 useful, but is required. For example, SDOs outside the IETF (such as 858 the IEEE 802 and the 3rd Generation Partnership Project (3GPP)) have 859 been assigned Vendor-Ids, enabling them to define their own VSA 860 format and assign Vendor types within their own space. 862 The use of VSAs by SDOs outside the IETF has gained in popularity for 863 several reasons: 865 Efficiency 866 As with SNMP, which defines an "Enterprise" Object Identifier (OID) 867 space suitable for use by vendors as well as other SDOs, the 868 definition of Vendor-Specific RADIUS attributes has become a common 869 occurrence as part of standards activity outside the IETF. For 870 reasons of efficiency, it is easiest if the RADIUS attributes 871 required to manage a standard are developed within the same SDO 872 that develops the standard itself. As noted in "Transferring MIB 873 Work from IETF Bridge MIB WG to IEEE 802.1 WG" [RFC4663], today few 874 vendors are willing to simultaneously fund individuals to 875 participate within an SDO to complete a standard, as well as to 876 participate in the IETF in order to complete the associated RADIUS 877 attributes specification. 879 Attribute scarcity 880 The standard RADIUS attribute space is limited to 255 unique 881 attributes. Of these, only about half remain available for 882 allocation. In the Vendor-Specific space, the number of attributes 883 available is a function of the format of the attribute (the size of 884 the Vendor type field). 886 Along with these advantages, some limitations of VSA usage are noted 887 in [RFC2865] Section 5.26: 889 This Attribute is available to allow vendors to support their own 890 extended Attributes not suitable for general usage. It MUST NOT 891 affect the operation of the RADIUS protocol. 893 Servers not equipped to interpret the vendor-specific information 894 sent by a client MUST ignore it (although it may be reported). 895 Clients which do not receive desired vendor-specific information 896 SHOULD make an attempt to operate without it, although they may do 897 so (and report they are doing so) in a degraded mode. 899 3.3.1. Interoperability Considerations 901 Vendors and SDOs are reminded that the standard RADIUS attribute 902 space, and the enumerated value space for enumerated attributes, are 903 reserved for allocation through work published via the IETF, as noted 904 in [RFC3575] Section 2.1. Some vendors and SDOs have in the past 905 performed self-allocation by assigning vendor-specific meaning to 906 "unused" values from the standard RADIUS attribute ID or enumerated 907 value space. This self-allocation results in interoperability 908 issues, and is counter-productive. Similarly, the Vendor-Specific 909 enumeration practice discussed in [RFC2882] Section 2.2.1 is NOT 910 RECOMMENDED. 912 If it is not possible to follow the IETF process, vendors and SDOs 913 SHOULD self-allocate an attribute from their Vendor-Specific space, 914 as discussed in Sections 3.3.2 and 3.3.3, below. 916 The design and specification of VSAs for multi-vendor usage SHOULD be 917 undertaken with the same level of care as standard RADIUS attributes. 918 Specifically, the provisions of this document that apply to standard 919 RADIUS attributes also apply to VSAs for multi-vendor usage. 921 3.3.2. Vendor Allocations 923 As noted in [RFC3575] Section 2.1, vendors are encouraged to utilize 924 VSAs to define functions "specific only to one vendor's 925 implementation of RADIUS, where no interoperability is deemed useful. 926 For functions specific only to one vendor's implementation of RADIUS, 927 the use of that should be encouraged instead of the allocation of 928 global attribute types." 930 The recommendation for vendors to allocate attributes from a vendor 931 space rather than via the IETF process is a recognition that vendors 932 desire to assert change control over their own RADIUS specifications. 933 This change control can be obtained by requesting a PEC from the 934 Internet Assigned Number Authority (IANA), for use as a Vendor-Id 935 within a Vendor-Specific attribute. The vendor can then allocate 936 attributes within the VSA space defined by that Vendor-Id, at their 937 sole discretion. Similarly, the use of data types (complex or 938 otherwise) within that VSA space is solely under the discretion of 939 the vendor. 941 Nevertheless, following the guidelines outlined within this document 942 has many advantages. It is therefore RECOMMENDED that vendors follow 943 the guidelines outlined here, which are intended to enable maximum 944 interoperability with minimal changes to existing systems. If these 945 guidelines are not followed, the result will be increased complexity 946 with little or no benefit. 948 3.3.3. SDO Allocations 950 Given the expanded utilization of RADIUS, it has become apparent that 951 requiring SDOs to accomplish all their RADIUS work within the IETF is 952 inherently inefficient and unscalable. Is is therefore RECOMMENDED 953 that SDO RADIUS Attribute specifications allocate attributes from the 954 vendor space, rather than requesting an allocation from the RADIUS 955 standard attribute space, for attributes matching any of the 956 following criteria: 958 * attributes relying on data types not defined within RADIUS 960 * attributes intended primarily for use within an SDO 962 * attributes intended primarily for use within a group of SDOs. 964 Any new RADIUS attributes or values intended for interoperable use 965 across a broad spectrum of the Internet Community SHOULD follow the 966 allocation process defined in [RFC3575]. 968 The recommendation for SDOs to allocate attributes from a vendor 969 space rather than via the IETF process is a recognition that SDOs 970 desire to assert change control over their own RADIUS specifications. 971 This change control can be obtained by requesting a PEC from the 972 Internet Assigned Number Authority (IANA), for use as a Vendor-Id 973 within a Vendor-Specific attribute. The SDO can then allocate 974 attributes within the VSA space defined by that Vendor-Id, at their 975 sole discretion. Similarly, the use of data types (complex or 976 otherwise) within that VSA space is solely under the discretion of 977 the SDO. 979 Nevertheless, following the guidelines outlined within this document 980 has many advantages. It is therefore RECOMMENDED that SDOs follow 981 the guidelines outlined here, which are intended to enable maximum 982 interoperability with minimal changes to existing systems. 984 3.3.4. Publication of specifications 986 In order to enable IETF review of SDO specifications, it is 987 RECOMMENDED that: 989 * SDOs make their RADIUS attribute specifications publicly 990 available; 992 * SDOs request review of RADIUS attribute specifications by 993 sending email to the AAA Doctors [DOCTORS] or equivalent mailing 994 list; 996 * IETF and SDO RADIUS attribute specifications are reviewed 997 according to the guidelines proposed in this document; 999 * Reviews of specifications are posted to the RADEXT WG mailing 1000 list, 1001 the AAA Doctors mailing list [DOCTORS] or another IETF mailing 1002 list 1003 suggested by the Operations & Management Area Directors of the 1004 IETF. 1006 It should be understood that SDOs do not have to rehost VSAs into the 1007 standards space solely for the purpose of obtaining IETF review. 1008 Rehosting puts pressure on the standards space, and may be harmful to 1009 interoperability, since it can create two ways to provision the same 1010 service. Rehosting may also require changes to the RADIUS data model 1011 which will affect implementations that do not intend to support the 1012 SDO specifications. 1014 These reviews can assist with creation of specifications that meet 1015 the SDO requirements, and which are also compatible with the 1016 traditional data model and uses of RADIUS. While these reviews 1017 require access to public specifications, the review process does not 1018 require publication of an IETF RFC. 1020 SDOs are encouraged to seek early review of their specifications by 1021 the IETF. It should be understood that reviews are a voluntary-based 1022 service offered on best-effort basis. 1024 Where the RADIUS specification is embedded within a larger document 1025 which cannot be made public, the RADIUS attribute and value 1026 definitions SHOULD be published instead as an Informational RFC, as 1027 with [RFC4679]. This process SHOULD be followed instead of 1028 requesting IANA allocations from within the standard RADIUS attribute 1029 space. 1031 Similarly, vendors are encouraged to make their specifications 1032 publicly available, for maximum interoperability. However, it is not 1033 necessary for them to request publication of their VSA specifications 1034 as Informational RFCs by the IETF. 1036 All other specifications, including new authentication, 1037 authorization, and/or security mechanisms SHOULD follow the 1038 allocation process defined in [RFC3575]. 1040 3.4. Polymorphic Attributes 1042 A polymorphic attribute is one whose format or meaning is dynamic. 1043 For example, rather than using a fixed data format, an attribute's 1044 format might change based on the contents of another attribute. Or, 1045 the meaning of an attribute may depend on earlier packets in a 1046 sequence. 1048 RADIUS server dictionary entries are typically static, enabling the 1049 user to enter the contents of an attribute without support for 1050 changing the format based on dynamic conditions. However, this 1051 limitation on static types does not prevent implementations from 1052 implementing policies that return different attributes based on the 1053 contents of received attributes; this is a common feature of existing 1054 RADIUS implementations. 1056 In general, polymorphism is NOT RECOMMENDED. Polymorphism rarely 1057 enables capabilities that would not be available through use of 1058 multiple attributes. Polymorphism requires code changes in the 1059 RADIUS server in situations where attributes with fixed formats would 1060 not require such changes. Thus, polymorphism increases complexity 1061 while decreasing generality, without delivering any corresponding 1062 benefits. 1064 Note that changing an attribute's format dynamically is not the same 1065 thing as using a fixed format and computing the attribute itself 1066 dynamically. RADIUS authentication attributes such as User-Password, 1067 EAP-Message, etc. while being computed dynamically, use a fixed 1068 format. 1070 4. IANA Considerations 1072 This document does not require that the IANA update any existing 1073 registry or create any new registry, but includes information that 1074 affects the IANA, which: 1076 * includes specific guidelines for Expert Reviewers appointed 1077 under the IANA considerations of [RFC3575] 1079 * includes guidelines that recommend against self allocation from 1080 the RADIUS standard attribute space in other SDO RADIUS 1081 Attribute specifications. 1083 * recommends that SDOs request a Private Enterprise Code (PEC) 1084 from the IANA, for use as a Vendor-Id within a Vendor-Specific 1085 attribute. 1087 5. Security Considerations 1089 This specification provides guidelines for the design of RADIUS 1090 attributes used in authentication, authorization and accounting. 1091 Threats and security issues for this application are described in 1092 [RFC3579] and [RFC3580]; security issues encountered in roaming are 1093 described in [RFC2607]. 1095 Obfuscation of RADIUS attributes on a per-attribute basis is 1096 necessary in some cases. The current standard mechanism for this is 1097 described in [RFC2865] Section 5.2 (for obscuring User-Password 1098 values) and is based on the MD5 algorithm specified in [RFC1321]. 1099 The MD5 and SHA-1 algorithms have recently become a focus of scrutiny 1100 and concern in security circles, and as a result, the use of these 1101 algorithms in new attributes is NOT RECOMMENDED. In addition, 1102 previous documents referred to this method as generating "encrypted" 1103 data. This terminology is no longer accepted within the 1104 cryptographic community. 1106 Where new RADIUS attributes use cryptographic algorithms, algorithm 1107 negotiation SHOULD be supported. Specification of a mandatory-to- 1108 implement algorithm is REQUIRED, and it is RECOMMENDED that the 1109 mandatory-to-implement algorithm be certifiable under FIPS 140 1110 [FIPS]. 1112 Where new RADIUS attributes encapsulate complex data types, or 1113 transport opaque data, the security considerations discussed in 1114 Section 5.1 SHOULD be addressed. 1116 Message authentication in RADIUS is provided largely via the Message- 1117 Authenticator attribute. See [RFC3579] Section 3.2, and also 1118 [RFC5080] 2.2.2, which says that client implementations SHOULD 1119 include a Message-Authenticator attribute in every Access-Request. 1121 In general, the security of the RADIUS protocol is poor. Robust 1122 deployments SHOULD support a secure communications protocol such as 1123 IPSec. See [RFC3579] Section 4, and [RFC3580] Section 5 for a more 1124 in-depth explanation of these issues. 1126 Implementations not following the suggestions outlined in this 1127 document may be subject to a problems such as ambiguous protocol 1128 decoding, packet loss leading to loss of billing information, and 1129 denial of service attacks. 1131 5.1. New Data Types and Complex Attributes 1133 The introduction of complex data types brings the potential for the 1134 introduction of new security vulnerabilities. Experience shows that 1135 the common data types have few security vulnerabilities, or else that 1136 all known issues have been found and fixed. New data types require 1137 new code, which may introduce new bugs, and therefore new attack 1138 vectors. 1140 Some systems permit complex attributes to be defined via a method 1141 that is more capable than traditional RADIUS dictionaries. These 1142 systems can reduce the security threat of new types significantly, 1143 but they do not remove it entirely. 1145 RADIUS servers are highly valued targets, as they control network 1146 access and interact with databases that store usernames and 1147 passwords. An extreme outcome of a vulnerability due to a new, 1148 complex type would be that an attacker is capable of taking complete 1149 control over the RADIUS server. 1151 The use of attributes representing opaque data does not reduce this 1152 threat. The threat merely moves from the RADIUS server to the system 1153 that consumes that opaque data. 1155 The threat is particularly severe when the opaque data originates 1156 from the user, and is not validated by the NAS. In those cases, the 1157 RADIUS server is potentially exposed to attack by malware residing on 1158 an unauthenticated host. 1160 Any system consuming opaque data that originates from a RADIUS system 1161 SHOULD be properly isolated from that RADIUS system, and SHOULD run 1162 with minimal privileges. Any potential vulnerabilities in the non- 1163 RADIUS system will then have minimal impact on the security of the 1164 system as a whole. 1166 6. References 1168 6.1. Normative References 1170 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1171 Requirement Levels", BCP 14, RFC 2119, March 1997. 1173 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 1174 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1175 2000. 1177 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1178 Authentication Dial In User Service)", RFC 3575, July 2003. 1180 6.2. Informative References 1182 [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of 1183 management information for TCP/IP-based internets", STD 16, 1184 RFC 1155, May 1990. 1186 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 1187 Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1188 1990. 1190 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1191 April 1992. 1193 [RFC2548] Zorn, Glen, "Microsoft Vendor-specific RADIUS Attributes", RFC 1194 2548, March 1999. 1196 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1197 Implementation in Roaming", RFC 2607, June 1999. 1199 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1201 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., 1202 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 1203 Support", RFC 2868, June 2000. 1205 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", 1206 RFC 2869, June 2000. 1208 [RFC2882] Mitton, D, "Network Access Servers Requirements: Extended 1209 RADIUS Practices", RFC 2882, July 2000. 1211 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 1212 3162, August 2001. 1214 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 1215 In User Service) Support For Extensible Authentication 1216 Protocol (EAP)", RFC 3579, September 2003. 1218 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE 1219 802.1X Remote Authentication Dial In User Service (RADIUS) 1220 Usage Guidelines", RFC3580, September 2003. 1222 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1223 RFC 3629, November 2003. 1225 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 1226 Documents", RFC 4181, September 2005. 1228 [RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge MIB WG 1229 to IEEE 802.1 WG", RFC 4663, September 2006. 1231 [RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for 1232 Virtual LAN and Priority Support", RFC 4675, September 2006. 1234 [RFC4679] Mammoliti, V., et al., "DSL Forum Vendor-Specific RADIUS 1235 Attributes", RFC 4679, September 2006. 1237 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 1238 Attribute", RFC 4818, April 2007. 1240 [RFC4821] Mathis, M. and Heffner, J, "Packetization Layer Path MTU 1241 Discovery", RFC 4821, March 2007. 1243 [RFC4849] Congdon, P. et al, "RADIUS Filter-Rule Attribute", RFC 4849, 1244 April 2007. 1246 [RFC5080] Nelson, D. and DeKok, A, "Common Remote Authentication Dial In 1247 User Service (RADIUS) Implementation Issues and Suggested 1248 Fixes", RFC 5080, December 2007. 1250 [RFC5090] Sterman, B. et al., "RADIUS Extension for Digest 1251 Authentication", RFC 5090, February 2008. 1253 [RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote 1254 Authentication Dial In User Service (RADIUS)", RFC 5176, 1255 January 2008. 1257 [DOCTORS] AAA Doctors Mailing list 1259 [FIPS] FIPS 140-3 (DRAFT), "Security Requirements for Cryptographic 1260 Modules", http://csrc.nist.gov/publications/fips/fips140-3/ 1262 [IEEE-802.1Q] 1263 IEEE Standards for Local and Metropolitan Area Networks: Draft 1264 Standard for Virtual Bridged Local Area Networks, 1265 P802.1Q-2003, January 2003. 1267 [RFC5580] Tschofenig, H. (Ed.), "Carrying Location Objects in RADIUS and 1268 Diameter", RFC 5580, August 2009. 1270 [AAA-SIP] Sterman, B. et al., "RADIUS Extension for Digest 1271 Authentication", draft-sterman-sip-aaa-00.txt, November 2001 1272 (expired). 1274 Appendix A - Design Guidelines 1276 The following text provides guidelines for the design of attributes 1277 used by the RADIUS protocol. Specifications that follow these 1278 guidelines are expected to achieve maximum interoperability with 1279 minimal changes to existing systems. 1281 A.1. Types matching the RADIUS data model 1283 A.1.1. Transport of basic data types 1285 Does the data fit within the basic data types described in Section 1286 2.1.1, as outlined below? If so, it SHOULD be encapsulated in a 1287 [RFC2865] format RADIUS attribute, or in a [RFC2865] format RADIUS 1288 VSA that uses one of the existing RADIUS data types: 1290 * 32-bit unsigned integer, in network byte order. 1292 * Enumerated data types, represented as a 32-bit unsigned integer 1293 with a list of name to value mappings. (e.g. Service-Type) 1295 * IPv4 address in network byte order. 1297 * time as 32 bit unsigned value, in network byte order, and in 1298 seconds since 00:00:00 UTC, January 1, 1970. 1300 * IPv6 address in network byte order. 1302 * Interface-Id (8 octet string in network byte order) 1304 * IPv6 prefix. 1306 * string (i.e., binary data), totalling 253 octets or less in 1307 length. This includes the opaque encapsulation of data 1308 structures defined outside of RADIUS. See also Appendix A.1.3, 1309 below. 1311 * UTF-8 text, totalling 253 octets or less in length. 1313 Note that the length limitations for VSAs of type String and Text are 1314 less than 253 octets, due to the additional overhead of the Vendor- 1315 Specific format. 1317 The following data also qualifies as "basic data types": 1319 * Attributes grouped into a logical container, using the 1320 [RFC2868] tagging mechanism. This approach is NOT 1321 RECOMMENDED (see Section 2.1.2), but is permissible where 1322 the alternatives are worse. 1324 * Attributes requiring the transport of more than 247 octets of 1325 Text or String data. This includes the opaque encapsulation 1326 of data structures defined outside of RADIUS. See also Section 1327 A.1.3, below. 1329 Nested groups or attributes do not qualify as "basic data types", and 1330 SHOULD NOT be used. 1332 A.1.2. Transport of Authentication and Security Data 1334 Does the data provide authentication and/or security capabilities for 1335 the RADIUS protocol, as outlined below? If so, it SHOULD be 1336 encapsulated in a [RFC2865] format RADIUS attribute. It SHOULD NOT 1337 be encapsulated in a [RFC2865] format RADIUS VSA. 1339 * Complex data types that carry authentication methods which 1340 RADIUS servers are expected to parse and verify as part of 1341 an authentication process. 1343 * Complex data types that carry security information intended 1344 to increase the security of the RADIUS protocol itself. 1346 Any data type carrying authentication and/or security data that is 1347 not meant to be parsed by a RADIUS server is an "opaque data type", 1348 as defined below. 1350 A.1.3. Opaque data types 1352 Does the attribute encapsulate an existing data structure defined 1353 outside of the RADIUS specifications? Can the attribute be treated 1354 as opaque data by RADIUS servers (including proxies?) If both 1355 questions can be answered affirmatively, a complex structure MAY be 1356 used in a RADIUS specification. 1358 The specification of the attribute SHOULD define the encapsulating 1359 attribute to be of type String. The specification SHOULD refer to an 1360 external document defining the structure. The specification SHOULD 1361 NOT define or describe the structure, as discussed above in Section 1362 2.1.3. 1364 A.2. Improper Data Types 1366 All data types other than the ones described above in Appendix A.1 1367 and Appendix B SHOULD NOT be used. This section describes in detail 1368 a number of data types that are NOT RECOMMENDED in new RADIUS 1369 specifications. Where possible, replacement data types are 1370 suggested. 1372 A.2.1. Basic Data Types 1374 Does the attribute use any of the following data types? If so, the 1375 data type SHOULD be replaced with the suggested alternatives, or it 1376 SHOULD NOT be used at all. 1378 * Signed integers of any size. 1379 SHOULD NOT be used. SHOULD be replaced with one or more 1380 unsigned integer attributes. The definition of the attribute 1381 can contain information that would otherwise go into the sign 1382 value of the integer. 1384 * 8 bit unsigned integers. 1385 SHOULD be replaced with 32-bit unsigned integer. There is 1386 insufficient justification to save three bytes. 1388 * 16 bit unsigned integers. 1389 SHOULD be replaced with 32-bit unsigned integer. There is 1390 insufficient justification to save two bytes. 1392 * Unsigned integers of size other than 32 1393 SHOULD be replaced by an unsigned integer of 32 bits. 1394 There is insufficient justification to define a new size of 1395 integer. 1397 * Integers of any size in non-network byte order 1398 SHOULD be replaced by unsigned integer of 32 bits in network 1399 There is no reason to transport integers in any format other 1400 than network byte order. 1402 * Multi-field text strings. 1403 Each field SHOULD be encapsulated in a separate attribute. 1405 * Polymorphic attributes. 1406 Multiple attributes, each with a static data type SHOULD be 1407 defined instead. 1409 * Nested AVPs. 1410 Attributes should be defined in a flat typespace. 1412 A.2.2. Complex Data Types 1414 Does the attribute: 1416 * define a complex data type not described in Appendix B, 1417 * that a RADIUS server and/or client is expected to parse, 1418 validate, or create the contents of via a dynamic computation? 1419 i.e. A type that cannot be treated as opaque data (Section A.1.3) 1421 * involve functionality that could be implemented without code 1422 changes on both the client and server? (i.e. a type that doesn't 1423 require dynamic computation and verification, such as those 1424 performed for authentication or security attributes) 1426 If so, this data type SHOULD be replaced with simpler types, as 1427 discussed above in Appendix A.2.1. Also see Section 2.1.3 for a 1428 discussion of why complex types are problematic. 1430 A.3. Vendor-Specific formats 1432 Does the specification contain Vendor-Specific attributes that match 1433 any of the following criteria? If so, the data type should be 1434 replaced with the suggested alternatives, or should not be used at 1435 all. 1437 * Vendor types of more than 8 bits. 1438 SHOULD NOT be used. Vendor types of 8 bits SHOULD be used 1439 instead. 1441 * Vendor lengths of less than 8 bits. (i.e., zero bits) 1442 SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used 1443 instead. 1445 * Vendor lengths of more than 8 bits. 1446 SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used 1447 instead. 1449 * Vendor-Specific contents that are not in Type-Length-Value 1450 format. 1451 SHOULD NOT be used. Vendor-Specific attributes SHOULD be in 1452 Type-Length-Value format. 1454 In general, Vendor-Specific attributes SHOULD follow the [RFC2865] 1455 suggested format. Vendor extensions to non-standard formats are NOT 1456 RECOMMENDED as they can negatively affect interoperability. 1458 A.4. Changes to the RADIUS Operational Model 1460 Does the specification change the RADIUS operation model, as outlined 1461 in the list below? If so, then another method of achieving the 1462 design objectives SHOULD be used. Potential problem areas include: 1464 * Defining new commands in RADIUS using attributes. 1466 The addition of new commands to RADIUS MUST be handled via 1467 allocation of a new Code, and not by the use of an attribute. 1468 This restriction includes new commands created by overloading 1469 the Service-Type attribute to define new values that modify 1470 the functionality of Access-Request packets. 1472 * Using RADIUS as a transport protocol for data unrelated to 1473 authentication, authorization, or accounting. Using RADIUS to 1474 transport authentication methods such as EAP is explicitly 1475 permitted, even if those methods require the transport of 1476 relatively large amounts of data. Transport of opaque data 1477 relating to AAA is also permitted, as discussed above in 1478 Section 2.1.3. However, if the specification does not relate 1479 to AAA, then RADIUS SHOULD NOT be used. 1481 * Assuming support for packet lengths greater than 4096 octets. 1482 Attribute designers cannot assume that RADIUS implementations 1483 can successfully handle packets larger than 4096 octets. 1484 If a specification could lead to a RADIUS packet larger than 1485 4096 octets, then the alternatives described in Section 3.3 1486 SHOULD be considered. 1488 * Stateless operation. The RADIUS protocol is stateless, and 1489 documents which require stateful protocol behavior without the 1490 use of the State Attribute need to be redesigned. 1492 * Provisioning of service in an Access-Reject. Such provisioning 1493 is not permitted, and MUST NOT be used. If limited access needs 1494 to be provided, then an Access-Accept with appropriate 1495 authorizations can be used instead. 1497 * Lack of user authentication or authorization restrictions. 1498 In an authorization check, where there is no demonstration of a 1499 live user, confidential data cannot be returned. Where there 1500 is a link to a previous user authentication, the State attribute 1501 needs to be present. 1503 * Lack of per-packet integrity and authentication. 1504 It is expected that documents will support per-packet 1505 integrity and authentication. 1507 * Modification of RADIUS packet sequences. 1508 In RADIUS, each request is encapsulated in its own packet, and 1509 elicits a single response that is sent to the requester. Since 1510 changes to this paradigm are likely to require major 1511 modifications to RADIUS client and server implementations, they 1512 SHOULD be avoided if possible. 1513 For further details, see Section 3.3. 1515 A.5. Allocation of attributes 1517 Does the attribute have a limited scope of applicability, as outlined 1518 below? If so, then the attributes SHOULD be allocated from the 1519 Vendor-Specific space. 1521 * attributes intended for a vendor to support their own systems, 1522 and not suitable for general usage 1524 * attributes relying on data types not defined within RADIUS 1526 * attributes intended primarily for use within an SDO 1528 * attributes intended primarily for use within a group of SDOs. 1530 Note that the points listed above do not relax the recommendations 1531 discussed in this document. Instead, they recognize that the RADIUS 1532 data model has limitations. In certain situations where 1533 interoperability can be strongly constrained by the SDO or vendor, an 1534 expanded data model MAY be used. It is RECOMMENDED, however, that 1535 the RADIUS data model be used, even when it is marginally less 1536 efficient than alternatives. 1538 When attributes are used primarily within a group of SDOs, and are 1539 not applicable to the wider Internet community, we expect that one 1540 SDO will be responsible for allocation from their own private space. 1542 Appendix B - Complex Attributes 1544 This section summarizes RADIUS attributes with complex data types 1545 that are defined in existing RFCs. 1547 This appendix is published for informational purposes only, and 1548 reflects the usage of attributes with complex data types at the time 1549 of the publication of this document. 1551 B.1. CHAP-Password 1553 [RFC2865] Section 5.3 defines the CHAP-Password Attribute which is 1554 sent from the RADIUS client to the RADIUS server in an Access- 1555 Request. The data type of the CHAP Identifier is not given, only the 1556 one octet length: 1558 0 1 2 1559 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 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1561 | Type | Length | CHAP Ident | String ... 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1564 Since this is an authentication attribute, code changes are required 1565 on the RADIUS client and server to support it, regardless of the 1566 attribute format. Therefore, this complex data type is acceptable in 1567 this situation. 1569 B.2. CHAP-Challenge 1571 [RFC2865] Section 5.40 defines the CHAP-Challenge Attribute which is 1572 sent from the RADIUS client to the RADIUS server in an Access- 1573 Request. While the data type of the CHAP Identifier is given, the 1574 text also says: 1576 If the CHAP challenge value is 16 octets long it MAY be placed in 1577 the Request Authenticator field instead of using this attribute. 1579 Defining attributes to contain values taken from the RADIUS packet 1580 header is NOT RECOMMENDED. Attributes should have values that are 1581 packed into a RADIUS AVP. 1583 B.3. Tunnel-Password 1585 [RFC2868] Section 3.5 defines the Tunnel-Password Attribute, which is 1586 sent from the RADIUS server to the client in an Access-Accept. This 1587 attribute includes Tag and Salt fields, as well as a string field 1588 which consists of three logical sub-fields: the Data-Length (one 1589 octet) and Password sub-fields (both of which are required), and the 1590 optional Padding sub-field. The attribute appears as follows: 1592 0 1 2 3 1593 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 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | Type | Length | Tag | Salt 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 Salt (cont) | String ... 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 Since this is a security attribute and is encrypted, code changes are 1601 required on the RADIUS client and server to support it, regardless of 1602 the attribute format. Therefore, this complex data type is 1603 acceptable in this situation. 1605 B.4. ARAP-Password 1607 [RFC2869] Section 5.4 defines the ARAP-Password attribute, which is 1608 sent from the RADIUS client to the server in an Access-Request. It 1609 contains four 4 octet values, instead of having a single Value field: 1611 0 1 2 3 1612 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 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 | Type | Length | Value1 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 | Value2 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 | Value3 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 | Value4 1621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1622 | 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1625 As with the CHAP-Password attribute, this is an authentication 1626 attribute which would have required code changes on the RADIUS client 1627 and server regardless of format. 1629 B.5. ARAP-Features 1631 [RFC2869] Section 5.5 defines the ARAP-Features Attribute, which is 1632 sent from the RADIUS server to the client in an Access-Accept or 1633 Access-Challenge. It contains a compound string of two single octet 1634 values, plus three 4-octet values, which the RADIUS client 1635 encapsulates in a feature flags packet in the ARAP protocol: 1637 0 1 2 3 1638 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 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 | Type | Length | Value1 | Value2 | 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 | Value3 | 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 | Value4 | 1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 | Value5 | 1647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 Unlike the previous attributes, this attribute contains no encrypted 1650 component, nor is it directly involved in authentication. The 1651 individual sub-fields therefore could have been encapsulated in 1652 separate attributes. 1654 While the contents of this attribute is intended to be placed in an 1655 ARAP packet, the fields need to be set by the RADIUS server. Using 1656 standard RADIUS data types would have simplified RADIUS server 1657 implementations, and subsequent management. The current form of the 1658 attribute requires either the RADIUS server implementation, or the 1659 RADIUS server administrator, to understand the internals of the ARAP 1660 protocol. 1662 B.6. Connect-Info 1664 [RFC2869] Section 5.11 defines the Connect-Info attribute, which is 1665 used to indicate the nature of the connection. 1667 0 1 2 1668 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1670 | Type | Length | Text... 1671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1673 Even though the type is Text, the rest of the description indicates 1674 that it is a complex attribute: 1676 The Text field consists of UTF-8 encoded 10646 _8_ characters. 1677 The connection speed SHOULD be included at the beginning of the 1678 first Connect-Info attribute in the packet. If the transmit and 1679 receive connection speeds differ, they may both be included in the 1680 first attribute with the transmit speed first (the speed the NAS 1681 modem transmits at), a slash (/), the receive speed, then 1682 optionally other information. 1683 For example, "28800 V42BIS/LAPM" or "52000/31200 V90" 1685 More than one Connect-Info attribute may be present in an 1686 Accounting-Request packet to accommodate expected efforts by ITU 1687 to have modems report more connection information in a standard 1688 format that might exceed 252 octets. 1690 This attribute contains no encrypted component, and is it not 1691 directly involved in authentication. The individual sub-fields could 1692 therefore have been encapsulated in separate attributes. 1694 Since the form of the text string is well defined, there is no 1695 benefit in using a text string. Instead, an integer attribute should 1696 have been assigned for each of the transmit speed and the receive 1697 speed. A separate enumerated integer should have been assigned for 1698 the additional information, as is done for the NAS-Port-Type 1699 attribute. 1701 B.7. Framed-IPv6-Prefix 1703 [RFC3162] Section 2.3 defines the Framed-IPv6-Prefix Attribute and 1704 [RFC4818] Section 3 reuses this format for the Delegated-IPv6-Prefix 1705 Attribute; these attributes are sent from the RADIUS server to the 1706 client in an Access-Accept. 1708 0 1 2 3 1709 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 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | Type | Length | Reserved | Prefix-Length | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 Prefix 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 Prefix 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1717 Prefix 1718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1719 Prefix | 1720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 The sub-fields encoded in these attributes are strongly related, and 1723 there was no previous definition of this data structure that could be 1724 referenced. Support for this attribute requires code changes on both 1725 the client and server, due to a new data type being defined. In this 1726 case it appears to be acceptable to encode them in one attribute. 1728 B.8. Egress-VLANID 1730 [RFC4675] Section 2.1 defines the Egress-VLANID Attribute which can 1731 be sent by a RADIUS client or server. 1733 0 1 2 3 1734 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 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1736 | Type | Length | Value 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 Value (cont) | 1739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1741 While it appears superficially to be of type Integer, the Value field 1742 is actually a packed structure, as follows: 1744 0 1 2 3 1745 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 1746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1747 | Tag Indic. | Pad | VLANID | 1748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 The length of the VLANID field is defined by the [IEEE-802.1Q] 1751 specification. The Tag indicator field is either 0x31 or 0x32, for 1752 compatibility with the Egress-VLAN-Name, as discussed below. The 1753 complex structure of Egress-VLANID overlaps with that of the base 1754 Integer data type, meaning that no code changes are required for a 1755 RADIUS server to support this attribute. Code changes are required 1756 on the NAS, if only to implement the VLAN ID enforcement. 1758 Given the IEEE VLAN requirements and the limited data model of 1759 RADIUS, the chosen method is likely the best of the possible 1760 alternatives. 1762 B.9. Egress-VLAN-Name 1764 [RFC4675] Section 2.3 defines the Egress-VLAN-Name Attribute which 1765 can be sent by a RADIUS client or server. 1767 0 1 2 3 1768 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 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 | Type | Length | Tag Indic. | String... 1771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1773 The Tag Indicator is either the character '1' or '2', which in ASCII 1774 map to the identical values for Tag Indicator in Egress-VLANID, 1775 above. The complex structure of this attribute is acceptable for 1776 reasons identical to those given for Egress-VLANID. 1777 B.9. Digest-* 1779 [RFC5090] attempts to standardize the functionality provided by an 1780 expired internet-draft [AAA-SIP] which improperly used two attributes 1781 from the "standard space" without being assigned them by IANA. This 1782 self-allocation is forbidden, as described above in Section 1.3 and 1783 in Section 2. In addition, the draft uses nested attributes, which 1784 are discouraged in Section 2.1. The updated document uses basic data 1785 types, and allocates nearly 20 attributes in the process. 1787 However, the draft has seen wide-spread implementation, where 1788 [RFC5090] has not. While there are a number of factors involved, one 1789 factor may be that implementors disagreed with the trade-offs made in 1790 the updated specification. It may have been better to simply 1791 document the existing format, and request IANA allocation of two 1792 attributes. The resulting design would have used nested attributes, 1793 but may have gained more wide-spread implementation. 1795 It is difficult to know which choice is optimal. Given the 1796 complexity of the protocols and implementations, it is impossible to 1797 define "hard and fast" rules for RADIUS design guidelines. 1799 Acknowledgments 1801 We would like to acknowledge David Nelson, Bernard Aboba, Emile van 1802 Bergen, Barney Wolff, Glen Zorn, Avi Lior, and Hannes Tschofenig for 1803 contributions to this document. 1805 Authors' Addresses 1807 Greg Weber 1808 Knoxville, TN 37932 1809 USA 1811 Email: gdweber@gmail.com 1813 Alan DeKok 1814 The FreeRADIUS Server Project 1815 http://freeradius.org/ 1817 Email: aland@freeradius.org