idnits 2.17.1 draft-ietf-radext-design-07.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 (5 March 2009) is 5529 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) -- Looks like a reference, but probably isn't: '8' on line 1506 == Outdated reference: A later version (-09) exists of draft-ietf-radext-extended-attributes-05 == Outdated reference: A later version (-24) exists of draft-ietf-geopriv-radius-lo-22 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Weber 3 INTERNET-DRAFT Individual Contributor 4 Category: Best Current Practice Alan DeKok (ed.) 5 FreeRADIUS 6 Expires: September 5, 2009 7 5 March 2009 9 RADIUS Design Guidelines 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. This document may contain material 13 from IETF Documents or IETF Contributions published or made publicly 14 available before November 10, 2008. The person(s) controlling the 15 copyright in some of this material may not have granted the IETF 16 Trust the right to allow modifications of such material outside the 17 IETF Standards Process. Without obtaining an adequate license from 18 the person(s) controlling the copyright in such materials, this 19 document may not be modified outside the IETF Standards Process, and 20 derivative works of it may not be created outside the IETF Standards 21 Process, except to format it for publication as an RFC or to 22 translate it into languages other than English. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on September 5, 2009. 42 Copyright Notice 44 Copyright (c) 2009 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents in effect on the date of 49 publication of this document (http://trustee.ietf.org/license-info). 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. 53 Abstract 55 This document provides guidelines for the design of attributes used 56 by the Remote Authentication Dial In User Service (RADIUS) protocol. 57 It is expected that these guidelines will prove useful to authors and 58 reviewers of future RADIUS attribute specifications, both within the 59 IETF as well as other Standards Development Organizations (SDOs). 61 Table of Contents 63 1. Introduction ............................................. 5 64 1.1. Applicability ....................................... 5 65 1.2. Terminology ......................................... 6 66 1.3. Requirements Language ............................... 7 67 2. RADIUS Data Model ........................................ 7 68 2.1. Standard Space ...................................... 7 69 2.1.1. Basic Data Types ............................... 7 70 2.1.2. Tagging Mechanism .............................. 9 71 2.1.3. Complex Attribute Usage ........................ 9 72 2.1.4. Complex Attributes and Security ................ 12 73 2.1.5. Service definitions and RADIUS ................. 12 74 2.2. Extended RADIUS Attributes .......................... 13 75 2.3. 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 ............................. 18 80 3.1.3. SDO Allocations ................................ 18 81 3.1.4. Publication of specifications .................. 19 82 3.2. Polymorphic Attributes .............................. 19 83 3.3. RADIUS Operational Model ............................ 20 84 4. IANA Considerations ...................................... 22 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. Extended data types ............................. 27 93 A.1.3. Opaque data types ............................... 28 94 A.2. Improper Data Types .................................. 28 95 A.2.1. Simple Data Types ............................... 28 96 A.2.2. Complex Data Types .............................. 29 97 A.3. Vendor-Specific formats .............................. 29 98 A.4. Changes to the RADIUS Operational Model .............. 30 99 A.5. Allocation of attributes ............................. 31 100 Appendix B - Complex Attributes .............................. 32 101 B.1. CHAP-Password ........................................ 32 102 B.2. CHAP-Challenge ....................................... 32 103 B.3. Tunnel-Password ...................................... 32 104 B.4. ARAP-Password ........................................ 33 105 B.5. ARAP-Features ........................................ 33 106 B.6. Connect-Info ......................................... 34 107 B.7. Framed-IPv6-Prefix ................................... 35 108 B.8. Egress-VLANID ........................................ 35 109 B.9. Egress-VLAN-Name ..................................... 36 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. As a result, 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. Applicability 139 As RADIUS has become more widely accepted as a management protocol, 140 its usage has become more prevalent, both within the IETF as well as 141 within other SDOs. Given the expanded utilization of RADIUS, it has 142 become apparent that requiring SDOs to accomplish all their RADIUS 143 work within the IETF is inherently inefficient and unscalable. By 144 articulating guidelines for RADIUS attribute design, this document 145 enables SDOs out of the IETF to design their own RADIUS attributes 146 within the Vendor-Specific Attribute (VSA) space. 148 It is RECOMMENDED that SDOs follow the guidelines articulated in this 149 document. Doing so will ensure the widest possible applicability and 150 interoperability of the specifications, while requiring minimal 151 changes to existing systems. Specifications that do not follow the 152 guidelines articulated herein or in [EXTEN] are NOT RECOMMENDED. 153 However, we recognize that there are some situations where SDOs or 154 vendors require the creation of specifications not following these 155 guidelines. We do not forbid these specifications, but it is 156 RECOMMENDED that they are created only if they have a limited scope 157 of applicability, and all attributes defined in those specifications 158 are VSAs, as discussed Section A.5, below. 160 It is RECOMMENDED that SDOs and vendors seek review of RADIUS 161 attribute specifications from the IETF. However, when specifications 162 are SDO specific, re-use existing data types, and follow these 163 guidelines, they do not require IETF review. 165 In order to enable IETF review of such specifications, the authors 166 recommend that: 168 * SDOs make their RADIUS attribute specifications publicly 169 available; 171 * SDOs request review of RADIUS attribute specifications by 172 sending email to the AAA Doctors [DOCTORS] or equivalent mailing 173 list; 175 * IETF and SDO RADIUS attribute specifications are reviewed 176 according to the guidelines proposed in this document; 178 * Reviews of specifications are posted to the RADEXT WG mailing 179 list, the AAA Doctors mailing list [DOCTORS] or another IETF 180 mailing list suggested by the Operations & Management Area 181 Directors of the IETF. 183 These reviews can assist with creation of specifications that meet 184 the SDO requirements, and which are also compatible with the 185 traditional data model and uses of RADIUS. While these reviews 186 require access to public specifications, the review process does not 187 require publication of an IETF RFC. 189 The advice in this document applies to attributes used to encode 190 service-provisioning or authentication data. RADIUS protocol 191 changes, or specification of attributes (such as Service-Type) that 192 can be used to, in effect, provide new RADIUS commands require 193 greater expertise and deeper review, as do changes to the RADIUS 194 operational model, as described in Section 3.3. Such changes MUST 195 NOT be undertaken outside the IETF and when handled within the IETF 196 require "IETF Consensus" for adoption, as noted in [RFC3575] Section 197 2.1. 199 1.2. Terminology 201 This document uses the following terms: 203 Network Access Server (NAS) 204 A device that provides an access service for a user to a network. 206 RADIUS server 207 A RADIUS authentication, authorization, and/or accounting (AAA) 208 server is an entity that provides one or more AAA services to a 209 NAS. 211 RADIUS proxy 212 A RADIUS proxy acts as a RADIUS server to the NAS, and a RADIUS 213 client to the RADIUS server. 215 1.3. Requirements Language 217 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 218 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 219 document are to be interpreted as described in [RFC2119]. 221 2. RADIUS Data Model 223 The Remote Authentication Dial In User Service (RADIUS) defined in 224 [RFC2865] and [RFC2866] uses elements known as attributes in order to 225 represent authentication, authorization and accounting data. 227 Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does 228 not define a formal data definition language. A handful of basic 229 data types are provided, and a data type is associated with an 230 attribute when the attribute is defined. 232 Two distinct attribute spaces are defined: the standard space, and a 233 Vendor-Specific space. Attributes in the standard space generally 234 are composed of a type, length, value (TLV) triplet, although complex 235 attributes have also been defined. The Vendor-Specific space is 236 encapsulated within a single attribute type (Vendor-Specific 237 Attribute). The format of this space is defined by individual 238 vendors, but the same TLV encoding used by the standard space is 239 recommended in [RFC2865] Section 5.26. The similarity between 240 attribute formats has enabled implementations to leverage common 241 parsing functionality, although in some cases the attributes in the 242 Vendor-Specific space have begun to diverge from the common format. 244 2.1. Standard Space 246 The following subsections describe common data types and formats 247 within the RADIUS standard attribute space. Common exceptions are 248 identified. 250 2.1.1. Basic Data Types 252 The data type of RADIUS attributes is not transported on the wire. 253 Rather, the data type of a RADIUS attribute is fixed when that 254 attribute is defined. Based on the RADIUS attribute type code, 255 RADIUS clients and servers can determine the data type based on pre- 256 configured entries within a data dictionary. 258 [RFC2865] defines the following data types: 260 text 1-253 octets containing UTF-8 encoded 10646 [RFC3629] 261 characters. Text of length zero (0) MUST NOT be sent; 262 omit the entire attribute instead. 263 string 1-253 octets containing binary data (values 0 through 264 255 decimal, inclusive). Strings of length zero (0) 265 MUST NOT be sent; omit the entire attribute instead. 266 IPv4 address 32 bit value, in network byte order. 267 integer 32 bit unsigned value, most significant octet first. 268 time 32 bit unsigned value, most significant octet first 269 -- seconds since 00:00:00 UTC, January 1, 1970. 271 In addition to these data types, follow-on RADIUS specifications 272 define attributes using the following additional types: 274 IPv6 address 128 bit value, most significant octet first. 275 IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to 276 128 bits of value, in network byte order. 277 integer64 64 bit unsigned value, most significant octet first. 278 This type has also been used to represent an IPv6 279 interface identifier. 281 Examples of the IPv6 address type include NAS-IPv6-Address defined in 282 [RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162] 283 Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3, 284 and in [RFC4818] Section 3. The integer64 type is used for the ARAP- 285 Challenge-Response Attribute defined in [RFC2869] Section 5.15, and 286 the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2. 287 [RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in 288 length, but denotes it as type String. 290 Given that attributes of type IPv6 address, IPv6 prefix, and 291 integer64 are already in use, it is RECOMMENDED that RADIUS server 292 implementations include support for these additional basic types, in 293 addition to the types defined in [RFC2865]. 295 Where the intent is to represent a specific IPv6 address, the IPv6 296 address type SHOULD be used. Although it is possible to use the IPv6 297 IPv6 Prefix type with a prefix length of 128 to represent an IPv6 298 address, this usage is NOT RECOMMENDED. 300 It is worth noting that since RADIUS only supports unsigned integers 301 of 32 or 64 bits, attributes using signed integer data types or 302 unsigned integer types of other sizes will require code changes, and 303 SHOULD be avoided. 305 For [RFC2865] RADIUS VSAs, the length limitation of the String and 306 Text types is 247 octets instead of 253 octets, due to the additional 307 overhead of the Vendor-Specific Attribute. 309 2.1.2. Tagging Mechanism 311 [RFC2868] defines an attribute grouping mechanism based on the use of 312 a one octet tag value. Tunnel attributes that refer to the same 313 tunnel are grouped together by virtue of using the same tag value. 315 This tagging mechanism has some drawbacks. There are a limited 316 number of unique tags (31). The tags are not well suited for use 317 with arbitrary binary data values, because it is not always possible 318 to tell if the first byte after the Length is the tag or the first 319 byte of the untagged value (assuming the tag is optional). 321 Other limitations of the tagging mechanism are that when integer 322 values are tagged, the value portion is reduced to three bytes 323 meaning only 24-bit numbers can be represented. The tagging 324 mechanism does not offer an ability to create nested groups of 325 attributes. Some RADIUS implementations treat tagged attributes as 326 having additional data types tagged-string and tagged-integer. These 327 types increase the complexity of implementing and managing RADIUS 328 systems. 330 New attributes SHOULD NOT use this tagging method because of the 331 limitations described above. New attributes SHOULD use the grouping 332 method described in [EXTEN]. 334 2.1.3. Complex Attribute Usage 336 The RADIUS attribute encoding is summarized in [RFC2865]: 338 0 1 2 339 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 341 | Type | Length | Value ... 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 344 However, some standard attributes do not follow this format. 345 Attributes that use sub-fields instead of using a basic data type are 346 known as "complex attributes". As described below, the definition of 347 complex attributes can lead to interoperability and deployment 348 issues, so they need to be introduced with care. 350 In general, complex attributes sent from the RADIUS server to the 351 client can be supported by concatenating the values into a String 352 data type field. However, separating these values into different 353 attributes, each with its own type and length, would have the 354 following benefits: 356 * it is easier for the user to enter the data as well-known 357 types, rather than complex structures; 358 * it enables additional error checking by leveraging the 359 parsing and validation routines for well-known types; 360 * it simplifies implementations by eliminating special-case 361 attribute-specific parsing. 363 One of the fundamental goals of the RADIUS protocol design was to 364 allow RADIUS servers to be configured to support new attributes 365 without requiring server code changes. RADIUS server implementations 366 typically provide support for basic data types, and define attributes 367 in a data dictionary. This architecture enables a new attribute to 368 be supported by the addition of a dictionary entry, without requiring 369 RADIUS server code changes. 371 On the RADIUS client, code changes are typically required in order to 372 implement a new attribute. The RADIUS client typically has to 373 compose the attribute dynamically when sending. When receiving, a 374 RADIUS client needs to be able to parse the attribute and carry out 375 the requested service. As a result, a detailed understanding of the 376 new attribute is required on clients, and data dictionaries are less 377 useful on clients than on servers. 379 Given these considerations, the introduction of a new basic or 380 complex attribute will typically require code changes on the RADIUS 381 client. The magnitude of changes for the complex attribute could be 382 greater, due to the potential need for custom parsing logic. 384 The RADIUS server can be configured to send a new static attribute by 385 entering its type and data format in the RADIUS server dictionary, 386 and then filling in the value within a policy based on the attribute 387 name, data type and type-specific value. For complex attribute types 388 not supported by RADIUS server dictionaries, changes to the 389 dictionary code can be required in order to allow the new attribute 390 to be supported by and configured on the RADIUS server. 392 Code changes can also be required in policy management and in the 393 RADIUS server's receive path. These changes are due to limitations 394 in RADIUS server policy languages, which typically only provide for 395 limited operations (such as comparisons or arithmetic operations) on 396 the basic data types. Many existing RADIUS policy languages 397 typically are not capable of parsing sub-elements, or providing 398 sophisticated matching functionality. 400 Given these limitations, the introduction of complex attributes can 401 require code changes on the RADIUS server which would be unnecessary 402 if basic data types had been used instead. In addition, attribute- 403 specific parsing means more complex software to develop and maintain. 404 More complexity can lead to more error prone implementations, 405 interoperability problems, and even security vulnerabilities. These 406 issues can increase costs to network administrators as well as 407 reducing reliability and introducing deployment barriers. As a 408 result, the introduction of new complex data types within RADIUS 409 attribute specifications SHOULD be avoided, except in the case of 410 complex attributes involving authentication or security 411 functionality. 413 As can be seen in Appendix B, most of the existing complex attributes 414 involve authentication or security functionality. Supporting this 415 functionality requires code changes on both the RADIUS client and 416 server, regardless of the attribute format. As a result, in most 417 cases, the use of complex attributes to represent these methods is 418 acceptable, and does not create additional interoperability or 419 deployment issues. 421 The only other exception to the recommendation against complex types 422 is for types that can be treated as opaque data by the RADIUS server. 423 For example, the EAP-Message attribute, defined in [RFC3579] Section 424 3.1 contains a complex data type that is an EAP packet. Since these 425 complex types do not need to be parsed by the RADIUS server, the 426 issues arising from policy language limitations do not arise. 427 Similarly, since attributes of these complex types can be configured 428 on the server using a data type of String, dictionary limitations are 429 also not encountered. Section A.1 below includes a series of 430 checklists that may be used to analyze a design for RECOMMENDED and 431 NOT RECOMMENDED behavior in relation to complex types. 433 If the RADIUS Server simply passes the contents of an attribute to 434 some non-RADIUS portion of the network, then the data is opaque, and 435 SHOULD be defined to be of type String. A concrete way of judging 436 this requirement is whether or not the attribute definition in the 437 RADIUS document contains delineated fields for sub-parts of the data. 438 If those fields need to be delineated in RADIUS, then the data is not 439 opaque, and it SHOULD be separated into individual RADIUS attributes. 441 An examination of existing RADIUS RFCs discloses a number of complex 442 attributes that have already been defined. Appendix B includes a 443 listing of complex attributes used within [RFC2865], [RFC2868], 444 [RFC2869], [RFC3162], [RFC4818], and [RFC4675]. The discussion of 445 these attributes includes reasons why a complex type is acceptable, 446 or suggestions for how the attribute could have been defined to 447 follow the RADIUS data model. 449 In other cases, the data in the complex type are described textually. 450 This is possible because the data types are not sent within the 451 attributes, but are a matter for endpoint interpretation. An 452 implementation can define additional data types, and use these data 453 types today by matching them to the attribute's textual description. 455 2.1.4. Complex Attributes and Security 457 The introduction of complex data types brings the potential for the 458 introduction of new security vulnerabilities. Experience shows that 459 the common data types have few security vulnerabilities, or else that 460 all known issues have been found and fixed. New data types require 461 new code, which may introduce new bugs, and therefore new attack 462 vectors. 464 RADIUS servers are highly valued targets, as they control network 465 access and interact with databases that store usernames and 466 passwords. An extreme outcome of a vulnerability due to a new, 467 complex type would be that an attacker is capable of taking complete 468 control over the RADIUS server. 470 The use of attributes representing opaque data does not reduce this 471 threat. The threat merely moves from the RADIUS server to the 472 application that consumes that opaque data. 474 The threat is particularly severe when the opaque data originates 475 from the user, and is not validated by the NAS. In those cases, the 476 RADIUS server is potentially exposed to attack by malware residing on 477 an unauthenticated host. Applications consuming opaque data that 478 reside on the RADIUS server SHOULD be properly isolated from the 479 RADIUS server, and SHOULD run with minimal privileges. Any potential 480 vulnerabilities in that application will then have minimal impact on 481 the security of the system as a whole. 483 2.1.5. Service definitions and RADIUS 485 RADIUS specifications define how an existing service or protocol can 486 be provisioned using RADIUS. Therefore, it is expected that a RADIUS 487 attribute specification will reference documents defining the 488 protocol or service to be provisioned. Within the IETF, a RADIUS 489 attribute specification SHOULD NOT be used to define the protocol or 490 service being provisioned. New services using RADIUS for 491 provisioning SHOULD be defined elsewhere and referenced in the RADIUS 492 specification. 494 New attributes, or new values of existing attributes, SHOULD NOT be 495 used to define new RADIUS commands. RADIUS attributes are intended 496 to: 498 * authenticate users 499 * authorize users (i.e., service provisioning or changes to 500 provisioning) 501 * account for user activity (i.e., logging of session activity) 503 New commands (i.e., the Code field in the packet header) are 504 allocated only through "IETF Consensus" as noted in [RFC3575] Section 505 2.1. Specifications also SHOULD NOT use new attributes to modify the 506 interpretation of existing RADIUS commands. 508 2.2. Extended RADIUS Attributes 510 The extended RADIUS attribute document [EXTEN] defines a number of 511 extensions to RADIUS. The standard attribute space is extended by 512 permitting standard allocations from within a specific subset of the 513 VSA space; the format of extended attributes is defined; and extended 514 data types are defined within that format. 516 New specifications seeking to extend the standard RADIUS data model 517 SHOULD examine [EXTEN] to see if their needs fit within the extended 518 RADIUS data model. 520 2.3. Vendor Space 522 As noted in [RFC2865] Section 5.26, the VSA format is defined as 523 follows: 525 0 1 2 3 526 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 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Type | Length | Vendor-Id 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 Vendor-Id (cont) | String... 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 533 The high-order octet of the Vendor-Id field is 0 and the low-order 3 534 octets are the Structure of Management Information (SMI) Network 535 Management Private Enterprise Code (PEC) of the Vendor in network 536 byte order. 538 While the format of the String field is defined by the vendor, 539 [RFC2865] Section 5.26 notes: 541 It SHOULD be encoded as a sequence of vendor type / vendor length 542 / value fields, as follows. The Attribute-Specific field is 543 dependent on the vendor's definition of that attribute. An 544 example encoding of the Vendor-Specific attribute using this 545 method follows: 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Type | Length | Vendor-Id 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 Vendor-Id (cont) | Vendor type | Vendor length | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Attribute-Specific... 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 557 Multiple sub-attributes MAY be encoded within a single Vendor- 558 Specific attribute, although they do not have to be. 560 Note that the Vendor type field in the recommended VSA format is only 561 a single octet, like the RADIUS type field. While this limitation 562 results in an efficient encoding, there are situations in which a 563 vendor or SDO will eventually wish to define more than 255 564 attributes. Also, an SDO can be comprised of multiple subgroups, 565 each of whom can desire autonomy over the definition of attributes 566 within their group. In such a situation, a 16-bit Vendor type field 567 would be more appropriate: 569 0 1 2 3 570 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 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Type | Length | Vendor-Id 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 Vendor-Id (cont) | Vendor type | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Vendor length | Attribute-Specific... 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 If additional functionality is required, the format defined in 580 [EXTEN] SHOULD be used, with a non-zero Vendor-Id field. 582 Other attribute formats are NOT RECOMMENDED. Examples of NOT 583 RECOMMENDED formats include Vendor types of more than 16 bits, Vendor 584 lengths of less than 8 bits, Vendor lengths of more than 8 bits, and 585 Vendor-Specific contents that are not in Type-Length-Value format. 587 In order to be compatible with the above recommendations for 588 attribute definitions, it is RECOMMENDED that RADIUS servers support 589 attributes using a 16-bit Vendor type field. 591 3. Data Model Issues 593 Since the closure of the RADIUS Working Group, the popularity and 594 prevalence of RADIUS has continued to grow. In addition to 595 increasing demand for allocation of attributes within the RADIUS 596 standard attribute space, the number of vendors and SDOs creating new 597 attributes within the Vendor-Specific attribute space has grown, and 598 this has lead to some divergence in approaches to RADIUS attribute 599 design. 601 In general, standard RADIUS attributes have a more constrained data 602 model than attributes within the vendor space. For example, vendors 603 and SDOs have evolved the data model to support new functions such as 604 attribute grouping and attribute fragmentation, with different groups 605 taking different approaches. 607 Given these enhancements, it has become difficult for vendors or SDOs 608 to translate attributes from the vendor space to the more stringent 609 standards space. For example, a Vendor-Specific attribute using sub- 610 elements could require allocation of several standard space 611 attributes using basic data types. In this case not only would 612 translation require substantial additional work, it would further 613 deplete the RADIUS standard attribute space. Given these 614 limitations, translation of vendor attributes to the standards space 615 is not necessarily desirable, particularly if the VSA specification 616 is publicly available and can be implemented within existing RADIUS 617 clients and servers. In such situations, the costs may substantially 618 outweigh the benefits. It is possible that some of the enhancements 619 made within the vendor space may eventually become available within 620 the standard attribute space. However, the divergence of the 621 standard and vendor attribute spaces is most likely a permanent 622 feature, and should be recognized as such. 624 Recent extensions to the RADIUS data model such as [EXTEN] make it 625 possible to minimize the use of complex attributes. New 626 specifications seeking to extend the standard RADIUS data model 627 SHOULD examine [EXTEN] to see if their needs fit within the extended 628 RADIUS data model. 630 3.1. Vendor Space 632 The usage model for RADIUS VSAs is described in [RFC2865] Section 633 6.2: 635 Note that RADIUS defines a mechanism for Vendor-Specific 636 extensions (Attribute 26) and the use of that should be encouraged 637 instead of allocation of global attribute types, for functions 638 specific only to one vendor's implementation of RADIUS, where no 639 interoperability is deemed useful. 641 Nevertheless, many new attributes have been defined in the vendor 642 specific space in situations where interoperability is not only 643 useful, but is required. For example, SDOs outside the IETF (such as 644 the IEEE 802 and the 3rd Generation Partnership Project (3GPP)) have 645 been assigned Vendor-Ids, enabling them to define their own VSA 646 format and assign Vendor types within their own space. 648 The use of VSAs by SDOs outside the IETF has gained in popularity for 649 several reasons: 651 Efficiency 652 As with SNMP, which defines an "Enterprise" Object Identifier (OID) 653 space suitable for use by vendors as well as other SDOs, the 654 definition of Vendor-Specific RADIUS attributes has become a common 655 occurrence as part of standards activity outside the IETF. For 656 reasons of efficiency, it is easiest if the RADIUS attributes 657 required to manage a standard are developed within the same SDO 658 that develops the standard itself. As noted in "Transferring MIB 659 Work from IETF Bridge MIB WG to IEEE 802.1 WG" [RFC4663], today few 660 vendors are willing to simultaneously fund individuals to 661 participate within an SDO to complete a standard, as well as to 662 participate in the IETF in order to complete the associated RADIUS 663 attributes specification. 665 Attribute scarcity 666 The standard RADIUS attribute space is limited to 255 unique 667 attributes. Of these, only about half remain available for 668 allocation. In the Vendor-Specific space, the number of attributes 669 available is a function of the format of the attribute (the size of 670 the Vendor type field). 672 Along with these advantages, some limitations of VSA usage are noted 673 in [RFC2865] Section 5.26: 675 This Attribute is available to allow vendors to support their own 676 extended Attributes not suitable for general usage. It MUST NOT 677 affect the operation of the RADIUS protocol. 679 Servers not equipped to interpret the vendor-specific information 680 sent by a client MUST ignore it (although it may be reported). 681 Clients which do not receive desired vendor-specific information 682 SHOULD make an attempt to operate without it, although they may do 683 so (and report they are doing so) in a degraded mode. 685 The limitation on changes to the RADIUS protocol effectively 686 prohibits VSAs from changing fundamental aspects of RADIUS operation, 687 such as modifying RADIUS packet sequences, or adding new commands. 688 However, the requirement for clients and servers to be able to 689 operate in the absence of VSAs has proven to be less of a constraint, 690 since it is still possible for a RADIUS client and server to mutually 691 indicate support for VSAs, after which behavior expectations can be 692 reset. 694 Therefore, RFC 2865 provides considerable latitude for development of 695 new attributes within the vendor space, while prohibiting development 696 of protocol variants. This flexibility implies that RADIUS 697 attributes can often be developed within the vendor space without 698 loss (and possibly even with gain) in functionality. 700 As a result, translation of RADIUS attributes developed within the 701 vendor space into the standard space may provide only modest 702 benefits, while accelerating the exhaustion of the standard attribute 703 space. We do not expect that all RADIUS attribute specifications 704 requiring interoperability will be developed within the IETF, and 705 allocated from the standards space. A more scalable approach is to 706 recognize the flexibility of the vendor space, while working toward 707 improvements in the quality and availability of RADIUS attribute 708 specifications, regardless of where they are developed. 710 3.1.1. Interoperability Considerations 712 Vendors and SDOs are reminded that the standard RADIUS attribute 713 space, and the enumerated value space for enumerated attributes, are 714 reserved for allocation through work published via the IETF, as noted 715 in [RFC3575] Section 2.1. Some vendors and SDOs have in the past 716 performed self-allocation by assigning vendor-specific meaning to 717 "unused" values from the standard RADIUS attribute ID or enumerated 718 value space. This self-allocation results in interoperability 719 issues, and is counter-productive. Similarly, the Vendor-Specific 720 enumeration practice discussed in [RFC2882] Section 2.2.1 is NOT 721 RECOMMENDED. 723 If it is not possible to follow the above procedure, vendors and SDOs 724 SHOULD self-allocate an attribute from their Vendor-Specific space, 725 and define an appropriate value for it. 727 As a side note, [RFC2865] Section 5.26 uses the term "Vendor-Specific 728 Attribute" to refer to an encoding format which can be used by 729 individual vendors to define attributes not suitable for general 730 usage. However, since then VSAs have also become widely used by SDOs 731 defining attributes intended for multi-vendor interoperability. As 732 such, these attributes are not specific to any single vendor, and the 733 term "Vendor-Specific" may be misleading. An alternate term which 734 better describes this use case is SDO-Specific Attribute (SSA). 736 The design and specification of VSAs for multi-vendor usage SHOULD be 737 undertaken with the same level of care as standard RADIUS attributes. 738 Specifically, the provisions of this document that apply to standard 739 RADIUS attributes also apply to SSAs or VSAs for multi-vendor usage. 741 3.1.2. Vendor Allocations 743 Vendor RADIUS Attribute specifications SHOULD allocate attributes 744 from the vendor space, rather than requesting an allocation from the 745 RADIUS standard attribute space. 747 As discussed in [RFC2865] Section 5.26, the vendor space is intended 748 for vendors to support their own Attributes not suitable for general 749 use. However, it is RECOMMENDED that vendors follow the guidelines 750 outlined here, which are intended to enable maximum interoperability 751 with minimal changes to existing systems. 753 Following these guidelines means that RADIUS servers can be updated 754 to support the vendor's equipment by editing a RADIUS dictionary. If 755 these guidelines are not followed, then the vendor's equipment can 756 only be supported via code changes in RADIUS server implementations. 757 Such code changes add complexity and delay to implementations. 759 3.1.3. SDO Allocations 761 SDO RADIUS Attribute specifications SHOULD allocate attributes from 762 the vendor space, rather than requesting an allocation from the 763 RADIUS standard attribute space, for attributes matching any of the 764 following criteria: 766 * attributes relying on data types not defined within RADIUS 767 * attributes intended primarily for use within an SDO 768 * attributes intended primarily for use within a group of SDOs. 770 Any new RADIUS attributes or values intended for interoperable use 771 across a broad spectrum of the Internet Community SHOULD follow the 772 normal IETF process, and SHOULD result in allocations from the RADIUS 773 standard space. 775 The recommendation for SDOs to allocate attributes from a vendor 776 space rather than via the IETF process is a recognition that SDOs may 777 desire to assert change control over their own RADIUS specifications. 778 This change control can be obtained by requesting a PEC from the 779 Internet Assigned Number Authority (IANA), for use as a Vendor-Id 780 within a Vendor-Specific attribute. Further allocation of attributes 781 inside of the VSA space defined by that Vendor-Id is subject solely 782 to the discretion of the SDO. Similarly, the use of data types 783 (complex or not) within that VSA space is solely under the discretion 784 of the SDO. It is RECOMMENDED that SDOs follow the guidelines 785 outlined here, which are intended to enable maximum interoperability 786 with minimal changes to existing systems. 788 It should be understood that SDOs do not have to rehost VSAs into the 789 standards space solely for the purpose of obtaining IETF review. 790 Rehosting puts pressure on the standards space, and may be harmful to 791 interoperability, since it can create two ways to provision the same 792 service. Rehosting may also require changes to the RADIUS data model 793 which will affect implementations that do not intend to support the 794 SDO specifications. 796 3.1.4. Publication of specifications 798 SDOs are encouraged to seek early review of SSA specifications by the 799 IETF. This review may be initiated by sending mail to the AAA 800 Doctors list [DOCTORS], with the understanding that this review is a 801 voluntary-based service offered on best-effort basis. Since the IETF 802 is not a membership organization, in order to enable the RADIUS SSA 803 specification to be reviewed, it is RECOMMENDED that it be made 804 publicly available; this also encourages interoperability. Where the 805 RADIUS SSA specification is embedded within a larger document which 806 cannot be made public, the RADIUS attribute and value definitions 807 SHOULD be published instead as an Informational RFC, as with 808 [RFC4679]. This process SHOULD be followed instead of requesting 809 IANA allocations from within the standard RADIUS attribute space. 811 Similarly, vendors are encouraged to make their specifications 812 publicly available, for maximum interoperability. However, it is not 813 necessary for them to request publication of their VSA specifications 814 as Informational RFCs by the IETF. 816 All other specifications, including new authentication, 817 authorization, and/or security mechanisms SHOULD be allocated via the 818 standard RADIUS space, as noted in [RFC3575] Section 2.1. 820 3.2. Polymorphic Attributes 822 A polymorphic attribute is one whose format or meaning is dynamic. 823 For example, rather than using a fixed data format, an attribute's 824 format might change based on the contents of another attribute. Or, 825 the meaning of an attribute may depend on earlier packets in a 826 sequence. 828 RADIUS server dictionary entries are typically static, enabling the 829 user to enter the contents of an attribute without support for 830 changing the format based on dynamic conditions. However, this 831 limitation on static types does not prevent implementations from 832 implementing policies that return different attributes based on the 833 contents of received attributes; this is a common feature of existing 834 RADIUS implementations. 836 In general, polymorphism is NOT RECOMMENDED. Polymorphism rarely 837 enables capabilities that would not be available through use of 838 multiple attributes. Polymorphism requires code changes in the 839 RADIUS server in situations where attributes with fixed formats would 840 not require such changes. Thus, polymorphism increases complexity 841 while decreasing generality, without delivering any corresponding 842 benefits. 844 Note that changing an attribute's format dynamically is not the same 845 thing as using a fixed format and computing the attribute itself 846 dynamically. RADIUS authentication attributes such as User-Password, 847 EAP-Message, etc. while being computed dynamically, use a fixed 848 format. 850 3.3. RADIUS Operational Model 852 The RADIUS operational model includes several assumptions: 854 * The RADIUS protocol is stateless; 855 * Provisioning of services is not possible within an 856 Access-Reject; 857 * Distinction between authorization checks and user 858 authentication; 859 * Authentication and integrity protection of RADIUS packets; 860 * The RADIUS protocol is a Request/Response protocol. 861 * Packet length restriction. 863 While RADIUS server implementations may keep state, the RADIUS 864 protocol is stateless, although information may be passed from one 865 protocol transaction to another via the State Attribute. As a 866 result, documents which require stateful protocol behavior without 867 use of the State Attribute are inherently incompatible with RADIUS as 868 defined in [RFC2865], and need to be redesigned. See [RFC5080] 869 Section 2.1.1 for a more in-depth discussion of the use of the State 870 Attribute. 872 As noted in [RFC5080] Section 2.6, the intent of an Access-Reject is 873 to deny access to the requested service. As a result, RADIUS does 874 not allow the provisioning of services within an Access-Reject. 875 Documents which include provisioning of services within an Access- 876 Reject are inherently incompatible with RADIUS, and need to be 877 redesigned. 879 As noted in [RFC5080] Section 2.1.1, a RADIUS Access-Request may not 880 contain user authentication attributes or a State Attribute linking 881 the Access-Request to an earlier user authentication. Such an 882 Access-Request, known as an authorization check, provides no 883 assurance that it corresponds to a live user. RADIUS specifications 884 defining attributes containing confidential information (such as 885 Tunnel-Password) should be careful to prohibit such attributes from 886 being returned in response to an authorization check. Also, 887 [RFC5080] Section 2.1.1 notes that authentication mechanisms need to 888 tie a sequence of Access-Request/Access-Challenge packets together 889 into one authentication session. The State Attribute is RECOMMENDED 890 for this purpose. 892 While [RFC2865] did not require authentication and integrity 893 protection of RADIUS Access-Request packets, subsequent 894 authentication mechanism specifications such as RADIUS/EAP [RFC3579] 895 and Digest Authentication [RFC5090] have mandated authentication and 896 integrity protection for certain RADIUS packets. [RFC5080] Section 897 2.1.1 makes this behavior RECOMMENDED for all Access-Request packets, 898 including Access-Request packets performing authorization checks. It 899 is expected that specifications for new RADIUS authentication 900 mechanisms will continue this practice. 902 The RADIUS protocol as defined in [RFC2865] is a request-response 903 protocol spoken between RADIUS clients and servers. A single RADIUS 904 Access-Request packet will solicit in response at most a single 905 Access-Accept, Access-Reject or Access-Challenge packet, sent to the 906 IP address and port of the RADIUS Client that originated the Access- 907 Request. Similarly, a single Change-of-Authorization (CoA)-Request 908 packet [RFC5176] will solicit in response at most a single CoA-ACK or 909 CoA-NAK packet, sent to the IP address and port of the Dynamic 910 Authorization Client (DAC) that originated the CoA-Request. A single 911 Disconnect-Request packet will solicit in response at most a single 912 Disconnect-ACK or Disconnect-NAK packet, sent to the IP address and 913 port of the Dynamic Authorization Client (DAC) that originated the 914 Disconnect-Request. Changes to this model are likely to require 915 major revisions to existing implementations and so this practice is 916 NOT RECOMMENDED. 918 The Length field in the RADIUS packet header is defined in [RFC2865] 919 Section 3. It is noted there that the maximum length of a RADIUS 920 packet is 4096 octets. As a result, attribute designers SHOULD NOT 921 assume that a RADIUS implementation can successfully process RADIUS 922 packets larger than 4096 octets. If a situation is envisaged where 923 it may be necessary to carry authentication, authorization or 924 accounting data in a packet larger than 4096 octets, then one of the 925 following approaches is RECOMMENDED: 927 1. Utilization of a sequence of packets. 928 For RADIUS authentication, a sequence of Access-Request/ Access- 929 Challenge packets would be used. For this to be feasible, 930 attribute designers need to enable inclusion of attributes that 931 can consume considerable space within Access-Challenge packets. 933 To maintain compatibility with existing NASes, either the use of 934 Access-Challenge packets needs to be permissible (as with 935 RADIUS/EAP, defined in [RFC3579]), or support for receipt of an 936 Access-Challenge needs to be indicated by the NAS (as in RADIUS 937 Location [RADIUSLOC]). Also, the specification needs to clearly 938 describe how attribute splitting is to be signalled and how 939 attributes included within the sequence are to be interpreted, 940 without requiring stateful operation. Unfortunately, previous 941 specifications have not always exhibited the required foresight. 942 For example, even though very large filter rules are 943 conceivable, the NAS-Filter-Rule Attribute defined in [RFC4849] 944 is not permitted in an Access-Challenge packet, nor is a 945 mechanism specified to allow a set of NAS-Filter-Rule attributes 946 to be split across an Access-Request/Access-Challenge sequence. 948 In the case of RADIUS accounting, transporting large amounts of 949 data would require a sequence of Accounting-Request packets. 950 This is a non-trivial change to RADIUS, since RADIUS accounting 951 clients would need to be modified to split the attribute stream 952 across multiple Accounting-Requests, and billing servers would 953 need to be modified to re-assemble and interpret the attribute 954 stream. 956 2. Utilization of names rather than values. 957 Where an attribute relates to a policy that could conceivably be 958 pre-provisioned on the NAS, then the name of the pre-provisioned 959 policy can be transmitted in an attribute, rather than the 960 policy itself, which could be quite large. An example of this 961 is the Filter-Id Attribute defined in [RFC2865] Section 5.11, 962 which enables a set of pre-provisioned filter rules to be 963 referenced by name. 965 3. Utilization of Packetization Layer Path MTU Discovery 966 techniques, as specified in [RFC4821]. As a last resort, where 967 the above techniques cannot be made to work, it may be possible 968 to apply the techniques described in [RFC4821] to discover the 969 maximum supported RADIUS packet size on the path between a 970 RADIUS client and a home server. While such an approach can 971 avoid the complexity of utilization of a sequence of packets, 972 dynamic discovery is likely to be time consuming and cannot be 973 guaranteed to work with existing RADIUS implementations. As a 974 result, this technique is not generally applicable. 976 4. IANA Considerations 978 This document does not require that the IANA update any existing 979 registry or create any new registry, but includes information that 980 affects the IANA, for example: 982 * includes guidelines that recommend against allocation from the 983 RADIUS standard attribute space in other SDO RADIUS Attribute 984 specifications. 985 * recommends that SDOs request a Private Enterprise Code (PEC) 986 from the IANA, for use as a Vendor-Id within a Vendor-Specific 987 attribute. 989 5. Security Considerations 991 This specification provides guidelines for the design of RADIUS 992 attributes used in authentication, authorization and accounting. 993 Threats and security issues for this application are described in 994 [RFC3579] and [RFC3580]; security issues encountered in roaming are 995 described in [RFC2607]. 997 Obfuscation of RADIUS attributes on a per-attribute basis is 998 necessary in some cases. The current standard mechanism for this is 999 described in [RFC2865] Section 5.2 (for obscuring User-Password 1000 values) and is based on the MD5 algorithm specified in [RFC1321]. 1001 The MD5 and SHA-1 algorithms have recently become a focus of scrutiny 1002 and concern in security circles, and as a result, the use of these 1003 algorithms in new attributes is NOT RECOMMENDED. In addition, 1004 previous documents referred to this method as generating "encrypted" 1005 data. This terminology is no longer accepted within the 1006 cryptographic community. 1008 Where new RADIUS attributes use cryptographic algorithms, algorithm 1009 negotiation SHOULD be supported. Specification of a mandatory-to- 1010 implement algorithm is REQUIRED, and it is RECOMMENDED that the 1011 mandatory-to-implement algorithm be certifiable under FIPS 140 1012 [FIPS]. 1014 Where new RADIUS attributes encapsulate complex data types, or 1015 transport opaque data, the security considerations discussed in 1016 Section 2.1.4 SHOULD be addressed. 1018 Message authentication in RADIUS is provided largely via the Message- 1019 Authenticator attribute. See [RFC3579] Section 3.2, and also 1020 [RFC5080] 2.2.2. 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 6. References 1029 6.1. Normative References 1031 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1032 Requirement Levels", BCP 14, RFC 2119, March 1997. 1034 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 1035 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1036 2000. 1038 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1039 Authentication Dial In User Service)", RFC 3575, July 2003. 1041 [EXTEN] Li, Y., et al., "Extended Remote Authentication Dial In User 1042 Service (RADIUS) Attributes", draft-ietf-radext-extended- 1043 attributes-05.txt, (work in progress). 1045 6.2. Informative References 1047 [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of 1048 management information for TCP/IP-based internets", STD 16, 1049 RFC 1155, May 1990. 1051 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 1052 Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1053 1990. 1055 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1056 April 1992. 1058 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1059 Implementation in Roaming", RFC 2607, June 1999. 1061 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1063 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., 1064 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 1065 Support", RFC 2868, June 2000. 1067 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", 1068 RFC 2869, June 2000. 1070 [RFC2882] Mitton, D, "Network Access Servers Requirements: Extended 1071 RADIUS Practices", RFC 2882, July 2000. 1073 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 1074 3162, August 2001. 1076 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 1077 In User Service) Support For Extensible Authentication 1078 Protocol (EAP)", RFC 3579, September 2003. 1080 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE 1081 802.1X Remote Authentication Dial In User Service (RADIUS) 1082 Usage Guidelines", RFC3580, September 2003. 1084 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1085 RFC 3629, November 2003. 1087 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 1088 Documents", RFC 4181, September 2005. 1090 [RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge MIB WG 1091 to IEEE 802.1 WG", RFC 4663, September 2006. 1093 [RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for 1094 Virtual LAN and Priority Support", RFC 4675, September 2006. 1096 [RFC4679] Mammoliti, V., et al., "DSL Forum Vendor-Specific RADIUS 1097 Attributes", RFC 4679, September 2006. 1099 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 1100 Attribute", RFC 4818, April 2007. 1102 [RFC4821] Mathis, M. and Heffner, J, "Packetization Layer Path MTU 1103 Discovery", RFC 4821, March 2007. 1105 [RFC4849] Congdon, P. et al, "RADIUS Filter-Rule Attribute", RFC 4849, 1106 April 2007. 1108 [RFC5080] Nelson, D. and DeKok, A, "Common Remote Authentication Dial In 1109 User Service (RADIUS) Implementation Issues and Suggested 1110 Fixes", RFC 5080, December 2007. 1112 [RFC5090] Sterman, B. et al., "RADIUS Extension for Digest 1113 Authentication", RFC 5090, February 2008. 1115 [RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote 1116 Authentication Dial In User Service (RADIUS)", RFC 5176, 1117 January 2008. 1119 [DOCTORS] AAA Doctors Mailing list 1121 [FIPS] FIPS 140-3 (DRAFT), "Security Requirements for Cryptographic 1122 Modules", http://csrc.nist.gov/publications/fips/fips140-3/ 1124 [IEEE-802.1Q] 1125 IEEE Standards for Local and Metropolitan Area Networks: Draft 1126 Standard for Virtual Bridged Local Area Networks, 1127 P802.1Q-2003, January 2003. 1129 [RADIUSLOC] 1130 Tschofenig, H. (Ed.), "Carrying Location Objects in RADIUS and 1131 Diameter", draft-ietf-geopriv-radius-lo-22.txt, (work in 1132 progress) 1134 Appendix A - Design Guidelines 1136 The following text provides guidelines for the design of attributes 1137 used by the RADIUS protocol. Specifications that follow these 1138 guidelines are expected to achieve maximum interoperability with 1139 minimal changes to existing systems. 1141 A.1. Types matching the RADIUS data model 1143 A.1.1. Transport of simple data 1145 Does the data fit within the existing RADIUS data model, as outlined 1146 below? If so, it SHOULD be encapsulated in a [RFC2865] format RADIUS 1147 attribute, or in a [RFC2865] format RADIUS VSA that uses one of the 1148 existing RADIUS data types. 1150 * 32-bit unsigned integer, most significant octet first. 1151 * Enumerated data types, represented as a 32-bit unsigned integer 1152 with a list of name to value mappings. (e.g., Service-Type) 1153 * 64-bit unsigned integer, most significant octet first. 1154 * IPv4 address in network byte order. 1155 * IPv6 address in network byte order. 1156 * IPv6 prefix. 1157 * time as 32 bit unsigned value, most significant octet first, in 1158 seconds since 00:00:00 UTC, January 1, 1970. 1159 * string (i.e., binary data), totalling 253 octets or less in 1160 length. This includes the opaque encapsulation of data 1161 structures defined outside of RADIUS. See also Section A.1.3, 1162 below. 1163 * UTF-8 text, totalling 253 octets or less in length. 1164 * Complex data types for authentication and/or security. 1165 These attributes SHOULD be defined only within the RADIUS 1166 attribute space, and SHOULD NOT be defined within the VSA space. 1168 Note that the length limitations for VSAs of type String and Text are 1169 less than 253 octets, due to the additional overhead of the Vendor- 1170 Specific format. 1172 A.1.2. Extended data types 1174 Where possible, the data types defined above in Section A.1.1 SHOULD 1175 be used. The extended data types defined in [EXTEN] SHOULD be used 1176 only where there is no clear method of expressing the data using 1177 existing types. 1179 Does the data fit within the extended RADIUS data model, as outlined 1180 below? If so, it SHOULD be encapsulated in a [EXTEN] format RADIUS 1181 VSA. 1183 * Attributes grouped into a logical container. 1184 This does not include nested groups. 1185 * Attributes requiring the transport of more than 247 octets of 1186 Text or String data. This includes the opaque encapsulation 1187 of data structures defined outside of RADIUS. See also Section 1188 A.1.3, below. 1190 A.1.3. Opaque data types 1192 Does the attribute encapsulate an existing data structure defined 1193 outside of the RADIUS specifications? Can the attribute be treated 1194 as opaque data by RADIUS servers (including proxies?) If both 1195 questions can be answered affirmatively, a complex structure MAY be 1196 used in a RADIUS specification. 1198 The specification of the attribute SHOULD define the encapsulating 1199 attribute to be of type String. The specification SHOULD refer to an 1200 external document defining the structure. The specification SHOULD 1201 NOT define or describe the structure, as discussed above in Section 1202 2.1.3. 1204 A.2. Improper Data Types 1206 All data types other than the ones described above in Section A.1 1207 SHOULD NOT be used. This section describes in detail a number of 1208 data types that are NOT RECOMMENDED in new RADIUS specifications. 1209 Where possible, replacement data types are suggested. 1211 A.2.1. Simple Data Types 1213 Does the attribute use any of the following data types? If so, the 1214 data type SHOULD be replaced with the suggested alternatives, or it 1215 SHOULD NOT be used at all. 1217 * Signed integers of any size. 1218 SHOULD NOT be used. SHOULD be replaced with one or more 1219 unsigned integer attributes. The definition of the attribute 1220 can contain information that would otherwise go into the sign 1221 value of the integer. 1222 * 8 bit unsigned integers. 1223 SHOULD be replaced with 32-bit unsigned integer. There is 1224 insufficient justification to save three bytes. 1225 * 16 bit unsigned integers. 1226 SHOULD be replaced with 32-bit unsigned integer. There is 1227 insufficient justification to save two bytes. 1228 * Unsigned integers of size other than 32 or 64. 1229 SHOULD be replaced by an unsigned integer of 32 or 64 bits. 1230 There is insufficient justification to define a new size of 1231 integer. 1232 * Integers of any size in non-network byte order 1233 SHOULD be replaced by unsigned integer of 32 or 64 bits, 1234 in network byte order. There is no reason to transport integers 1235 in any format other than network byte order. 1236 * Tagged data types as described in [RFC2868]. 1237 These data types SHOULD NOT be used in new specifications. The 1238 attribute grouping method defined in [EXTEN] SHOULD be used 1239 instead. 1240 * Complex data structures defined only within RADIUS. 1241 The additional functionality defined in [EXTEN] SHOULD be used 1242 instead. This recommendation does not apply to new attributes 1243 for authentication or security, as described below in Section 1244 A.2.2. 1245 * Multi-field text strings. 1246 Each field SHOULD be encapsulated in a separate attribute. 1247 Where grouping of fields is desired, the additional 1248 functionality defined in [EXTEN] SHOULD be used instead. 1249 * Polymorphic attributes. 1250 Multiple attributes, each with a static data type SHOULD be 1251 defined instead. 1252 * Nested AVPs. 1253 Attributes should be defined in a flat typespace, possibly using 1254 a 16-bit Vendor type field (see Section 2.3). Where grouping of 1255 fields is desired, the additional functionality defined in 1256 [EXTEN] SHOULD be used instead. 1258 A.2.2. Complex Data Types 1260 Does the attribute define a complex data type for purposes other than 1261 authentication or security? If so, this data type SHOULD be replaced 1262 with simpler types, as discussed above in Section A.2.1. Also see 1263 Section 2.1.3 for a discussion of why complex types are problematic. 1265 A.3. Vendor-Specific formats 1267 Does the specification contain Vendor-Specific attributes that match 1268 any of the following criteria? If so, the data type should be 1269 replaced with the suggested alternatives, or should not be used at 1270 all. 1272 * Vendor types of more than 16 bits. 1273 SHOULD NOT be used. Vendor types of 8 or 16 bits SHOULD be used 1274 instead. 1275 * Vendor lengths of less than 8 bits. (i.e., zero bits) 1276 SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used 1277 instead. 1279 * Vendor lengths of more than 8 bits. 1280 SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used 1281 instead. 1282 * Vendor-Specific contents that are not in Type-Length-Value 1283 format. 1284 SHOULD NOT be used. Vendor-Specific attributes SHOULD be in 1285 Type-Length-Value format. 1287 We recognize that SDOs may require more than 256 attributes, which is 1288 the limit of the 8-bit [RFC2865] Vendor-Specific space. Those SDOs 1289 SHOULD use Vendor types of 16 bits, as described in [EXTEN]. 1290 However, SDOs SHOULD NOT use Vendor types of 16 bits unless there are 1291 immediate requirements. Future-proofing a specification is 1292 insufficient grounds for using 16-bit Vendor types. 1294 In general, Vendor-Specific attributes SHOULD follow the [RFC2865] 1295 suggested format, or the [EXTEN] format if more functionality or a 1296 larger attribute space is necessary. 1298 A.4. Changes to the RADIUS Operational Model 1300 Does the specification change the RADIUS operation model, as outlined 1301 in the list below? If so, then another method of achieving the 1302 design objectives SHOULD be used. Potential problem areas include: 1304 * Defining new commands in RADIUS using attributes. 1305 The addition of new commands to RADIUS MUST be handled via 1306 allocation of a new Code, and not by the use of an attribute. 1307 This restriction includes new commands created by overloading 1308 the Service-Type attribute to define new values that modify 1309 the functionality of Access-Request packets. 1310 * Using RADIUS as a transport protocol for data unrelated to 1311 authentication, authorization, or accounting. Using RADIUS to 1312 transport authentication methods such as EAP is explicitly 1313 permitted, even if those methods require the transport of 1314 relatively large amounts of data. Transport of opaque data 1315 relating to AAA is also permitted, as discussed above in 1316 Section 2.1.3. However, if the specification does not relate 1317 to AAA, then RADIUS SHOULD NOT be used. 1318 * Assuming support for packet lengths greater than 4096 octets. 1319 Attribute designers cannot assume that RADIUS implementations 1320 can successfully handle packets larger than 4096 octets. 1321 If a specification could lead to a RADIUS packet larger than 1322 4096 octets, then the alternatives described in Section 3.3 1323 SHOULD be considered. 1324 * Stateless operation. The RADIUS protocol is stateless, and 1325 documents which require stateful protocol behavior without the 1326 use of the State Attribute need to be redesigned. 1328 * Provisioning of service in an Access-Reject. Such provisioning 1329 is not permitted, and MUST NOT be used. If limited access needs 1330 to be provided, then an Access-Accept with appropriate 1331 authorizations can be used instead. 1332 * Lack of user authentication or authorization restrictions. 1333 In an authorization check, where there is no demonstration of a 1334 live user, confidential data cannot be returned. Where there 1335 is a link to a previous user authentication, the State attribute 1336 needs to be present. 1337 * Lack of per-packet integrity and authentication. 1338 It is expected that documents will support per-packet 1339 integrity and authentication. 1340 * Modification of RADIUS packet sequences. 1341 In RADIUS, each request is encapsulated in it's own packet, and 1342 elicits a single response that is sent to the requester. Since 1343 changes to this paradigm are likely to require major 1344 modifications to RADIUS client and server implementations, they 1345 SHOULD be avoided if possible. 1346 For further details, see Section 3.3. 1348 A.5. Allocation of attributes 1350 Does the attribute have a limited scope of applicability, as outlined 1351 below? If so, then the attributes SHOULD be allocated from the 1352 Vendor-Specific space. 1354 * attributes intended for a vendor to support their own systems, 1355 and not suitable for general usage 1356 * attributes relying on data types not defined within RADIUS 1357 * attributes intended primarily for use within an SDO 1358 * attributes intended primarily for use within a group of SDOs. 1360 Note that the points listed above do not relax the recommendations 1361 discussed in this document. Instead, they recognize that the RADIUS 1362 data model has limitations. In certain situations where 1363 interoperability can be strongly constrained by the SDO or vendor, an 1364 expanded data model MAY be used. We recommend, however, that the 1365 RADIUS data model SHOULD be used, even if it is marginally less 1366 efficient than alternatives. 1368 When attributes are used primarily within a group of SDOs, and are 1369 not applicable to the wider Internet community, we expect that one 1370 SDO will be responsible for allocation from their own private space. 1372 Appendix B - Complex Attributes 1374 This section summarizes RADIUS attributes with complex data types 1375 that are defined in existing RFCs. 1377 This appendix is published for informational purposes only, and 1378 reflects the usage of attributes with complex data types at the time 1379 of the publication of this document. 1381 B.1. CHAP-Password 1383 [RFC2865] Section 5.3 defines the CHAP-Password Attribute which is 1384 sent from the RADIUS client to the RADIUS server in an Access- 1385 Request. The data type of the CHAP Identifier is not given, only the 1386 one octet length: 1388 0 1 2 1389 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 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1391 | Type | Length | CHAP Ident | String ... 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1394 Since this is an authentication attribute, code changes are required 1395 on the RADIUS client and server to support it, regardless of the 1396 attribute format. Therefore, this complex data type is acceptable in 1397 this situation. 1399 B.2. CHAP-Challenge 1401 [RFC2865] Section 5.40 defines the CHAP-Challenge Attribute which is 1402 sent from the RADIUS client to the RADIUS server in an Access- 1403 Request. While the data type of the CHAP Identifier is given, the 1404 text also says: 1406 If the CHAP challenge value is 16 octets long it MAY be placed in 1407 the Request Authenticator field instead of using this attribute. 1409 Defining attributes to contain values taken from the RADIUS packet 1410 header is NOT RECOMMENDED. Attributes should have values that are 1411 packed into a RADIUS AVP. 1413 B.3. Tunnel-Password 1415 [RFC2868] Section 3.5 defines the Tunnel-Password Attribute, which is 1416 sent from the RADIUS server to the client in an Access-Accept. This 1417 attribute includes Tag and Salt fields, as well as a string field 1418 which consists of three logical sub-fields: the Data-Length (one 1419 octet) and Password sub-fields (both of which are required), and the 1420 optional Padding sub-field. The attribute appears as follows: 1422 0 1 2 3 1423 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 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 | Type | Length | Tag | Salt 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 Salt (cont) | String ... 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 Since this is a security attribute and is encrypted, code changes are 1431 required on the RADIUS client and server to support it, regardless of 1432 the attribute format. Therefore, this complex data type is 1433 acceptable in this situation. 1435 B.4. ARAP-Password 1437 [RFC2869] Section 5.4 defines the ARAP-Password attribute, which is 1438 sent from the RADIUS client to the server in an Access-Request. It 1439 contains four 4 octet values, instead of having a single Value field: 1441 0 1 2 3 1442 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 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 | Type | Length | Value1 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 | Value2 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 | Value3 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 | Value4 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1452 | 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 As with the CHAP-Password attribute, this is an authentication 1456 attribute which would have required code changes on the RADIUS client 1457 and server regardless of format. 1459 B.5. ARAP-Features 1461 [RFC2869] Section 5.5 defines the ARAP-Features Attribute, which is 1462 sent from the RADIUS server to the client in an Access-Accept or 1463 Access-Challenge. It contains a compound string of two single octet 1464 values, plus three 4-octet values, which the RADIUS client 1465 encapsulates in a feature flags packet in the ARAP protocol: 1467 0 1 2 3 1468 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 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 | Type | Length | Value1 | Value2 | 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 | Value3 | 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 | Value4 | 1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1476 | Value5 | 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 Unlike the previous attributes, this attribute contains no encrypted 1480 component, nor is it directly involved in authentication. The 1481 individual sub-fields therefore could have been encapsulated in 1482 separate attributes. 1484 While the contents of this attribute is intended to be placed in an 1485 ARAP packet, the fields need to be set by the RADIUS server. Using 1486 standard RADIUS data types would have simplified RADIUS server 1487 implementations, and subsequent management. The current form of the 1488 attribute requires either the RADIUS server implementation, or the 1489 RADIUS server administrator, to understand the internals of the ARAP 1490 protocol. 1492 B.6. Connect-Info 1494 [RFC2869] Section 5.11 defines the Connect-Info attribute, which is 1495 used to indicate the nature of the connection. 1497 0 1 2 1498 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 | Type | Length | Text... 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 Even though the type is Text, the rest of the description indicates 1504 that it is a complex attribute: 1506 The Text field consists of UTF-8 encoded 10646 [8] characters. 1507 The connection speed SHOULD be included at the beginning of the 1508 first Connect-Info attribute in the packet. If the transmit and 1509 receive connection speeds differ, they may both be included in the 1510 first attribute with the transmit speed first (the speed the NAS 1511 modem transmits at), a slash (/), the receive speed, then 1512 optionally other information. 1513 For example, "28800 V42BIS/LAPM" or "52000/31200 V90" 1515 More than one Connect-Info attribute may be present in an 1516 Accounting-Request packet to accommodate expected efforts by ITU 1517 to have modems report more connection information in a standard 1518 format that might exceed 252 octets. 1520 This attribute contains no encrypted component, and is it not 1521 directly involved in authentication. The individual sub-fields could 1522 therefore have been encapsulated in separate attributes. 1524 Since the form of the text string is well defined, there is no 1525 benefit in using a text string. Instead, an integer attribute should 1526 have been assigned for each of the transmit speed and the receive 1527 speed. A separate enumerated integer should have been assigned for 1528 the additional information, as is done for the NAS-Port-Type 1529 attribute. 1531 B.7. Framed-IPv6-Prefix 1533 [RFC3162] Section 2.3 defines the Framed-IPv6-Prefix Attribute and 1534 [RFC4818] Section 3 reuses this format for the Delegated-IPv6-Prefix 1535 Attribute; these attributes are sent from the RADIUS server to the 1536 client in an Access-Accept. 1538 0 1 2 3 1539 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 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 | Type | Length | Reserved | Prefix-Length | 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 Prefix 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 Prefix 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 Prefix 1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1549 Prefix | 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 The sub-fields encoded in these attributes are strongly related, and 1553 there was no previous definition of this data structure that could be 1554 referenced. Support for this attribute requires code changes on both 1555 the client and server, due to a new data type being defined. In this 1556 case it appears to be acceptable to encode them in one attribute. 1558 B.8. Egress-VLANID 1560 [RFC4675] Section 2.1 defines the Egress-VLANID Attribute which can 1561 be sent by a RADIUS client or server. 1563 0 1 2 3 1564 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 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 | Type | Length | Value 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 Value (cont) | 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1571 While it appears superficially to be of type Integer, the Value field 1572 is actually a packed structure, as follows: 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 | Tag Indic. | Pad | VLANID | 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 The length of the VLANID field is defined by the [IEEE-802.1Q] 1581 specification. The Tag indicator field is either 0x31 or 0x32, for 1582 compatibility with the Egress-VLAN-Name, as discussed below. The 1583 complex structure of Egress-VLANID overlaps with that of the base 1584 Integer data type, meaning that no code changes are required for a 1585 RADIUS server to support this attribute. Code changes are required 1586 on the NAS, if only to implement the VLAN ID enforcement. 1588 Given the IEEE VLAN requirements and the limited data model of 1589 RADIUS, the chosen method is likely the best of the possible 1590 alternatives. Future specifications that attempt to obtain similar 1591 functionality SHOULD use the extended types from [EXTEN]. 1593 B.9. Egress-VLAN-Name 1595 [RFC4675] Section 2.3 defines the Egress-VLAN-Name Attribute which 1596 can be sent by a RADIUS client or server. 1598 0 1 2 3 1599 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 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 | Type | Length | Tag Indic. | String... 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1604 The Tag Indicator is either the character '1' or '2', which in ASCII 1605 map to the identical values for Tag Indicator in Egress-VLANID, 1606 above. The complex structure of this attribute is acceptable for 1607 reasons identical to those given for Egress-VLANID. Future 1608 specifications that attempt to obtain similar functionality SHOULD 1609 use the extended types from [EXTEN]. 1611 Acknowledgments 1612 We would like to acknowledge David Nelson, Bernard Aboba, Emile van 1613 Bergen, Barney Wolff and Glen Zorn for contributions to this 1614 document. 1616 Authors' Addresses 1618 Greg Weber 1619 Knoxville, TN 37932 1620 USA 1622 Email: gdweber@gmail.com 1624 Alan DeKok 1625 The FreeRADIUS Server Project 1626 http://freeradius.org/ 1628 Email: aland@freeradius.org