draft-ietf-radext-design-12.txt   draft-ietf-radext-design-13.txt 
Network Working Group Alan DeKok (ed.) Network Working Group Alan DeKok (ed.)
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Category: Best Current Practice G. Weber Category: Best Current Practice G. Weber
<draft-ietf-radext-design-12.txt> Individual Contributor <draft-ietf-radext-design-13.txt> Individual Contributor
Expires: September 22, 2010 Expires: October 14, 2010
22 March 2010 14 April 2010
RADIUS Design Guidelines RADIUS Design Guidelines
draft-ietf-radext-design-12 draft-ietf-radext-design-13
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 22, 2010. This Internet-Draft will expire on October 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info/) in effect on the date of (http://trustee.ietf.org/license-info/) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 11 skipping to change at page 3, line 11
It is expected that these guidelines will prove useful to authors and It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs). IETF as well as other Standards Development Organizations (SDOs).
Table of Contents Table of Contents
1. Introduction ............................................. 5 1. Introduction ............................................. 5
1.1. Terminology ......................................... 5 1.1. Terminology ......................................... 5
1.2. Requirements Language ............................... 5 1.2. Requirements Language ............................... 5
1.3. Applicability ....................................... 6 1.3. Applicability ....................................... 6
1.3.1. Impact on SDOs ................................. 7
2. Guidelines ............................................... 7 2. Guidelines ............................................... 7
2.1. Data Types .......................................... 8 2.1. Data Types .......................................... 8
2.2. Vendor-Specific Space ............................... 9 2.2. Vendor-Specific Attribute Space ..................... 9
2.3. Service definitions and RADIUS ...................... 10 2.3. Service definitions and RADIUS ...................... 10
2.4. Translation of Vendor Specifications ................ 10 2.4. Translation of Vendor Specifications ................ 11
3. Rationale ................................................ 11 3. Rationale ................................................ 11
3.1. RADIUS Operational Model ............................ 11 3.1. RADIUS Operational Model ............................ 11
3.2. Data Model Issues ................................... 14 3.2. Data Model Issues ................................... 14
3.2.1. Basic Data Types ............................... 14 3.2.1. Basic Data Types ............................... 15
3.2.2. Tagging Mechanism .............................. 16 3.2.2. Tagging Mechanism .............................. 16
3.2.3. Complex Data Types ............................. 16 3.2.3. Complex Data Types ............................. 17
3.3. Vendor Space ........................................ 19 3.3. Vendor Space ........................................ 20
3.3.1. Interoperability Considerations ................ 20 3.3.1. Interoperability Considerations ................ 21
3.3.2. Vendor Allocations ............................. 21 3.3.2. Vendor Allocations ............................. 21
3.3.3. SDO Allocations ................................ 21 3.3.3. SDO Allocations ................................ 22
3.3.4. Publication of specifications .................. 22 3.3.4. Publication of specifications .................. 22
3.4. Polymorphic Attributes .............................. 22 3.4. Polymorphic Attributes .............................. 24
4. IANA Considerations ...................................... 23 4. IANA Considerations ...................................... 24
5. Security Considerations .................................. 23 5. Security Considerations .................................. 25
5.1. New Data Types and Complex Attributes ............... 24 5.1. New Data Types and Complex Attributes ............... 26
6. References ............................................... 25 6. References ............................................... 26
6.1. Normative References ................................ 25 6.1. Normative References ................................ 26
6.2. Informative References .............................. 25 6.2. Informative References .............................. 27
Appendix A - Design Guidelines ............................... 28 Appendix A - Design Guidelines ............................... 29
A.1. Types matching the RADIUS data model ................. 28 A.1. Types matching the RADIUS data model ................. 29
A.1.1. Transport of basic data types ................... 28 A.1.1. Transport of basic data types ................... 29
A.1.2. Transport of Authentication and Security Data ... 29 A.1.2. Transport of Authentication and Security Data ... 30
A.1.3. Opaque data types ............................... 29 A.1.3. Opaque data types ............................... 30
A.2. Improper Data Types .................................. 29 A.2. Improper Data Types .................................. 30
A.2.1. Basic Data Types ................................ 30 A.2.1. Basic Data Types ................................ 31
A.2.2. Complex Data Types .............................. 30 A.2.2. Complex Data Types .............................. 31
A.3. Vendor-Specific formats .............................. 31 A.3. Vendor-Specific formats .............................. 32
A.4. Changes to the RADIUS Operational Model .............. 31 A.4. Changes to the RADIUS Operational Model .............. 32
A.5. Allocation of attributes ............................. 33 A.5. Allocation of attributes ............................. 34
Appendix B - Complex Attributes .............................. 34 Appendix B - Complex Attributes .............................. 35
B.1. CHAP-Password ........................................ 34 B.1. CHAP-Password ........................................ 35
B.2. CHAP-Challenge ....................................... 34 B.2. CHAP-Challenge ....................................... 35
B.3. Tunnel-Password ...................................... 34 B.3. Tunnel-Password ...................................... 35
B.4. ARAP-Password ........................................ 35 B.4. ARAP-Password ........................................ 36
B.5. ARAP-Features ........................................ 35 B.5. ARAP-Features ........................................ 36
B.6. Connect-Info ......................................... 36 B.6. Connect-Info ......................................... 37
B.7. Framed-IPv6-Prefix ................................... 37 B.7. Framed-IPv6-Prefix ................................... 38
B.8. Egress-VLANID ........................................ 37 B.8. Egress-VLANID ........................................ 38
B.9. Egress-VLAN-Name ..................................... 38 B.9. Egress-VLAN-Name ..................................... 39
B.9. Digest-* ............................................. 39
1. Introduction 1. Introduction
This document provides guidelines for the design of RADIUS attributes This document provides guidelines for the design of RADIUS attributes
both within the IETF as well as within other SDOs. By articulating both within the IETF as well as within other SDOs. By articulating
RADIUS design guidelines, it is hoped that this document will RADIUS design guidelines, it is hoped that this document will
encourage the development and publication of high quality RADIUS encourage the development and publication of high quality RADIUS
attribute specifications. attribute specifications.
However, the advice in this document will not be helpful unless it is However, the advice in this document will not be helpful unless it is
put to use. As with "Guidelines for Authors and Reviewers of MIB put to use. As with "Guidelines for Authors and Reviewers of MIB
Documents" [RFC4181], it is expected that this document will be used Documents" [RFC4181], it is expected that this document will be used
by authors to check their document against the guidelines prior to by authors to check their document against the guidelines prior to
requesting review (such as an "Expert Review" described in publication, or requesting review (such as an "Expert Review"
[RFC3575]). Similarly, it is expected that this document will used described in [RFC3575]). Similarly, it is expected that this
by reviewers (such as WG participants or the AAA Doctors [DOCTORS]), document will used by reviewers (such as WG participants or the AAA
resulting in an improvement in the consistency of reviews. Doctors [DOCTORS]), resulting in an improvement in the consistency of
reviews.
In order to meet these objectives, this document needs to cover not In order to meet these objectives, this document needs to cover not
only the science of attribute design, but also the art. Therefore, only the science of attribute design, but also the art. Therefore,
in addition to covering the most frequently encountered issues, this in addition to covering the most frequently encountered issues, this
document attempts to provide some of the considerations motivating document explains some of the considerations motivating the
the guidelines. guidelines. These considerations include complexity trade-offs that
make it difficult to provide "hard and fast" rules for attribute
In order to characterize current attribute usage, both the basic and design. This document explains those trade-offs through reviews of
complex data types defined in the existing RADIUS RFCs are reviewed. current attribute usage.
1.1. Terminology 1.1. Terminology
This document uses the following terms: This document uses the following terms:
Network Access Server (NAS) Network Access Server (NAS)
A device that provides an access service for a user to a network. A device that provides an access service for a user to a network.
RADIUS server RADIUS server
A RADIUS authentication, authorization, and/or accounting (AAA) A RADIUS authentication, authorization, and/or accounting (AAA)
skipping to change at page 6, line 8 skipping to change at page 6, line 9
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The uses of "MUST" and "MUST NOT" in this document are limited to (a) The uses of "MUST" and "MUST NOT" in this document are limited to (a)
requirements to follow the IETF process for IETF standards, and (b) requirements to follow the IETF process for IETF standards, and (b)
quotes from other documents. As a result, the uses of "MUST" and quotes from other documents. As a result, the uses of "MUST" and
"MUST NOT" in this document do not prescribe new mandatory behavior "MUST NOT" in this document do not prescribe new mandatory behavior
within implementations. within implementations.
1.3. Applicability 1.3. Applicability
The reviews and advice in this document applies to attributes used to
encode service-provisioning, authentication, or accounting data,
based on the attribute formats and data encodings defined in RFC 2865
and subsequent RADIUS RFCs. It is RECOMMENDED that these guidelines
be applied to reviews of documents that request allocations within
the IETF standard attribute space defined in [RFC2865]. Doing so
will ensure the widest possible applicability and interoperability of
the specifications, while requiring minimal changes to existing
systems.
These guidelines may also prove useful in the design of attributes
within the Vendor-Specific Attribute (VSA) space. As noted in RFC
2865 Section 5.26, RADIUS VSAs were created "to allow vendors to
support their own extended Attributes not suitable for general
usage." Rather than requesting allocation of standard attributes for
those uses, [RFC2865] Section 6.2 notes that utilization of VSAs
"should be encouraged instead of allocation of global attribute
types, for functions specific only to one vendor's implementation of
RADIUS, where no interoperability is deemed useful."
However, experience has shown that attributes not originally designed
for general usage can subsequently garner wide-spread deployment. An
example is the vendor-specific attributes defined in [RFC2548], which
have been widely implemented within IEEE 802.11 Access Points.
While SDOs and vendors MAY choose to create specifications not
following these guidelines, this should be done only when those
specifications are intended for use in scenarios within a limited
scope of applicability. Where general usage is possible, adhering to
these guidelines is RECOMMENDED.
Guidelines are provided for vendor allocations in Section 3.3.2; and
for SDO allocations in Section 3.3.3. SDOs and vendors desiring
review of their specifications by the IETF are encouraged to follow
the advice presented in Section 3.3.4.
RADIUS protocol changes, or specification of attributes (such as
Service-Type) that can, in effect, provide new RADIUS commands
require greater expertise and deeper review, as do changes to the
RADIUS operational model. As a result, such changes are outside the
scope of this document and MUST NOT be undertaken outside the IETF.
1.3.1. Impact on SDOs
As RADIUS has become more widely accepted as a management protocol, As RADIUS has become more widely accepted as a management protocol,
its usage has become more prevalent, both within the IETF as well as its usage has become more prevalent, both within the IETF as well as
within other SDOs. Given the expanded utilization of RADIUS, it has within other SDOs. Given the expanded utilization of RADIUS, it has
become apparent that requiring SDOs to accomplish all their RADIUS become apparent that requiring SDOs to accomplish all their RADIUS
work within the IETF is inherently inefficient and unscalable. By work within the IETF is inherently inefficient and unscalable. By
articulating guidelines for RADIUS attribute design, this document articulating guidelines for RADIUS attribute design, this document
enables SDOs out of the IETF to design their own RADIUS attributes enables SDOs out of the IETF to design their own RADIUS attributes
within the Vendor-Specific Attribute (VSA) space. within the Vendor-Specific Attribute (VSA) space.
It is RECOMMENDED that SDOs follow the guidelines articulated in this It is RECOMMENDED that SDOs follow the guidelines articulated in this
document. Doing so will ensure the widest possible applicability and document. However, we recognize that there are some situations where
interoperability of the specifications, while requiring minimal SDOs or vendors require the creation of specifications not following
changes to existing systems. Specifications that do not follow the these guidelines. We do not forbid these specifications, but it is
guidelines articulated herein are NOT RECOMMENDED. However, we
recognize that there are some situations where SDOs or vendors
require the creation of specifications not following these
guidelines. We do not forbid these specifications, but it is
RECOMMENDED that they are created only if they have a limited scope RECOMMENDED that they are created only if they have a limited scope
of applicability, and all attributes defined in those specifications of applicability, and all new attributes defined in those
are VSAs, as discussed Appendix A.5, below. specifications are VSAs. See Section 3, below, for additional
discussion of this topic.
It is RECOMMENDED that SDOs and vendors seek review of RADIUS It is RECOMMENDED that SDOs and vendors seek review of RADIUS
attribute specifications from the IETF. However, when specifications attribute specifications from the IETF. However, specifications do
are SDO specific, re-use existing data types, and follow these not require IETF review when they satisfy all of the following
guidelines, they do not require IETF review. criteria:
In order to enable IETF review of such specifications, the authors
recommend that:
* SDOs make their RADIUS attribute specifications publicly
available;
* SDOs request review of RADIUS attribute specifications by * are SDO specific;
sending email to the AAA Doctors [DOCTORS] or equivalent mailing
list;
* IETF and SDO RADIUS attribute specifications are reviewed * reference attributes from pre-existing IETF or SDO
according to the guidelines proposed in this document; specifications;
* Reviews of specifications are posted to the RADEXT WG mailing * define new attributes only in the VSA space;
list, the AAA Doctors mailing list [DOCTORS] or another IETF
mailing list suggested by the Operations & Management Area
Directors of the IETF.
These reviews can assist with creation of specifications that meet * use only the "basic data types" (see below) for all VSAs;
the SDO requirements, and which are also compatible with the
traditional data model and uses of RADIUS. While these reviews
require access to public specifications, the review process does not
require publication of an IETF RFC.
The advice in this document applies to attributes used to encode * follow the guidelines given in this document.
service-provisioning or authentication data. RADIUS protocol
changes, or specification of attributes (such as Service-Type) that
can be used to, in effect, provide new RADIUS commands require
greater expertise and deeper review, as do changes to the RADIUS
operational model as discussed below in Section ZZZ. Such changes
MUST NOT be undertaken outside the IETF and when handled within the
IETF require "IETF Consensus" for adoption, as noted in [RFC3575]
Section 2.1.
2. Guidelines 2. Guidelines
The Remote Authentication Dial In User Service (RADIUS) defined in The Remote Authentication Dial In User Service (RADIUS) defined in
[RFC2865] and [RFC2866] uses elements known as attributes in order to [RFC2865] and [RFC2866] uses elements known as attributes in order to
represent authentication, authorization and accounting data. represent authentication, authorization and accounting data.
Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does
not define a formal data definition language. The data type of not define a formal data definition language. The data type of
RADIUS attributes is not transported on the wire. Rather, the data RADIUS attributes is not transported on the wire. Rather, the data
skipping to change at page 7, line 43 skipping to change at page 8, line 14
data dictionary. data dictionary.
To explain the implications of this early RADIUS design decision we To explain the implications of this early RADIUS design decision we
distinguish two types of data types, namely "basic" and "complex". distinguish two types of data types, namely "basic" and "complex".
Basic data types use one of the existing RADIUS data types as defined Basic data types use one of the existing RADIUS data types as defined
below, encapsulated in a [RFC2865] format RADIUS attribute, or in a below, encapsulated in a [RFC2865] format RADIUS attribute, or in a
[RFC2865] format RADIUS VSA. All other data formats are "complex [RFC2865] format RADIUS VSA. All other data formats are "complex
types". types".
RADIUS attributes are also divided into two distinct attribute RADIUS attributes are also divided into two distinct attribute
spaces: the standard space, and a Vendor-Specific space. Attributes spaces: the "standard space", and a "Vendor-Specific Attribute
in the standard space follow the [RFC2865] attribute format, with space". Attributes in the "standard space" follow the [RFC2865]
allocation managed by the Internet Assigned Number Authority (IANA). attribute format, with allocation managed by the Internet Assigned
Number Authority (IANA). Vendors MUST NOT "self-allocate" attributes
in this space, as they are not authoritative for it.
The Vendor-Specific space is defined to be the contents of the The VSA space is defined to be the contents of the "String" field of
"String" field of the Vendor-Specific Attribute ([RFC2865] Section the Vendor-Specific Attribute ([RFC2865] Section 5.26). Allocation
5.26). See Section 2.2, below, for a more in-depth discussion. in this space is managed independently by each vendor. See Section
2.2, below, for a more in-depth discussion.
2.1. Data Types 2.1. Data Types
RADIUS defines a limited set of data types, defined as "basic data RADIUS defines a limited set of data types, defined as "basic data
types". The following data qualifies as "basic data types": types". The following data qualifies as "basic data types":
* 32-bit unsigned integer, in network byte order. * 32-bit unsigned integer, in network byte order.
* Enumerated data types, represented as a 32-bit unsigned integer * Enumerated data types, represented as a 32-bit unsigned integer
with a list of name to value mappings. (e.g., Service-Type) with a list of name to value mappings. (e.g. Service-Type)
* Interface-Id (8 octet string in network byte order)
* IPv4 address in network byte order. * IPv4 address in network byte order.
* time as 32 bit unsigned value, in network byte order, and in
seconds since 00:00:00 UTC, January 1, 1970.
* IPv6 address in network byte order. * IPv6 address in network byte order.
* IPv6 prefix. * Interface-Id (8 octet string in network byte order)
* time as 32 bit unsigned value, in network byte order, and in * IPv6 prefix.
seconds since 00:00:00 UTC, January 1, 1970.
* string (i.e., binary data), totalling 253 octets or less in * string (i.e., binary data), totalling 253 octets or less in
length. This includes the opaque encapsulation of data length. This includes the opaque encapsulation of data
structures defined outside of RADIUS. See also Appendix A.1.3, structures defined outside of RADIUS. See also Appendix A.1.3,
below. below.
* UTF-8 text, totalling 253 octets or less in length. * UTF-8 text, totalling 253 octets or less in length.
Note that the length limitations for VSAs of type String and Text are Note that the length limitations for VSAs of type String and Text are
less than 253 octets, due to the additional overhead of the Vendor- less than 253 octets, due to the additional overhead of the Vendor-
skipping to change at page 8, line 45 skipping to change at page 9, line 18
The following data also qualifies as "basic data types": The following data also qualifies as "basic data types":
* Attributes grouped into a logical container, using the * Attributes grouped into a logical container, using the
[RFC2868] tagging mechanism. This approach is NOT RECOMMENDED, [RFC2868] tagging mechanism. This approach is NOT RECOMMENDED,
but is permissible where the alternatives are worse. but is permissible where the alternatives are worse.
* Attributes requiring the transport of more than 247 octets of * Attributes requiring the transport of more than 247 octets of
Text or String data. This includes the opaque encapsulation Text or String data. This includes the opaque encapsulation
of data structures defined outside of RADIUS. of data structures defined outside of RADIUS.
(e.g. EAP-Message)
Nested groups or attributes do not qualify as "basic data types", and
SHOULD NOT be used.
All other data formats are defined to be "complex data types", and All other data formats are defined to be "complex data types", and
are NOT RECOMMENDED. However, there may be situations where complex are NOT RECOMMENDED for normal use. Nested attributes, or attributes
attributes are beneficial because they reduce complexity in the non- grouped via methods other than defined in [RFC2868] do not qualify as
RADIUS systems. Unfortunately, there are no "hard and fast" rules "basic data types", and SHOULD NOT be used.
for where the complexity would best be located. Each situation has
to be decided on a case-by-case basis.
See Appendix B for an audit of existing attributes of complex data There may be situations where complex attributes are acceptable
types, including a discussion of benefits and drawbacks. because they reduce complexity in non-RADIUS systems, or because
leveraging the basic data types would be awkward. Unfortunately,
there are no "hard and fast" rules for where the complexity would
best be located. Each situation has to be decided on a case-by-case
basis. The cost-benefit trade-off may result in a "complex data
type" being defined in RADIUS, as discussed in Appendix B. When this
is done, an explanation SHOULD be offered as to why the complex data
type was used.
2.2. Vendor-Specific Space 2.2. Vendor-Specific Attribute Space
The Vendor-Specific space is defined to be the contents of the The Vendor-Specific Attribute space is defined to be the contents of
"String" field of the Vendor-Specific Attribute ([RFC2865] Section the "String" field of the Vendor-Specific Attribute ([RFC2865]
5.26). As discussed there, it is intended for vendors to support Section 5.26). As discussed there, it is intended for vendors to
their own Attributes not suitable for general use. It is RECOMMENDED support their own Attributes not suitable for general use. It is
that vendors follow the guidelines outlined here, which are intended RECOMMENDED that vendors follow the guidelines outlined here, which
to enable maximum interoperability with minimal changes to existing are intended to enable maximum interoperability with minimal changes
systems. to existing systems.
Following these guidelines means that RADIUS servers can be updated Following these guidelines means that RADIUS servers can be updated
to support the vendor's equipment by editing a RADIUS dictionary. If to support the vendor's equipment by editing a RADIUS dictionary. If
these guidelines are not followed, then the vendor's equipment can these guidelines are not followed, then the vendor's equipment can
only be supported via code changes in RADIUS server implementations. only be supported via code changes in RADIUS server implementations.
Such code changes add complexity and delay to implementations. Such code changes add complexity and delay to implementations.
Vendor RADIUS Attribute specifications SHOULD allocate attributes Vendor RADIUS Attribute specifications SHOULD allocate attributes
from the vendor space, rather than requesting an allocation from the from the vendor space, rather than requesting an allocation from the
RADIUS standard attribute space. RADIUS standard attribute space.
skipping to change at page 10, line 27 skipping to change at page 10, line 47
used to define new RADIUS commands. RADIUS attributes are intended used to define new RADIUS commands. RADIUS attributes are intended
to: to:
* authenticate users * authenticate users
* authorize users (i.e., service provisioning or changes to * authorize users (i.e., service provisioning or changes to
provisioning) provisioning)
* account for user activity (i.e., logging of session activity) * account for user activity (i.e., logging of session activity)
New commands (i.e., the Code field in the packet header) are New commands (i.e., the Code field in the packet header) and new
allocated only through "IETF Consensus" as noted in [RFC3575] Section attributes in the "standard space" are allocated only through "IETF
2.1. Specifications also SHOULD NOT use new attributes to modify the Consensus" as noted in [RFC3575] Section 2.1.
interpretation of existing RADIUS commands.
2.4. Translation of Vendor Specifications 2.4. Translation of Vendor Specifications
The limitation on changes to the RADIUS protocol effectively The limitation on changes to the RADIUS protocol effectively
prohibits VSAs from changing fundamental aspects of RADIUS operation, prohibits VSAs from changing fundamental aspects of RADIUS operation,
such as modifying RADIUS packet sequences, or adding new commands. such as modifying RADIUS packet sequences, or adding new commands.
However, the requirement for clients and servers to be able to However, the requirement for clients and servers to be able to
operate in the absence of VSAs has proven to be less of a constraint, operate in the absence of VSAs has proven to be less of a constraint,
since it is still possible for a RADIUS client and server to mutually since it is still possible for a RADIUS client and server to mutually
indicate support for VSAs, after which behavior expectations can be indicate support for VSAs, after which behavior expectations can be
skipping to change at page 11, line 29 skipping to change at page 11, line 51
The RADIUS operational model includes several assumptions: The RADIUS operational model includes several assumptions:
* The RADIUS protocol is stateless; * The RADIUS protocol is stateless;
* Provisioning of services is not possible within an * Provisioning of services is not possible within an
Access-Reject; Access-Reject;
* There is a distinction between authorization checks and user * There is a distinction between authorization checks and user
authentication; authentication;
* The protocol provices for authentication and integrity * The protocol provides for authentication and integrity
protection of packets; protection of packets;
* The RADIUS protocol is a Request/Response protocol; * The RADIUS protocol is a Request/Response protocol;
* The protocol defines packet length restrictions. * The protocol defines packet length restrictions.
While RADIUS server implementations may keep state, the RADIUS While RADIUS server implementations may keep state, the RADIUS
protocol is stateless, although information may be passed from one protocol is stateless, although information may be passed from one
protocol transaction to another via the State Attribute. As a protocol transaction to another via the State Attribute. As a
result, documents which require stateful protocol behavior without result, documents which require stateful protocol behavior without
skipping to change at page 14, line 20 skipping to change at page 14, line 40
RADIUS client and a home server. While such an approach can RADIUS client and a home server. While such an approach can
avoid the complexity of utilization of a sequence of packets, avoid the complexity of utilization of a sequence of packets,
dynamic discovery is likely to be time consuming and cannot be dynamic discovery is likely to be time consuming and cannot be
guaranteed to work with existing RADIUS implementations. As a guaranteed to work with existing RADIUS implementations. As a
result, this technique is not generally applicable. result, this technique is not generally applicable.
3.2. Data Model Issues 3.2. Data Model Issues
The RADIUS data types are poorly defined. While [RFC2865] Section 5 The RADIUS data types are poorly defined. While [RFC2865] Section 5
defines basic data types, later specifications did not follow this defines basic data types, later specifications did not follow this
practice. This led implementations to define their own names for practice. This problem has led implementations to define their own
data types, leading to non-standard names for those types. names for data types, resulting in non-standard names for those
types.
In addition, the number of vendors and SDOs creating new attributes In addition, the number of vendors and SDOs creating new attributes
within the Vendor-Specific attribute space has grown, and this has within the Vendor-Specific attribute space has grown, and this has
lead to some divergence in approaches to RADIUS attribute design. lead to some divergence in approaches to RADIUS attribute design.
For example, vendors and SDOs have evolved the data model to support For example, vendors and SDOs have evolved the data model to support
new functions such as more data types, along with attribute grouping functions such as new data types, along with attribute grouping and
and attribute fragmentation, with different groups taking different attribute fragmentation, with different groups taking different
approaches. These approaches are often incompatible, leading to approaches. These approaches are often incompatible, leading to
additional complexity in RADIUS implementations. additional complexity in RADIUS implementations.
This section describes the history of the RADIUS data model, in an In order to avoid repeating old mistakes, his section describes the
attempt to codify existing practices, and to avoid repeating old history of the RADIUS data model, and attempts to codify existing
mistakes. practices.
3.2.1. Basic Data Types 3.2.1. Basic Data Types
[RFC2865] and [RFC2866] utilize data types defined in [RFC2865] [RFC2865] and [RFC2866] utilize data types defined in [RFC2865]
Section 5, which states the following: Section 5, which states the following:
The format of the value field is one of five data types. Note The format of the value field is one of five data types. Note
that type "text" is a subset of type "string". that type "text" is a subset of type "string".
text 1-253 octets containing UTF-8 encoded 10646 [RFC3629] text 1-253 octets containing UTF-8 encoded 10646 [RFC3629]
skipping to change at page 15, line 26 skipping to change at page 15, line 48
[RFC2865]. As a result, the data type is ambiguous in some cases, [RFC2865]. As a result, the data type is ambiguous in some cases,
and may not be consistent among different implementations. and may not be consistent among different implementations.
It is out of the scope of this document to resolve all potential It is out of the scope of this document to resolve all potential
ambiguities within existing RADIUS specifications. However in order ambiguities within existing RADIUS specifications. However in order
to prevent future ambiguities, it is recommended that future RADIUS to prevent future ambiguities, it is recommended that future RADIUS
attribute specifications explicitly define newly created data types attribute specifications explicitly define newly created data types
at the beginning of the document, and indicate clearly the data type at the beginning of the document, and indicate clearly the data type
to be used for each attribute. to be used for each attribute.
[RFC3162] utilizes but does not explicitly define the following data For example, [RFC3162] utilizes but does not explicitly define the
types: following data types:
IPv6 address 128 bit value, in network byte order. IPv6 address 128 bit value, in network byte order.
IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to
128 bits of value, in network byte order. 128 bits of value, in network byte order.
Examples of the IPv6 address type include NAS-IPv6-Address defined in The IPv6 address type is used for the NAS-IPv6-Address defined in
[RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162] [RFC3162] Section 2.1 and the Login-IPv6-Host defined in [RFC3162]
Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3, Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3,
and in [RFC4818] Section 3. and in [RFC4818] Section 3.
While the Framed-Interface-Id attribute defined in [RFC3162] Section While the Framed-Interface-Id attribute defined in [RFC3162] Section
2.2 included a value field of 8 octets, the data type was not 2.2 included a value field of 8 octets, the data type was not
explicitly indicated, and therefore there is controversy over whether explicitly indicated, and therefore there is controversy over whether
the format of this attribute was intended to be an 8 octet String or the format of this attribute was intended to be an 8 octet String or
whether a special Interface-Id type was intended. whether a special Interface-Id type was intended.
Given that attributes of type "IPv6 address" and "IPv6 prefix" are Given that attributes of type "IPv6 address" and "IPv6 prefix" are
skipping to change at page 16, line 50 skipping to change at page 17, line 26
The RADIUS attribute encoding is summarized in [RFC2865]: The RADIUS attribute encoding is summarized in [RFC2865]:
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Value ... | Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
However, some standard attributes do not follow this format. However, some standard attributes do not follow this format.
Attributes that use sub-fields instead of using a basic data type as Attributes that use a format other than the basic data types as
discussed in the above sections are defined to be "complex types". discussed above are defined to be "complex types". As described
As described below in this section the creation of complex types can below in this section, the creation of complex types can lead to
lead to interoperability and deployment issues, so they need to be interoperability and deployment issues, so they need to be introduced
introduced with care. with care.
In general, complex types sent from the RADIUS server to the client In general, complex types containing multiple sub-fields can be
can be supported by concatenating the values into a String data type supported by concatenating the sub-fields into a String data type
field. However, separating these values into different attributes, field. However, separating these sub-fields into different
each with its own type and length, would have the following benefits: attributes, each with its own type and length, would have the
following benefits:
* it is easier for the user to enter the data as well-known * it is easier for the user to enter the data as well-known
types, rather than complex structures; types, rather than complex structures;
* it enables additional error checking by leveraging the * it enables additional error checking by leveraging the
parsing and validation routines for well-known types; parsing and validation routines for well-known types;
* it simplifies implementations by eliminating special-case * it simplifies implementations by eliminating special-case
attribute-specific parsing. attribute-specific parsing.
skipping to change at page 20, line 51 skipping to change at page 21, line 26
in [RFC3575] Section 2.1. Some vendors and SDOs have in the past in [RFC3575] Section 2.1. Some vendors and SDOs have in the past
performed self-allocation by assigning vendor-specific meaning to performed self-allocation by assigning vendor-specific meaning to
"unused" values from the standard RADIUS attribute ID or enumerated "unused" values from the standard RADIUS attribute ID or enumerated
value space. This self-allocation results in interoperability value space. This self-allocation results in interoperability
issues, and is counter-productive. Similarly, the Vendor-Specific issues, and is counter-productive. Similarly, the Vendor-Specific
enumeration practice discussed in [RFC2882] Section 2.2.1 is NOT enumeration practice discussed in [RFC2882] Section 2.2.1 is NOT
RECOMMENDED. RECOMMENDED.
If it is not possible to follow the IETF process, vendors and SDOs If it is not possible to follow the IETF process, vendors and SDOs
SHOULD self-allocate an attribute from their Vendor-Specific space, SHOULD self-allocate an attribute from their Vendor-Specific space,
and define an appropriate value for it. as discussed in Sections 3.3.2 and 3.3.3, below.
As a side note, [RFC2865] Section 5.26 uses the term "Vendor-Specific
Attribute" to refer to an encoding format which can be used by
individual vendors to define attributes not suitable for general
usage. However, since then VSAs have also become widely used by SDOs
defining attributes intended for multi-vendor interoperability. As
such, these attributes are not specific to any single vendor, and the
term "Vendor-Specific" may be misleading. An alternate term which
better describes this use case is SDO-Specific Attribute (SSA).
The design and specification of VSAs for multi-vendor usage SHOULD be The design and specification of VSAs for multi-vendor usage SHOULD be
undertaken with the same level of care as standard RADIUS attributes. undertaken with the same level of care as standard RADIUS attributes.
Specifically, the provisions of this document that apply to standard Specifically, the provisions of this document that apply to standard
RADIUS attributes also apply to SSAs or VSAs for multi-vendor usage. RADIUS attributes also apply to VSAs for multi-vendor usage.
3.3.2. Vendor Allocations 3.3.2. Vendor Allocations
As noted in [RFC3575] Section 2.1, vendors are encouraged to utilize
VSAs to define functions "specific only to one vendor's
implementation of RADIUS, where no interoperability is deemed useful.
For functions specific only to one vendor's implementation of RADIUS,
the use of that should be encouraged instead of the allocation of
global attribute types."
The recommendation for vendors to allocate attributes from a vendor
space rather than via the IETF process is a recognition that vendors
desire to assert change control over their own RADIUS specifications.
This change control can be obtained by requesting a PEC from the
Internet Assigned Number Authority (IANA), for use as a Vendor-Id
within a Vendor-Specific attribute. The vendor can then allocate
attributes within the VSA space defined by that Vendor-Id, at their
sole discretion. Similarly, the use of data types (complex or
otherwise) within that VSA space is solely under the discretion of
the vendor.
Nevertheless, following the guidelines outlined within this document
has many advantages. It is therefore RECOMMENDED that vendors follow
the guidelines outlined here, which are intended to enable maximum
interoperability with minimal changes to existing systems. If these
guidelines are not followed, the result will be increased complexity
with little or no benefit.
3.3.3. SDO Allocations 3.3.3. SDO Allocations
SDO RADIUS Attribute specifications SHOULD allocate attributes from Given the expanded utilization of RADIUS, it has become apparent that
the vendor space, rather than requesting an allocation from the requiring SDOs to accomplish all their RADIUS work within the IETF is
RADIUS standard attribute space, for attributes matching any of the inherently inefficient and unscalable. Is is therefore RECOMMENDED
that SDO RADIUS Attribute specifications allocate attributes from the
vendor space, rather than requesting an allocation from the RADIUS
standard attribute space, for attributes matching any of the
following criteria: following criteria:
* attributes relying on data types not defined within RADIUS * attributes relying on data types not defined within RADIUS
* attributes intended primarily for use within an SDO * attributes intended primarily for use within an SDO
* attributes intended primarily for use within a group of SDOs. * attributes intended primarily for use within a group of SDOs.
Any new RADIUS attributes or values intended for interoperable use Any new RADIUS attributes or values intended for interoperable use
across a broad spectrum of the Internet Community SHOULD follow the across a broad spectrum of the Internet Community SHOULD follow the
normal IETF process, and SHOULD result in allocations from the RADIUS allocation process defined in [RFC3575].
standard space.
The recommendation for SDOs to allocate attributes from a vendor The recommendation for SDOs to allocate attributes from a vendor
space rather than via the IETF process is a recognition that SDOs may space rather than via the IETF process is a recognition that SDOs
desire to assert change control over their own RADIUS specifications. desire to assert change control over their own RADIUS specifications.
This change control can be obtained by requesting a PEC from the This change control can be obtained by requesting a PEC from the
Internet Assigned Number Authority (IANA), for use as a Vendor-Id Internet Assigned Number Authority (IANA), for use as a Vendor-Id
within a Vendor-Specific attribute. Further allocation of attributes within a Vendor-Specific attribute. The SDO can then allocate
inside of the VSA space defined by that Vendor-Id is subject solely attributes within the VSA space defined by that Vendor-Id, at their
to the discretion of the SDO. Similarly, the use of data types sole discretion. Similarly, the use of data types (complex or
(complex or not) within that VSA space is solely under the discretion otherwise) within that VSA space is solely under the discretion of
of the SDO. It is RECOMMENDED that SDOs follow the guidelines the SDO.
outlined here, which are intended to enable maximum interoperability
with minimal changes to existing systems. Nevertheless, following the guidelines outlined within this document
has many advantages. It is therefore RECOMMENDED that SDOs follow
the guidelines outlined here, which are intended to enable maximum
interoperability with minimal changes to existing systems.
3.3.4. Publication of specifications
In order to enable IETF review of SDO specifications, it is
RECOMMENDED that:
* SDOs make their RADIUS attribute specifications publicly
available;
* SDOs request review of RADIUS attribute specifications by
sending email to the AAA Doctors [DOCTORS] or equivalent mailing
list;
* IETF and SDO RADIUS attribute specifications are reviewed
according to the guidelines proposed in this document;
* Reviews of specifications are posted to the RADEXT WG mailing
list,
the AAA Doctors mailing list [DOCTORS] or another IETF mailing
list
suggested by the Operations & Management Area Directors of the
IETF.
It should be understood that SDOs do not have to rehost VSAs into the It should be understood that SDOs do not have to rehost VSAs into the
standards space solely for the purpose of obtaining IETF review. standards space solely for the purpose of obtaining IETF review.
Rehosting puts pressure on the standards space, and may be harmful to Rehosting puts pressure on the standards space, and may be harmful to
interoperability, since it can create two ways to provision the same interoperability, since it can create two ways to provision the same
service. Rehosting may also require changes to the RADIUS data model service. Rehosting may also require changes to the RADIUS data model
which will affect implementations that do not intend to support the which will affect implementations that do not intend to support the
SDO specifications. SDO specifications.
3.3.4. Publication of specifications These reviews can assist with creation of specifications that meet
the SDO requirements, and which are also compatible with the
traditional data model and uses of RADIUS. While these reviews
require access to public specifications, the review process does not
require publication of an IETF RFC.
SDOs are encouraged to seek early review of SSA specifications by the SDOs are encouraged to seek early review of their specifications by
IETF. This review may be initiated by sending mail to the AAA the IETF. It should be understood that reviews are a voluntary-based
Doctors list [DOCTORS], with the understanding that this review is a service offered on best-effort basis.
voluntary-based service offered on best-effort basis. Since the IETF
is not a membership organization, in order to enable the RADIUS SSA Where the RADIUS specification is embedded within a larger document
specification to be reviewed, it is RECOMMENDED that it be made which cannot be made public, the RADIUS attribute and value
publicly available; this also encourages interoperability. Where the definitions SHOULD be published instead as an Informational RFC, as
RADIUS SSA specification is embedded within a larger document which with [RFC4679]. This process SHOULD be followed instead of
cannot be made public, the RADIUS attribute and value definitions requesting IANA allocations from within the standard RADIUS attribute
SHOULD be published instead as an Informational RFC, as with space.
[RFC4679]. This process SHOULD be followed instead of requesting
IANA allocations from within the standard RADIUS attribute space.
Similarly, vendors are encouraged to make their specifications Similarly, vendors are encouraged to make their specifications
publicly available, for maximum interoperability. However, it is not publicly available, for maximum interoperability. However, it is not
necessary for them to request publication of their VSA specifications necessary for them to request publication of their VSA specifications
as Informational RFCs by the IETF. as Informational RFCs by the IETF.
All other specifications, including new authentication, All other specifications, including new authentication,
authorization, and/or security mechanisms SHOULD be allocated via the authorization, and/or security mechanisms SHOULD follow the
standard RADIUS space, as noted in [RFC3575] Section 2.1. allocation process defined in [RFC3575].
3.4. Polymorphic Attributes 3.4. Polymorphic Attributes
A polymorphic attribute is one whose format or meaning is dynamic. A polymorphic attribute is one whose format or meaning is dynamic.
For example, rather than using a fixed data format, an attribute's For example, rather than using a fixed data format, an attribute's
format might change based on the contents of another attribute. Or, format might change based on the contents of another attribute. Or,
the meaning of an attribute may depend on earlier packets in a the meaning of an attribute may depend on earlier packets in a
sequence. sequence.
RADIUS server dictionary entries are typically static, enabling the RADIUS server dictionary entries are typically static, enabling the
skipping to change at page 25, line 45 skipping to change at page 27, line 18
management information for TCP/IP-based internets", STD 16, management information for TCP/IP-based internets", STD 16,
RFC 1155, May 1990. RFC 1155, May 1990.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol (SNMP)", STD 15, RFC 1157, May Network Management Protocol (SNMP)", STD 15, RFC 1157, May
1990. 1990.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC2548] Zorn, Glen, "Microsoft Vendor-specific RADIUS Attributes", RFC
2548, March 1999.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999. Implementation in Roaming", RFC 2607, June 1999.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.,
and I. Goyret, "RADIUS Attributes for Tunnel Protocol and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000. Support", RFC 2868, June 2000.
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions",
skipping to change at page 28, line 5 skipping to change at page 28, line 47
Modules", http://csrc.nist.gov/publications/fips/fips140-3/ Modules", http://csrc.nist.gov/publications/fips/fips140-3/
[IEEE-802.1Q] [IEEE-802.1Q]
IEEE Standards for Local and Metropolitan Area Networks: Draft IEEE Standards for Local and Metropolitan Area Networks: Draft
Standard for Virtual Bridged Local Area Networks, Standard for Virtual Bridged Local Area Networks,
P802.1Q-2003, January 2003. P802.1Q-2003, January 2003.
[RFC5580] Tschofenig, H. (Ed.), "Carrying Location Objects in RADIUS and [RFC5580] Tschofenig, H. (Ed.), "Carrying Location Objects in RADIUS and
Diameter", RFC 5580, August 2009. Diameter", RFC 5580, August 2009.
[AAA-SIP] Sterman, B. et al., "RADIUS Extension for Digest
Authentication", draft-sterman-sip-aaa-00.txt, November 2001
(expired).
Appendix A - Design Guidelines Appendix A - Design Guidelines
The following text provides guidelines for the design of attributes The following text provides guidelines for the design of attributes
used by the RADIUS protocol. Specifications that follow these used by the RADIUS protocol. Specifications that follow these
guidelines are expected to achieve maximum interoperability with guidelines are expected to achieve maximum interoperability with
minimal changes to existing systems. minimal changes to existing systems.
A.1. Types matching the RADIUS data model A.1. Types matching the RADIUS data model
A.1.1. Transport of basic data types A.1.1. Transport of basic data types
Does the data fit within the basic data types described in Section Does the data fit within the basic data types described in Section
2.1.1, as outlined below? If so, it SHOULD be encapsulated in a 2.1.1, as outlined below? If so, it SHOULD be encapsulated in a
[RFC2865] format RADIUS attribute, or in a [RFC2865] format RADIUS [RFC2865] format RADIUS attribute, or in a [RFC2865] format RADIUS
VSA that uses one of the existing RADIUS data types: VSA that uses one of the existing RADIUS data types:
* 32-bit unsigned integer, in network byte order. * 32-bit unsigned integer, in network byte order.
* Enumerated data types, represented as a 32-bit unsigned integer * Enumerated data types, represented as a 32-bit unsigned integer
with a list of name to value mappings. (e.g., Service-Type) with a list of name to value mappings. (e.g. Service-Type)
* Interface-Id (8 octet string in network byte order)
* IPv4 address in network byte order. * IPv4 address in network byte order.
* time as 32 bit unsigned value, in network byte order, and in
seconds since 00:00:00 UTC, January 1, 1970.
* IPv6 address in network byte order. * IPv6 address in network byte order.
* IPv6 prefix. * Interface-Id (8 octet string in network byte order)
* time as 32 bit unsigned value, in network byte order, and in * IPv6 prefix.
seconds since 00:00:00 UTC, January 1, 1970.
* string (i.e., binary data), totalling 253 octets or less in * string (i.e., binary data), totalling 253 octets or less in
length. This includes the opaque encapsulation of data length. This includes the opaque encapsulation of data
structures defined outside of RADIUS. See also Appendix A.1.3, structures defined outside of RADIUS. See also Appendix A.1.3,
below. below.
* UTF-8 text, totalling 253 octets or less in length. * UTF-8 text, totalling 253 octets or less in length.
Note that the length limitations for VSAs of type String and Text are Note that the length limitations for VSAs of type String and Text are
less than 253 octets, due to the additional overhead of the Vendor- less than 253 octets, due to the additional overhead of the Vendor-
skipping to change at page 32, line 47 skipping to change at page 33, line 47
In an authorization check, where there is no demonstration of a In an authorization check, where there is no demonstration of a
live user, confidential data cannot be returned. Where there live user, confidential data cannot be returned. Where there
is a link to a previous user authentication, the State attribute is a link to a previous user authentication, the State attribute
needs to be present. needs to be present.
* Lack of per-packet integrity and authentication. * Lack of per-packet integrity and authentication.
It is expected that documents will support per-packet It is expected that documents will support per-packet
integrity and authentication. integrity and authentication.
* Modification of RADIUS packet sequences. * Modification of RADIUS packet sequences.
In RADIUS, each request is encapsulated in it's own packet, and In RADIUS, each request is encapsulated in its own packet, and
elicits a single response that is sent to the requester. Since elicits a single response that is sent to the requester. Since
changes to this paradigm are likely to require major changes to this paradigm are likely to require major
modifications to RADIUS client and server implementations, they modifications to RADIUS client and server implementations, they
SHOULD be avoided if possible. SHOULD be avoided if possible.
For further details, see Section 3.3. For further details, see Section 3.3.
A.5. Allocation of attributes A.5. Allocation of attributes
Does the attribute have a limited scope of applicability, as outlined Does the attribute have a limited scope of applicability, as outlined
below? If so, then the attributes SHOULD be allocated from the below? If so, then the attributes SHOULD be allocated from the
skipping to change at page 33, line 24 skipping to change at page 34, line 24
* attributes relying on data types not defined within RADIUS * attributes relying on data types not defined within RADIUS
* attributes intended primarily for use within an SDO * attributes intended primarily for use within an SDO
* attributes intended primarily for use within a group of SDOs. * attributes intended primarily for use within a group of SDOs.
Note that the points listed above do not relax the recommendations Note that the points listed above do not relax the recommendations
discussed in this document. Instead, they recognize that the RADIUS discussed in this document. Instead, they recognize that the RADIUS
data model has limitations. In certain situations where data model has limitations. In certain situations where
interoperability can be strongly constrained by the SDO or vendor, an interoperability can be strongly constrained by the SDO or vendor, an
expanded data model MAY be used. We recommend, however, that the expanded data model MAY be used. It is RECOMMENDED, however, that
RADIUS data model SHOULD be used, even if it is marginally less the RADIUS data model be used, even when it is marginally less
efficient than alternatives. efficient than alternatives.
When attributes are used primarily within a group of SDOs, and are When attributes are used primarily within a group of SDOs, and are
not applicable to the wider Internet community, we expect that one not applicable to the wider Internet community, we expect that one
SDO will be responsible for allocation from their own private space. SDO will be responsible for allocation from their own private space.
Appendix B - Complex Attributes Appendix B - Complex Attributes
This section summarizes RADIUS attributes with complex data types This section summarizes RADIUS attributes with complex data types
that are defined in existing RFCs. that are defined in existing RFCs.
skipping to change at page 38, line 47 skipping to change at page 39, line 47
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag Indic. | String... | Type | Length | Tag Indic. | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Tag Indicator is either the character '1' or '2', which in ASCII The Tag Indicator is either the character '1' or '2', which in ASCII
map to the identical values for Tag Indicator in Egress-VLANID, map to the identical values for Tag Indicator in Egress-VLANID,
above. The complex structure of this attribute is acceptable for above. The complex structure of this attribute is acceptable for
reasons identical to those given for Egress-VLANID. reasons identical to those given for Egress-VLANID.
B.9. Digest-*
[RFC5090] attempts to standardize the functionality provided by an
expired internet-draft [AAA-SIP] which improperly used two attributes
from the "standard space" without being assigned them by IANA. This
self-allocation is forbidden, as described above in Section 1.3 and
in Section 2. In addition, the draft uses nested attributes, which
are discouraged in Section 2.1. The updated document uses basic data
types, and allocates nearly 20 attributes in the process.
However, the draft has seen wide-spread implementation, where
[RFC5090] has not. While there are a number of factors involved, one
factor may be that implementors disagreed with the trade-offs made in
the updated specification. It may have been better to simply
document the existing format, and request IANA allocation of two
attributes. The resulting design would have used nested attributes,
but may have gained more wide-spread implementation.
It is difficult to know which choice is optimal. Given the
complexity of the protocols and implementations, it is impossible to
define "hard and fast" rules for RADIUS design guidelines.
Acknowledgments Acknowledgments
We would like to acknowledge David Nelson, Bernard Aboba, Emile van We would like to acknowledge David Nelson, Bernard Aboba, Emile van
Bergen, Barney Wolff and Glen Zorn for contributions to this Bergen, Barney Wolff, Glen Zorn, Avi Lior, and Hannes Tschofenig for
document. contributions to this document.
Authors' Addresses Authors' Addresses
Greg Weber Greg Weber
Knoxville, TN 37932 Knoxville, TN 37932
USA USA
Email: gdweber@gmail.com Email: gdweber@gmail.com
Alan DeKok Alan DeKok
 End of changes. 63 change blocks. 
195 lines changed or deleted 298 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/