7 Internet Engineering Task Force (IETF) A. DeKok, Ed.
8 Request for Comments: 6158 FreeRADIUS
10 Category: Best Current Practice Individual Contributor
11 ISSN: 2070-1721 March 2011
15 RADIUS Design Guidelines
19 This document provides guidelines for the design of attributes used
20 by the Remote Authentication Dial In User Service (RADIUS) protocol.
21 It is expected that these guidelines will prove useful to authors and
22 reviewers of future RADIUS attribute specifications, within the IETF
23 as well as other Standards Development Organizations (SDOs).
27 This memo documents an Internet Best Current Practice.
29 This document is a product of the Internet Engineering Task Force
30 (IETF). It represents the consensus of the IETF community. It has
31 received public review and has been approved for publication by the
32 Internet Engineering Steering Group (IESG). Further information on
33 BCPs is available in Section 2 of RFC 5741.
35 Information about the current status of this document, any errata,
36 and how to provide feedback on it may be obtained at
37 http://www.rfc-editor.org/info/rfc6158.
41 Copyright (c) 2011 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (http://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Simplified BSD License text as described in Section 4.e of
51 the Trust Legal Provisions and are provided without warranty as
52 described in the Simplified BSD License.
58 DeKok & Weber Best Current Practice [Page 1]
60 RFC 6158 RADIUS Design Guidelines March 2011
63 This document may contain material from IETF Documents or IETF
64 Contributions published or made publicly available before November
65 10, 2008. The person(s) controlling the copyright in some of this
66 material may not have granted the IETF Trust the right to allow
67 modifications of such material outside the IETF Standards Process.
68 Without obtaining an adequate license from the person(s) controlling
69 the copyright in such materials, this document may not be modified
70 outside the IETF Standards Process, and derivative works of it may
71 not be created outside the IETF Standards Process, except to format
72 it for publication as an RFC or to translate it into languages other
77 1. Introduction ....................................................3
78 1.1. Terminology ................................................4
79 1.2. Requirements Language ......................................4
80 1.3. Applicability ..............................................5
81 1.3.1. Reviews .............................................5
82 2. Guidelines ......................................................6
83 2.1. Data Types .................................................8
84 2.2. Vendor Space ...............................................9
85 2.3. Service Definitions and RADIUS .............................9
86 2.4. Translation of Vendor Specifications ......................10
87 3. Rationale ......................................................11
88 3.1. RADIUS Operational Model ..................................11
89 3.2. Data Model Issues .........................................14
90 3.2.1. Issues with Definitions of Types ...................15
91 3.2.2. Tagging Mechanism ..................................16
92 3.2.3. Complex Data Types .................................16
93 3.2.4. Complex Data Type Exceptions .......................18
94 3.3. Vendor Space ..............................................19
95 3.3.1. Interoperability Considerations ....................20
96 3.3.2. Vendor Allocations .................................20
97 3.3.3. SDO Allocations ....................................20
98 3.4. Polymorphic Attributes ....................................21
99 4. IANA Considerations ............................................22
100 5. Security Considerations ........................................22
101 5.1. New Data Types and Complex Attributes .....................23
102 6. References .....................................................24
103 6.1. Normative References ......................................24
104 6.2. Informative References ....................................24
105 Appendix A. Design Guidelines Checklist ..........................27
106 A.1. Types Matching the RADIUS Data Model ......................27
107 A.1.1. Transport of Basic Data Types ........................27
108 A.1.2. Transport of Authentication and Security Data ........27
109 A.1.3. Opaque Data Types ....................................27
110 A.1.4. Pre-existing Data Types ..............................28
114 DeKok & Weber Best Current Practice [Page 2]
116 RFC 6158 RADIUS Design Guidelines March 2011
119 A.2. Improper Data Types .......................................28
120 A.2.1. Simple Data Types ....................................28
121 A.2.2. More Complex Data Types ..............................29
122 A.3. Vendor-Specific Formats ...................................29
123 A.4. Changes to the RADIUS Operational Model ...................30
124 A.5. Allocation of Attributes ..................................31
125 Appendix B. Complex Attributes ...................................32
126 B.1. CHAP-Password .............................................32
127 B.2. CHAP-Challenge ............................................32
128 B.3. Tunnel-Password ...........................................33
129 B.4. ARAP-Password .............................................33
130 B.5. ARAP-Features .............................................34
131 B.6. Connect-Info ..............................................34
132 B.7. Framed-IPv6-Prefix ........................................35
133 B.8. Egress-VLANID .............................................36
134 B.9. Egress-VLAN-Name ..........................................37
135 B.10. Digest-* .................................................37
136 Acknowledgments ...................................................37
140 This document provides guidelines for the design of Remote
141 Authentication Dial In User Service (RADIUS) attributes within the
142 IETF as well as within other Standards Development Organizations
143 (SDOs). By articulating RADIUS design guidelines, it is hoped that
144 this document will encourage the development and publication of high-
145 quality RADIUS attribute specifications.
147 However, the advice in this document will not be helpful unless it is
148 put to use. As with "Guidelines for Authors and Reviewers of MIB
149 Documents" [RFC4181], it is expected that authors will check their
150 document against the guidelines in this document prior to publication
151 or requesting review (such as an "Expert Review" described in
152 [RFC3575]). Similarly, it is expected that this document will be
153 used by reviewers (such as WG participants or the Authentication,
154 Authorization, and Accounting (AAA) Doctors [DOCTORS]), resulting in
155 an improvement in the consistency of reviews.
157 In order to meet these objectives, this document needs to cover not
158 only the science of attribute design but also the art. Therefore, in
159 addition to covering the most frequently encountered issues, this
160 document explains some of the considerations motivating the
161 guidelines. These considerations include complexity trade-offs that
162 make it difficult to provide "hard and fast" rules for attribute
163 design. This document explains those trade-offs through reviews of
164 current attribute usage.
170 DeKok & Weber Best Current Practice [Page 3]
172 RFC 6158 RADIUS Design Guidelines March 2011
175 The rest of the document is organized as follows. Section 1
176 discusses the applicability of the guidelines and defines a
177 recommended review process for RADIUS specifications. Section 2
178 defines the design guidelines in terms of what is "RECOMMENDED" and
179 "NOT RECOMMENDED". Section 3 gives a longer explanation of the
180 rationale behind the guidelines given in the previous section.
181 Appendix A repeats the guidelines in a "checklist" format. Appendix
182 B discusses previously defined attributes that do not follow the
185 Authors of new RADIUS specifications can be compliant with the design
186 guidelines by working through the checklists given in Appendix A.
187 Reviewers of RADIUS specifications are expected to be familiar with
192 This document uses the following terms:
194 Network Access Server (NAS)
195 A device that provides an access service for a user to a network.
198 A RADIUS authentication, authorization, and accounting (AAA)
199 server is an entity that provides one or more AAA services to a
203 Codes in the RADIUS Attribute Type Space that are allocated by
204 IANA and that follow the format defined in Section 5 of RFC 2865
208 The contents of the Vendor-Specific Attribute (VSA), as defined in
209 [RFC2865], Section 5.26. These attributes provide a unique
210 attribute type space in the "String" field for each vendor
211 (identified by the Vendor-Type field), which they can self-
214 1.2. Requirements Language
216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
218 document are to be interpreted as described in [RFC2119].
226 DeKok & Weber Best Current Practice [Page 4]
228 RFC 6158 RADIUS Design Guidelines March 2011
233 The advice in this document applies to RADIUS attributes used to
234 encode service-provisioning, authentication, or accounting data based
235 on the attribute encodings and data formats defined in RFC 2865
236 [RFC2865], RFC 2866 [RFC2866], and subsequent RADIUS RFCs.
238 Since this document represents a Best Current Practice, it does not
239 update or deprecate existing standards. As a result, uses of the
240 terms "MUST" and "MUST NOT" are limited to requirements already
241 present in existing documents.
243 It is RECOMMENDED that these guidelines be followed for all new
244 RADIUS specifications, whether they originate from a vendor, an SDO,
245 or the IETF. Doing so will ensure the widest possible applicability
246 and interoperability of the specifications, while requiring minimal
247 changes to existing systems. In particular, it is expected that
248 RADIUS specifications requesting allocation within the standard space
249 will follow these guidelines and will explain why this is not
250 possible if they cannot.
252 However, there are situations in which vendors or SDOs can choose not
253 to follow these guidelines without major consequences. As noted in
254 Section 5.26 of [RFC2865], Vendor-Specific Attributes (VSAs) are
255 "available to allow vendors to support their own extended Attributes
256 not suitable for general usage". Where vendors or SDOs develop
257 specifications "not suitable for general usage", limited
258 interoperability and inability to use existing implementations may be
259 acceptable, and, in these situations, vendors and SDOs MAY choose not
260 to conform to these guidelines.
262 Note that the RADEXT WG is currently (as of 2011) involved in
263 developing updates to RADIUS. Those updates will provide their own
264 usage guidelines that may modify some of the guidelines defined here,
265 such as defining new data types, practices, etc.
267 RADIUS protocol changes, or specification of attributes (such as
268 Service-Type), that can, in effect, provide new RADIUS commands
269 require greater expertise and deeper review, as do changes to the
270 RADIUS operational model. As a result, such changes are outside the
271 scope of this document and MUST NOT be undertaken outside the IETF.
275 For specifications utilizing attributes within the standard space,
276 conformance with the design guidelines in this document is expected
277 unless a good case can be made for an exception. Reviewers SHOULD
278 use the design guidelines as a review checklist.
282 DeKok & Weber Best Current Practice [Page 5]
284 RFC 6158 RADIUS Design Guidelines March 2011
287 While not required, IETF review may also be beneficial for
288 specifications utilizing the vendor space. Experience has shown that
289 attributes not originally designed for general usage can subsequently
290 garner wide-spread deployment. An example is the Vendor-Specific
291 Attributes defined in [RFC2548], which have been widely implemented
292 within IEEE 802.11 Access Points.
294 In order to assist in the development of specifications conforming to
295 these guidelines, authors can request review by sending an email to
296 the AAA Doctors [DOCTORS] or equivalent mailing list. The IETF
297 Operations & Management Area Directors will then arrange for the
298 review to be completed and posted to the AAA Doctors mailing list
299 [DOCTORS], RADEXT WG mailing list, or other IETF mailing lists.
300 Since reviews are handled by volunteers, responses are provided on a
301 best-effort basis, with no service-level guarantees. Authors are
302 encouraged to seek review as early as possible, so as to avoid
305 As reviewers require access to the specification, vendors and SDOs
306 are encouraged to make it publicly available. Where the RADIUS
307 specification is embedded within a larger document that cannot be
308 made public, the RADIUS attribute and value definitions can be made
309 available on a public web site or can be published as an
310 Informational RFC, as with [RFC4679].
312 The review process requires neither allocation of attributes within
313 the standard space nor publication of an RFC. Requiring SDOs or
314 vendors to rehost VSAs into the standard space solely for the purpose
315 of obtaining review would put pressure on the standard space and may
316 be harmful to interoperability since it would create two ways to
317 provision the same service. Rehosting may also require changes to
318 the RADIUS data model, which will affect implementations that do not
319 intend to support the SDO or vendor specifications.
321 Similarly, vendors are encouraged to make their specifications
322 publicly available, for maximum interoperability. However, it is not
323 necessary for a vendor to request publication of a VSA specification
328 The RADIUS protocol as defined in [RFC2865] and [RFC2866] uses
329 elements known as attributes in order to represent authentication,
330 authorization, and accounting data.
338 DeKok & Weber Best Current Practice [Page 6]
340 RFC 6158 RADIUS Design Guidelines March 2011
343 Unlike Simple Network Management Protocol (SNMP), first defined in
344 [RFC1157] and [RFC1155], RADIUS does not define a formal data
345 definition language. The data type of RADIUS attributes is not
346 transported on the wire. Rather, the data type of a RADIUS attribute
347 is fixed when an attribute is defined. Based on the RADIUS attribute
348 type code, RADIUS clients and servers can determine the data type
349 based on pre-configured entries within a data dictionary.
351 To explain the implications of this early RADIUS design decision, we
352 distinguish two kinds of data types, namely "basic" and "complex".
353 Basic data types use one of the existing RADIUS data types as defined
354 in Section 2.1, encapsulated in a [RFC2865] RADIUS attribute or in a
355 [RFC2865] RADIUS VSA. All other data formats are "complex types".
357 RADIUS attributes can be classified into one of three broad
360 * Attributes that are of interest to a single vendor, e.g., for a
361 product or product line. Minimal cross-vendor interoperability
364 Vendor-Specific Attributes (VSAs) are appropriate for use in
365 this situation. Code-point allocation is managed by the vendor
366 with the vendor space defined by their Private Enterprise Number
367 (PEN), as given in the Vendor-Id field.
369 * Attributes that are of interest to an industry segment, where an
370 SDO defines the attributes for that industry. Multi-vendor
371 interoperability within an industry segment is expected.
373 Vendor-Specific Attributes (VSAs) MUST be used. Code-point
374 allocation is managed by the SDO with the vendor space defined
375 by the SDO's PEN rather than the PEN of an individual vendor.
377 * Attributes that are of broad interest to the Internet community.
378 Multi-vendor interoperability is expected.
380 Attributes within the standard space are appropriate for this
381 purpose and are allocated via IANA as described in [RFC3575].
382 Since the standard space represents a finite resource, and is
383 the only attribute space available for use by IETF working
384 groups, vendors, and SDOs are encouraged to utilize the vendor
385 space rather than request allocation of attributes from the
386 standard space. Usage of attribute type codes reserved for
387 standard attributes is considered antisocial behavior and is
388 strongly discouraged.
394 DeKok & Weber Best Current Practice [Page 7]
396 RFC 6158 RADIUS Design Guidelines March 2011
401 RADIUS defines a limited set of data types, defined as "basic data
402 types". The following data qualifies as "basic data types":
404 * 32-bit unsigned integer in network byte order.
406 * Enumerated data types, represented as a 32-bit unsigned integer
407 with a list of name to value mappings (e.g., Service-Type).
409 * IPv4 address in network byte order.
411 * Time as a 32-bit unsigned value in network byte order and in
412 seconds since 00:00:00 UTC, January 1, 1970.
414 * IPv6 address in network byte order.
416 * Interface-Id (8-octet string in network byte order).
420 * String (i.e., binary data), totaling 253 octets or less in
421 length. This includes the opaque encapsulation of data
422 structures defined outside of RADIUS. See also Appendix A.1.3
423 for additional discussion.
425 * UTF-8 text [RFC3629], totaling 253 octets or less in length.
427 Note that the length limitations for VSAs of type String and Text are
428 less than 253 octets, due to the additional overhead of the Vendor-
431 The following data also qualifies as "basic data types":
433 * Attributes grouped into a logical container using the [RFC2868]
434 tagging mechanism. This approach is NOT RECOMMENDED (see
435 Section 3.2.2) but is permissible where the alternatives are
438 * Attributes requiring the transport of more than 253 octets of
439 Text or String data. This includes the opaque encapsulation of
440 data structures defined outside of RADIUS, e.g., EAP-Message.
442 All other data formats (including nested attributes) are defined to
443 be "complex data types" and are NOT RECOMMENDED for normal use.
444 Complex data types MAY be used in situations where they reduce
445 complexity in non-RADIUS systems or where using the basic data types
446 would be awkward (such as where grouping would be required in order
450 DeKok & Weber Best Current Practice [Page 8]
452 RFC 6158 RADIUS Design Guidelines March 2011
455 to link related attributes). Since there are no "hard and fast"
456 rules for where complexity is best located, each situation has to be
457 decided on a case-by-case basis. Examples of this trade-off are
458 discussed in Appendix B. Where a complex data type is selected, an
459 explanation SHOULD be offered as to why this was necessary.
463 The Vendor space is defined to be the contents of the Vendor-Specific
464 Attribute ([RFC2865], Section 5.26) where the Vendor-Id defines the
465 space for a particular vendor, and the contents of the "String" field
466 define a unique attribute type space for that vendor. As discussed
467 there, it is intended for vendors and SDOs to support their own
468 attributes not suitable for general use.
470 While the encoding of attributes within the vendor space is under the
471 control of vendors and SDOs, following the guidelines described here
472 is advantageous since it enables maximum interoperability with
473 minimal changes to existing systems.
475 For example, RADIUS server support for new attributes using "basic
476 data types" can typically be accomplished by editing a RADIUS
477 dictionary, whereas "complex data types" typically require RADIUS
478 server code changes, which can add complexity and delays in
481 Vendor RADIUS Attribute specifications SHOULD self-allocate
482 attributes from the vendor space rather than request an allocation
483 from within the standard space.
485 VSA encodings that do not follow the [RFC2865], Section 5.26 encoding
486 scheme are NOT RECOMMENDED. Although [RFC2865] does not mandate it,
487 implementations commonly assume that the Vendor Id can be used as a
488 key to determine the on-the-wire encoding of a VSA. Vendors
489 therefore SHOULD NOT use multiple encodings for VSAs that are
490 associated with a particular Vendor Id. A vendor wishing to use
491 multiple VSA encodings SHOULD request one Vendor Id for each VSA
492 encoding that they will use.
494 2.3. Service Definitions and RADIUS
496 RADIUS specifications define how an existing service or protocol can
497 be provisioned using RADIUS, usually via the Service-Type Attribute.
498 Therefore, it is expected that a RADIUS attribute specification will
499 reference documents defining the protocol or service to be
500 provisioned. Within the IETF, a RADIUS attribute specification
506 DeKok & Weber Best Current Practice [Page 9]
508 RFC 6158 RADIUS Design Guidelines March 2011
511 SHOULD NOT be used to define the protocol or service being
512 provisioned. New services using RADIUS for provisioning SHOULD be
513 defined elsewhere and referenced in the RADIUS specification.
515 New attributes, or new values of existing attributes, SHOULD NOT be
516 used to define new RADIUS commands. RADIUS attributes are intended
521 * authorize users (i.e., service provisioning or changes to
524 * account for user activity (i.e., logging of session activity)
526 Requirements for allocation of new commands (i.e., the Code field in
527 the packet header) and new attributes within the standard space are
528 described in [RFC3575], Section 2.1.
530 2.4. Translation of Vendor Specifications
532 [RFC2865], Section 5.26 defines Vendor-Specific Attributes as
535 This Attribute is available to allow vendors to support their own
536 extended Attributes not suitable for general usage. It MUST NOT
537 affect the operation of the RADIUS protocol.
539 Servers not equipped to interpret the vendor-specific information
540 sent by a client MUST ignore it (although it may be reported).
541 Clients which do not receive desired vendor-specific information
542 SHOULD make an attempt to operate without it, although they may do
543 so (and report they are doing so) in a degraded mode.
545 The limitation on changes to the RADIUS protocol effectively
546 prohibits VSAs from changing fundamental aspects of RADIUS operation,
547 such as modifying RADIUS packet sequences or adding new commands.
548 However, the requirement for clients and servers to be able to
549 operate in the absence of VSAs has proven to be less of a constraint
550 since it is still possible for a RADIUS client and server to mutually
551 indicate support for VSAs, after which behavior expectations can be
554 Therefore, RFC 2865 provides considerable latitude for development of
555 new attributes within the vendor space, while prohibiting development
556 of protocol variants. This flexibility implies that RADIUS
557 attributes can often be developed within the vendor space without
558 loss (and possibly even with gain) in functionality.
562 DeKok & Weber Best Current Practice [Page 10]
564 RFC 6158 RADIUS Design Guidelines March 2011
567 As a result, translation of RADIUS attributes developed within the
568 vendor space into the standard space may provide only modest
569 benefits, while accelerating the exhaustion of the standard space.
570 We do not expect that all RADIUS attribute specifications requiring
571 interoperability will be developed within the IETF, and allocated
572 from the standard space. A more scalable approach is to recognize
573 the flexibility of the vendor space, while working toward
574 improvements in the quality and availability of RADIUS attribute
575 specifications, regardless of where they are developed.
577 It is therefore NOT RECOMMENDED that specifications intended solely
578 for use by a vendor or SDO be translated into the standard space.
582 This section outlines the rationale behind the above recommendations.
584 3.1. RADIUS Operational Model
586 The RADIUS operational model includes several assumptions:
588 * The RADIUS protocol is stateless.
590 * Provisioning of services is not possible within an Access-Reject
591 or Disconnect-Request.
593 * There is a distinction between authorization checks and user
596 * The protocol provides for authentication and integrity
597 protection of packets.
599 * The RADIUS protocol is a Request/Response protocol.
601 * The protocol defines packet length restrictions.
603 While RADIUS server implementations may keep state, the RADIUS
604 protocol is stateless, although information may be passed from one
605 protocol transaction to another via the State Attribute. As a
606 result, documents that require stateful protocol behavior without use
607 of the State Attribute are inherently incompatible with RADIUS as
608 defined in [RFC2865] and MUST be redesigned. See [RFC5080], Section
609 2.1.1 for additional discussion surrounding the use of the State
612 As noted in [RFC5080], Section 2.6, the intent of an Access-Reject is
613 to deny access to the requested service. As a result, RADIUS does
614 not allow the provisioning of services within an Access-Reject or
618 DeKok & Weber Best Current Practice [Page 11]
620 RFC 6158 RADIUS Design Guidelines March 2011
623 Disconnect-Request. Documents that include provisioning of services
624 within an Access-Reject or Disconnect-Request are inherently
625 incompatible with RADIUS and need to be redesigned.
627 [RFC5176], Section 3 notes the following:
629 A Disconnect-Request MUST contain only NAS and session
630 identification attributes. If other attributes are included in a
631 Disconnect-Request, implementations MUST send a Disconnect-NAK; an
632 Error-Cause Attribute with value "Unsupported Attribute" MAY be
635 As a result, documents that include provisioning of services within a
636 Disconnect-Request are inherently incompatible with RADIUS and need
639 As noted in [RFC5080], Section 2.1.1, a RADIUS Access-Request may not
640 contain user authentication attributes or a State Attribute linking
641 the Access-Request to an earlier user authentication. Such an
642 Access-Request, known as an authorization check, provides no
643 assurance that it corresponds to a live user. RADIUS specifications
644 defining attributes containing confidential information (such as
645 Tunnel-Password) should be careful to prohibit such attributes from
646 being returned in response to an authorization check. Also,
647 [RFC5080], Section 2.1.1 notes that authentication mechanisms need to
648 tie a sequence of Access-Request/Access-Challenge packets together
649 into one authentication session. The State Attribute is RECOMMENDED
652 While [RFC2865] did not require authentication and integrity
653 protection of RADIUS Access-Request packets, subsequent
654 authentication mechanism specifications, such as RADIUS/EAP [RFC3579]
655 and Digest Authentication [RFC5090], have mandated authentication and
656 integrity protection for certain RADIUS packets. [RFC5080], Section
657 2.1.1 makes this behavior RECOMMENDED for all Access-Request packets,
658 including Access-Request packets performing authorization checks. It
659 is expected that specifications for new RADIUS authentication
660 mechanisms will continue this practice.
662 The RADIUS protocol as defined in [RFC2865] is a request-response
663 protocol spoken between RADIUS clients and servers. A single RADIUS
664 request packet ([RFC2865], [RFC2866], or [RFC5176]) will solicit in
665 response at most a single response packet, sent to the IP address and
666 port of the RADIUS client that originated the request. Changes to
667 this model are likely to require major revisions to existing
668 implementations, and this practice is NOT RECOMMENDED.
674 DeKok & Weber Best Current Practice [Page 12]
676 RFC 6158 RADIUS Design Guidelines March 2011
679 The Length field in the RADIUS packet header is defined in [RFC2865]
680 Section 3. It is noted there that the maximum length of a RADIUS
681 packet is 4096 octets. As a result, attribute designers SHOULD NOT
682 assume that a RADIUS implementation can successfully process RADIUS
683 packets larger than 4096 octets.
685 Even when packets are less than 4096 octets, they may be larger than
686 the Path Maximum Transmission Unit (PMTU). Any packet larger than
687 the PMTU will be fragmented, making communications more brittle as
688 firewalls and filtering devices often discard fragments. Transport
689 of fragmented UDP packets appears to be a poorly tested code path on
690 network devices. Some devices appear to be incapable of transporting
691 fragmented UDP packets, making it difficult to deploy RADIUS in a
692 network where those devices are deployed. We RECOMMEND that RADIUS
693 messages be kept as small possible.
695 If a situation is envisaged where it may be necessary to carry
696 authentication, authorization, or accounting data in a packet larger
697 than 4096 octets, then one of the following approaches is
700 1. Utilization of a sequence of packets.
701 For RADIUS authentication, a sequence of Access-
702 Request/Access-Challenge packets would be used. For this to
703 be feasible, attribute designers need to enable inclusion of
704 attributes that can consume considerable space within Access-
705 Challenge packets. To maintain compatibility with existing
706 NASes, either the use of Access-Challenge packets needs to be
707 permissible (as with RADIUS/EAP, defined in [RFC3579]) or
708 support for receipt of an Access-Challenge needs to be
709 indicated by the NAS (as in RADIUS Location [RFC5580]). Also,
710 the specification needs to clearly describe how attribute
711 splitting is to be signaled and how attributes included within
712 the sequence are to be interpreted, without requiring stateful
713 operation. Unfortunately, previous specifications have not
714 always exhibited the required foresight. For example, even
715 though very large filter rules are conceivable, the NAS-
716 Filter-Rule Attribute defined in [RFC4849] is not permitted in
717 an Access-Challenge packet, nor is a mechanism specified to
718 allow a set of NAS-Filter-Rule Attributes to be split across
719 an Access-Request/Access-Challenge sequence.
721 In the case of RADIUS accounting, transporting large amounts
722 of data would require a sequence of Accounting-Request
723 packets. This is a non-trivial change to RADIUS, since RADIUS
724 accounting clients would need to be modified to split the
730 DeKok & Weber Best Current Practice [Page 13]
732 RFC 6158 RADIUS Design Guidelines March 2011
735 attribute stream across multiple Accounting-Requests, and
736 billing servers would need to be modified to reassemble and
737 interpret the attribute stream.
739 2. Utilization of names rather than values.
740 Where an attribute relates to a policy that could conceivably
741 be pre-provisioned on the NAS, then the name of the pre-
742 provisioned policy can be transmitted in an attribute rather
743 than the policy itself, which could be quite large. An
744 example of this is the Filter-Id Attribute defined in
745 [RFC2865], Section 5.11, which enables a set of pre-
746 provisioned filter rules to be referenced by name.
748 3. Utilization of Packetization Layer Path MTU Discovery
749 techniques, as specified in [RFC4821].
750 As a last resort, where the above techniques cannot be made to
751 work, it may be possible to apply the techniques described in
752 [RFC4821] to discover the maximum supported RADIUS packet size
753 on the path between a RADIUS client and a home server. While
754 such an approach can avoid the complexity of utilization of a
755 sequence of packets, dynamic discovery is likely to be time
756 consuming and cannot be guaranteed to work with existing
757 RADIUS implementations. As a result, this technique is not
758 generally applicable.
760 3.2. Data Model Issues
762 While [RFC2865], Section 5 defines basic data types, later
763 specifications did not follow this practice. This problem has led
764 implementations to define their own names for data types, resulting
765 in non-standard names for those types.
767 In addition, the number of vendors and SDOs creating new attributes
768 within the vendor space has grown, and this has led to some
769 divergence in approaches to RADIUS attribute design. For example,
770 vendors and SDOs have evolved the data model to support functions
771 such as new data types along with attribute grouping and attribute
772 fragmentation, with different groups taking different approaches.
773 These approaches are often incompatible, leading to additional
774 complexity in RADIUS implementations.
776 In order to avoid repeating old mistakes, this section describes the
777 history of the RADIUS data model and attempts to codify existing
786 DeKok & Weber Best Current Practice [Page 14]
788 RFC 6158 RADIUS Design Guidelines March 2011
791 3.2.1. Issues with Definitions of Types
793 [RFC2865], Section 5 explicitly defines five data types: text,
794 string, address, integer, and time. Both the names and
795 interpretations of the types are given.
797 Subsequent RADIUS specifications defined attributes by using type
798 names not defined in [RFC2865], without defining the new names as
799 done in [RFC2865]. They did not consistently indicate the format of
800 the value field using the same conventions as [RFC2865]. As a
801 result, the data type is ambiguous in some cases and may not be
802 consistent among different implementations.
804 It is out of the scope of this document to resolve all potential
805 ambiguities within existing RADIUS specifications. However, in order
806 to prevent future ambiguities, it is RECOMMENDED that future RADIUS
807 attribute specifications explicitly define newly created data types
808 at the beginning of the document and indicate clearly the data type
809 to be used for each attribute.
811 For example, [RFC3162] utilizes, but does not explicitly define, a
812 type that encapsulates an IPv6 address (Sections 2.1 and 2.4) and
813 another type that encapsulates an IPv6 prefix (Section 2.3). The
814 IPv6 address attributes confusingly are referenced as type "Address"
815 in the document. This is a similar name as the "address" type
816 defined in [RFC2865], which was defined to refer solely to IPv4
819 While the Framed-Interface-Id Attribute defined in [RFC3162], Section
820 2.2 included a value field of 8 octets, the data type was not
821 explicitly indicated; therefore, there is controversy over whether
822 the format of the data was intended to be an 8-octet String or
823 whether a special Interface-Id type was intended.
825 Given that attributes encapsulating an IPv6 address and an IPv6
826 prefix are already in use, it is RECOMMENDED that RADIUS server
827 implementations include support for these as basic types, in addition
828 to the types defined in [RFC2865]. Where the intent is to represent
829 a specific IPv6 address, an "IPv6 address" type SHOULD be used.
830 Although it is possible to use an "IPv6 Prefix" type with a prefix
831 length of 128 to represent an IPv6 address, this usage is NOT
832 RECOMMENDED. Implementations supporting the Framed-Interface-Id
833 Attribute may select a data type of their choosing (most likely an
834 8-octet String or a special "Interface Id" data type).
842 DeKok & Weber Best Current Practice [Page 15]
844 RFC 6158 RADIUS Design Guidelines March 2011
847 It is worth noting that since RADIUS only supports unsigned integers
848 of 32 bits, attributes using signed integer data types or unsigned
849 integer types of other sizes will require code changes and SHOULD be
852 For [RFC2865] RADIUS VSAs, the length limitation of the String and
853 Text types is 247 octets instead of 253 octets, due to the additional
854 overhead of the Vendor-Specific Attribute.
856 3.2.2. Tagging Mechanism
858 [RFC2868] defines an attribute grouping mechanism based on the use of
859 a one-octet tag value. Tunnel attributes that refer to the same
860 tunnel are grouped together by virtue of using the same tag value.
862 This tagging mechanism has some drawbacks. There are a limited
863 number of unique tags (31). The tags are not well suited for use
864 with arbitrary binary data values because it is not always possible
865 to tell if the first byte after the Length is the tag or the first
866 byte of the untagged value (assuming the tag is optional).
868 Other limitations of the tagging mechanism are that when integer
869 values are tagged, the value portion is reduced to three bytes,
870 meaning only 24-bit numbers can be represented. The tagging
871 mechanism does not offer an ability to create nested groups of
872 attributes. Some RADIUS implementations treat tagged attributes as
873 having the additional data types tagged-string and tagged-integer.
874 These types increase the complexity of implementing and managing
877 For these reasons, the tagging scheme described in RFC 2868 is NOT
878 RECOMMENDED for use as a generic grouping mechanism.
880 3.2.3. Complex Data Types
882 As described in this section, the creation of complex types can lead
883 to interoperability and deployment issues, so they need to be
884 introduced with care. For example, the RADIUS attribute encoding is
885 summarized in [RFC2865]:
888 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
890 | Type | Length | Value ...
891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
898 DeKok & Weber Best Current Practice [Page 16]
900 RFC 6158 RADIUS Design Guidelines March 2011
903 However, some standard attributes pack multiple sub-fields into the
904 "Value" field, resulting in the creation a non-standard, i.e.,
905 complex, type. Separating these sub-fields into different
906 attributes, each with its own type and length, would have the
909 * When manual data entry is required, it is easier for an
910 administrator to enter the data as well-known types rather than
911 as complex structures.
913 * It enables additional error checking by leveraging the parsing
914 and validation routines for well-known types.
916 * It simplifies implementations by eliminating special-case,
917 attribute-specific parsing.
919 One of the fundamental goals of the RADIUS protocol design was to
920 allow RADIUS servers to be configured to support new attributes,
921 without requiring server code changes. RADIUS server implementations
922 typically provide support for basic data types and define attributes
923 in a data dictionary. This architecture enables a new attribute to
924 be supported by the addition of a dictionary entry, without requiring
925 other RADIUS server code changes.
927 Code changes can also be required in policy management systems and in
928 the RADIUS server's receive path. These changes are due to
929 limitations in RADIUS server policy languages, which commonly provide
930 for limited operations (such as comparisons or arithmetic operations)
931 on the existing data types. Many existing RADIUS policy languages
932 typically are not capable of parsing sub-elements or providing more
933 sophisticated matching functionality.
935 On the RADIUS client, code changes are typically required in order to
936 implement a new attribute. The RADIUS client typically has to
937 compose the attribute dynamically when sending. When receiving, a
938 RADIUS client needs to be able to parse the attribute and carry out
939 the requested service. As a result, a detailed understanding of the
940 new attribute is required on clients, and data dictionaries are less
941 useful on clients than on servers.
943 Given these limitations, the introduction of new types can require
944 code changes on the RADIUS server, which would be unnecessary if
945 basic data types had been used instead. In addition, if "ad hoc"
946 types are used, attribute-specific parsing is required, which means
947 more complex software to develop and maintain. More complexity can
948 lead to more error-prone implementations, interoperability problems,
954 DeKok & Weber Best Current Practice [Page 17]
956 RFC 6158 RADIUS Design Guidelines March 2011
959 and even security vulnerabilities. These issues can increase costs
960 to network administrators as well as reduce reliability and introduce
963 3.2.4. Complex Data Type Exceptions
965 As described in Section 2.1, the introduction of complex data types
966 is discouraged where viable alternatives are available. A potential
967 exception is attributes that inherently require code changes on both
968 the client and server. For example, as described in Appendix B,
969 complex attributes have been used in situations involving
970 authentication and security attributes, which need to be dynamically
971 computed and verified. Supporting this functionality requires code
972 changes on both the RADIUS client and server, regardless of the
973 attribute format. As a result, in most cases, the use of complex
974 attributes to represent these methods is acceptable and does not
975 create additional interoperability or deployment issues.
977 Another exception to the recommendation against complex types is for
978 types that can be treated as opaque data by the RADIUS server. For
979 example, the EAP-Message Attribute, defined in [RFC3579], Section
980 3.1, contains a complex data type that is an Extensible
981 Authentication Protocol (EAP) packet. Since these complex types do
982 not need to be parsed by the RADIUS server, the issues arising from
983 server limitations do not arise. Similarly, since attributes of
984 these complex types can be configured on the server using a data type
985 of String, dictionary limitations are also not encountered. Appendix
986 A.1 includes a series of checklists that may be used to analyze a
987 design for RECOMMENDED and NOT RECOMMENDED behavior in relation to
990 If the RADIUS Server simply passes the contents of an attribute to
991 some non-RADIUS portion of the network, then the data is opaque to
992 RADIUS and SHOULD be defined to be of type String. A concrete way of
993 judging this requirement is whether or not the attribute definition
994 in the RADIUS document contains delineated fields for sub-parts of
995 the data. If those fields need to be delineated in RADIUS, then the
996 data is not opaque to RADIUS, and it SHOULD be separated into
997 individual RADIUS attributes.
999 An examination of existing RADIUS RFCs discloses a number of complex
1000 attributes that have already been defined. Appendix B includes a
1001 listing of complex attributes used within [RFC2865], [RFC2868],
1002 [RFC2869], [RFC3162], [RFC4818], and [RFC4675]. The discussion of
1003 these attributes includes reasons why a complex type is acceptable or
1004 suggestions for how the attribute could have been defined to follow
1005 the RADIUS data model.
1010 DeKok & Weber Best Current Practice [Page 18]
1012 RFC 6158 RADIUS Design Guidelines March 2011
1015 In other cases, the data in the complex type are described textually
1016 in a specification. This is possible because the data types are not
1017 sent within the attributes but are a matter for endpoint
1018 interpretation. An implementation can define additional data types
1019 and use these data types today by matching them to the attribute's
1024 The usage model for RADIUS VSAs is described in [RFC2865], Section
1027 Note that RADIUS defines a mechanism for Vendor-Specific
1028 extensions (Attribute 26) and the use of that should be encouraged
1029 instead of allocation of global attribute types, for functions
1030 specific only to one vendor's implementation of RADIUS, where no
1031 interoperability is deemed useful.
1033 Nevertheless, many new attributes have been defined in the vendor
1034 space in situations where interoperability is not only useful but is
1035 required. For example, SDOs outside the IETF (such as the IEEE 802
1036 and the 3rd Generation Partnership Project (3GPP)) have been assigned
1037 Vendor-Ids, enabling them to define their own VSA encoding and assign
1038 Vendor types within their own vendor space, as defined by their
1041 The use of VSAs by SDOs outside the IETF has gained in popularity for
1045 As with SNMP, which defines an "Enterprise" Object Identifier
1046 (OID) space suitable for use by vendors as well as other SDOs, the
1047 definition of Vendor-Specific Attributes has become a common
1048 occurrence as part of standards activity outside the IETF. For
1049 reasons of efficiency, it is easiest if the RADIUS attributes
1050 required to manage a standard are developed within the same SDO
1051 that develops the standard itself. As noted in "Transferring MIB
1052 Work from IETF Bridge MIB WG to IEEE 802.1 WG" [RFC4663], today
1053 few vendors are willing to simultaneously fund individuals to
1054 participate within an SDO to complete a standard as well as to
1055 participate in the IETF in order to complete the associated RADIUS
1056 attributes specification.
1059 The standard space is limited to 255 unique attributes. Of these,
1060 only about half remain available for allocation. In the vendor
1061 space, the number of attributes available is a function of the
1062 encoding of the attribute (the size of the Vendor type field).
1066 DeKok & Weber Best Current Practice [Page 19]
1068 RFC 6158 RADIUS Design Guidelines March 2011
1071 3.3.1. Interoperability Considerations
1073 Vendors and SDOs are reminded that the standard space and the
1074 enumerated value space for enumerated attributes are reserved for
1075 allocation through work published via the IETF, as noted in
1076 [RFC3575], Section 2.1. In the past, some vendors and SDOs have
1077 assigned vendor-specific meaning to "unused" values from the standard
1078 space. This process results in interoperability issues and is
1079 counterproductive. Similarly, the vendor-specific enumeration
1080 practice discussed in [RFC2882], Section 2.2.1 is NOT RECOMMENDED.
1082 If it is not possible to follow the IETF process, vendors and SDOs
1083 SHOULD self-allocate an attribute, which MUST be in their own vendor
1084 space as defined by their unique Vendor-Id, as discussed in Sections
1087 The design and specification of VSAs for multi-vendor usage SHOULD be
1088 undertaken with the same level of care as standard RADIUS attributes.
1089 Specifically, the provisions of this document that apply to standard
1090 RADIUS attributes also apply to VSAs for multi-vendor usage.
1092 3.3.2. Vendor Allocations
1094 As noted in [RFC3575], Section 2.1, vendors are encouraged to utilize
1095 VSAs to define functions "specific only to one vendor's
1096 implementation of RADIUS, where no interoperability is deemed useful.
1097 For functions specific only to one vendor's implementation of RADIUS,
1098 the use of that should be encouraged instead of the allocation of
1099 global attribute types".
1101 The recommendation for vendors to allocate attributes from a vendor
1102 space rather than via the IETF process is a recognition that vendors
1103 desire to assert change control over their own RADIUS specifications.
1104 This change control can be obtained by requesting a PEN from the
1105 Internet Assigned Number Authority (IANA) for use as a Vendor-Id
1106 within a Vendor-Specific Attribute. The vendor can then allocate
1107 attributes within the vendor space defined by that Vendor-Id at their
1108 sole discretion. Similarly, the use of data types (complex or
1109 otherwise) within that vendor space is solely under the discretion of
1112 3.3.3. SDO Allocations
1114 Given the expanded utilization of RADIUS, it has become apparent that
1115 requiring SDOs to accomplish all their RADIUS work within the IETF is
1116 inherently inefficient and unscalable. It is therefore RECOMMENDED
1122 DeKok & Weber Best Current Practice [Page 20]
1124 RFC 6158 RADIUS Design Guidelines March 2011
1127 that SDO RADIUS Attribute specifications allocate attributes from the
1128 vendor space rather than request an allocation from the RADIUS
1129 standard space for attributes matching any of the following criteria:
1131 * Attributes relying on data types not defined within RADIUS
1133 * Attributes intended primarily for use within an SDO
1135 * Attributes intended primarily for use within a group of SDOs
1137 Any new RADIUS attributes or values intended for interoperable use
1138 across a broad spectrum of the Internet community SHOULD follow the
1139 allocation process defined in [RFC3575].
1141 The recommendation for SDOs to allocate attributes from a vendor
1142 space rather than via the IETF process is a recognition that SDOs
1143 desire to assert change control over their own RADIUS specifications.
1144 This change control can be obtained by requesting a PEN from the
1145 Internet Assigned Number Authority (IANA) for use as a Vendor-Id
1146 within a Vendor-Specific Attribute. The SDO can then allocate
1147 attributes within the vendor space defined by that Vendor-Id at their
1148 sole discretion. Similarly, the use of data types (complex or
1149 otherwise) within that vendor space is solely under the discretion of
1152 3.4. Polymorphic Attributes
1154 A polymorphic attribute is one whose format or meaning is dynamic.
1155 For example, rather than using a fixed data format, an attribute's
1156 format might change based on the contents of another attribute. Or,
1157 the meaning of an attribute may depend on earlier packets in a
1160 RADIUS server dictionary entries are typically static, enabling the
1161 user to enter the contents of an attribute without support for
1162 changing the format based on dynamic conditions. However, this
1163 limitation on static types does not prevent implementations from
1164 implementing policies that return different attributes based on the
1165 contents of received attributes; this is a common feature of existing
1166 RADIUS implementations.
1168 In general, polymorphism is NOT RECOMMENDED. Polymorphism rarely
1169 enables capabilities that would not be available through use of
1170 multiple attributes. Polymorphism requires code changes in the
1171 RADIUS server in situations where attributes with fixed formats would
1172 not require such changes. Thus, polymorphism increases complexity
1173 while decreasing generality, without delivering any corresponding
1178 DeKok & Weber Best Current Practice [Page 21]
1180 RFC 6158 RADIUS Design Guidelines March 2011
1183 Note that changing an attribute's format dynamically is not the same
1184 thing as using a fixed format and computing the attribute itself
1185 dynamically. RADIUS authentication attributes, such as User-
1186 Password, EAP-Message, etc., while being computed dynamically, use a
1189 4. IANA Considerations
1191 This document has no action items for IANA. However, it does provide
1192 guidelines for Expert Reviewers appointed as described in [RFC3575].
1194 5. Security Considerations
1196 This specification provides guidelines for the design of RADIUS
1197 attributes used in authentication, authorization, and accounting.
1198 Threats and security issues for this application are described in
1199 [RFC3579] and [RFC3580]; security issues encountered in roaming are
1200 described in [RFC2607].
1202 Obfuscation of RADIUS attributes on a per-attribute basis is
1203 necessary in some cases. The current standard mechanism for this is
1204 described in [RFC2865], Section 5.2 (for obscuring User-Password
1205 values) and is based on the MD5 algorithm specified in [RFC1321].
1206 The MD5 and SHA-1 algorithms have recently become a focus of scrutiny
1207 and concern in security circles, and as a result, the use of these
1208 algorithms in new attributes is NOT RECOMMENDED. In addition,
1209 previous documents referred to this method as generating "encrypted"
1210 data. This terminology is no longer accepted within the
1211 cryptographic community.
1213 Where new RADIUS attributes use cryptographic algorithms, algorithm
1214 negotiation SHOULD be supported. Specification of a mandatory-to-
1215 implement algorithm is REQUIRED, and it is RECOMMENDED that the
1216 mandatory-to-implement algorithm be certifiable under FIPS 140
1219 Where new RADIUS attributes encapsulate complex data types, or
1220 transport opaque data, the security considerations discussed in
1221 Section 5.1 SHOULD be addressed.
1223 Message authentication in RADIUS is provided largely via the Message-
1224 Authenticator attribute. See Section 3.2 of [RFC3579] and also
1225 Section 2.2.2 of [RFC5080], which say that client implementations
1226 SHOULD include a Message-Authenticator Attribute in every Access-
1234 DeKok & Weber Best Current Practice [Page 22]
1236 RFC 6158 RADIUS Design Guidelines March 2011
1239 In general, the security of the RADIUS protocol is poor. Robust
1240 deployments SHOULD support a secure communications protocol such as
1241 IPsec. See Section 4 of [RFC3579] and Section 5 of [RFC3580] for a
1242 more in-depth explanation of these issues.
1244 Implementations not following the suggestions outlined in this
1245 document may be subject to problems such as ambiguous protocol
1246 decoding, packet loss leading to loss of billing information, and
1247 denial-of-service attacks.
1249 5.1. New Data Types and Complex Attributes
1251 The introduction of complex data types brings the potential for the
1252 introduction of new security vulnerabilities. Experience shows that
1253 the common data types have few security vulnerabilities, or else that
1254 all known issues have been found and fixed. New data types require
1255 new code, which may introduce new bugs and therefore new attack
1258 Some systems permit complex attributes to be defined via a method
1259 that is more capable than traditional RADIUS dictionaries. These
1260 systems can reduce the security threat of new types significantly,
1261 but they do not remove it entirely.
1263 RADIUS servers are highly valued targets, as they control network
1264 access and interact with databases that store usernames and
1265 passwords. An extreme outcome of a vulnerability due to a new,
1266 complex type would be that an attacker is capable of taking complete
1267 control over the RADIUS server.
1269 The use of attributes representing opaque data does not reduce this
1270 threat. The threat merely moves from the RADIUS server to the system
1271 that consumes that opaque data. The threat is particularly severe
1272 when the opaque data originates from the user and is not validated by
1273 the NAS. In those cases, the RADIUS server is potentially exposed to
1274 attack by malware residing on an unauthenticated host.
1276 Any system consuming opaque data that originates from a RADIUS system
1277 SHOULD be properly isolated from that RADIUS system and SHOULD run
1278 with minimal privileges. Any potential vulnerabilities in the non-
1279 RADIUS system will then have minimal impact on the security of the
1290 DeKok & Weber Best Current Practice [Page 23]
1292 RFC 6158 RADIUS Design Guidelines March 2011
1297 6.1. Normative References
1299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1300 Requirement Levels", BCP 14, RFC 2119, March 1997.
1302 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
1303 "Remote Authentication Dial In User Service (RADIUS)",
1304 RFC 2865, June 2000.
1306 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
1307 Authentication Dial In User Service)", RFC 3575, July
1310 6.2. Informative References
1312 [RFC1155] Rose, M. and K. McCloghrie, "Structure and
1313 identification of management information for TCP/IP-
1314 based internets", STD 16, RFC 1155, May 1990.
1316 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
1317 "Simple Network Management Protocol (SNMP)", RFC 1157,
1320 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1323 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS
1324 Attributes", RFC 2548, March 1999.
1326 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
1327 Implementation in Roaming", RFC 2607, June 1999.
1329 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
1331 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
1332 Holdrege, M., and I. Goyret, "RADIUS Attributes for
1333 Tunnel Protocol Support", RFC 2868, June 2000.
1335 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS
1336 Extensions", RFC 2869, June 2000.
1338 [RFC2882] Mitton, D., "Network Access Servers Requirements:
1339 Extended RADIUS Practices", RFC 2882, July 2000.
1341 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
1342 RFC 3162, August 2001.
1346 DeKok & Weber Best Current Practice [Page 24]
1348 RFC 6158 RADIUS Design Guidelines March 2011
1351 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote
1352 Authentication Dial In User Service) Support For
1353 Extensible Authentication Protocol (EAP)", RFC 3579,
1356 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J.
1357 Roese, "IEEE 802.1X Remote Authentication Dial In User
1358 Service (RADIUS) Usage Guidelines", RFC 3580, September
1361 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
1362 10646", STD 63, RFC 3629, November 2003.
1364 [RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers
1365 of MIB Documents", BCP 111, RFC 4181, September 2005.
1367 [RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge
1368 MIB WG to IEEE 802.1 WG", RFC 4663, September 2006.
1370 [RFC4675] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS
1371 Attributes for Virtual LAN and Priority Support", RFC
1372 4675, September 2006.
1374 [RFC4679] Mammoliti, V., Zorn, G., Arberg, P., and R. Rennison,
1375 "DSL Forum Vendor-Specific RADIUS Attributes", RFC
1376 4679, September 2006.
1378 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
1379 Attribute", RFC 4818, April 2007.
1381 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path
1382 MTU Discovery", RFC 4821, March 2007.
1384 [RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter
1385 Rule Attribute", RFC 4849, April 2007.
1387 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
1388 Dial In User Service (RADIUS) Implementation Issues and
1389 Suggested Fixes", RFC 5080, December 2007.
1391 [RFC5090] Sterman, B., Sadolevsky, D., Schwartz, D., Williams,
1392 D., and W. Beck, "RADIUS Extension for Digest
1393 Authentication", RFC 5090, February 2008.
1395 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
1396 Aboba, "Dynamic Authorization Extensions to Remote
1397 Authentication Dial In User Service (RADIUS)", RFC
1402 DeKok & Weber Best Current Practice [Page 25]
1404 RFC 6158 RADIUS Design Guidelines March 2011
1407 [DOCTORS] AAA Doctors Mailing List, www.ietf.org/mail-
1408 archive/web/aaa-doctors.
1410 [FIPS] FIPS 140-3 (DRAFT), "Security Requirements for
1411 Cryptographic Modules",
1412 http://csrc.nist.gov/publications/PubsFIPS.html.
1414 [IEEE-802.1Q] IEEE Standards for Local and Metropolitan Area
1415 Networks: Draft Standard for Virtual Bridged Local Area
1416 Networks, P802.1Q-2003, January 2003.
1418 [RFC5580] Tschofenig, H., Ed., Adrangi, F., Jones, M., Lior, A.,
1419 and B. Aboba, "Carrying Location Objects in RADIUS and
1420 Diameter", RFC 5580, August 2009.
1422 [AAA-SIP] Sterman, B., Sadolevsky, D., Schwartz, D., Williams,
1423 D., and W. Beck, "RADIUS Extension for Digest
1424 Authentication", Work in Progress, November 2004.
1458 DeKok & Weber Best Current Practice [Page 26]
1460 RFC 6158 RADIUS Design Guidelines March 2011
1463 Appendix A. Design Guidelines Checklist
1465 The following text provides guidelines for the design of attributes
1466 used by the RADIUS protocol. Specifications that follow these
1467 guidelines are expected to achieve maximum interoperability with
1468 minimal changes to existing systems.
1470 A.1. Types Matching the RADIUS Data Model
1472 A.1.1. Transport of Basic Data Types
1474 Does the data fit within the basic data types described in Section
1475 2.1? If so, it SHOULD be encapsulated in a [RFC2865] format RADIUS
1476 attribute or in a [RFC2865] format RADIUS VSA that uses one of the
1477 existing RADIUS data types.
1479 A.1.2. Transport of Authentication and Security Data
1481 Does the data provide authentication and/or security capabilities for
1482 the RADIUS protocol as outlined below? If so, use of a complex data
1483 type is acceptable under the following circumstances:
1485 * Complex data types that carry authentication methods that RADIUS
1486 servers are expected to parse and verify as part of an
1487 authentication process.
1489 * Complex data types that carry security information intended to
1490 increase the security of the RADIUS protocol itself.
1492 Any data type carrying authentication and/or security data that is
1493 not meant to be parsed by a RADIUS server is an "opaque data type",
1494 as defined in Section A.1.3.
1496 A.1.3. Opaque Data Types
1498 Does the attribute encapsulate an existing data structure defined
1499 outside of the RADIUS specifications? Can the attribute be treated
1500 as opaque data by RADIUS servers (including proxies)? If both
1501 questions can be answered affirmatively, a complex structure MAY be
1502 used in a RADIUS specification.
1504 The specification of the attribute SHOULD define the encapsulating
1505 attribute to be of type String. The specification SHOULD refer to an
1506 external document defining the structure. The specification SHOULD
1507 NOT define or describe the structure, for reasons discussed in
1514 DeKok & Weber Best Current Practice [Page 27]
1516 RFC 6158 RADIUS Design Guidelines March 2011
1519 A.1.4. Pre-Existing Data Types
1521 There is a trade-off in design between reusing existing formats for
1522 historical compatibility or choosing new formats for a "better"
1523 design. This trade-off does not always require the "better" design
1524 to be used. As a result, pre-existing complex data types described
1525 in Appendix B MAY be used.
1527 A.2. Improper Data Types
1529 This section suggests alternatives to data types that do not fall
1530 within the "basic data type" definition. Section A.2.1 describes
1531 simple data types, which should be replaced by basic data types.
1532 Section A.2.2 describes more complex data types, which should be
1533 replaced by multiple attributes using the basic data types.
1535 A.2.1. Simple Data Types
1537 Does the attribute use any of the following data types? If so, the
1538 data type SHOULD be replaced with the suggested alternatives, or it
1539 SHOULD NOT be used at all.
1541 * Signed integers of any size.
1542 SHOULD NOT be used. SHOULD be replaced with one or more
1543 unsigned integer attributes. The definition of the attribute
1544 can contain information that would otherwise go into the sign
1545 value of the integer.
1547 * 8-bit unsigned integers.
1548 SHOULD be replaced with 32-bit unsigned integer. There is
1549 insufficient justification to save three bytes.
1551 * 16-bit unsigned integers.
1552 SHOULD be replaced with 32-bit unsigned integer. There is
1553 insufficient justification to save two bytes.
1555 * Unsigned integers of size other than 32 bits.
1556 SHOULD be replaced by an unsigned integer of 32 bits. There is
1557 insufficient justification to define a new size of integer.
1559 * Integers of any size in non-network byte order.
1560 SHOULD be replaced by unsigned integer of 32 bits in network.
1561 There is no reason to transport integers in any format other
1562 than network byte order.
1564 * Multi-field text strings.
1565 Each field SHOULD be encapsulated in a separate attribute.
1570 DeKok & Weber Best Current Practice [Page 28]
1572 RFC 6158 RADIUS Design Guidelines March 2011
1575 * Polymorphic attributes.
1576 Multiple attributes, each with a static data type, SHOULD be
1579 * Nested attribute-value pairs (AVPs).
1580 Attributes should be defined in a flat typespace.
1582 A.2.2. More Complex Data Types
1586 * define a complex data type not described in Appendix B?
1588 * that a RADIUS server and/or client is expected to parse,
1589 validate, or create the contents of via a dynamic computation
1590 (i.e., a type that cannot be treated as opaque data (Section
1593 * involve functionality that could be implemented without code
1594 changes on both the client and server (i.e., a type that doesn't
1595 require dynamic computation and verification, such as those
1596 performed for authentication or security attributes)?
1598 If so, this data type SHOULD be replaced with simpler types, as
1599 discussed in Appendix A.2.1. See also Section 2.1 for a discussion
1600 of why complex types are problematic.
1602 A.3. Vendor-Specific Formats
1604 Does the specification contain Vendor-Specific Attributes that match
1605 any of the following criteria? If so, the VSA encoding should be
1606 replaced with the [RFC2865], Section 5.26 encoding or should not be
1609 * Vendor types of more than 8 bits.
1610 SHOULD NOT be used. Vendor types of 8 bits SHOULD be used
1613 * Vendor lengths of less than 8 bits (i.e., zero bits).
1614 SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used
1617 * Vendor lengths of more than 8 bits.
1618 SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used
1626 DeKok & Weber Best Current Practice [Page 29]
1628 RFC 6158 RADIUS Design Guidelines March 2011
1631 * Vendor-specific contents that are not in Type-Length-Value
1633 SHOULD NOT be used. Vendor-Specific Attributes SHOULD be in
1634 Type-Length-Value format.
1636 In general, Vendor-Specific Attributes SHOULD follow the encoding
1637 suggested in Section 5.26 of [RFC2865]. Vendor extensions to non-
1638 standard encodings are NOT RECOMMENDED as they can negatively affect
1641 A.4. Changes to the RADIUS Operational Model
1643 Does the specification change the RADIUS operation model as outlined
1644 in the list below? If so, then another method of achieving the
1645 design objectives SHOULD be used. Potential problem areas include
1648 * Defining new commands in RADIUS using attributes.
1649 The addition of new commands to RADIUS MUST be handled via
1650 allocation of a new Code and not by the use of an attribute.
1651 This restriction includes new commands created by overloading
1652 the Service-Type Attribute to define new values that modify the
1653 functionality of Access-Request packets.
1655 * Using RADIUS as a transport protocol for data unrelated to
1656 authentication, authorization, or accounting.
1657 Using RADIUS to transport authentication methods such as EAP is
1658 explicitly permitted, even if those methods require the
1659 transport of relatively large amounts of data. Transport of
1660 opaque data relating to AAA is also permitted, as discussed in
1661 Section 3.2.3. However, if the specification does not relate to
1662 AAA, then RADIUS SHOULD NOT be used.
1664 * Assuming support for packet lengths greater than 4096 octets.
1665 Attribute designers cannot assume that RADIUS implementations
1666 can successfully handle packets larger than 4096 octets. If a
1667 specification could lead to a RADIUS packet larger than 4096
1668 octets, then the alternatives described in Section 3.3 SHOULD be
1671 * Stateless operation.
1672 The RADIUS protocol is stateless, and documents that require
1673 stateful protocol behavior without the use of the State
1674 Attribute need to be redesigned.
1682 DeKok & Weber Best Current Practice [Page 30]
1684 RFC 6158 RADIUS Design Guidelines March 2011
1687 * Provisioning of service in an Access-Reject.
1688 Such provisioning is not permitted, and MUST NOT be used. If
1689 limited access needs to be provided, then an Access-Accept with
1690 appropriate authorizations can be used instead.
1692 * Provisioning of service in a Disconnect-Request.
1693 Such provisioning is not permitted and MUST NOT be used. If
1694 limited access needs to be provided, then a CoA-Request
1695 [RFC5176] with appropriate authorizations can be used instead.
1697 * Lack of user authentication or authorization restrictions.
1698 In an authorization check, where there is no demonstration of a
1699 live user, confidential data cannot be returned. Where there is
1700 a link to a previous user authentication, the State Attribute
1703 * Lack of per-packet integrity and authentication.
1704 It is expected that documents will support per-packet integrity
1707 * Modification of RADIUS packet sequences.
1708 In RADIUS, each request is encapsulated in its own packet and
1709 elicits a single response that is sent to the requester. Since
1710 changes to this paradigm are likely to require major
1711 modifications to RADIUS client and server implementations, they
1712 SHOULD be avoided if possible.
1714 For further details, see Section 3.1.
1716 A.5. Allocation of Attributes
1718 Does the attribute have a limited scope of applicability as outlined
1719 below? If so, then the attributes SHOULD be allocated from the
1720 vendor space rather than requesting allocation from the standard
1723 * attributes intended for a vendor to support their own systems
1724 and not suitable for general usage
1726 * attributes relying on data types not defined within RADIUS
1728 * attributes intended primarily for use within an SDO
1730 * attributes intended primarily for use within a group of SDOs
1732 Note that the points listed above do not relax the recommendations
1733 discussed in this document. Instead, they recognize that the RADIUS
1734 data model has limitations. In certain situations where
1738 DeKok & Weber Best Current Practice [Page 31]
1740 RFC 6158 RADIUS Design Guidelines March 2011
1743 interoperability can be strongly constrained by the SDO or vendor, an
1744 expanded data model MAY be used. It is RECOMMENDED, however, that
1745 the RADIUS data model be used, even when it is marginally less
1746 efficient than alternatives.
1748 When attributes are used primarily within a group of SDOs, and are
1749 not applicable to the wider Internet community, we expect that one
1750 SDO will be responsible for allocation from their own private vendor
1753 Appendix B. Complex Attributes
1755 This appendix summarizes RADIUS attributes with complex data types
1756 that are defined in existing RFCs.
1758 This appendix is published for informational purposes only and
1759 reflects the usage of attributes with complex data types at the time
1760 of the publication of this document.
1764 [RFC2865], Section 5.3 defines the CHAP-Password Attribute, which is
1765 sent from the RADIUS client to the RADIUS server in an Access-
1766 Request. The data type of the CHAP Identifier is not given, only the
1770 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
1771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1772 | Type | Length | CHAP Ident | String ...
1773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
1775 Since this is an authentication attribute, code changes are required
1776 on the RADIUS client and server to support it, regardless of the
1777 attribute format. Therefore, this complex data type is acceptable in
1782 [RFC2865], Section 5.40 defines the CHAP-Challenge Attribute, which
1783 is sent from the RADIUS client to the RADIUS server in an Access-
1784 Request. While the data type of the CHAP Identifier is given, the
1787 If the CHAP challenge value is 16 octets long it MAY be placed in
1788 the Request Authenticator field instead of using this attribute.
1794 DeKok & Weber Best Current Practice [Page 32]
1796 RFC 6158 RADIUS Design Guidelines March 2011
1799 Defining attributes to contain values taken from the RADIUS packet
1800 header is NOT RECOMMENDED. Attributes should have values that are
1801 packed into a RADIUS AVP.
1803 B.3. Tunnel-Password
1805 [RFC2868], Section 3.5 defines the Tunnel-Password Attribute, which
1806 is sent from the RADIUS server to the client in an Access-Accept.
1807 This attribute includes Tag and Salt fields, as well as a String
1808 field that consists of three logical sub-fields: the Data-Length
1809 (required and one octet), Password sub-fields (required), and the
1810 optional Padding sub-field. The attribute appears as follows:
1813 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
1814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1815 | Type | Length | Tag | Salt
1816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1817 Salt (cont) | String ...
1818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1820 Since this is a security attribute, code changes are required on the
1821 RADIUS client and server to support it, regardless of the attribute
1822 format. However, while use of a complex data type is acceptable in
1823 this situation, the design of the Tunnel-Password Attribute is
1824 problematic from a security perspective since it uses MD5 as a cipher
1825 and provides a password to a NAS, potentially without proper
1830 [RFC2869], Section 5.4 defines the ARAP-Password Attribute, which is
1831 sent from the RADIUS client to the server in an Access-Request. It
1832 contains four 4-octet values instead of having a single Value field:
1835 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
1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1837 | Type | Length | Value1
1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1850 DeKok & Weber Best Current Practice [Page 33]
1852 RFC 6158 RADIUS Design Guidelines March 2011
1855 As with the CHAP-Password Attribute, this is an authentication
1856 attribute that would have required code changes on the RADIUS client
1857 and server, regardless of format.
1861 [RFC2869], Section 5.5 defines the ARAP-Features Attribute, which is
1862 sent from the RADIUS server to the client in an Access-Accept or
1863 Access-Challenge. It contains a compound string of two single octet
1864 values, plus three 4-octet values, which the RADIUS client
1865 encapsulates in a feature flags packet in the Apple Remote Access
1869 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
1870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1871 | Type | Length | Value1 | Value2 |
1872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1880 Unlike the previous attributes, this attribute contains no encrypted
1881 component, nor is it directly involved in authentication. The
1882 individual sub-fields therefore could have been encapsulated in
1883 separate attributes.
1885 While the contents of this attribute are intended to be placed in an
1886 ARAP packet, the fields need to be set by the RADIUS server. Using
1887 standard RADIUS data types would have simplified RADIUS server
1888 implementations and subsequent management. The current form of the
1889 attribute requires either the RADIUS server implementation or the
1890 RADIUS server administrator to understand the internals of the ARAP
1895 [RFC2869], Section 5.11 defines the Connect-Info Attribute, which is
1896 used to indicate the nature of the connection.
1899 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1901 | Type | Length | Text...
1902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1906 DeKok & Weber Best Current Practice [Page 34]
1908 RFC 6158 RADIUS Design Guidelines March 2011
1911 Even though the type is Text, the rest of the description indicates
1912 that it is a complex attribute:
1914 The Text field consists of UTF-8 encoded 10646 [8] characters.
1915 The connection speed SHOULD be included at the beginning of the
1916 first Connect-Info attribute in the packet. If the transmit and
1917 receive connection speeds differ, they may both be included in the
1918 first attribute with the transmit speed first (the speed the NAS
1919 modem transmits at), a slash (/), the receive speed, then
1920 optionally other information.
1922 For example, "28800 V42BIS/LAPM" or "52000/31200 V90"
1924 More than one Connect-Info attribute may be present in an
1925 Accounting-Request packet to accommodate expected efforts by ITU
1926 to have modems report more connection information in a standard
1927 format that might exceed 252 octets.
1929 This attribute contains no encrypted component and is not directly
1930 involved in authentication. The individual sub-fields could
1931 therefore have been encapsulated in separate attributes.
1933 However, since the definition refers to potential standardization
1934 activity within ITU, the Connect-Info Attribute can also be thought
1935 of as opaque data whose definition is provided elsewhere. The
1936 Connect-Info Attribute could therefore qualify for an exception as
1937 described in Section 3.2.4.
1939 B.7. Framed-IPv6-Prefix
1941 Section 2.3 of [RFC3162] defines the Framed-IPv6-Prefix Attribute,
1942 and Section 3 of [RFC4818] reuses this format for the Delegated-
1943 IPv6-Prefix Attribute; these attributes are sent from the RADIUS
1944 server to the client in an Access-Accept.
1947 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
1948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1949 | Type | Length | Reserved | Prefix-Length |
1950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1962 DeKok & Weber Best Current Practice [Page 35]
1964 RFC 6158 RADIUS Design Guidelines March 2011
1967 The sub-fields encoded in these attributes are strongly related, and
1968 there was no previous definition of this data structure that could be
1969 referenced. Support for this attribute requires code changes on both
1970 the client and server, due to a new data type being defined. In this
1971 case, it appears to be acceptable to encode them in one attribute.
1975 [RFC4675], Section 2.1 defines the Egress-VLANID Attribute, which can
1976 be sent by a RADIUS client or server.
1979 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
1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1981 | Type | Length | Value
1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1986 While it appears superficially to be of type Integer, the Value field
1987 is actually a packed structure, as follows:
1990 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
1991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1992 | Tag Indic. | Pad | VLANID |
1993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1995 The length of the VLANID field is defined by the [IEEE-802.1Q]
1996 specification. The Tag Indicator field is either 0x31 or 0x32, for
1997 compatibility with the Egress-VLAN-Name, as discussed below. The
1998 complex structure of Egress-VLANID overlaps with that of the base
1999 Integer data type, meaning that no code changes are required for a
2000 RADIUS server to support this attribute. Code changes are required
2001 on the NAS, if only to implement the VLAN ID enforcement.
2003 Given the IEEE VLAN requirements and the limited data model of
2004 RADIUS, the chosen method is likely the best of the possible
2018 DeKok & Weber Best Current Practice [Page 36]
2020 RFC 6158 RADIUS Design Guidelines March 2011
2023 B.9. Egress-VLAN-Name
2025 [RFC4675], Section 2.3 defines the Egress-VLAN-Name Attribute, which
2026 can be sent by a RADIUS client or server.
2029 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
2030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2031 | Type | Length | Tag Indic. | String...
2032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2034 The Tag Indicator is either the character '1' or '2', which in ASCII
2035 map to the identical values for Tag Indicator in Egress-VLANID above.
2036 The complex structure of this attribute is acceptable for reasons
2037 identical to those given for Egress-VLANID.
2041 [RFC5090] attempts to standardize the functionality provided by an
2042 expired Internet-Draft [AAA-SIP], which improperly uses two
2043 attributes from the standard space without having been assigned them
2044 by IANA. This self-allocation is forbidden, as described in Section
2045 2. In addition, the document uses nested attributes, which are
2046 discouraged in Section 2.1. The updated document uses basic data
2047 types and allocates nearly 20 attributes in the process.
2049 However, the document has seen wide-spread implementation, but
2050 [RFC5090] has not. One explanation may be that implementors
2051 disagreed with the trade-offs made in the updated specification. It
2052 may have been better to simply document the existing format and
2053 request IANA allocation of two attributes. The resulting design
2054 would have used nested attributes but may have gained more wide-
2055 spread implementation.
2059 We would like to acknowledge David Nelson, Bernard Aboba, Emile van
2060 Bergen, Barney Wolff, Glen Zorn, Avi Lior, and Hannes Tschofenig for
2061 contributions to this document.
2074 DeKok & Weber Best Current Practice [Page 37]
2076 RFC 6158 RADIUS Design Guidelines March 2011
2082 The FreeRADIUS Server Project
2083 http://freeradius.org/
2085 EMail: aland@freeradius.org
2092 EMail: gdweber@gmail.com
2130 DeKok & Weber Best Current Practice [Page 38]