idnits 2.17.1 draft-ietf-radext-design-08.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 (6 September 2009) is 5340 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: March 6, 2010 7 6 September 2009 9 RADIUS Design Guidelines 10 draft-ietf-radext-design-08 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 March 6, 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 ...................................... 6 70 2.1.1. Basic Data Types ............................... 6 71 2.1.2. Tagging Mechanism .............................. 8 72 2.1.3. Complex Attribute Usage ........................ 8 73 2.1.4. Complex Attributes and Security ................ 11 74 2.1.5. Service definitions and RADIUS ................. 11 75 2.2. Vendor Space ........................................ 12 76 3. Data Model Issues ........................................ 13 77 3.1. Vendor Space ........................................ 14 78 3.1.1. Interoperability Considerations ................ 16 79 3.1.2. Vendor Allocations ............................. 16 80 3.1.3. SDO Allocations ................................ 17 81 3.1.4. Publication of specifications .................. 18 82 3.2. Polymorphic Attributes .............................. 18 83 3.3. RADIUS Operational Model ............................ 19 84 4. IANA Considerations ...................................... 22 85 5. Security Considerations .................................. 22 86 6. References ............................................... 23 87 6.1. Normative References ................................ 23 88 6.2. Informative References .............................. 23 89 Appendix A - Design Guidelines ............................... 26 90 A.1. Types matching the RADIUS data model ................. 26 91 A.1.1. Transport of simple data ........................ 26 92 A.1.2. Opaque data types ............................... 26 93 A.2. Improper Data Types .................................. 27 94 A.2.1. Simple Data Types ............................... 27 95 A.2.2. Complex Data Types .............................. 28 96 A.3. Vendor-Specific formats .............................. 28 97 A.4. Changes to the RADIUS Operational Model .............. 29 98 A.5. Allocation of attributes ............................. 30 99 Appendix B - Complex Attributes .............................. 31 100 B.1. CHAP-Password ........................................ 31 101 B.2. CHAP-Challenge ....................................... 31 102 B.3. Tunnel-Password ...................................... 31 103 B.4. ARAP-Password ........................................ 32 104 B.5. ARAP-Features ........................................ 32 105 B.6. Connect-Info ......................................... 33 106 B.7. Framed-IPv6-Prefix ................................... 34 107 B.8. Egress-VLANID ........................................ 34 108 B.9. Egress-VLAN-Name ..................................... 35 110 1. Introduction 112 This document provides guidelines for the design of RADIUS attributes 113 both within the IETF as well as within other SDOs. By articulating 114 RADIUS design guidelines, it is hoped that this document will 115 encourage the development and publication of high quality RADIUS 116 attribute specifications. 118 However, the advice in this document will not be helpful unless it is 119 put to use. As with "Guidelines for Authors and Reviewers of MIB 120 Documents" [RFC4181], it is expected that this document will be used 121 by authors to check their document against the guidelines prior to 122 requesting review (such as an "Expert Review" described in 123 [RFC3575]). Similarly, it is expected that this document will used 124 by reviewers (such as WG participants or the AAA Doctors [DOCTORS]), 125 resulting in an improvement in the consistency of reviews. 127 In order to meet these objectives, this document needs to cover not 128 only the science of attribute design, but also the art. As a result, 129 in addition to covering the most frequently encountered issues, this 130 document attempts to provide some of the considerations motivating 131 the guidelines. 133 In order to characterize current attribute usage, both the basic and 134 complex data types defined in the existing RADIUS RFCs are reviewed. 136 1.1. Terminology 138 This document uses the following terms: 140 Network Access Server (NAS) 141 A device that provides an access service for a user to a network. 143 RADIUS server 144 A RADIUS authentication, authorization, and/or accounting (AAA) 145 server is an entity that provides one or more AAA services to a 146 NAS. 148 RADIUS proxy 149 A RADIUS proxy acts as a RADIUS server to the NAS, and a RADIUS 150 client to the RADIUS server. 152 1.2. Requirements Language 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 1.3. Applicability 160 As RADIUS has become more widely accepted as a management protocol, 161 its usage has become more prevalent, both within the IETF as well as 162 within other SDOs. Given the expanded utilization of RADIUS, it has 163 become apparent that requiring SDOs to accomplish all their RADIUS 164 work within the IETF is inherently inefficient and unscalable. By 165 articulating guidelines for RADIUS attribute design, this document 166 enables SDOs out of the IETF to design their own RADIUS attributes 167 within the Vendor-Specific Attribute (VSA) space. 169 It is RECOMMENDED that SDOs follow the guidelines articulated in this 170 document. Doing so will ensure the widest possible applicability and 171 interoperability of the specifications, while requiring minimal 172 changes to existing systems. Specifications that do not follow the 173 guidelines articulated herein are NOT RECOMMENDED. However, we 174 recognize that there are some situations where SDOs or vendors 175 require the creation of specifications not following these 176 guidelines. We do not forbid these specifications, but it is 177 RECOMMENDED that they are created only if they have a limited scope 178 of applicability, and all attributes defined in those specifications 179 are VSAs, as discussed Appendix A.5, below. 181 It is RECOMMENDED that SDOs and vendors seek review of RADIUS 182 attribute specifications from the IETF. However, when specifications 183 are SDO specific, re-use existing data types, and follow these 184 guidelines, they do not require IETF review. 186 In order to enable IETF review of such specifications, the authors 187 recommend that: 189 * SDOs make their RADIUS attribute specifications publicly 190 available; 192 * SDOs request review of RADIUS attribute specifications by 193 sending email to the AAA Doctors [DOCTORS] or equivalent mailing 194 list; 196 * IETF and SDO RADIUS attribute specifications are reviewed 197 according to the guidelines proposed in this document; 199 * Reviews of specifications are posted to the RADEXT WG mailing 200 list, the AAA Doctors mailing list [DOCTORS] or another IETF 201 mailing list suggested by the Operations & Management Area 202 Directors of the IETF. 204 These reviews can assist with creation of specifications that meet 205 the SDO requirements, and which are also compatible with the 206 traditional data model and uses of RADIUS. While these reviews 207 require access to public specifications, the review process does not 208 require publication of an IETF RFC. 210 The advice in this document applies to attributes used to encode 211 service-provisioning or authentication data. RADIUS protocol 212 changes, or specification of attributes (such as Service-Type) that 213 can be used to, in effect, provide new RADIUS commands require 214 greater expertise and deeper review, as do changes to the RADIUS 215 operational model as discussed below in Section 3.3. Such changes 216 MUST NOT be undertaken outside the IETF and when handled within the 217 IETF require "IETF Consensus" for adoption, as noted in [RFC3575] 218 Section 2.1. 220 2. RADIUS Data Model 222 The Remote Authentication Dial In User Service (RADIUS) defined in 223 [RFC2865] and [RFC2866] uses elements known as attributes in order to 224 represent authentication, authorization and accounting data. 226 Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does 227 not define a formal data definition language. A handful of basic 228 data types are provided, and a data type is associated with an 229 attribute when the attribute is defined. 231 Two distinct attribute spaces are defined: the standard space, and a 232 Vendor-Specific space. Attributes in the standard space generally 233 are composed of a type, length, value (TLV) triplet, although complex 234 attributes have also been defined. The Vendor-Specific space is 235 encapsulated within a single attribute type (Vendor-Specific 236 Attribute). The format of this space is defined by individual 237 vendors, but the same TLV encoding used by the standard space is 238 recommended in [RFC2865] Section 5.26. The similarity between 239 attribute formats has enabled implementations to leverage common 240 parsing functionality, although in some cases the attributes in the 241 Vendor-Specific space have begun to diverge from the common format. 243 2.1. Standard Space 245 The following subsections describe common data types and formats 246 within the RADIUS standard attribute space. Common exceptions are 247 identified. 249 2.1.1. Basic Data Types 251 The data type of RADIUS attributes is not transported on the wire. 252 Rather, the data type of a RADIUS attribute is fixed when that 253 attribute is defined. Based on the RADIUS attribute type code, 254 RADIUS clients and servers can determine the data type based on pre- 255 configured entries within a data dictionary. 257 [RFC2865] defines the following data types: 259 text 1-253 octets containing UTF-8 encoded 10646 [RFC3629] 260 characters. Text of length zero (0) MUST NOT be sent; 261 omit the entire attribute instead. 262 string 1-253 octets containing binary data (values 0 through 263 255 decimal, inclusive). Strings of length zero (0) 264 MUST NOT be sent; omit the entire attribute instead. 265 IPv4 address 32 bit value, in network byte order. 266 integer 32 bit unsigned value, in network byte order. 267 time 32 bit unsigned value, in network byte order. 268 -- seconds since 00:00:00 UTC, January 1, 1970. 270 In addition to these data types, follow-on RADIUS specifications 271 define attributes using the following additional types: 273 IPv6 address 128 bit value, in network byte order. 274 IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to 275 128 bits of value, in network byte order. 276 integer64 64 bit unsigned value, in network byte order 277 This type has also been used to represent an IPv6 278 interface identifier. 280 Examples of the IPv6 address type include NAS-IPv6-Address defined in 281 [RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162] 282 Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3, 283 and in [RFC4818] Section 3. The integer64 type is used for the ARAP- 284 Challenge-Response Attribute defined in [RFC2869] Section 5.15, and 285 the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2. 286 [RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in 287 length, but denotes it as type String. 289 Given that attributes of type IPv6 address, IPv6 prefix, and 290 integer64 are already in use, it is RECOMMENDED that RADIUS server 291 implementations include support for these additional basic types, in 292 addition to the types defined in [RFC2865]. 294 Where the intent is to represent a specific IPv6 address, the IPv6 295 address type SHOULD be used. Although it is possible to use the IPv6 296 IPv6 Prefix type with a prefix length of 128 to represent an IPv6 297 address, this usage is NOT RECOMMENDED. 299 It is worth noting that since RADIUS only supports unsigned integers 300 of 32 or 64 bits, attributes using signed integer data types or 301 unsigned integer types of other sizes will require code changes, and 302 SHOULD be avoided. 304 For [RFC2865] RADIUS VSAs, the length limitation of the String and 305 Text types is 247 octets instead of 253 octets, due to the additional 306 overhead of the Vendor-Specific Attribute. 308 2.1.2. Tagging Mechanism 310 [RFC2868] defines an attribute grouping mechanism based on the use of 311 a one octet tag value. Tunnel attributes that refer to the same 312 tunnel are grouped together by virtue of using the same tag value. 314 This tagging mechanism has some drawbacks. There are a limited 315 number of unique tags (31). The tags are not well suited for use 316 with arbitrary binary data values, because it is not always possible 317 to tell if the first byte after the Length is the tag or the first 318 byte of the untagged value (assuming the tag is optional). 320 Other limitations of the tagging mechanism are that when integer 321 values are tagged, the value portion is reduced to three bytes 322 meaning only 24-bit numbers can be represented. The tagging 323 mechanism does not offer an ability to create nested groups of 324 attributes. Some RADIUS implementations treat tagged attributes as 325 having additional data types tagged-string and tagged-integer. These 326 types increase the complexity of implementing and managing RADIUS 327 systems. 329 New attributes SHOULD NOT use this tagging method because of the 330 limitations described above. 332 2.1.3. Complex Attribute Usage 334 The RADIUS attribute encoding is summarized in [RFC2865]: 336 0 1 2 337 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 339 | Type | Length | Value ... 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 342 However, some standard attributes do not follow this format. 343 Attributes that use sub-fields instead of using a basic data type are 344 known as "complex attributes". As described below, the definition of 345 complex attributes can lead to interoperability and deployment 346 issues, so they need to be introduced with care. 348 In general, complex attributes sent from the RADIUS server to the 349 client can be supported by concatenating the values into a String 350 data type field. However, separating these values into different 351 attributes, each with its own type and length, would have the 352 following benefits: 354 * it is easier for the user to enter the data as well-known 355 types, rather than complex structures; 356 * it enables additional error checking by leveraging the 357 parsing and validation routines for well-known types; 358 * it simplifies implementations by eliminating special-case 359 attribute-specific parsing. 361 One of the fundamental goals of the RADIUS protocol design was to 362 allow RADIUS servers to be configured to support new attributes 363 without requiring server code changes. RADIUS server implementations 364 typically provide support for basic data types, and define attributes 365 in a data dictionary. This architecture enables a new attribute to 366 be supported by the addition of a dictionary entry, without requiring 367 RADIUS server code changes. 369 On the RADIUS client, code changes are typically required in order to 370 implement a new attribute. The RADIUS client typically has to 371 compose the attribute dynamically when sending. When receiving, a 372 RADIUS client needs to be able to parse the attribute and carry out 373 the requested service. As a result, a detailed understanding of the 374 new attribute is required on clients, and data dictionaries are less 375 useful on clients than on servers. 377 Given these considerations, the introduction of a new basic or 378 complex attribute will typically require code changes on the RADIUS 379 client. The magnitude of changes for the complex attribute could be 380 greater, due to the potential need for custom parsing logic. 382 The RADIUS server can be configured to send a new static attribute by 383 entering its type and data format in the RADIUS server dictionary, 384 and then filling in the value within a policy based on the attribute 385 name, data type and type-specific value. For complex attribute types 386 not supported by RADIUS server dictionaries, changes to the 387 dictionary code can be required in order to allow the new attribute 388 to be supported by and configured on the RADIUS server. 390 Code changes can also be required in policy management and in the 391 RADIUS server's receive path. These changes are due to limitations 392 in RADIUS server policy languages, which typically only provide for 393 limited operations (such as comparisons or arithmetic operations) on 394 the basic data types. Many existing RADIUS policy languages 395 typically are not capable of parsing sub-elements, or providing 396 sophisticated matching functionality. 398 Given these limitations, the introduction of complex attributes can 399 require code changes on the RADIUS server which would be unnecessary 400 if basic data types had been used instead. In addition, attribute- 401 specific parsing means more complex software to develop and maintain. 402 More complexity can lead to more error prone implementations, 403 interoperability problems, and even security vulnerabilities. These 404 issues can increase costs to network administrators as well as 405 reducing reliability and introducing deployment barriers. As a 406 result, the introduction of new complex data types within RADIUS 407 attribute specifications SHOULD be avoided, except in the case of 408 complex attributes involving authentication or security 409 functionality. 411 As can be seen in Appendix B, most of the existing complex attributes 412 involve authentication or security functionality. Supporting this 413 functionality requires code changes on both the RADIUS client and 414 server, regardless of the attribute format. As a result, in most 415 cases, the use of complex attributes to represent these methods is 416 acceptable, and does not create additional interoperability or 417 deployment issues. 419 The only other exception to the recommendation against complex types 420 is for types that can be treated as opaque data by the RADIUS server. 421 For example, the EAP-Message attribute, defined in [RFC3579] Section 422 3.1 contains a complex data type that is an EAP packet. Since these 423 complex types do not need to be parsed by the RADIUS server, the 424 issues arising from policy language limitations do not arise. 425 Similarly, since attributes of these complex types can be configured 426 on the server using a data type of String, dictionary limitations are 427 also not encountered. Appendix A.1 below includes a series of 428 checklists that may be used to analyze a design for RECOMMENDED and 429 NOT RECOMMENDED behavior in relation to complex types. 431 If the RADIUS Server simply passes the contents of an attribute to 432 some non-RADIUS portion of the network, then the data is opaque, and 433 SHOULD be defined to be of type String. A concrete way of judging 434 this requirement is whether or not the attribute definition in the 435 RADIUS document contains delineated fields for sub-parts of the data. 436 If those fields need to be delineated in RADIUS, then the data is not 437 opaque, and it SHOULD be separated into individual RADIUS attributes. 439 An examination of existing RADIUS RFCs discloses a number of complex 440 attributes that have already been defined. Appendix B includes a 441 listing of complex attributes used within [RFC2865], [RFC2868], 442 [RFC2869], [RFC3162], [RFC4818], and [RFC4675]. The discussion of 443 these attributes includes reasons why a complex type is acceptable, 444 or suggestions for how the attribute could have been defined to 445 follow the RADIUS data model. 447 In other cases, the data in the complex type are described textually. 448 This is possible because the data types are not sent within the 449 attributes, but are a matter for endpoint interpretation. An 450 implementation can define additional data types, and use these data 451 types today by matching them to the attribute's textual description. 453 2.1.4. Complex Attributes and Security 455 The introduction of complex data types brings the potential for the 456 introduction of new security vulnerabilities. Experience shows that 457 the common data types have few security vulnerabilities, or else that 458 all known issues have been found and fixed. New data types require 459 new code, which may introduce new bugs, and therefore new attack 460 vectors. 462 RADIUS servers are highly valued targets, as they control network 463 access and interact with databases that store usernames and 464 passwords. An extreme outcome of a vulnerability due to a new, 465 complex type would be that an attacker is capable of taking complete 466 control over the RADIUS server. 468 The use of attributes representing opaque data does not reduce this 469 threat. The threat merely moves from the RADIUS server to the 470 application that consumes that opaque data. 472 The threat is particularly severe when the opaque data originates 473 from the user, and is not validated by the NAS. In those cases, the 474 RADIUS server is potentially exposed to attack by malware residing on 475 an unauthenticated host. Applications consuming opaque data that 476 reside on the RADIUS server SHOULD be properly isolated from the 477 RADIUS server, and SHOULD run with minimal privileges. Any potential 478 vulnerabilities in that application will then have minimal impact on 479 the security of the system as a whole. 481 2.1.5. Service definitions and RADIUS 483 RADIUS specifications define how an existing service or protocol can 484 be provisioned using RADIUS. Therefore, it is expected that a RADIUS 485 attribute specification will reference documents defining the 486 protocol or service to be provisioned. Within the IETF, a RADIUS 487 attribute specification SHOULD NOT be used to define the protocol or 488 service being provisioned. New services using RADIUS for 489 provisioning SHOULD be defined elsewhere and referenced in the RADIUS 490 specification. 492 New attributes, or new values of existing attributes, SHOULD NOT be 493 used to define new RADIUS commands. RADIUS attributes are intended 494 to: 496 * authenticate users 497 * authorize users (i.e., service provisioning or changes to 498 provisioning) 499 * account for user activity (i.e., logging of session activity) 501 New commands (i.e., the Code field in the packet header) are 502 allocated only through "IETF Consensus" as noted in [RFC3575] Section 503 2.1. Specifications also SHOULD NOT use new attributes to modify the 504 interpretation of existing RADIUS commands. 506 2.2. Vendor Space 508 As noted in [RFC2865] Section 5.26, the VSA format is defined as 509 follows: 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Type | Length | Vendor-Id 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Vendor-Id (cont) | String... 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 519 The high-order octet of the Vendor-Id field is 0 and the low-order 3 520 octets are the Structure of Management Information (SMI) Network 521 Management Private Enterprise Code (PEC) of the Vendor in network 522 byte order. 524 While the format of the String field is defined by the vendor, 525 [RFC2865] Section 5.26 notes: 527 It SHOULD be encoded as a sequence of vendor type / vendor length 528 / value fields, as follows. The Attribute-Specific field is 529 dependent on the vendor's definition of that attribute. An 530 example encoding of the Vendor-Specific attribute using this 531 method follows: 533 0 1 2 3 534 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 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Type | Length | Vendor-Id 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 Vendor-Id (cont) | Vendor type | Vendor length | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Attribute-Specific... 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 543 Multiple sub-attributes MAY be encoded within a single Vendor- 544 Specific attribute, although they do not have to be. 546 Note that the Vendor type field in the recommended VSA format is only 547 a single octet, like the RADIUS type field. While this limitation 548 results in an efficient encoding, there are situations in which a 549 vendor or SDO will eventually wish to define more than 255 550 attributes. Also, an SDO can be comprised of multiple subgroups, 551 each of whom can desire autonomy over the definition of attributes 552 within their group. In such a situation, a 16-bit Vendor type field 553 would be more appropriate: 555 0 1 2 3 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Type | Length | Vendor-Id 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 Vendor-Id (cont) | Vendor type | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Vendor length | Attribute-Specific... 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 Other attribute formats are NOT RECOMMENDED. Examples of NOT 566 RECOMMENDED formats include Vendor types of more than 16 bits, Vendor 567 lengths of less than 8 bits, Vendor lengths of more than 8 bits, and 568 Vendor-Specific contents that are not in Type-Length-Value format. 570 In order to be compatible with the above recommendations for 571 attribute definitions, it is RECOMMENDED that RADIUS servers support 572 attributes using a 16-bit Vendor type field. 574 Although [RFC2865] does not mandate it, implementations commonly 575 assume that the Vendor Id can be used as a key to determine the on- 576 the-wire format of a VSA. Vendors therefore SHOULD NOT use multiple 577 formats for VSAs that are associated with a particular Vendor Id. A 578 vendor wishing to use multiple VSA formats, SHOULD request one Vendor 579 Id for each VSA format that they will use. 581 3. Data Model Issues 583 Since the closure of the RADIUS Working Group, the popularity and 584 prevalence of RADIUS has continued to grow. In addition to 585 increasing demand for allocation of attributes within the RADIUS 586 standard attribute space, the number of vendors and SDOs creating new 587 attributes within the Vendor-Specific attribute space has grown, and 588 this has lead to some divergence in approaches to RADIUS attribute 589 design. 591 In general, standard RADIUS attributes have a more constrained data 592 model than attributes within the vendor space. For example, vendors 593 and SDOs have evolved the data model to support new functions such as 594 attribute grouping and attribute fragmentation, with different groups 595 taking different approaches. 597 Given these enhancements, it has become difficult for vendors or SDOs 598 to translate attributes from the vendor space to the more stringent 599 standards space. For example, a Vendor-Specific attribute using sub- 600 elements could require allocation of several standard space 601 attributes using basic data types. In this case not only would 602 translation require substantial additional work, it would further 603 deplete the RADIUS standard attribute space. Given these 604 limitations, translation of vendor attributes to the standards space 605 is not necessarily desirable, particularly if the VSA specification 606 is publicly available and can be implemented within existing RADIUS 607 clients and servers. In such situations, the costs may substantially 608 outweigh the benefits. It is possible that some of the enhancements 609 made within the vendor space may eventually become available within 610 the standard attribute space. However, the divergence of the 611 standard and vendor attribute spaces is most likely a permanent 612 feature, and should be recognized as such. 614 3.1. Vendor Space 616 The usage model for RADIUS VSAs is described in [RFC2865] Section 617 6.2: 619 Note that RADIUS defines a mechanism for Vendor-Specific 620 extensions (Attribute 26) and the use of that should be encouraged 621 instead of allocation of global attribute types, for functions 622 specific only to one vendor's implementation of RADIUS, where no 623 interoperability is deemed useful. 625 Nevertheless, many new attributes have been defined in the vendor 626 specific space in situations where interoperability is not only 627 useful, but is required. For example, SDOs outside the IETF (such as 628 the IEEE 802 and the 3rd Generation Partnership Project (3GPP)) have 629 been assigned Vendor-Ids, enabling them to define their own VSA 630 format and assign Vendor types within their own space. 632 The use of VSAs by SDOs outside the IETF has gained in popularity for 633 several reasons: 635 Efficiency 636 As with SNMP, which defines an "Enterprise" Object Identifier (OID) 637 space suitable for use by vendors as well as other SDOs, the 638 definition of Vendor-Specific RADIUS attributes has become a common 639 occurrence as part of standards activity outside the IETF. For 640 reasons of efficiency, it is easiest if the RADIUS attributes 641 required to manage a standard are developed within the same SDO 642 that develops the standard itself. As noted in "Transferring MIB 643 Work from IETF Bridge MIB WG to IEEE 802.1 WG" [RFC4663], today few 644 vendors are willing to simultaneously fund individuals to 645 participate within an SDO to complete a standard, as well as to 646 participate in the IETF in order to complete the associated RADIUS 647 attributes specification. 649 Attribute scarcity 650 The standard RADIUS attribute space is limited to 255 unique 651 attributes. Of these, only about half remain available for 652 allocation. In the Vendor-Specific space, the number of attributes 653 available is a function of the format of the attribute (the size of 654 the Vendor type field). 656 Along with these advantages, some limitations of VSA usage are noted 657 in [RFC2865] Section 5.26: 659 This Attribute is available to allow vendors to support their own 660 extended Attributes not suitable for general usage. It MUST NOT 661 affect the operation of the RADIUS protocol. 663 Servers not equipped to interpret the vendor-specific information 664 sent by a client MUST ignore it (although it may be reported). 665 Clients which do not receive desired vendor-specific information 666 SHOULD make an attempt to operate without it, although they may do 667 so (and report they are doing so) in a degraded mode. 669 The limitation on changes to the RADIUS protocol effectively 670 prohibits VSAs from changing fundamental aspects of RADIUS operation, 671 such as modifying RADIUS packet sequences, or adding new commands. 672 However, the requirement for clients and servers to be able to 673 operate in the absence of VSAs has proven to be less of a constraint, 674 since it is still possible for a RADIUS client and server to mutually 675 indicate support for VSAs, after which behavior expectations can be 676 reset. 678 Therefore, RFC 2865 provides considerable latitude for development of 679 new attributes within the vendor space, while prohibiting development 680 of protocol variants. This flexibility implies that RADIUS 681 attributes can often be developed within the vendor space without 682 loss (and possibly even with gain) in functionality. 684 As a result, translation of RADIUS attributes developed within the 685 vendor space into the standard space may provide only modest 686 benefits, while accelerating the exhaustion of the standard attribute 687 space. We do not expect that all RADIUS attribute specifications 688 requiring interoperability will be developed within the IETF, and 689 allocated from the standards space. A more scalable approach is to 690 recognize the flexibility of the vendor space, while working toward 691 improvements in the quality and availability of RADIUS attribute 692 specifications, regardless of where they are developed. 694 3.1.1. Interoperability Considerations 696 Vendors and SDOs are reminded that the standard RADIUS attribute 697 space, and the enumerated value space for enumerated attributes, are 698 reserved for allocation through work published via the IETF, as noted 699 in [RFC3575] Section 2.1. Some vendors and SDOs have in the past 700 performed self-allocation by assigning vendor-specific meaning to 701 "unused" values from the standard RADIUS attribute ID or enumerated 702 value space. This self-allocation results in interoperability 703 issues, and is counter-productive. Similarly, the Vendor-Specific 704 enumeration practice discussed in [RFC2882] Section 2.2.1 is NOT 705 RECOMMENDED. 707 If it is not possible to follow the IETF process, vendors and SDOs 708 SHOULD self-allocate an attribute from their Vendor-Specific space, 709 and define an appropriate value for it. 711 As a side note, [RFC2865] Section 5.26 uses the term "Vendor-Specific 712 Attribute" to refer to an encoding format which can be used by 713 individual vendors to define attributes not suitable for general 714 usage. However, since then VSAs have also become widely used by SDOs 715 defining attributes intended for multi-vendor interoperability. As 716 such, these attributes are not specific to any single vendor, and the 717 term "Vendor-Specific" may be misleading. An alternate term which 718 better describes this use case is SDO-Specific Attribute (SSA). 720 The design and specification of VSAs for multi-vendor usage SHOULD be 721 undertaken with the same level of care as standard RADIUS attributes. 722 Specifically, the provisions of this document that apply to standard 723 RADIUS attributes also apply to SSAs or VSAs for multi-vendor usage. 725 3.1.2. Vendor Allocations 727 Vendor RADIUS Attribute specifications SHOULD allocate attributes 728 from the vendor space, rather than requesting an allocation from the 729 RADIUS standard attribute space. 731 As discussed in [RFC2865] Section 5.26, the vendor space is intended 732 for vendors to support their own Attributes not suitable for general 733 use. However, it is RECOMMENDED that vendors follow the guidelines 734 outlined here, which are intended to enable maximum interoperability 735 with minimal changes to existing systems. 737 Following these guidelines means that RADIUS servers can be updated 738 to support the vendor's equipment by editing a RADIUS dictionary. If 739 these guidelines are not followed, then the vendor's equipment can 740 only be supported via code changes in RADIUS server implementations. 741 Such code changes add complexity and delay to implementations. 743 3.1.3. SDO Allocations 745 SDO RADIUS Attribute specifications SHOULD allocate attributes from 746 the vendor space, rather than requesting an allocation from the 747 RADIUS standard attribute space, for attributes matching any of the 748 following criteria: 750 * attributes relying on data types not defined within RADIUS 751 * attributes intended primarily for use within an SDO 752 * attributes intended primarily for use within a group of SDOs. 754 Any new RADIUS attributes or values intended for interoperable use 755 across a broad spectrum of the Internet Community SHOULD follow the 756 normal IETF process, and SHOULD result in allocations from the RADIUS 757 standard space. 759 The recommendation for SDOs to allocate attributes from a vendor 760 space rather than via the IETF process is a recognition that SDOs may 761 desire to assert change control over their own RADIUS specifications. 762 This change control can be obtained by requesting a PEC from the 763 Internet Assigned Number Authority (IANA), for use as a Vendor-Id 764 within a Vendor-Specific attribute. Further allocation of attributes 765 inside of the VSA space defined by that Vendor-Id is subject solely 766 to the discretion of the SDO. Similarly, the use of data types 767 (complex or not) within that VSA space is solely under the discretion 768 of the SDO. It is RECOMMENDED that SDOs follow the guidelines 769 outlined here, which are intended to enable maximum interoperability 770 with minimal changes to existing systems. 772 It should be understood that SDOs do not have to rehost VSAs into the 773 standards space solely for the purpose of obtaining IETF review. 774 Rehosting puts pressure on the standards space, and may be harmful to 775 interoperability, since it can create two ways to provision the same 776 service. Rehosting may also require changes to the RADIUS data model 777 which will affect implementations that do not intend to support the 778 SDO specifications. 780 3.1.4. Publication of specifications 782 SDOs are encouraged to seek early review of SSA specifications by the 783 IETF. This review may be initiated by sending mail to the AAA 784 Doctors list [DOCTORS], with the understanding that this review is a 785 voluntary-based service offered on best-effort basis. Since the IETF 786 is not a membership organization, in order to enable the RADIUS SSA 787 specification to be reviewed, it is RECOMMENDED that it be made 788 publicly available; this also encourages interoperability. Where the 789 RADIUS SSA specification is embedded within a larger document which 790 cannot be made public, the RADIUS attribute and value definitions 791 SHOULD be published instead as an Informational RFC, as with 792 [RFC4679]. This process SHOULD be followed instead of requesting 793 IANA allocations from within the standard RADIUS attribute space. 795 Similarly, vendors are encouraged to make their specifications 796 publicly available, for maximum interoperability. However, it is not 797 necessary for them to request publication of their VSA specifications 798 as Informational RFCs by the IETF. 800 All other specifications, including new authentication, 801 authorization, and/or security mechanisms SHOULD be allocated via the 802 standard RADIUS space, as noted in [RFC3575] Section 2.1. 804 3.2. Polymorphic Attributes 806 A polymorphic attribute is one whose format or meaning is dynamic. 807 For example, rather than using a fixed data format, an attribute's 808 format might change based on the contents of another attribute. Or, 809 the meaning of an attribute may depend on earlier packets in a 810 sequence. 812 RADIUS server dictionary entries are typically static, enabling the 813 user to enter the contents of an attribute without support for 814 changing the format based on dynamic conditions. However, this 815 limitation on static types does not prevent implementations from 816 implementing policies that return different attributes based on the 817 contents of received attributes; this is a common feature of existing 818 RADIUS implementations. 820 In general, polymorphism is NOT RECOMMENDED. Polymorphism rarely 821 enables capabilities that would not be available through use of 822 multiple attributes. Polymorphism requires code changes in the 823 RADIUS server in situations where attributes with fixed formats would 824 not require such changes. Thus, polymorphism increases complexity 825 while decreasing generality, without delivering any corresponding 826 benefits. 828 Note that changing an attribute's format dynamically is not the same 829 thing as using a fixed format and computing the attribute itself 830 dynamically. RADIUS authentication attributes such as User-Password, 831 EAP-Message, etc. while being computed dynamically, use a fixed 832 format. 834 3.3. RADIUS Operational Model 836 The RADIUS operational model includes several assumptions: 838 * The RADIUS protocol is stateless; 839 * Provisioning of services is not possible within an 840 Access-Reject; 841 * There is a distinction between authorization checks and user 842 authentication; 843 * The protocol provices for authentication and integrity 844 protection of packets; 845 * The RADIUS protocol is a Request/Response protocol; 846 * The protocol defines packet length restrictions. 848 While RADIUS server implementations may keep state, the RADIUS 849 protocol is stateless, although information may be passed from one 850 protocol transaction to another via the State Attribute. As a 851 result, documents which require stateful protocol behavior without 852 use of the State Attribute are inherently incompatible with RADIUS as 853 defined in [RFC2865], and need to be redesigned. See [RFC5080] 854 Section 2.1.1 for a more in-depth discussion of the use of the State 855 Attribute. 857 As noted in [RFC5080] Section 2.6, the intent of an Access-Reject is 858 to deny access to the requested service. As a result, RADIUS does 859 not allow the provisioning of services within an Access-Reject. 860 Documents which include provisioning of services within an Access- 861 Reject are inherently incompatible with RADIUS, and need to be 862 redesigned. 864 As noted in [RFC5080] Section 2.1.1, a RADIUS Access-Request may not 865 contain user authentication attributes or a State Attribute linking 866 the Access-Request to an earlier user authentication. Such an 867 Access-Request, known as an authorization check, provides no 868 assurance that it corresponds to a live user. RADIUS specifications 869 defining attributes containing confidential information (such as 870 Tunnel-Password) should be careful to prohibit such attributes from 871 being returned in response to an authorization check. Also, 872 [RFC5080] Section 2.1.1 notes that authentication mechanisms need to 873 tie a sequence of Access-Request/Access-Challenge packets together 874 into one authentication session. The State Attribute is RECOMMENDED 875 for this purpose. 877 While [RFC2865] did not require authentication and integrity 878 protection of RADIUS Access-Request packets, subsequent 879 authentication mechanism specifications such as RADIUS/EAP [RFC3579] 880 and Digest Authentication [RFC5090] have mandated authentication and 881 integrity protection for certain RADIUS packets. [RFC5080] Section 882 2.1.1 makes this behavior RECOMMENDED for all Access-Request packets, 883 including Access-Request packets performing authorization checks. It 884 is expected that specifications for new RADIUS authentication 885 mechanisms will continue this practice. 887 The RADIUS protocol as defined in [RFC2865] is a request-response 888 protocol spoken between RADIUS clients and servers. A single RADIUS 889 Access-Request packet will solicit in response at most a single 890 Access-Accept, Access-Reject or Access-Challenge packet, sent to the 891 IP address and port of the RADIUS Client that originated the Access- 892 Request. Similarly, a single Change-of-Authorization (CoA)-Request 893 packet [RFC5176] will solicit in response at most a single CoA-ACK or 894 CoA-NAK packet, sent to the IP address and port of the Dynamic 895 Authorization Client (DAC) that originated the CoA-Request. A single 896 Disconnect-Request packet will solicit in response at most a single 897 Disconnect-ACK or Disconnect-NAK packet, sent to the IP address and 898 port of the Dynamic Authorization Client (DAC) that originated the 899 Disconnect-Request. Changes to this model are likely to require 900 major revisions to existing implementations and so this practice is 901 NOT RECOMMENDED. 903 The Length field in the RADIUS packet header is defined in [RFC2865] 904 Section 3. It is noted there that the maximum length of a RADIUS 905 packet is 4096 octets. As a result, attribute designers SHOULD NOT 906 assume that a RADIUS implementation can successfully process RADIUS 907 packets larger than 4096 octets. 909 Even when packets are less than 4096 octets, they may be larger than 910 the Path Maximum Transmission Unit (PMTU). Any packet larger than 911 the PMTU will be fragmented, making communications more brittle as 912 firewalls and filtering devices often discard fragments. Transport 913 of fragmented UDP packets appears to be a poorly tested code path on 914 network devices. Some devices appear to be incapable of transporting 915 fragmented UDP packets, making it difficult to deploy RADIUS in a 916 network where those devices are deployed. We RECOMMEND that RADIUS 917 messages be kept as small possible. 919 If a situation is envisaged where it may be necessary to carry 920 authentication, authorization or accounting data in a packet larger 921 than 4096 octets, then one of the following approaches is 922 RECOMMENDED: 924 1. Utilization of a sequence of packets. 926 For RADIUS authentication, a sequence of Access-Request/ Access- 927 Challenge packets would be used. For this to be feasible, 928 attribute designers need to enable inclusion of attributes that 929 can consume considerable space within Access-Challenge packets. 930 To maintain compatibility with existing NASes, either the use of 931 Access-Challenge packets needs to be permissible (as with 932 RADIUS/EAP, defined in [RFC3579]), or support for receipt of an 933 Access-Challenge needs to be indicated by the NAS (as in RADIUS 934 Location [RFC5580]). Also, the specification needs to clearly 935 describe how attribute splitting is to be signalled and how 936 attributes included within the sequence are to be interpreted, 937 without requiring stateful operation. Unfortunately, previous 938 specifications have not always exhibited the required foresight. 939 For example, even though very large filter rules are 940 conceivable, the NAS-Filter-Rule Attribute defined in [RFC4849] 941 is not permitted in an Access-Challenge packet, nor is a 942 mechanism specified to allow a set of NAS-Filter-Rule attributes 943 to be split across an Access-Request/Access-Challenge sequence. 945 In the case of RADIUS accounting, transporting large amounts of 946 data would require a sequence of Accounting-Request packets. 947 This is a non-trivial change to RADIUS, since RADIUS accounting 948 clients would need to be modified to split the attribute stream 949 across multiple Accounting-Requests, and billing servers would 950 need to be modified to re-assemble and interpret the attribute 951 stream. 953 2. Utilization of names rather than values. 954 Where an attribute relates to a policy that could conceivably be 955 pre-provisioned on the NAS, then the name of the pre-provisioned 956 policy can be transmitted in an attribute, rather than the 957 policy itself, which could be quite large. An example of this 958 is the Filter-Id Attribute defined in [RFC2865] Section 5.11, 959 which enables a set of pre-provisioned filter rules to be 960 referenced by name. 962 3. Utilization of Packetization Layer Path MTU Discovery 963 techniques, as specified in [RFC4821]. As a last resort, where 964 the above techniques cannot be made to work, it may be possible 965 to apply the techniques described in [RFC4821] to discover the 966 maximum supported RADIUS packet size on the path between a 967 RADIUS client and a home server. While such an approach can 968 avoid the complexity of utilization of a sequence of packets, 969 dynamic discovery is likely to be time consuming and cannot be 970 guaranteed to work with existing RADIUS implementations. As a 971 result, this technique is not generally applicable. 973 4. IANA Considerations 975 This document does not require that the IANA update any existing 976 registry or create any new registry, but includes information that 977 affects the IANA, which: 979 * includes specific guidelines for Expert Reviewers appointed 980 under the IANA considerations of [RFC3575] 981 * includes guidelines that recommend against self allocation from 982 the RADIUS standard attribute space in other SDO RADIUS 983 Attribute specifications. 984 * recommends that SDOs request a Private Enterprise Code (PEC) 985 from the IANA, for use as a Vendor-Id within a Vendor-Specific 986 attribute. 988 5. Security Considerations 990 This specification provides guidelines for the design of RADIUS 991 attributes used in authentication, authorization and accounting. 992 Threats and security issues for this application are described in 993 [RFC3579] and [RFC3580]; security issues encountered in roaming are 994 described in [RFC2607]. 996 Obfuscation of RADIUS attributes on a per-attribute basis is 997 necessary in some cases. The current standard mechanism for this is 998 described in [RFC2865] Section 5.2 (for obscuring User-Password 999 values) and is based on the MD5 algorithm specified in [RFC1321]. 1000 The MD5 and SHA-1 algorithms have recently become a focus of scrutiny 1001 and concern in security circles, and as a result, the use of these 1002 algorithms in new attributes is NOT RECOMMENDED. In addition, 1003 previous documents referred to this method as generating "encrypted" 1004 data. This terminology is no longer accepted within the 1005 cryptographic community. 1007 Where new RADIUS attributes use cryptographic algorithms, algorithm 1008 negotiation SHOULD be supported. Specification of a mandatory-to- 1009 implement algorithm is REQUIRED, and it is RECOMMENDED that the 1010 mandatory-to-implement algorithm be certifiable under FIPS 140 1011 [FIPS]. 1013 Where new RADIUS attributes encapsulate complex data types, or 1014 transport opaque data, the security considerations discussed in 1015 Section 2.1.4 SHOULD be addressed. 1017 Message authentication in RADIUS is provided largely via the Message- 1018 Authenticator attribute. See [RFC3579] Section 3.2, and also 1019 [RFC5080] 2.2.2, which says that client implementations SHOULD 1020 include a Message-Authenticator attribute in every Access-Request. 1022 In general, the security of the RADIUS protocol is poor. Robust 1023 deployments SHOULD support a secure communications protocol such as 1024 IPSec. See [RFC3579] Section 4, and [RFC3580] Section 5 for a more 1025 in-depth explanation of these issues. 1027 Implementations not following the suggestions outlined in this 1028 document may be subject to a problems such as ambiguous protocol 1029 decoding, packet loss leading to loss of billing information, and 1030 denial of service attacks. 1032 6. References 1034 6.1. Normative References 1036 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1037 Requirement Levels", BCP 14, RFC 2119, March 1997. 1039 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 1040 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1041 2000. 1043 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1044 Authentication Dial In User Service)", RFC 3575, July 2003. 1046 6.2. Informative References 1048 [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of 1049 management information for TCP/IP-based internets", STD 16, 1050 RFC 1155, May 1990. 1052 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 1053 Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1054 1990. 1056 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1057 April 1992. 1059 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1060 Implementation in Roaming", RFC 2607, June 1999. 1062 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1064 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., 1065 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 1066 Support", RFC 2868, June 2000. 1068 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", 1069 RFC 2869, June 2000. 1071 [RFC2882] Mitton, D, "Network Access Servers Requirements: Extended 1072 RADIUS Practices", RFC 2882, July 2000. 1074 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 1075 3162, August 2001. 1077 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 1078 In User Service) Support For Extensible Authentication 1079 Protocol (EAP)", RFC 3579, September 2003. 1081 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE 1082 802.1X Remote Authentication Dial In User Service (RADIUS) 1083 Usage Guidelines", RFC3580, September 2003. 1085 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1086 RFC 3629, November 2003. 1088 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 1089 Documents", RFC 4181, September 2005. 1091 [RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge MIB WG 1092 to IEEE 802.1 WG", RFC 4663, September 2006. 1094 [RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for 1095 Virtual LAN and Priority Support", RFC 4675, September 2006. 1097 [RFC4679] Mammoliti, V., et al., "DSL Forum Vendor-Specific RADIUS 1098 Attributes", RFC 4679, September 2006. 1100 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 1101 Attribute", RFC 4818, April 2007. 1103 [RFC4821] Mathis, M. and Heffner, J, "Packetization Layer Path MTU 1104 Discovery", RFC 4821, March 2007. 1106 [RFC4849] Congdon, P. et al, "RADIUS Filter-Rule Attribute", RFC 4849, 1107 April 2007. 1109 [RFC5080] Nelson, D. and DeKok, A, "Common Remote Authentication Dial In 1110 User Service (RADIUS) Implementation Issues and Suggested 1111 Fixes", RFC 5080, December 2007. 1113 [RFC5090] Sterman, B. et al., "RADIUS Extension for Digest 1114 Authentication", RFC 5090, February 2008. 1116 [RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote 1117 Authentication Dial In User Service (RADIUS)", RFC 5176, 1118 January 2008. 1120 [DOCTORS] AAA Doctors Mailing list 1122 [FIPS] FIPS 140-3 (DRAFT), "Security Requirements for Cryptographic 1123 Modules", http://csrc.nist.gov/publications/fips/fips140-3/ 1125 [IEEE-802.1Q] 1126 IEEE Standards for Local and Metropolitan Area Networks: Draft 1127 Standard for Virtual Bridged Local Area Networks, 1128 P802.1Q-2003, January 2003. 1130 [RFC5580] Tschofenig, H. (Ed.), "Carrying Location Objects in RADIUS and 1131 Diameter", RFC 5580, August 2009. 1133 Appendix A - Design Guidelines 1135 The following text provides guidelines for the design of attributes 1136 used by the RADIUS protocol. Specifications that follow these 1137 guidelines are expected to achieve maximum interoperability with 1138 minimal changes to existing systems. 1140 A.1. Types matching the RADIUS data model 1142 A.1.1. Transport of simple data 1144 Does the data fit within the existing RADIUS data model, as outlined 1145 below? If so, it SHOULD be encapsulated in a [RFC2865] format RADIUS 1146 attribute, or in a [RFC2865] format RADIUS VSA that uses one of the 1147 existing RADIUS data types. 1149 * 32-bit unsigned integer, in network byte order. 1150 * Enumerated data types, represented as a 32-bit unsigned integer 1151 with a list of name to value mappings. (e.g., Service-Type) 1152 * 64-bit unsigned integer, in network byte order. 1153 * IPv4 address in network byte order. 1154 * IPv6 address in network byte order. 1155 * IPv6 prefix. 1156 * time as 32 bit unsigned value, in network byte order, and in 1157 seconds since 00:00:00 UTC, January 1, 1970. 1158 * string (i.e., binary data), totalling 253 octets or less in 1159 length. This includes the opaque encapsulation of data 1160 structures defined outside of RADIUS. See also Appendix A.1.2, 1161 below. 1162 * UTF-8 text, totalling 253 octets or less in length. 1163 * Complex data types for authentication and/or security. 1164 These attributes SHOULD be defined only within the RADIUS 1165 attribute space, and SHOULD NOT be defined within the VSA space. 1167 Note that the length limitations for VSAs of type String and Text are 1168 less than 253 octets, due to the additional overhead of the Vendor- 1169 Specific format. 1171 * Attributes grouped into a logical container. 1172 This does not include nested groups. 1173 * Attributes requiring the transport of more than 247 octets of 1174 Text or String data. This includes the opaque encapsulation 1175 of data structures defined outside of RADIUS. See also Section 1176 A.1.2, below. 1178 A.1.2. Opaque data types 1180 Does the attribute encapsulate an existing data structure defined 1181 outside of the RADIUS specifications? Can the attribute be treated 1182 as opaque data by RADIUS servers (including proxies?) If both 1183 questions can be answered affirmatively, a complex structure MAY be 1184 used in a RADIUS specification. 1186 The specification of the attribute SHOULD define the encapsulating 1187 attribute to be of type String. The specification SHOULD refer to an 1188 external document defining the structure. The specification SHOULD 1189 NOT define or describe the structure, as discussed above in Section 1190 2.1.3. 1192 A.2. Improper Data Types 1194 All data types other than the ones described above in Appendix A.1 1195 SHOULD NOT be used. This section describes in detail a number of 1196 data types that are NOT RECOMMENDED in new RADIUS specifications. 1197 Where possible, replacement data types are suggested. 1199 A.2.1. Simple Data Types 1201 Does the attribute use any of the following data types? If so, the 1202 data type SHOULD be replaced with the suggested alternatives, or it 1203 SHOULD NOT be used at all. 1205 * Signed integers of any size. 1206 SHOULD NOT be used. SHOULD be replaced with one or more 1207 unsigned integer attributes. The definition of the attribute 1208 can contain information that would otherwise go into the sign 1209 value of the integer. 1210 * 8 bit unsigned integers. 1211 SHOULD be replaced with 32-bit unsigned integer. There is 1212 insufficient justification to save three bytes. 1213 * 16 bit unsigned integers. 1214 SHOULD be replaced with 32-bit unsigned integer. There is 1215 insufficient justification to save two bytes. 1216 * Unsigned integers of size other than 32 or 64. 1217 SHOULD be replaced by an unsigned integer of 32 or 64 bits. 1218 There is insufficient justification to define a new size of 1219 integer. 1220 * Integers of any size in non-network byte order 1221 SHOULD be replaced by unsigned integer of 32 or 64 bits, 1222 in network byte order. There is no reason to transport integers 1223 in any format other than network byte order. 1224 * Tagged data types as described in [RFC2868]. 1225 These data types SHOULD NOT be used in new specifications. 1226 * Complex data structures defined only within RADIUS. 1227 SHOULD NOT be used. This recommendation does not apply to new 1228 attributes for authentication or security, as described below 1229 in Section A.2.2. 1230 * Multi-field text strings. 1231 Each field SHOULD be encapsulated in a separate attribute. 1232 * Polymorphic attributes. 1233 Multiple attributes, each with a static data type SHOULD be 1234 defined instead. 1235 * Nested AVPs. 1236 Attributes should be defined in a flat typespace, possibly using 1237 a 16-bit Vendor type field (see Section 2.3). 1239 A.2.2. Complex Data Types 1241 Does the attribute define a complex data type for purposes other than 1242 authentication or security? If so, this data type SHOULD be replaced 1243 with simpler types, as discussed above in Appendix A.2.1. Also see 1244 Section 2.1.3 for a discussion of why complex types are problematic. 1246 A.3. Vendor-Specific formats 1248 Does the specification contain Vendor-Specific attributes that match 1249 any of the following criteria? If so, the data type should be 1250 replaced with the suggested alternatives, or should not be used at 1251 all. 1253 * Vendor types of more than 16 bits. 1254 SHOULD NOT be used. Vendor types of 8 or 16 bits SHOULD be used 1255 instead. 1256 * Vendor lengths of less than 8 bits. (i.e., zero bits) 1257 SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used 1258 instead. 1259 * Vendor lengths of more than 8 bits. 1260 SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used 1261 instead. 1262 * Vendor-Specific contents that are not in Type-Length-Value 1263 format. 1264 SHOULD NOT be used. Vendor-Specific attributes SHOULD be in 1265 Type-Length-Value format. 1267 In general, Vendor-Specific attributes SHOULD follow the [RFC2865] 1268 suggested format. However, we recognize that SDOs may require more 1269 than 256 attributes, which is the limit of the 8-bit [RFC2865] 1270 Vendor-Specific space. Those SDOs SHOULD use Vendor types of 16 1271 bits, as described in Section 2.3. However, SDOs SHOULD NOT use 1272 Vendor types of 16 bits unless there are immediate requirements. 1273 Future-proofing a specification is insufficient grounds for using 1274 16-bit Vendor types. 1276 A.4. Changes to the RADIUS Operational Model 1278 Does the specification change the RADIUS operation model, as outlined 1279 in the list below? If so, then another method of achieving the 1280 design objectives SHOULD be used. Potential problem areas include: 1282 * Defining new commands in RADIUS using attributes. 1283 The addition of new commands to RADIUS MUST be handled via 1284 allocation of a new Code, and not by the use of an attribute. 1285 This restriction includes new commands created by overloading 1286 the Service-Type attribute to define new values that modify 1287 the functionality of Access-Request packets. 1288 * Using RADIUS as a transport protocol for data unrelated to 1289 authentication, authorization, or accounting. Using RADIUS to 1290 transport authentication methods such as EAP is explicitly 1291 permitted, even if those methods require the transport of 1292 relatively large amounts of data. Transport of opaque data 1293 relating to AAA is also permitted, as discussed above in 1294 Section 2.1.3. However, if the specification does not relate 1295 to AAA, then RADIUS SHOULD NOT be used. 1296 * Assuming support for packet lengths greater than 4096 octets. 1297 Attribute designers cannot assume that RADIUS implementations 1298 can successfully handle packets larger than 4096 octets. 1299 If a specification could lead to a RADIUS packet larger than 1300 4096 octets, then the alternatives described in Section 3.3 1301 SHOULD be considered. 1302 * Stateless operation. The RADIUS protocol is stateless, and 1303 documents which require stateful protocol behavior without the 1304 use of the State Attribute need to be redesigned. 1305 * Provisioning of service in an Access-Reject. Such provisioning 1306 is not permitted, and MUST NOT be used. If limited access needs 1307 to be provided, then an Access-Accept with appropriate 1308 authorizations can be used instead. 1309 * Lack of user authentication or authorization restrictions. 1310 In an authorization check, where there is no demonstration of a 1311 live user, confidential data cannot be returned. Where there 1312 is a link to a previous user authentication, the State attribute 1313 needs to be present. 1314 * Lack of per-packet integrity and authentication. 1315 It is expected that documents will support per-packet 1316 integrity and authentication. 1317 * Modification of RADIUS packet sequences. 1318 In RADIUS, each request is encapsulated in it's own packet, and 1319 elicits a single response that is sent to the requester. Since 1320 changes to this paradigm are likely to require major 1321 modifications to RADIUS client and server implementations, they 1322 SHOULD be avoided if possible. 1323 For further details, see Section 3.3. 1325 A.5. Allocation of attributes 1327 Does the attribute have a limited scope of applicability, as outlined 1328 below? If so, then the attributes SHOULD be allocated from the 1329 Vendor-Specific space. 1331 * attributes intended for a vendor to support their own systems, 1332 and not suitable for general usage 1333 * attributes relying on data types not defined within RADIUS 1334 * attributes intended primarily for use within an SDO 1335 * attributes intended primarily for use within a group of SDOs. 1337 Note that the points listed above do not relax the recommendations 1338 discussed in this document. Instead, they recognize that the RADIUS 1339 data model has limitations. In certain situations where 1340 interoperability can be strongly constrained by the SDO or vendor, an 1341 expanded data model MAY be used. We recommend, however, that the 1342 RADIUS data model SHOULD be used, even if it is marginally less 1343 efficient than alternatives. 1345 When attributes are used primarily within a group of SDOs, and are 1346 not applicable to the wider Internet community, we expect that one 1347 SDO will be responsible for allocation from their own private space. 1349 Appendix B - Complex Attributes 1351 This section summarizes RADIUS attributes with complex data types 1352 that are defined in existing RFCs. 1354 This appendix is published for informational purposes only, and 1355 reflects the usage of attributes with complex data types at the time 1356 of the publication of this document. 1358 B.1. CHAP-Password 1360 [RFC2865] Section 5.3 defines the CHAP-Password Attribute which is 1361 sent from the RADIUS client to the RADIUS server in an Access- 1362 Request. The data type of the CHAP Identifier is not given, only the 1363 one octet length: 1365 0 1 2 1366 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 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1368 | Type | Length | CHAP Ident | String ... 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1371 Since this is an authentication attribute, code changes are required 1372 on the RADIUS client and server to support it, regardless of the 1373 attribute format. Therefore, this complex data type is acceptable in 1374 this situation. 1376 B.2. CHAP-Challenge 1378 [RFC2865] Section 5.40 defines the CHAP-Challenge Attribute which is 1379 sent from the RADIUS client to the RADIUS server in an Access- 1380 Request. While the data type of the CHAP Identifier is given, the 1381 text also says: 1383 If the CHAP challenge value is 16 octets long it MAY be placed in 1384 the Request Authenticator field instead of using this attribute. 1386 Defining attributes to contain values taken from the RADIUS packet 1387 header is NOT RECOMMENDED. Attributes should have values that are 1388 packed into a RADIUS AVP. 1390 B.3. Tunnel-Password 1392 [RFC2868] Section 3.5 defines the Tunnel-Password Attribute, which is 1393 sent from the RADIUS server to the client in an Access-Accept. This 1394 attribute includes Tag and Salt fields, as well as a string field 1395 which consists of three logical sub-fields: the Data-Length (one 1396 octet) and Password sub-fields (both of which are required), and the 1397 optional Padding sub-field. The attribute appears as follows: 1399 0 1 2 3 1400 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 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 | Type | Length | Tag | Salt 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 Salt (cont) | String ... 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 Since this is a security attribute and is encrypted, code changes are 1408 required on the RADIUS client and server to support it, regardless of 1409 the attribute format. Therefore, this complex data type is 1410 acceptable in this situation. 1412 B.4. ARAP-Password 1414 [RFC2869] Section 5.4 defines the ARAP-Password attribute, which is 1415 sent from the RADIUS client to the server in an Access-Request. It 1416 contains four 4 octet values, instead of having a single Value field: 1418 0 1 2 3 1419 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 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 | Type | Length | Value1 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 | Value2 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 | Value3 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 | Value4 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 | 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 As with the CHAP-Password attribute, this is an authentication 1433 attribute which would have required code changes on the RADIUS client 1434 and server regardless of format. 1436 B.5. ARAP-Features 1438 [RFC2869] Section 5.5 defines the ARAP-Features Attribute, which is 1439 sent from the RADIUS server to the client in an Access-Accept or 1440 Access-Challenge. It contains a compound string of two single octet 1441 values, plus three 4-octet values, which the RADIUS client 1442 encapsulates in a feature flags packet in the ARAP protocol: 1444 0 1 2 3 1445 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 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 | Type | Length | Value1 | Value2 | 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | Value3 | 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | Value4 | 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 | Value5 | 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 Unlike the previous attributes, this attribute contains no encrypted 1457 component, nor is it directly involved in authentication. The 1458 individual sub-fields therefore could have been encapsulated in 1459 separate attributes. 1461 While the contents of this attribute is intended to be placed in an 1462 ARAP packet, the fields need to be set by the RADIUS server. Using 1463 standard RADIUS data types would have simplified RADIUS server 1464 implementations, and subsequent management. The current form of the 1465 attribute requires either the RADIUS server implementation, or the 1466 RADIUS server administrator, to understand the internals of the ARAP 1467 protocol. 1469 B.6. Connect-Info 1471 [RFC2869] Section 5.11 defines the Connect-Info attribute, which is 1472 used to indicate the nature of the connection. 1474 0 1 2 1475 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 | Type | Length | Text... 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 Even though the type is Text, the rest of the description indicates 1481 that it is a complex attribute: 1483 The Text field consists of UTF-8 encoded 10646 _8_ characters. 1484 The connection speed SHOULD be included at the beginning of the 1485 first Connect-Info attribute in the packet. If the transmit and 1486 receive connection speeds differ, they may both be included in the 1487 first attribute with the transmit speed first (the speed the NAS 1488 modem transmits at), a slash (/), the receive speed, then 1489 optionally other information. 1490 For example, "28800 V42BIS/LAPM" or "52000/31200 V90" 1492 More than one Connect-Info attribute may be present in an 1493 Accounting-Request packet to accommodate expected efforts by ITU 1494 to have modems report more connection information in a standard 1495 format that might exceed 252 octets. 1497 This attribute contains no encrypted component, and is it not 1498 directly involved in authentication. The individual sub-fields could 1499 therefore have been encapsulated in separate attributes. 1501 Since the form of the text string is well defined, there is no 1502 benefit in using a text string. Instead, an integer attribute should 1503 have been assigned for each of the transmit speed and the receive 1504 speed. A separate enumerated integer should have been assigned for 1505 the additional information, as is done for the NAS-Port-Type 1506 attribute. 1508 B.7. Framed-IPv6-Prefix 1510 [RFC3162] Section 2.3 defines the Framed-IPv6-Prefix Attribute and 1511 [RFC4818] Section 3 reuses this format for the Delegated-IPv6-Prefix 1512 Attribute; these attributes are sent from the RADIUS server to the 1513 client in an Access-Accept. 1515 0 1 2 3 1516 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 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 | Type | Length | Reserved | Prefix-Length | 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 Prefix 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 Prefix 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 Prefix 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 Prefix | 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 The sub-fields encoded in these attributes are strongly related, and 1530 there was no previous definition of this data structure that could be 1531 referenced. Support for this attribute requires code changes on both 1532 the client and server, due to a new data type being defined. In this 1533 case it appears to be acceptable to encode them in one attribute. 1535 B.8. Egress-VLANID 1537 [RFC4675] Section 2.1 defines the Egress-VLANID Attribute which can 1538 be sent by a RADIUS client or server. 1540 0 1 2 3 1541 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 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 | Type | Length | Value 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 Value (cont) | 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1548 While it appears superficially to be of type Integer, the Value field 1549 is actually a packed structure, as follows: 1551 0 1 2 3 1552 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 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1554 | Tag Indic. | Pad | VLANID | 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 The length of the VLANID field is defined by the [IEEE-802.1Q] 1558 specification. The Tag indicator field is either 0x31 or 0x32, for 1559 compatibility with the Egress-VLAN-Name, as discussed below. The 1560 complex structure of Egress-VLANID overlaps with that of the base 1561 Integer data type, meaning that no code changes are required for a 1562 RADIUS server to support this attribute. Code changes are required 1563 on the NAS, if only to implement the VLAN ID enforcement. 1565 Given the IEEE VLAN requirements and the limited data model of 1566 RADIUS, the chosen method is likely the best of the possible 1567 alternatives. 1569 B.9. Egress-VLAN-Name 1571 [RFC4675] Section 2.3 defines the Egress-VLAN-Name Attribute which 1572 can be sent by a RADIUS client or server. 1574 0 1 2 3 1575 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 1576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1577 | Type | Length | Tag Indic. | String... 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 The Tag Indicator is either the character '1' or '2', which in ASCII 1581 map to the identical values for Tag Indicator in Egress-VLANID, 1582 above. The complex structure of this attribute is acceptable for 1583 reasons identical to those given for Egress-VLANID. 1585 Acknowledgments 1587 We would like to acknowledge David Nelson, Bernard Aboba, Emile van 1588 Bergen, Barney Wolff and Glen Zorn for contributions to this 1589 document. 1591 Authors' Addresses 1593 Greg Weber 1594 Knoxville, TN 37932 1595 USA 1597 Email: gdweber@gmail.com 1599 Alan DeKok 1600 The FreeRADIUS Server Project 1601 http://freeradius.org/ 1603 Email: aland@freeradius.org