idnits 2.17.1 draft-ietf-radext-design-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (4 December 2009) is 5257 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Alan DeKok (ed.) 3 INTERNET-DRAFT FreeRADIUS 4 Category: Best Current Practice G. Weber 5 Individual Contributor 6 Expires: April 32, 2010 7 4 December 2009 9 RADIUS Design Guidelines 10 draft-ietf-radext-design-10 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 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 April 12, 2010. 43 Copyright Notice 45 Copyright (c) 2009 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 in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 This document provides guidelines for the design of attributes used 57 by the Remote Authentication Dial In User Service (RADIUS) protocol. 58 It is expected that these guidelines will prove useful to authors and 59 reviewers of future RADIUS attribute specifications, both within the 60 IETF as well as other Standards Development Organizations (SDOs). 62 Table of Contents 64 1. Introduction ............................................. 4 65 1.1. Terminology ......................................... 4 66 1.2. Requirements Language ............................... 4 67 1.3. Applicability ....................................... 5 68 2. RADIUS Data Model ........................................ 6 69 2.1. Standard Space ...................................... 7 70 2.1.1. Basic Data Types Defined in RFC 2865 ........... 7 71 2.1.2. Tagging Mechanism .............................. 8 72 2.1.3. Complex Attribute Usage ........................ 9 73 2.1.4. Complex Attributes and Security ................ 11 74 2.1.5. Service definitions and RADIUS ................. 12 75 2.2. Vendor Space ........................................ 13 76 3. Data Model Issues ........................................ 14 77 3.1. Vendor Space ........................................ 15 78 3.1.1. Interoperability Considerations ................ 17 79 3.1.2. Vendor Allocations ............................. 17 80 3.1.3. SDO Allocations ................................ 18 81 3.1.4. Publication of specifications .................. 18 82 3.2. Polymorphic Attributes .............................. 19 83 3.3. RADIUS Operational Model ............................ 20 84 4. IANA Considerations ...................................... 23 85 5. Security Considerations .................................. 23 86 6. References ............................................... 24 87 6.1. Normative References ................................ 24 88 6.2. Informative References .............................. 24 89 Appendix A - Design Guidelines ............................... 27 90 A.1. Types matching the RADIUS data model ................. 27 91 A.1.1. Transport of simple data ........................ 27 92 A.1.2. Transport of Authentication and Security Data ... 28 93 A.1.3. Opaque data types ............................... 28 94 A.2. Improper Data Types .................................. 28 95 A.2.1. Simple Data Types ............................... 29 96 A.2.2. Complex Data Types .............................. 29 97 A.3. Vendor-Specific formats .............................. 30 98 A.4. Changes to the RADIUS Operational Model .............. 30 99 A.5. Allocation of attributes ............................. 32 100 Appendix B - Complex Attributes .............................. 33 101 B.1. CHAP-Password ........................................ 33 102 B.2. CHAP-Challenge ....................................... 33 103 B.3. Tunnel-Password ...................................... 33 104 B.4. ARAP-Password ........................................ 34 105 B.5. ARAP-Features ........................................ 34 106 B.6. Connect-Info ......................................... 35 107 B.7. Framed-IPv6-Prefix ................................... 36 108 B.8. Egress-VLANID ........................................ 36 109 B.9. Egress-VLAN-Name ..................................... 37 111 1. Introduction 113 This document provides guidelines for the design of RADIUS attributes 114 both within the IETF as well as within other SDOs. By articulating 115 RADIUS design guidelines, it is hoped that this document will 116 encourage the development and publication of high quality RADIUS 117 attribute specifications. 119 However, the advice in this document will not be helpful unless it is 120 put to use. As with "Guidelines for Authors and Reviewers of MIB 121 Documents" [RFC4181], it is expected that this document will be used 122 by authors to check their document against the guidelines prior to 123 requesting review (such as an "Expert Review" described in 124 [RFC3575]). Similarly, it is expected that this document will used 125 by reviewers (such as WG participants or the AAA Doctors [DOCTORS]), 126 resulting in an improvement in the consistency of reviews. 128 In order to meet these objectives, this document needs to cover not 129 only the science of attribute design, but also the art. Therefore, 130 in addition to covering the most frequently encountered issues, this 131 document attempts to provide some of the considerations motivating 132 the guidelines. 134 In order to characterize current attribute usage, both the basic and 135 complex data types defined in the existing RADIUS RFCs are reviewed. 137 1.1. Terminology 139 This document uses the following terms: 141 Network Access Server (NAS) 142 A device that provides an access service for a user to a network. 144 RADIUS server 145 A RADIUS authentication, authorization, and/or accounting (AAA) 146 server is an entity that provides one or more AAA services to a 147 NAS. 149 RADIUS proxy 150 A RADIUS proxy acts as a RADIUS server to the NAS, and a RADIUS 151 client to the RADIUS server. 153 1.2. Requirements Language 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [RFC2119]. 159 The uses of "MUST" and "MUST NOT" in this document are limited to (a) 160 requirements to follow the IETF process for IETF standards, and (b) 161 quotes from other documents. As a result, the uses of "MUST" and 162 "MUST NOT" in this document do not prescribe new mandatory behavior 163 within implementations. 165 1.3. Applicability 167 As RADIUS has become more widely accepted as a management protocol, 168 its usage has become more prevalent, both within the IETF as well as 169 within other SDOs. Given the expanded utilization of RADIUS, it has 170 become apparent that requiring SDOs to accomplish all their RADIUS 171 work within the IETF is inherently inefficient and unscalable. By 172 articulating guidelines for RADIUS attribute design, this document 173 enables SDOs out of the IETF to design their own RADIUS attributes 174 within the Vendor-Specific Attribute (VSA) space. 176 It is RECOMMENDED that SDOs follow the guidelines articulated in this 177 document. Doing so will ensure the widest possible applicability and 178 interoperability of the specifications, while requiring minimal 179 changes to existing systems. Specifications that do not follow the 180 guidelines articulated herein are NOT RECOMMENDED. However, we 181 recognize that there are some situations where SDOs or vendors 182 require the creation of specifications not following these 183 guidelines. We do not forbid these specifications, but it is 184 RECOMMENDED that they are created only if they have a limited scope 185 of applicability, and all attributes defined in those specifications 186 are VSAs, as discussed Appendix A.5, below. 188 It is RECOMMENDED that SDOs and vendors seek review of RADIUS 189 attribute specifications from the IETF. However, when specifications 190 are SDO specific, re-use existing data types, and follow these 191 guidelines, they do not require IETF review. 193 In order to enable IETF review of such specifications, the authors 194 recommend that: 196 * SDOs make their RADIUS attribute specifications publicly 197 available; 199 * SDOs request review of RADIUS attribute specifications by 200 sending email to the AAA Doctors [DOCTORS] or equivalent mailing 201 list; 203 * IETF and SDO RADIUS attribute specifications are reviewed 204 according to the guidelines proposed in this document; 206 * Reviews of specifications are posted to the RADEXT WG mailing 207 list, the AAA Doctors mailing list [DOCTORS] or another IETF 208 mailing list suggested by the Operations & Management Area 209 Directors of the IETF. 211 These reviews can assist with creation of specifications that meet 212 the SDO requirements, and which are also compatible with the 213 traditional data model and uses of RADIUS. While these reviews 214 require access to public specifications, the review process does not 215 require publication of an IETF RFC. 217 The advice in this document applies to attributes used to encode 218 service-provisioning or authentication data. RADIUS protocol 219 changes, or specification of attributes (such as Service-Type) that 220 can be used to, in effect, provide new RADIUS commands require 221 greater expertise and deeper review, as do changes to the RADIUS 222 operational model as discussed below in Section 3.3. Such changes 223 MUST NOT be undertaken outside the IETF and when handled within the 224 IETF require "IETF Consensus" for adoption, as noted in [RFC3575] 225 Section 2.1. 227 2. RADIUS Data Model 229 The Remote Authentication Dial In User Service (RADIUS) defined in 230 [RFC2865] and [RFC2866] uses elements known as attributes in order to 231 represent authentication, authorization and accounting data. 233 Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does 234 not define a formal data definition language. The data type of 235 RADIUS attributes is not transported on the wire. Rather, the data 236 type of a RADIUS attribute is fixed when an attribute is defined. 237 Based on the RADIUS attribute type code, RADIUS clients and servers 238 can determine the data type based on preconfigured entries within a 239 data dictionary. 241 Two distinct attribute spaces are defined: the standard space, and a 242 Vendor-Specific space. Attributes in the standard space generally 243 are composed of a type, length, value (TLV) triplet, although complex 244 attributes have also been defined. The Vendor-Specific space is 245 encapsulated within a single attribute type (Vendor-Specific 246 Attribute). The format of this space is defined by individual 247 vendors, but the same TLV encoding used by the standard space is 248 recommended in [RFC2865] Section 5.26. The similarity between 249 attribute formats has enabled implementations to leverage common 250 parsing functionality, although in some cases the attributes in the 252 2.1. Standard Space 254 The following subsections describe common data types and formats 255 within the RADIUS standard attribute space. Common exceptions are 256 identified. 258 2.1.1. Basic Data Types Defined in RFC 2865 260 [RFC2865] and [RFC2866] utilize data types defined in [RFC2865] 261 Section 5, which states the following: 263 The format of the value field is one of five data types. Note 264 that type "text" is a subset of type "string". 266 text 1-253 octets containing UTF-8 encoded 10646 [RFC3629] 267 characters. Text of length zero (0) MUST NOT be sent; 268 omit the entire attribute instead. 270 string 1-253 octets containing binary data (values 0 through 271 255 decimal, inclusive). Strings of length zero (0) 272 MUST NOT be sent; omit the entire attribute instead. 274 address 32 bit value, most significant octet first. 276 integer 32 bit unsigned value, most significant octet first. 278 time 32 bit unsigned value, most significant octet first -- 279 seconds since 00:00:00 UTC, January 1, 1970. The 280 standard Attributes do not use this data type but it is 281 presented here for possible use in future attributes. 283 In addition to the data types defined in [RFC2865], subsequent RADIUS 284 specifications defined attributes using additional basic data types. 285 These specifications did not explicitly define new data types as was 286 done in [RFC2865]. They did not consistently indicate the format of 287 the value field using the same conventions as [RFC2865]. As a 288 result, the data type is ambiguous in some cases, and may not be 289 consistent among different implementations. 291 It is out of the scope of this document to resolve all potential 292 ambiguities within existing RADIUS specifications. However in order 293 to prevent future ambiguities, it is recommended that future RADIUS 294 attribute specifications explicitly define newly created data types 295 at the beginning of the document, and indicate clearly the data type 296 to be used for each attribute. 298 [RFC3162] utilizes but does not explicitly define the following data 299 types: 301 IPv6 address 128 bit value, in network byte order. 302 IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to 303 128 bits of value, in network byte order. 305 Examples of the IPv6 address type include NAS-IPv6-Address defined in 306 [RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162] 307 Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3, 308 and in [RFC4818] Section 3. 310 While the Framed-Interface-Id attribute defined in [RFC3162] Section 311 2.2 included a value field of 8 octets, the data type was not 312 explicitly indicated, and therefore there is controversy over whether 313 the format of this attribute was intended to be an 8 octet String or 314 whether a special Interface-Id type was intended. 316 Given that attributes of type "IPv6 address" and "IPv6 prefix" are 317 already in use, it is RECOMMENDED that RADIUS server implementations 318 include support for these additional basic types, in addition to the 319 types defined in [RFC2865]. Where the intent is to represent a 320 specific IPv6 address, the "IPv6 address" type SHOULD be used. 321 Although it is possible to use the "IPv6 Prefix" type with a prefix 322 length of 128 to represent an IPv6 address, this usage is NOT 323 RECOMMENDED. Implementations supporting the Framed-Interface-Id 324 attribute may select a data type of their choosing (most likely an 8 325 octet String or a special Interface-Id data type). 327 It is worth noting that since RADIUS only supports unsigned integers 328 of 32 bits, attributes using signed integer data types or unsigned 329 integer types of other sizes will require code changes, and SHOULD be 330 avoided. 332 For [RFC2865] RADIUS VSAs, the length limitation of the String and 333 Text types is 247 octets instead of 253 octets, due to the additional 334 overhead of the Vendor-Specific Attribute. 336 2.1.2. Tagging Mechanism 338 [RFC2868] defines an attribute grouping mechanism based on the use of 339 a one octet tag value. Tunnel attributes that refer to the same 340 tunnel are grouped together by virtue of using the same tag value. 342 This tagging mechanism has some drawbacks. There are a limited 343 number of unique tags (31). The tags are not well suited for use 344 with arbitrary binary data values, because it is not always possible 345 to tell if the first byte after the Length is the tag or the first 346 byte of the untagged value (assuming the tag is optional). 348 Other limitations of the tagging mechanism are that when integer 349 values are tagged, the value portion is reduced to three bytes 350 meaning only 24-bit numbers can be represented. The tagging 351 mechanism does not offer an ability to create nested groups of 352 attributes. Some RADIUS implementations treat tagged attributes as 353 having additional data types tagged-string and tagged-integer. These 354 types increase the complexity of implementing and managing RADIUS 355 systems. 357 For these reasons, the tagging scheme described in RFC 2868 is NOT 358 RECOMMENDED for use as a generic grouping mechanism. 360 2.1.3. Complex Attribute Usage 362 The RADIUS attribute encoding is summarized in [RFC2865]: 364 0 1 2 365 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 367 | Type | Length | Value ... 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 370 However, some standard attributes do not follow this format. 371 Attributes that use sub-fields instead of using a basic data type are 372 known as "complex attributes". As described below, the definition of 373 complex attributes can lead to interoperability and deployment 374 issues, so they need to be introduced with care. 376 In general, complex attributes sent from the RADIUS server to the 377 client can be supported by concatenating the values into a String 378 data type field. However, separating these values into different 379 attributes, each with its own type and length, would have the 380 following benefits: 382 * it is easier for the user to enter the data as well-known 383 types, rather than complex structures; 385 * it enables additional error checking by leveraging the 386 parsing and validation routines for well-known types; 388 * it simplifies implementations by eliminating special-case 389 attribute-specific parsing. 391 One of the fundamental goals of the RADIUS protocol design was to 392 allow RADIUS servers to be configured to support new attributes 393 without requiring server code changes. RADIUS server implementations 394 typically provide support for basic data types, and define attributes 395 in a data dictionary. This architecture enables a new attribute to 396 be supported by the addition of a dictionary entry, without requiring 397 RADIUS server code changes. 399 On the RADIUS client, code changes are typically required in order to 400 implement a new attribute. The RADIUS client typically has to 401 compose the attribute dynamically when sending. When receiving, a 402 RADIUS client needs to be able to parse the attribute and carry out 403 the requested service. As a result, a detailed understanding of the 404 new attribute is required on clients, and data dictionaries are less 405 useful on clients than on servers. 407 Given these considerations, the introduction of a new basic or 408 complex attribute will typically require code changes on the RADIUS 409 client. The magnitude of changes for the complex attribute could be 410 greater, due to the potential need for custom parsing logic. 412 The RADIUS server can be configured to send a new static attribute by 413 entering its type and data format in the RADIUS server dictionary, 414 and then filling in the value within a policy based on the attribute 415 name, data type and type-specific value. For complex attribute types 416 not supported by RADIUS server dictionaries, changes to the 417 dictionary code can be required in order to allow the new attribute 418 to be supported by and configured on the RADIUS server. 420 Code changes can also be required in policy management and in the 421 RADIUS server's receive path. These changes are due to limitations 422 in RADIUS server policy languages, which typically only provide for 423 limited operations (such as comparisons or arithmetic operations) on 424 the basic data types. Many existing RADIUS policy languages 425 typically are not capable of parsing sub-elements, or providing 426 sophisticated matching functionality. 428 Given these limitations, the introduction of complex attributes can 429 require code changes on the RADIUS server which would be unnecessary 430 if basic data types had been used instead. In addition, attribute- 431 specific parsing means more complex software to develop and maintain. 432 More complexity can lead to more error prone implementations, 433 interoperability problems, and even security vulnerabilities. These 434 issues can increase costs to network administrators as well as 435 reducing reliability and introducing deployment barriers. We 436 therefore RECOMMEND thathte introduction of new complex data types 437 within RADIUS attribute specifications be avoided. A potential 438 exception to this recommendation occurs for attributes that 439 inherently require code changes on both the client and server. For 440 example, as described in Appendix B, complex attributes have been 441 used in situations involving authentication and security attributes 442 that need to be dynamically computed and verified. 444 As can be seen in Appendix B, most of the existing complex attributes 445 involve authentication or security functionality. Supporting this 446 functionality requires code changes on both the RADIUS client and 447 server, regardless of the attribute format. As a result, in most 448 cases, the use of complex attributes to represent these methods is 449 acceptable, and does not create additional interoperability or 450 deployment issues. 452 The only other exception to the recommendation against complex types 453 is for types that can be treated as opaque data by the RADIUS server. 454 For example, the EAP-Message attribute, defined in [RFC3579] Section 455 3.1 contains a complex data type that is an EAP packet. Since these 456 complex types do not need to be parsed by the RADIUS server, the 457 issues arising from policy language limitations do not arise. 458 Similarly, since attributes of these complex types can be configured 459 on the server using a data type of String, dictionary limitations are 460 also not encountered. Appendix A.1 below includes a series of 461 checklists that may be used to analyze a design for RECOMMENDED and 462 NOT RECOMMENDED behavior in relation to complex types. 464 If the RADIUS Server simply passes the contents of an attribute to 465 some non-RADIUS portion of the network, then the data is opaque, and 466 SHOULD be defined to be of type String. A concrete way of judging 467 this requirement is whether or not the attribute definition in the 468 RADIUS document contains delineated fields for sub-parts of the data. 469 If those fields need to be delineated in RADIUS, then the data is not 470 opaque, and it SHOULD be separated into individual RADIUS attributes. 472 An examination of existing RADIUS RFCs discloses a number of complex 473 attributes that have already been defined. Appendix B includes a 474 listing of complex attributes used within [RFC2865], [RFC2868], 475 [RFC2869], [RFC3162], [RFC4818], and [RFC4675]. The discussion of 476 these attributes includes reasons why a complex type is acceptable, 477 or suggestions for how the attribute could have been defined to 478 follow the RADIUS data model. 480 In other cases, the data in the complex type are described textually. 481 This is possible because the data types are not sent within the 482 attributes, but are a matter for endpoint interpretation. An 483 implementation can define additional data types, and use these data 484 types today by matching them to the attribute's textual description. 486 2.1.4. Complex Attributes and Security 488 The introduction of complex data types brings the potential for the 489 introduction of new security vulnerabilities. Experience shows that 490 the common data types have few security vulnerabilities, or else that 491 all known issues have been found and fixed. New data types require 492 new code, which may introduce new bugs, and therefore new attack 493 vectors. 495 RADIUS servers are highly valued targets, as they control network 496 access and interact with databases that store usernames and 497 passwords. An extreme outcome of a vulnerability due to a new, 498 complex type would be that an attacker is capable of taking complete 499 control over the RADIUS server. 501 The use of attributes representing opaque data does not reduce this 502 threat. The threat merely moves from the RADIUS server to the 503 application that consumes that opaque data. 505 The threat is particularly severe when the opaque data originates 506 from the user, and is not validated by the NAS. In those cases, the 507 RADIUS server is potentially exposed to attack by malware residing on 508 an unauthenticated host. Applications consuming opaque data that 509 reside on the RADIUS server SHOULD be properly isolated from the 510 RADIUS server, and SHOULD run with minimal privileges. Any potential 511 vulnerabilities in that application will then have minimal impact on 512 the security of the system as a whole. 514 2.1.5. Service definitions and RADIUS 516 RADIUS specifications define how an existing service or protocol can 517 be provisioned using RADIUS. Therefore, it is expected that a RADIUS 518 attribute specification will reference documents defining the 519 protocol or service to be provisioned. Within the IETF, a RADIUS 520 attribute specification SHOULD NOT be used to define the protocol or 521 service being provisioned. New services using RADIUS for 522 provisioning SHOULD be defined elsewhere and referenced in the RADIUS 523 specification. 525 New attributes, or new values of existing attributes, SHOULD NOT be 526 used to define new RADIUS commands. RADIUS attributes are intended 527 to: 529 * authenticate users 531 * authorize users (i.e., service provisioning or changes to 532 provisioning) 534 * account for user activity (i.e., logging of session activity) 536 New commands (i.e., the Code field in the packet header) are 537 allocated only through "IETF Consensus" as noted in [RFC3575] Section 538 2.1. Specifications also SHOULD NOT use new attributes to modify the 539 interpretation of existing RADIUS commands. 541 2.2. Vendor Space 543 As noted in [RFC2865] Section 5.26, the VSA format is defined as 544 follows: 546 0 1 2 3 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Type | Length | Vendor-Id 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 Vendor-Id (cont) | String... 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 554 The high-order octet of the Vendor-Id field is 0 and the low-order 3 555 octets are the Structure of Management Information (SMI) Network 556 Management Private Enterprise Code (PEC) of the Vendor in network 557 byte order. 559 While the format of the String field is defined by the vendor, 560 [RFC2865] Section 5.26 notes: 562 It SHOULD be encoded as a sequence of vendor type / vendor length 563 / value fields, as follows. The Attribute-Specific field is 564 dependent on the vendor's definition of that attribute. An 565 example encoding of the Vendor-Specific attribute using this 566 method follows: 568 0 1 2 3 569 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 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Type | Length | Vendor-Id 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 Vendor-Id (cont) | Vendor type | Vendor length | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Attribute-Specific... 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 578 Multiple sub-attributes MAY be encoded within a single Vendor- 579 Specific attribute, although they do not have to be. 581 Note that the Vendor type field in the recommended VSA format is only 582 a single octet, like the RADIUS type field. While this limitation 583 results in an efficient encoding, there are situations in which a 584 vendor or SDO will eventually wish to define more than 255 585 attributes. Also, an SDO can be comprised of multiple subgroups, each 586 of whom can desire autonomy over the definition of attributes within 587 their group. The most interoperable way to address these issues is 588 for the vendor or SDO to request allocation of multiple Vendor 589 identifiers. 591 However, instead of doing this, vendors have defined the following 592 non-standard VSA formats: 594 * Vendor types of 16 bits, followed by an 8 bit length and 595 then attribute-specific data. 597 * Vendor types of 32 bits, followed by no length field, and 598 then attribute-specific data. 600 * Vendor types of the RFC format, but where some VSAs are 601 defined as "grouped" or TLV attributes. These attributes 602 are then used to carry sub-attributes. 604 * "Bare" ASCII strings that immediately follow the Vendor-Id, 605 without using a Vendor type or Vendor length. 607 All VSA schemes that do not follow the [RFC2865] recommendations are 608 NOT RECOMMENDED. These non-standard formats will typically not be 609 implementable without RADIUS server code changes. This includes all 610 the above formats, as well as Vendor types of more than 8 bits, 611 vendor lengths of less than 8 bits, vendor lengths of more than 8 612 bits and Vendor-Specific contents that are not in Type-Length-Value 613 format. 615 Although [RFC2865] does not mandate it, implementations commonly 616 assume that the Vendor Id can be used as a key to determine the on- 617 the-wire format of a VSA. Vendors therefore SHOULD NOT use multiple 618 formats for VSAs that are associated with a particular Vendor Id. A 619 vendor wishing to use multiple VSA formats SHOULD request one Vendor 620 Id for each VSA format that they will use. 622 3. Data Model Issues 624 Since the closure of the RADIUS Working Group, the popularity and 625 prevalence of RADIUS has continued to grow. In addition to 626 increasing demand for allocation of attributes within the RADIUS 627 standard attribute space, the number of vendors and SDOs creating new 628 attributes within the Vendor-Specific attribute space has grown, and 629 this has lead to some divergence in approaches to RADIUS attribute 630 design. 632 In general, standard RADIUS attributes have a more constrained data 633 model than attributes within the vendor space. For example, vendors 634 and SDOs have evolved the data model to support new functions such as 635 attribute grouping and attribute fragmentation, with different groups 636 taking different approaches. 638 Given these enhancements, it has become difficult for vendors or SDOs 639 to translate attributes from the vendor space to the more stringent 640 standards space. For example, a Vendor-Specific attribute using sub- 641 elements could require allocation of several standard space 642 attributes using basic data types. In this case not only would 643 translation require substantial additional work, it would further 644 deplete the RADIUS standard attribute space. Given these 645 limitations, translation of vendor attributes to the standards space 646 is not necessarily desirable, particularly if the VSA specification 647 is publicly available and can be implemented within existing RADIUS 648 clients and servers. In such situations, the costs may substantially 649 outweigh the benefits. It is possible that some of the enhancements 650 made within the vendor space may eventually become available within 651 the standard attribute space. However, the divergence of the 652 standard and vendor attribute spaces is most likely a permanent 653 feature, and should be recognized as such. 655 3.1. Vendor Space 657 The usage model for RADIUS VSAs is described in [RFC2865] Section 658 6.2: 660 Note that RADIUS defines a mechanism for Vendor-Specific 661 extensions (Attribute 26) and the use of that should be encouraged 662 instead of allocation of global attribute types, for functions 663 specific only to one vendor's implementation of RADIUS, where no 664 interoperability is deemed useful. 666 Nevertheless, many new attributes have been defined in the vendor 667 specific space in situations where interoperability is not only 668 useful, but is required. For example, SDOs outside the IETF (such as 669 the IEEE 802 and the 3rd Generation Partnership Project (3GPP)) have 670 been assigned Vendor-Ids, enabling them to define their own VSA 671 format and assign Vendor types within their own space. 673 The use of VSAs by SDOs outside the IETF has gained in popularity for 674 several reasons: 676 Efficiency 677 As with SNMP, which defines an "Enterprise" Object Identifier (OID) 678 space suitable for use by vendors as well as other SDOs, the 679 definition of Vendor-Specific RADIUS attributes has become a common 680 occurrence as part of standards activity outside the IETF. For 681 reasons of efficiency, it is easiest if the RADIUS attributes 682 required to manage a standard are developed within the same SDO 683 that develops the standard itself. As noted in "Transferring MIB 684 Work from IETF Bridge MIB WG to IEEE 802.1 WG" [RFC4663], today few 685 vendors are willing to simultaneously fund individuals to 686 participate within an SDO to complete a standard, as well as to 687 participate in the IETF in order to complete the associated RADIUS 688 attributes specification. 690 Attribute scarcity 691 The standard RADIUS attribute space is limited to 255 unique 692 attributes. Of these, only about half remain available for 693 allocation. In the Vendor-Specific space, the number of attributes 694 available is a function of the format of the attribute (the size of 695 the Vendor type field). 697 Along with these advantages, some limitations of VSA usage are noted 698 in [RFC2865] Section 5.26: 700 This Attribute is available to allow vendors to support their own 701 extended Attributes not suitable for general usage. It MUST NOT 702 affect the operation of the RADIUS protocol. 704 Servers not equipped to interpret the vendor-specific information 705 sent by a client MUST ignore it (although it may be reported). 706 Clients which do not receive desired vendor-specific information 707 SHOULD make an attempt to operate without it, although they may do 708 so (and report they are doing so) in a degraded mode. 710 The limitation on changes to the RADIUS protocol effectively 711 prohibits VSAs from changing fundamental aspects of RADIUS operation, 712 such as modifying RADIUS packet sequences, or adding new commands. 713 However, the requirement for clients and servers to be able to 714 operate in the absence of VSAs has proven to be less of a constraint, 715 since it is still possible for a RADIUS client and server to mutually 716 indicate support for VSAs, after which behavior expectations can be 717 reset. 719 Therefore, RFC 2865 provides considerable latitude for development of 720 new attributes within the vendor space, while prohibiting development 721 of protocol variants. This flexibility implies that RADIUS 722 attributes can often be developed within the vendor space without 723 loss (and possibly even with gain) in functionality. 725 As a result, translation of RADIUS attributes developed within the 726 vendor space into the standard space may provide only modest 727 benefits, while accelerating the exhaustion of the standard attribute 728 space. We do not expect that all RADIUS attribute specifications 729 requiring interoperability will be developed within the IETF, and 730 allocated from the standards space. A more scalable approach is to 731 recognize the flexibility of the vendor space, while working toward 732 improvements in the quality and availability of RADIUS attribute 733 specifications, regardless of where they are developed. 735 3.1.1. Interoperability Considerations 737 Vendors and SDOs are reminded that the standard RADIUS attribute 738 space, and the enumerated value space for enumerated attributes, are 739 reserved for allocation through work published via the IETF, as noted 740 in [RFC3575] Section 2.1. Some vendors and SDOs have in the past 741 performed self-allocation by assigning vendor-specific meaning to 742 "unused" values from the standard RADIUS attribute ID or enumerated 743 value space. This self-allocation results in interoperability 744 issues, and is counter-productive. Similarly, the Vendor-Specific 745 enumeration practice discussed in [RFC2882] Section 2.2.1 is NOT 746 RECOMMENDED. 748 If it is not possible to follow the IETF process, vendors and SDOs 749 SHOULD self-allocate an attribute from their Vendor-Specific space, 750 and define an appropriate value for it. 752 As a side note, [RFC2865] Section 5.26 uses the term "Vendor-Specific 753 Attribute" to refer to an encoding format which can be used by 754 individual vendors to define attributes not suitable for general 755 usage. However, since then VSAs have also become widely used by SDOs 756 defining attributes intended for multi-vendor interoperability. As 757 such, these attributes are not specific to any single vendor, and the 758 term "Vendor-Specific" may be misleading. An alternate term which 759 better describes this use case is SDO-Specific Attribute (SSA). 761 The design and specification of VSAs for multi-vendor usage SHOULD be 762 undertaken with the same level of care as standard RADIUS attributes. 763 Specifically, the provisions of this document that apply to standard 764 RADIUS attributes also apply to SSAs or VSAs for multi-vendor usage. 766 3.1.2. Vendor Allocations 768 Vendor RADIUS Attribute specifications SHOULD allocate attributes 769 from the vendor space, rather than requesting an allocation from the 770 RADIUS standard attribute space. 772 As discussed in [RFC2865] Section 5.26, the vendor space is intended 773 for vendors to support their own Attributes not suitable for general 774 use. However, it is RECOMMENDED that vendors follow the guidelines 775 outlined here, which are intended to enable maximum interoperability 776 with minimal changes to existing systems. 778 Following these guidelines means that RADIUS servers can be updated 779 to support the vendor's equipment by editing a RADIUS dictionary. If 780 these guidelines are not followed, then the vendor's equipment can 781 only be supported via code changes in RADIUS server implementations. 782 Such code changes add complexity and delay to implementations. 784 3.1.3. SDO Allocations 786 SDO RADIUS Attribute specifications SHOULD allocate attributes from 787 the vendor space, rather than requesting an allocation from the 788 RADIUS standard attribute space, for attributes matching any of the 789 following criteria: 791 * attributes relying on data types not defined within RADIUS 793 * attributes intended primarily for use within an SDO 795 * attributes intended primarily for use within a group of SDOs. 797 Any new RADIUS attributes or values intended for interoperable use 798 across a broad spectrum of the Internet Community SHOULD follow the 799 normal IETF process, and SHOULD result in allocations from the RADIUS 800 standard space. 802 The recommendation for SDOs to allocate attributes from a vendor 803 space rather than via the IETF process is a recognition that SDOs may 804 desire to assert change control over their own RADIUS specifications. 805 This change control can be obtained by requesting a PEC from the 806 Internet Assigned Number Authority (IANA), for use as a Vendor-Id 807 within a Vendor-Specific attribute. Further allocation of attributes 808 inside of the VSA space defined by that Vendor-Id is subject solely 809 to the discretion of the SDO. Similarly, the use of data types 810 (complex or not) within that VSA space is solely under the discretion 811 of the SDO. It is RECOMMENDED that SDOs follow the guidelines 812 outlined here, which are intended to enable maximum interoperability 813 with minimal changes to existing systems. 815 It should be understood that SDOs do not have to rehost VSAs into the 816 standards space solely for the purpose of obtaining IETF review. 817 Rehosting puts pressure on the standards space, and may be harmful to 818 interoperability, since it can create two ways to provision the same 819 service. Rehosting may also require changes to the RADIUS data model 820 which will affect implementations that do not intend to support the 821 SDO specifications. 823 3.1.4. Publication of specifications 825 SDOs are encouraged to seek early review of SSA specifications by the 826 IETF. This review may be initiated by sending mail to the AAA 827 Doctors list [DOCTORS], with the understanding that this review is a 828 voluntary-based service offered on best-effort basis. Since the IETF 829 is not a membership organization, in order to enable the RADIUS SSA 830 specification to be reviewed, it is RECOMMENDED that it be made 831 publicly available; this also encourages interoperability. Where the 832 RADIUS SSA specification is embedded within a larger document which 833 cannot be made public, the RADIUS attribute and value definitions 834 SHOULD be published instead as an Informational RFC, as with 835 [RFC4679]. This process SHOULD be followed instead of requesting 836 IANA allocations from within the standard RADIUS attribute space. 838 Similarly, vendors are encouraged to make their specifications 839 publicly available, for maximum interoperability. However, it is not 840 necessary for them to request publication of their VSA specifications 841 as Informational RFCs by the IETF. 843 All other specifications, including new authentication, 844 authorization, and/or security mechanisms SHOULD be allocated via the 845 standard RADIUS space, as noted in [RFC3575] Section 2.1. 847 3.2. Polymorphic Attributes 849 A polymorphic attribute is one whose format or meaning is dynamic. 850 For example, rather than using a fixed data format, an attribute's 851 format might change based on the contents of another attribute. Or, 852 the meaning of an attribute may depend on earlier packets in a 853 sequence. 855 RADIUS server dictionary entries are typically static, enabling the 856 user to enter the contents of an attribute without support for 857 changing the format based on dynamic conditions. However, this 858 limitation on static types does not prevent implementations from 859 implementing policies that return different attributes based on the 860 contents of received attributes; this is a common feature of existing 861 RADIUS implementations. 863 In general, polymorphism is NOT RECOMMENDED. Polymorphism rarely 864 enables capabilities that would not be available through use of 865 multiple attributes. Polymorphism requires code changes in the 866 RADIUS server in situations where attributes with fixed formats would 867 not require such changes. Thus, polymorphism increases complexity 868 while decreasing generality, without delivering any corresponding 869 benefits. 871 Note that changing an attribute's format dynamically is not the same 872 thing as using a fixed format and computing the attribute itself 873 dynamically. RADIUS authentication attributes such as User-Password, 874 EAP-Message, etc. while being computed dynamically, use a fixed 875 format. 877 3.3. RADIUS Operational Model 879 The RADIUS operational model includes several assumptions: 881 * The RADIUS protocol is stateless; 883 * Provisioning of services is not possible within an 884 Access-Reject; 886 * There is a distinction between authorization checks and user 887 authentication; 889 * The protocol provices for authentication and integrity 890 protection of packets; 892 * The RADIUS protocol is a Request/Response protocol; 894 * The protocol defines packet length restrictions. 896 While RADIUS server implementations may keep state, the RADIUS 897 protocol is stateless, although information may be passed from one 898 protocol transaction to another via the State Attribute. As a 899 result, documents which require stateful protocol behavior without 900 use of the State Attribute are inherently incompatible with RADIUS as 901 defined in [RFC2865], and need to be redesigned. See [RFC5080] 902 Section 2.1.1 for a more in-depth discussion of the use of the State 903 Attribute. 905 As noted in [RFC5080] Section 2.6, the intent of an Access-Reject is 906 to deny access to the requested service. As a result, RADIUS does 907 not allow the provisioning of services within an Access-Reject. 908 Documents which include provisioning of services within an Access- 909 Reject are inherently incompatible with RADIUS, and need to be 910 redesigned. 912 As noted in [RFC5080] Section 2.1.1, a RADIUS Access-Request may not 913 contain user authentication attributes or a State Attribute linking 914 the Access-Request to an earlier user authentication. Such an 915 Access-Request, known as an authorization check, provides no 916 assurance that it corresponds to a live user. RADIUS specifications 917 defining attributes containing confidential information (such as 918 Tunnel-Password) should be careful to prohibit such attributes from 919 being returned in response to an authorization check. Also, 920 [RFC5080] Section 2.1.1 notes that authentication mechanisms need to 921 tie a sequence of Access-Request/Access-Challenge packets together 922 into one authentication session. The State Attribute is RECOMMENDED 923 for this purpose. 925 While [RFC2865] did not require authentication and integrity 926 protection of RADIUS Access-Request packets, subsequent 927 authentication mechanism specifications such as RADIUS/EAP [RFC3579] 928 and Digest Authentication [RFC5090] have mandated authentication and 929 integrity protection for certain RADIUS packets. [RFC5080] Section 930 2.1.1 makes this behavior RECOMMENDED for all Access-Request packets, 931 including Access-Request packets performing authorization checks. It 932 is expected that specifications for new RADIUS authentication 933 mechanisms will continue this practice. 935 The RADIUS protocol as defined in [RFC2865] is a request-response 936 protocol spoken between RADIUS clients and servers. A single RADIUS 937 Access-Request packet will solicit in response at most a single 938 Access-Accept, Access-Reject or Access-Challenge packet, sent to the 939 IP address and port of the RADIUS Client that originated the Access- 940 Request. Similarly, a single Change-of-Authorization (CoA)-Request 941 packet [RFC5176] will solicit in response at most a single CoA-ACK or 942 CoA-NAK packet, sent to the IP address and port of the Dynamic 943 Authorization Client (DAC) that originated the CoA-Request. A single 944 Disconnect-Request packet will solicit in response at most a single 945 Disconnect-ACK or Disconnect-NAK packet, sent to the IP address and 946 port of the Dynamic Authorization Client (DAC) that originated the 947 Disconnect-Request. Changes to this model are likely to require 948 major revisions to existing implementations and so this practice is 949 NOT RECOMMENDED. 951 The Length field in the RADIUS packet header is defined in [RFC2865] 952 Section 3. It is noted there that the maximum length of a RADIUS 953 packet is 4096 octets. As a result, attribute designers SHOULD NOT 954 assume that a RADIUS implementation can successfully process RADIUS 955 packets larger than 4096 octets. 957 Even when packets are less than 4096 octets, they may be larger than 958 the Path Maximum Transmission Unit (PMTU). Any packet larger than 959 the PMTU will be fragmented, making communications more brittle as 960 firewalls and filtering devices often discard fragments. Transport 961 of fragmented UDP packets appears to be a poorly tested code path on 962 network devices. Some devices appear to be incapable of transporting 963 fragmented UDP packets, making it difficult to deploy RADIUS in a 964 network where those devices are deployed. We RECOMMEND that RADIUS 965 messages be kept as small possible. 967 If a situation is envisaged where it may be necessary to carry 968 authentication, authorization or accounting data in a packet larger 969 than 4096 octets, then one of the following approaches is 970 RECOMMENDED: 972 1. Utilization of a sequence of packets. 974 For RADIUS authentication, a sequence of Access-Request/ Access- 975 Challenge packets would be used. For this to be feasible, 976 attribute designers need to enable inclusion of attributes that 977 can consume considerable space within Access-Challenge packets. 978 To maintain compatibility with existing NASes, either the use of 979 Access-Challenge packets needs to be permissible (as with 980 RADIUS/EAP, defined in [RFC3579]), or support for receipt of an 981 Access-Challenge needs to be indicated by the NAS (as in RADIUS 982 Location [RFC5580]). Also, the specification needs to clearly 983 describe how attribute splitting is to be signalled and how 984 attributes included within the sequence are to be interpreted, 985 without requiring stateful operation. Unfortunately, previous 986 specifications have not always exhibited the required foresight. 987 For example, even though very large filter rules are 988 conceivable, the NAS-Filter-Rule Attribute defined in [RFC4849] 989 is not permitted in an Access-Challenge packet, nor is a 990 mechanism specified to allow a set of NAS-Filter-Rule attributes 991 to be split across an Access-Request/Access-Challenge sequence. 993 In the case of RADIUS accounting, transporting large amounts of 994 data would require a sequence of Accounting-Request packets. 995 This is a non-trivial change to RADIUS, since RADIUS accounting 996 clients would need to be modified to split the attribute stream 997 across multiple Accounting-Requests, and billing servers would 998 need to be modified to re-assemble and interpret the attribute 999 stream. 1001 2. Utilization of names rather than values. 1002 Where an attribute relates to a policy that could conceivably be 1003 pre-provisioned on the NAS, then the name of the pre-provisioned 1004 policy can be transmitted in an attribute, rather than the 1005 policy itself, which could be quite large. An example of this 1006 is the Filter-Id Attribute defined in [RFC2865] Section 5.11, 1007 which enables a set of pre-provisioned filter rules to be 1008 referenced by name. 1010 3. Utilization of Packetization Layer Path MTU Discovery 1011 techniques, as specified in [RFC4821]. As a last resort, where 1012 the above techniques cannot be made to work, it may be possible 1013 to apply the techniques described in [RFC4821] to discover the 1014 maximum supported RADIUS packet size on the path between a 1015 RADIUS client and a home server. While such an approach can 1016 avoid the complexity of utilization of a sequence of packets, 1017 dynamic discovery is likely to be time consuming and cannot be 1018 guaranteed to work with existing RADIUS implementations. As a 1019 result, this technique is not generally applicable. 1021 4. IANA Considerations 1023 This document does not require that the IANA update any existing 1024 registry or create any new registry, but includes information that 1025 affects the IANA, which: 1027 * includes specific guidelines for Expert Reviewers appointed 1028 under the IANA considerations of [RFC3575] 1030 * includes guidelines that recommend against self allocation from 1031 the RADIUS standard attribute space in other SDO RADIUS 1032 Attribute specifications. 1034 * recommends that SDOs request a Private Enterprise Code (PEC) 1035 from the IANA, for use as a Vendor-Id within a Vendor-Specific 1036 attribute. 1038 5. Security Considerations 1040 This specification provides guidelines for the design of RADIUS 1041 attributes used in authentication, authorization and accounting. 1042 Threats and security issues for this application are described in 1043 [RFC3579] and [RFC3580]; security issues encountered in roaming are 1044 described in [RFC2607]. 1046 Obfuscation of RADIUS attributes on a per-attribute basis is 1047 necessary in some cases. The current standard mechanism for this is 1048 described in [RFC2865] Section 5.2 (for obscuring User-Password 1049 values) and is based on the MD5 algorithm specified in [RFC1321]. 1050 The MD5 and SHA-1 algorithms have recently become a focus of scrutiny 1051 and concern in security circles, and as a result, the use of these 1052 algorithms in new attributes is NOT RECOMMENDED. In addition, 1053 previous documents referred to this method as generating "encrypted" 1054 data. This terminology is no longer accepted within the 1055 cryptographic community. 1057 Where new RADIUS attributes use cryptographic algorithms, algorithm 1058 negotiation SHOULD be supported. Specification of a mandatory-to- 1059 implement algorithm is REQUIRED, and it is RECOMMENDED that the 1060 mandatory-to-implement algorithm be certifiable under FIPS 140 1061 [FIPS]. 1063 Where new RADIUS attributes encapsulate complex data types, or 1064 transport opaque data, the security considerations discussed in 1065 Section 2.1.4 SHOULD be addressed. 1067 Message authentication in RADIUS is provided largely via the Message- 1068 Authenticator attribute. See [RFC3579] Section 3.2, and also 1070 [RFC5080] 2.2.2, which says that client implementations SHOULD 1071 include a Message-Authenticator attribute in every Access-Request. 1073 In general, the security of the RADIUS protocol is poor. Robust 1074 deployments SHOULD support a secure communications protocol such as 1075 IPSec. See [RFC3579] Section 4, and [RFC3580] Section 5 for a more 1076 in-depth explanation of these issues. 1078 Implementations not following the suggestions outlined in this 1079 document may be subject to a problems such as ambiguous protocol 1080 decoding, packet loss leading to loss of billing information, and 1081 denial of service attacks. 1083 6. References 1085 6.1. Normative References 1087 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1088 Requirement Levels", BCP 14, RFC 2119, March 1997. 1090 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 1091 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1092 2000. 1094 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1095 Authentication Dial In User Service)", RFC 3575, July 2003. 1097 6.2. Informative References 1099 [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of 1100 management information for TCP/IP-based internets", STD 16, 1101 RFC 1155, May 1990. 1103 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 1104 Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1105 1990. 1107 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1108 April 1992. 1110 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1111 Implementation in Roaming", RFC 2607, June 1999. 1113 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1115 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., 1116 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 1117 Support", RFC 2868, June 2000. 1119 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", 1120 RFC 2869, June 2000. 1122 [RFC2882] Mitton, D, "Network Access Servers Requirements: Extended 1123 RADIUS Practices", RFC 2882, July 2000. 1125 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 1126 3162, August 2001. 1128 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 1129 In User Service) Support For Extensible Authentication 1130 Protocol (EAP)", RFC 3579, September 2003. 1132 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE 1133 802.1X Remote Authentication Dial In User Service (RADIUS) 1134 Usage Guidelines", RFC3580, September 2003. 1136 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1137 RFC 3629, November 2003. 1139 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 1140 Documents", RFC 4181, September 2005. 1142 [RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge MIB WG 1143 to IEEE 802.1 WG", RFC 4663, September 2006. 1145 [RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for 1146 Virtual LAN and Priority Support", RFC 4675, September 2006. 1148 [RFC4679] Mammoliti, V., et al., "DSL Forum Vendor-Specific RADIUS 1149 Attributes", RFC 4679, September 2006. 1151 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 1152 Attribute", RFC 4818, April 2007. 1154 [RFC4821] Mathis, M. and Heffner, J, "Packetization Layer Path MTU 1155 Discovery", RFC 4821, March 2007. 1157 [RFC4849] Congdon, P. et al, "RADIUS Filter-Rule Attribute", RFC 4849, 1158 April 2007. 1160 [RFC5080] Nelson, D. and DeKok, A, "Common Remote Authentication Dial In 1161 User Service (RADIUS) Implementation Issues and Suggested 1162 Fixes", RFC 5080, December 2007. 1164 [RFC5090] Sterman, B. et al., "RADIUS Extension for Digest 1165 Authentication", RFC 5090, February 2008. 1167 [RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote 1168 Authentication Dial In User Service (RADIUS)", RFC 5176, 1169 January 2008. 1171 [DOCTORS] AAA Doctors Mailing list 1173 [FIPS] FIPS 140-3 (DRAFT), "Security Requirements for Cryptographic 1174 Modules", http://csrc.nist.gov/publications/fips/fips140-3/ 1176 [IEEE-802.1Q] 1177 IEEE Standards for Local and Metropolitan Area Networks: Draft 1178 Standard for Virtual Bridged Local Area Networks, 1179 P802.1Q-2003, January 2003. 1181 [RFC5580] Tschofenig, H. (Ed.), "Carrying Location Objects in RADIUS and 1182 Diameter", RFC 5580, August 2009. 1184 Appendix A - Design Guidelines 1186 The following text provides guidelines for the design of attributes 1187 used by the RADIUS protocol. Specifications that follow these 1188 guidelines are expected to achieve maximum interoperability with 1189 minimal changes to existing systems. 1191 A.1. Types matching the RADIUS data model 1193 A.1.1. Transport of simple data 1195 Does the data fit within the basic data types described in Section 1196 2.1.1, as outlined below? If so, it SHOULD be encapsulated in a 1197 [RFC2865] format RADIUS attribute, or in a [RFC2865] format RADIUS 1198 VSA that uses one of the existing RADIUS data types. 1200 * 32-bit unsigned integer, in network byte order. 1202 * Enumerated data types, represented as a 32-bit unsigned integer 1203 with a list of name to value mappings. (e.g., Service-Type) 1205 * Interface-Id (8 octet string in network byte order) 1207 * IPv4 address in network byte order. 1209 * IPv6 address in network byte order. 1211 * IPv6 prefix. 1213 * time as 32 bit unsigned value, in network byte order, and in 1214 seconds since 00:00:00 UTC, January 1, 1970. 1216 * string (i.e., binary data), totalling 253 octets or less in 1217 length. This includes the opaque encapsulation of data 1218 structures defined outside of RADIUS. See also Appendix A.1.3, 1219 below. 1221 * UTF-8 text, totalling 253 octets or less in length. 1223 Note that the length limitations for VSAs of type String and Text are 1224 less than 253 octets, due to the additional overhead of the Vendor- 1225 Specific format. 1227 The following data also qualifies as "simple data types": 1229 * Attributes grouped into a logical container, using the 1230 [RFC2868] tagging mechanism. This approach is NOT 1231 RECOMMENDED (see Section 2.1.2), but is permissible where 1232 the alternatives are worse. 1234 * Attributes requiring the transport of more than 247 octets of 1235 Text or String data. This includes the opaque encapsulation 1236 of data structures defined outside of RADIUS. See also Section 1237 A.1.3, below. 1239 Nested groups or attributes do not qualify as "simple data types", 1240 and SHOULD NOT be used. 1242 A.1.2. Transport of Authentication and Security Data 1244 Does the data provide authentication and/or security capabilities for 1245 the RADIUS protocol, as outlined below? If so, it SHOULD be 1246 encapsulated in a [RFC2865] format RADIUS attribute. It SHOULD NOT 1247 be encapsulated in a [RFC2865] format RADIUS VSA. 1249 * Complex data types that carry authentication methods which 1250 RADIUS servers are expected to parse and verify as part of 1251 an authentication process. 1253 * Complex data types that carry security information intended 1254 to increase the security of the RADIUS protocol itself. 1256 Any data type carrying authentication and/or security data that is 1257 not meant to be parsed by a RADIUS server is an "opaque data type", 1258 as defined below. 1260 A.1.3. Opaque data types 1262 Does the attribute encapsulate an existing data structure defined 1263 outside of the RADIUS specifications? Can the attribute be treated 1264 as opaque data by RADIUS servers (including proxies?) If both 1265 questions can be answered affirmatively, a complex structure MAY be 1266 used in a RADIUS specification. 1268 The specification of the attribute SHOULD define the encapsulating 1269 attribute to be of type String. The specification SHOULD refer to an 1270 external document defining the structure. The specification SHOULD 1271 NOT define or describe the structure, as discussed above in Section 1272 2.1.3. 1274 A.2. Improper Data Types 1276 All data types other than the ones described above in Appendix A.1 1277 and Appendix B SHOULD NOT be used. This section describes in detail 1278 a number of data types that are NOT RECOMMENDED in new RADIUS 1279 specifications. Where possible, replacement data types are 1280 suggested. 1282 A.2.1. Simple Data Types 1284 Does the attribute use any of the following data types? If so, the 1285 data type SHOULD be replaced with the suggested alternatives, or it 1286 SHOULD NOT be used at all. 1288 * Signed integers of any size. 1289 SHOULD NOT be used. SHOULD be replaced with one or more 1290 unsigned integer attributes. The definition of the attribute 1291 can contain information that would otherwise go into the sign 1292 value of the integer. 1294 * 8 bit unsigned integers. 1295 SHOULD be replaced with 32-bit unsigned integer. There is 1296 insufficient justification to save three bytes. 1298 * 16 bit unsigned integers. 1299 SHOULD be replaced with 32-bit unsigned integer. There is 1300 insufficient justification to save two bytes. 1302 * Unsigned integers of size other than 32 1303 SHOULD be replaced by an unsigned integer of 32 bits. 1304 There is insufficient justification to define a new size of 1305 integer. 1307 * Integers of any size in non-network byte order 1308 SHOULD be replaced by unsigned integer of 32 bits in network 1309 There is no reason to transport integers in any format other 1310 than network byte order. 1312 * Multi-field text strings. 1313 Each field SHOULD be encapsulated in a separate attribute. 1315 * Polymorphic attributes. 1316 Multiple attributes, each with a static data type SHOULD be 1317 defined instead. 1319 * Nested AVPs. 1320 Attributes should be defined in a flat typespace. 1322 A.2.2. Complex Data Types 1324 Does the attribute: 1326 * define a complex data type not described in Appendix B, 1327 * that a RADIUS server and/or client is expected to parse, 1328 validate, or create the contents of via a dynamic computation? 1329 i.e. A type that cannot be treated as opaque data (Section A.1.3) 1331 * involve functionality that could be implemented without code 1332 changes on both the client and server? (i.e. a type that doesn't 1333 require dynamic computation and verification, such as those 1334 performed for authentication or security attributes) 1336 If so, this data type SHOULD be replaced with simpler types, as 1337 discussed above in Appendix A.2.1. Also see Section 2.1.3 for a 1338 discussion of why complex types are problematic. 1340 A.3. Vendor-Specific formats 1342 Does the specification contain Vendor-Specific attributes that match 1343 any of the following criteria? If so, the data type should be 1344 replaced with the suggested alternatives, or should not be used at 1345 all. 1347 * Vendor types of more than 8 bits. 1348 SHOULD NOT be used. Vendor types of 8 bits SHOULD be used 1349 instead. 1351 * Vendor lengths of less than 8 bits. (i.e., zero bits) 1352 SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used 1353 instead. 1355 * Vendor lengths of more than 8 bits. 1356 SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used 1357 instead. 1359 * Vendor-Specific contents that are not in Type-Length-Value 1360 format. 1361 SHOULD NOT be used. Vendor-Specific attributes SHOULD be in 1362 Type-Length-Value format. 1364 In general, Vendor-Specific attributes SHOULD follow the [RFC2865] 1365 suggested format. Vendor extensions to non-standard formats are NOT 1366 RECOMMENDED as they can negatively affect interoperability. 1368 A.4. Changes to the RADIUS Operational Model 1370 Does the specification change the RADIUS operation model, as outlined 1371 in the list below? If so, then another method of achieving the 1372 design objectives SHOULD be used. Potential problem areas include: 1374 * Defining new commands in RADIUS using attributes. 1376 The addition of new commands to RADIUS MUST be handled via 1377 allocation of a new Code, and not by the use of an attribute. 1378 This restriction includes new commands created by overloading 1379 the Service-Type attribute to define new values that modify 1380 the functionality of Access-Request packets. 1382 * Using RADIUS as a transport protocol for data unrelated to 1383 authentication, authorization, or accounting. Using RADIUS to 1384 transport authentication methods such as EAP is explicitly 1385 permitted, even if those methods require the transport of 1386 relatively large amounts of data. Transport of opaque data 1387 relating to AAA is also permitted, as discussed above in 1388 Section 2.1.3. However, if the specification does not relate 1389 to AAA, then RADIUS SHOULD NOT be used. 1391 * Assuming support for packet lengths greater than 4096 octets. 1392 Attribute designers cannot assume that RADIUS implementations 1393 can successfully handle packets larger than 4096 octets. 1394 If a specification could lead to a RADIUS packet larger than 1395 4096 octets, then the alternatives described in Section 3.3 1396 SHOULD be considered. 1398 * Stateless operation. The RADIUS protocol is stateless, and 1399 documents which require stateful protocol behavior without the 1400 use of the State Attribute need to be redesigned. 1402 * Provisioning of service in an Access-Reject. Such provisioning 1403 is not permitted, and MUST NOT be used. If limited access needs 1404 to be provided, then an Access-Accept with appropriate 1405 authorizations can be used instead. 1407 * Lack of user authentication or authorization restrictions. 1408 In an authorization check, where there is no demonstration of a 1409 live user, confidential data cannot be returned. Where there 1410 is a link to a previous user authentication, the State attribute 1411 needs to be present. 1413 * Lack of per-packet integrity and authentication. 1414 It is expected that documents will support per-packet 1415 integrity and authentication. 1417 * Modification of RADIUS packet sequences. 1418 In RADIUS, each request is encapsulated in it's own packet, and 1419 elicits a single response that is sent to the requester. Since 1420 changes to this paradigm are likely to require major 1421 modifications to RADIUS client and server implementations, they 1422 SHOULD be avoided if possible. 1423 For further details, see Section 3.3. 1425 A.5. Allocation of attributes 1427 Does the attribute have a limited scope of applicability, as outlined 1428 below? If so, then the attributes SHOULD be allocated from the 1429 Vendor-Specific space. 1431 * attributes intended for a vendor to support their own systems, 1432 and not suitable for general usage 1434 * attributes relying on data types not defined within RADIUS 1436 * attributes intended primarily for use within an SDO 1438 * attributes intended primarily for use within a group of SDOs. 1440 Note that the points listed above do not relax the recommendations 1441 discussed in this document. Instead, they recognize that the RADIUS 1442 data model has limitations. In certain situations where 1443 interoperability can be strongly constrained by the SDO or vendor, an 1444 expanded data model MAY be used. We recommend, however, that the 1445 RADIUS data model SHOULD be used, even if it is marginally less 1446 efficient than alternatives. 1448 When attributes are used primarily within a group of SDOs, and are 1449 not applicable to the wider Internet community, we expect that one 1450 SDO will be responsible for allocation from their own private space. 1452 Appendix B - Complex Attributes 1454 This section summarizes RADIUS attributes with complex data types 1455 that are defined in existing RFCs. 1457 This appendix is published for informational purposes only, and 1458 reflects the usage of attributes with complex data types at the time 1459 of the publication of this document. 1461 B.1. CHAP-Password 1463 [RFC2865] Section 5.3 defines the CHAP-Password Attribute which is 1464 sent from the RADIUS client to the RADIUS server in an Access- 1465 Request. The data type of the CHAP Identifier is not given, only the 1466 one octet length: 1468 0 1 2 1469 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 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1471 | Type | Length | CHAP Ident | String ... 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1474 Since this is an authentication attribute, code changes are required 1475 on the RADIUS client and server to support it, regardless of the 1476 attribute format. Therefore, this complex data type is acceptable in 1477 this situation. 1479 B.2. CHAP-Challenge 1481 [RFC2865] Section 5.40 defines the CHAP-Challenge Attribute which is 1482 sent from the RADIUS client to the RADIUS server in an Access- 1483 Request. While the data type of the CHAP Identifier is given, the 1484 text also says: 1486 If the CHAP challenge value is 16 octets long it MAY be placed in 1487 the Request Authenticator field instead of using this attribute. 1489 Defining attributes to contain values taken from the RADIUS packet 1490 header is NOT RECOMMENDED. Attributes should have values that are 1491 packed into a RADIUS AVP. 1493 B.3. Tunnel-Password 1495 [RFC2868] Section 3.5 defines the Tunnel-Password Attribute, which is 1496 sent from the RADIUS server to the client in an Access-Accept. This 1497 attribute includes Tag and Salt fields, as well as a string field 1498 which consists of three logical sub-fields: the Data-Length (one 1499 octet) and Password sub-fields (both of which are required), and the 1500 optional Padding sub-field. The attribute appears as follows: 1502 0 1 2 3 1503 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 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 | Type | Length | Tag | Salt 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 Salt (cont) | String ... 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1510 Since this is a security attribute and is encrypted, code changes are 1511 required on the RADIUS client and server to support it, regardless of 1512 the attribute format. Therefore, this complex data type is 1513 acceptable in this situation. 1515 B.4. ARAP-Password 1517 [RFC2869] Section 5.4 defines the ARAP-Password attribute, which is 1518 sent from the RADIUS client to the server in an Access-Request. It 1519 contains four 4 octet values, instead of having a single Value field: 1521 0 1 2 3 1522 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 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 | Type | Length | Value1 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 | Value2 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 | Value3 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 | Value4 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 | 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 As with the CHAP-Password attribute, this is an authentication 1536 attribute which would have required code changes on the RADIUS client 1537 and server regardless of format. 1539 B.5. ARAP-Features 1541 [RFC2869] Section 5.5 defines the ARAP-Features Attribute, which is 1542 sent from the RADIUS server to the client in an Access-Accept or 1543 Access-Challenge. It contains a compound string of two single octet 1544 values, plus three 4-octet values, which the RADIUS client 1545 encapsulates in a feature flags packet in the ARAP protocol: 1547 0 1 2 3 1548 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 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 | Type | Length | Value1 | Value2 | 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 | Value3 | 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1554 | Value4 | 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 | Value5 | 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 Unlike the previous attributes, this attribute contains no encrypted 1560 component, nor is it directly involved in authentication. The 1561 individual sub-fields therefore could have been encapsulated in 1562 separate attributes. 1564 While the contents of this attribute is intended to be placed in an 1565 ARAP packet, the fields need to be set by the RADIUS server. Using 1566 standard RADIUS data types would have simplified RADIUS server 1567 implementations, and subsequent management. The current form of the 1568 attribute requires either the RADIUS server implementation, or the 1569 RADIUS server administrator, to understand the internals of the ARAP 1570 protocol. 1572 B.6. Connect-Info 1574 [RFC2869] Section 5.11 defines the Connect-Info attribute, which is 1575 used to indicate the nature of the connection. 1577 0 1 2 1578 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | Type | Length | Text... 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1583 Even though the type is Text, the rest of the description indicates 1584 that it is a complex attribute: 1586 The Text field consists of UTF-8 encoded 10646 _8_ characters. 1587 The connection speed SHOULD be included at the beginning of the 1588 first Connect-Info attribute in the packet. If the transmit and 1589 receive connection speeds differ, they may both be included in the 1590 first attribute with the transmit speed first (the speed the NAS 1591 modem transmits at), a slash (/), the receive speed, then 1592 optionally other information. 1593 For example, "28800 V42BIS/LAPM" or "52000/31200 V90" 1595 More than one Connect-Info attribute may be present in an 1596 Accounting-Request packet to accommodate expected efforts by ITU 1597 to have modems report more connection information in a standard 1598 format that might exceed 252 octets. 1600 This attribute contains no encrypted component, and is it not 1601 directly involved in authentication. The individual sub-fields could 1602 therefore have been encapsulated in separate attributes. 1604 Since the form of the text string is well defined, there is no 1605 benefit in using a text string. Instead, an integer attribute should 1606 have been assigned for each of the transmit speed and the receive 1607 speed. A separate enumerated integer should have been assigned for 1608 the additional information, as is done for the NAS-Port-Type 1609 attribute. 1611 B.7. Framed-IPv6-Prefix 1613 [RFC3162] Section 2.3 defines the Framed-IPv6-Prefix Attribute and 1614 [RFC4818] Section 3 reuses this format for the Delegated-IPv6-Prefix 1615 Attribute; these attributes are sent from the RADIUS server to the 1616 client in an Access-Accept. 1618 0 1 2 3 1619 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 1620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 | Type | Length | Reserved | Prefix-Length | 1622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1623 Prefix 1624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1625 Prefix 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 Prefix 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 Prefix | 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 The sub-fields encoded in these attributes are strongly related, and 1633 there was no previous definition of this data structure that could be 1634 referenced. Support for this attribute requires code changes on both 1635 the client and server, due to a new data type being defined. In this 1636 case it appears to be acceptable to encode them in one attribute. 1638 B.8. Egress-VLANID 1640 [RFC4675] Section 2.1 defines the Egress-VLANID Attribute which can 1641 be sent by a RADIUS client or server. 1643 0 1 2 3 1644 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 1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 | Type | Length | Value 1647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1648 Value (cont) | 1649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 While it appears superficially to be of type Integer, the Value field 1652 is actually a packed structure, as follows: 1654 0 1 2 3 1655 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 1656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1657 | Tag Indic. | Pad | VLANID | 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 The length of the VLANID field is defined by the [IEEE-802.1Q] 1661 specification. The Tag indicator field is either 0x31 or 0x32, for 1662 compatibility with the Egress-VLAN-Name, as discussed below. The 1663 complex structure of Egress-VLANID overlaps with that of the base 1664 Integer data type, meaning that no code changes are required for a 1665 RADIUS server to support this attribute. Code changes are required 1666 on the NAS, if only to implement the VLAN ID enforcement. 1668 Given the IEEE VLAN requirements and the limited data model of 1669 RADIUS, the chosen method is likely the best of the possible 1670 alternatives. 1672 B.9. Egress-VLAN-Name 1674 [RFC4675] Section 2.3 defines the Egress-VLAN-Name Attribute which 1675 can be sent by a RADIUS client or server. 1677 0 1 2 3 1678 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 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 | Type | Length | Tag Indic. | String... 1681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 The Tag Indicator is either the character '1' or '2', which in ASCII 1684 map to the identical values for Tag Indicator in Egress-VLANID, 1685 above. The complex structure of this attribute is acceptable for 1686 reasons identical to those given for Egress-VLANID. 1688 Acknowledgments 1690 We would like to acknowledge David Nelson, Bernard Aboba, Emile van 1691 Bergen, Barney Wolff and Glen Zorn for contributions to this 1692 document. 1694 Authors' Addresses 1696 Greg Weber 1697 Knoxville, TN 37932 1698 USA 1700 Email: gdweber@gmail.com 1702 Alan DeKok 1703 The FreeRADIUS Server Project 1704 http://freeradius.org/ 1706 Email: aland@freeradius.org