draft-ietf-radext-design-00.txt   draft-ietf-radext-design-01.txt 
Network Working Group G. Weber Network Working Group G. Weber
INTERNET-DRAFT Cisco Systems INTERNET-DRAFT Individual Contributor
Category: Standards Track Alan DeKok (ed.) Category: Standards Track Alan DeKok (ed.)
FreeRADIUS <draft-ietf-radext-design-01.txt> FreeRADIUS
Expires: March 4, 2008 Expires: May 15, 2008
15 November 2007
4 September 2007
RADIUS Design Guidelines RADIUS Design Guidelines
draft-ietf-radext-design-00.txt draft-ietf-radext-design-01.txt
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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 35 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 January 25, 2008. This Internet-Draft will expire on May 15, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document provides guidelines for the design of attributes used This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol. by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and It is expected that these guidelines will prove useful to authors and
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction ............................................. 3 1. Introduction ............................................. 3
1.1. Applicability ....................................... 3 1.1. Applicability ....................................... 3
1.2. Terminology ......................................... 4 1.2. Terminology ......................................... 4
1.3. Requirements Language ............................... 4 1.3. Requirements Language ............................... 4
2. RADIUS Data Model ........................................ 4 2. RADIUS Data Model ........................................ 4
2.1. Standard Space ...................................... 5 2.1. Standard Space ...................................... 5
2.1.1. Basic Data Types ............................... 5 2.1.1. Basic Data Types ............................... 5
2.1.2. Tagging Mechanism .............................. 6 2.1.2. Tagging Mechanism .............................. 6
2.1.3. Complex Attribute Usage ........................ 6 2.1.3. Complex Attribute Usage ........................ 7
2.2. Vendor Space ........................................ 8 2.1.4. Service definitions and RADIUS ................. 9
3. Data Model Issues ........................................ 10 2.2. Vendor Space ........................................ 10
3.1. Vendor Space ........................................ 10 3. Data Model Issues ........................................ 11
3.2. Polymorphic Attributes .............................. 12 3.1. Vendor Space ........................................ 12
4. IANA Considerations ...................................... 13 3.1.1. Interoperability Considerations ................ 14
5. Security Considerations .................................. 13 3.1.2. Vendor Allocations ............................. 14
6. References ............................................... 13 3.1.3. SDO Allocations ................................ 15
6.1. Normative References ................................ 13 3.1.4. Publication of specifications .................. 15
6.2. Informative References .............................. 14 3.2. Polymorphic Attributes .............................. 16
Full Copyright Statement ..................................... 21 4. IANA Considerations ...................................... 16
5. Security Considerations .................................. 16
6. References ............................................... 17
6.1. Normative References ................................ 17
6.2. Informative References .............................. 17
Appendix A - Design Guidelines ............................... 20
A.1. Types matching the RADIUS data model ................. 20
A.1.1. Transport of simple data ........................ 20
A.1.2. Extended data types ............................. 20
A.1.3. Complex data types .............................. 21
A.2. Improper Data Types .................................. 21
A.2.1. Simple Data Types ............................... 21
A.2.2. Complex Data Types .............................. 22
A.3. Vendor-Specific formats .............................. 22
A.4. New functionality in RADIUS. ......................... 23
A.5. Allocation of attributes ............................. 23
Appendix B - Complex Attributes .............................. 25
B.1. CHAP-Password ........................................ 25
B.2. CHAP-Challenge ....................................... 25
B.3. Tunnel-Password ...................................... 25
B.4. ARAP-Password ........................................ 26
B.5. ARAP-Features ........................................ 26
B.6. Connect-Info ......................................... 27
B.7. Framed-IPv6-Prefix ................................... 27
B.8. Egress-VLANID ........................................ 28
B.9. Egress-VLAN-Name ..................................... 29
Full Copyright Statement ..................................... 30
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 Standards Development both within the IETF as well as within other Standards Development
Organizations (SDOs). Organizations (SDOs). It recognizes that requiring SDOs to
accomplish all their RADIUS work within the IETF is inherently
inefficient and unscalable. By articulating guidelines for attribute
design, this document enables to SDOs to design their own RADIUS
attributes within the Vendor-Specific Attribute (VSA) space, seeking
review from the IETF.
As with "Guidelines for Authors and Reviewers of MIB Documents" As with "Guidelines for Authors and Reviewers of MIB Documents"
[RFC4181], it is expected that this document will enable authors to [RFC4181], it is expected that this document will enable authors to
check their document against the guidelines prior to requesting a check their document against the guidelines prior to requesting a
review (such an "Expert Review" described in [RFC3575]). Similarly, review (such an "Expert Review" described in [RFC3575]). Similarly,
it is hoped that this document will be of use to reviewers (such as it is hoped that this document will be of use to reviewers (such as
WG participants or the AAA Doctors) in improving the consistency of WG participants or the AAA Doctors) in improving the consistency of
reviews. 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. As a result, only the science of attribute design, but also the art. As a result,
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 attempts to provide some of the considerations motivating
the guidelines. the guidelines.
In order to characterize current attribute usage, both the basic and In order to characterize current attribute usage, both the basic and
complex data types defined in the existing RADIUS RFCs are reviewed, complex data types defined in the existing RADIUS RFCs are reviewed,
together with the ad-hoc extensions to that data model that have been together with the ad-hoc extensions to that data model that have been
used in Vendor Specific Attributes (VSAs). In addition, used in Vendor-Specific Attributes.
recommendations are made with respect to recommended VSA formats as
well as handling of RADIUS type 26 attributes within Diameter.
1.1. Applicability 1.1. Applicability
The major goal of this document is to encourage the development and The major goal of this document is to encourage the development and
publication of high quality RADIUS attribute specifications. By publication of high quality RADIUS attribute specifications. By
articulating RADIUS design guidelines, it is hoped that this document articulating RADIUS design guidelines, it is hoped that this document
will be a step in that direction. However, the advice in this will be a step in that direction. However, the advice in this
document will not be helpful unless it is put to use. In particular, document will not be helpful unless it is put to use. In particular,
the authors recommend: the authors recommend:
o Development of a program to encourage SDOs to make their RADIUS * Development of a program to encourage SDOs to make their RADIUS
attribute specifications publicly available; attribute specifications publicly available;
o Review of IETF and SDO specifications according to the * Review of IETF and SDO specifications according to the
guidelines proposed in this document; guidelines proposed in this document;
The advice in this document applies to attributes used to encode The advice in this document applies to attributes used to encode
data. RADIUS protocol changes, or specification of attributes that data. RADIUS protocol changes, or specification of attributes that
can be used to provide new RADIUS commands (such as Service-Type) are can be used to provide new RADIUS commands (such as Service-Type) are
out of scope. Since protocol changes require greater expertise and out of scope. Since protocol changes require greater expertise and
deeper review, such changes should not be undertaken outside the IETF deeper review, such changes should not be undertaken outside the IETF
and when handled within the IETF require "IETF Consensus" for and when handled within the IETF require "IETF Consensus" for
adoption, as noted in [RFC3575] Section 2.1. adoption, as noted in [RFC3575] Section 2.1.
As with protocol changes, this document does not provide guidance to As with protocol changes, this document does not provide guidance to
document authors seeking to change the RADIUS operational model. document authors seeking to change the RADIUS operational model.
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
use of the State Attribute are inherently incompatible with RADIUS as use of the State Attribute are inherently incompatible with RADIUS as
defined in [RFC2865], and need to be redesigned. defined in [RFC2865], and need to be redesigned.
See [FIXES] Section 2.1.1 for a more in-depth discussion of the use See [RFC5080] Section 2.1.1 for a more in-depth discussion of the use
of the State Attribute. of the State Attribute.
1.2. Terminology 1.2. 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 server is an entity that provides an A RADIUS authentication, authorization, and/or accounting (AAA)
authentication service to a NAS. server is an entity that provides one or more AAA services to a
NAS.
RADIUS proxy RADIUS proxy
A RADIUS proxy acts as an authentication server to the NAS, and a A RADIUS proxy acts as a RADIUS server to the NAS, and a RADIUS
RADIUS client to the RADIUS server. client to the RADIUS server.
1.3. Requirements Language 1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. RADIUS Data Model 2. RADIUS Data Model
The Remote Authentication Dial In User Service (RADIUS) defined in The Remote Authentication Dial In User Service (RADIUS) defined in
[RFC2865] [RFC2866] utilizes elements known as attributes, in order [RFC2865] and [RFC2866] uses elements known as attributes in order to
to represent authentication, authorization and accounting (AAA) data. represent authentication, authorization and accounting data.
Unlike SNMP, first defined in [RFC1157] [RFC1155], RADIUS does not Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does
define a formal data definition language. A handful of basic data not define a formal data definition language. A handful of basic
types are provided, and a data type is associated with an attribute data types are provided, and a data type is associated with an
when that attribute is defined. attribute when the attribute is defined.
Two distinct attribute spaces are defined: the standard space, and a Two distinct attribute spaces are defined: the standard space, and a
vendor specific space. Attributes in the standard space generally Vendor-Specific space. Attributes in the standard space generally
are composed of a type, length, value (TLV) triplet, although complex are composed of a type, length, value (TLV) triplet, although complex
attributes have also been defined. The vendor specific space is attributes have also been defined. The Vendor-Specific space is
encapsulated within a single attribute type (Vendor-Specific encapsulated within a single attribute type (Vendor-Specific
Attribute or VSA). The format of this space is defined by individual Attribute). The format of this space is defined by individual
vendors, but the same TLV encoding used by the standard space is vendors, but the same TLV encoding used by the standard space is
recommended in [RFC2865] Section 5.26. The similarity between recommended in [RFC2865] Section 5.26. The similarity between
attribute formats has enabled implementations to leverage common attribute formats has enabled implementations to leverage common
parsing functionality, although in some cases the attributes in the parsing functionality, although in some cases the attributes in the
vendor specific space have begun to diverge from the common format. Vendor-Specific space have begun to diverge from the common format.
2.1. Standard Space 2.1. Standard Space
The following subsections describe common data types and formats The following subsections describe common data types and formats
within the RADIUS standard attribute space. Common exceptions are within the RADIUS standard attribute space. Common exceptions are
identified. identified.
2.1.1. Basic Data Types 2.1.1. Basic Data Types
The data type of RADIUS attributes is not transported on the wire. The data type of RADIUS attributes is not transported on the wire.
Rather, the data type of a RADIUS attribute is fixed when that Rather, the data type of a RADIUS attribute is fixed when that
attribute is defined. Based on the RADIUS attribute type code, attribute is defined. Based on the RADIUS attribute type code,
RADIUS clients and servers can determine the data type based on pre- RADIUS clients and servers can determine the data type based on pre-
configured entries within a data dictionary. configured entries within a data dictionary.
RFC 2865 [RFC2865] defines the following data types: [RFC2865] defines the following data types:
text 1-253 octets containing UTF-8 encoded 10646 [RFC3629] text 1-253 octets containing UTF-8 encoded 10646 [RFC3629]
characters. Text of length zero (0) MUST NOT be sent; characters. Text of length zero (0) MUST NOT be sent;
omit the entire attribute instead. omit the entire attribute instead.
string 1-253 octets containing binary data (values 0 through string 1-253 octets containing binary data (values 0 through
255 decimal, inclusive). Strings of length zero (0) 255 decimal, inclusive). Strings of length zero (0)
MUST NOT be sent; omit the entire attribute instead. MUST NOT be sent; omit the entire attribute instead.
IPv4 address 32 bit value, most significant octet first. IPv4 address 32 bit value, most significant octet first.
integer 32 bit unsigned value, most significant octet first. integer 32 bit unsigned value, most significant octet first.
time 32 bit unsigned value, most significant octet first time 32 bit unsigned value, most significant octet first
skipping to change at page 6, line 8 skipping to change at page 6, line 12
128 bits of value, most significant octet first. 128 bits of value, most significant octet first.
integer64 64 bit unsigned value, most significant octet first. integer64 64 bit unsigned value, most significant octet first.
Examples of the IPv6 address type include NAS-IPv6-Address defined in Examples of the IPv6 address type include NAS-IPv6-Address defined in
[RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162] [RFC3162] Section 2.1 and 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. The integer64 type is used for the ARAP- and in [RFC4818] Section 3. The integer64 type is used for the ARAP-
Challenge-Response Attribute defined in [RFC2869] Section 5.15, and Challenge-Response Attribute defined in [RFC2869] Section 5.15, and
the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2. the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2.
[RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in [RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in
length, but denotes it as type "String". length, but denotes it as type String.
Given that attributes of type IPv6 address, IPv6 prefix, and Given that attributes of type IPv6 address, IPv6 prefix, and
integer64 are already in use, it is RECOMMENDED that RADIUS server integer64 are already in use, it is RECOMMENDED that RADIUS server
implementations include support for these additional basic types, in implementations include support for these additional basic types, in
addition to the types defined in [RFC2865]. addition to the types defined in [RFC2865].
It is worth noting that since RADIUS only supports unsigned integers It is worth noting that since RADIUS only supports unsigned integers
of 32 or 64 bits, attributes utilizing signed integer data types or of 32 or 64 bits, attributes using signed integer data types or
unsigned integer types of other sizes will require code changes, and unsigned integer types of other sizes will require code changes, and
SHOULD be avoided. SHOULD be avoided.
For [RFC2865] RADIUS VSAs, the length limitation of the String and
Text types is 247 octets instead of 253 octets, due to the additional
overhead of the Vendor-Specific Attribute.
2.1.2. Tagging Mechanism 2.1.2. Tagging Mechanism
[RFC2868] defines an attribute grouping mechanism based on the use of [RFC2868] defines an attribute grouping mechanism based on the use of
a one octet tag value. Tunnel attributes that refer to the same a one octet tag value. Tunnel attributes that refer to the same
tunnel are grouped together by virtue of using the same tag value. tunnel are grouped together by virtue of using the same tag value.
This tagging mechanism has some drawbacks. There are a limited This tagging mechanism has some drawbacks. There are a limited
number of unique tags (31). The tags are not well suited for use number of unique tags (31). The tags are not well suited for use
with arbitrary binary data values because it is not always possible with arbitrary binary data values, because it is not always possible
to tell if the first byte after the Length is the tag or the first to tell if the first byte after the Length is the tag or the first
byte of the untagged value (assuming the tag is optional). byte of the untagged value (assuming the tag is optional).
When integer values are tagged, the value portion is reduced to three Other limitations of the tagging mechaism are that when integer
bytes meaning only 24-bit numbers can be represented. values are tagged, the value portion is reduced to three bytes
meaning only 24-bit numbers can be represented. The tagging
The tagging mechanism does not offer an ability to create nested mechanism does not offer an ability to create nested groups of
groups of attributes. attributes. Some RADIUS implementations treat tagged attributes as
having additional data types tagged-string and tagged-integer. These
types increase the complexity of implementing and managing RADIUS
systems.
Some RADIUS implementations treat tagged attributes as an additional New attributes SHOULD NOT use this tagging method because of the
data type. limitatations described above. New attributes SHOULD use the
grouping method described in [EXTEN].
2.1.3. Complex Attribute Usage 2.1.3. Complex Attribute Usage
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 are
Attributes that utilize sub-fields instead of utilizing a basic data known as "complex attributes". As described below, the definition of
type are known as "complex attributes". As described below, complex attributes can lead to interoperability and deployment
definition of complex attributes can lead to interoperability and issues, so they need to introduced with care.
deployment issues, so that they need to introduced with care.
In general, complex attributes sent from the RADIUS server to the In general, complex attributes sent from the RADIUS server to the
client can be supported by concatenating the values into a String client can be supported by concatenating the values into a String
data type field. However, separating these values into different data type field. However, separating these values into different
attributes, each with its own type and length, would make it easier attributes, each with its own type and length, would have the
for the user to enter the data, would enable additional error following benefits:
checking and would simplify implementations by eliminating special
case, attribute specific parsing. * it is easier for the user to enter the data as well-known
types, rather than complex structures
* it enables additional error checking by leveraging the
parsing and validation routines for well-known types
* it simplifies implementations by eliminating special-case
attribute-specific parsing.
One of the fundamental goals of the RADIUS protocol design was to One of the fundamental goals of the RADIUS protocol design was to
allow RADIUS servers to be configured to support new attributes allow RADIUS servers to be configured to support new attributes
without requiring server code changes. RADIUS server implementations without requiring server code changes. RADIUS server implementations
typically utilize a data dictionary providing support for basic data typically use provide support for basic data types, and define
types, enabling a new attribute to be supported by addition of a attributes in a data dictionary. This architecture enables a new
dictionary entry, without requiring RADIUS server code changes. attribute to be supported by the addition of a dictionary entry,
without requiring RADIUS server code changes.
On the RADIUS client, code changes are typically required in order to On the RADIUS client, code changes are typically required in order to
implement a new attribute, since the RADIUS client typically has to implement a new attribute, as the RADIUS client typically has to
compose the attribute dynamically when sending. When receiving, a compose the attribute dynamically when sending. When receiving, a
RADIUS client needs to be able to parse the attribute and carry out RADIUS client needs to be able to parse the attribute and carry out
the requested service, so that a detailed understanding of the new the requested service. As a result, a detailed understanding of the
attribute is required. new attribute is required on clients, and data dictionaries are less
useful on clients than on servers.
Given this, the introduction of a new basic or complex attribute will Given these considerations, the introduction of a new basic or
typically require code changes on the RADIUS client, although the complex attribute will typically require code changes on the RADIUS
magnitude of changes for the complex attribute could be greater, due client. The magnitude of changes for the complex attribute could be
to the potential need for custom parsing logic. greater, due to the potential need for custom parsing logic.
However, the RADIUS server can be configured to send a new attribute The RADIUS server can be configured to send a new attribute by
by entering its type and data format in the RADIUS server dictionary, entering its type and data format in the RADIUS server dictionary,
then filling in the value within a form based on the data type. For and then filling in the value within a policy based on the attribute
complex attribute types not supported by RADIUS server dictionaries, name, data type and type-specific value. For complex attribute types
changes to the dictionary and forms code can be required in order to not supported by RADIUS server dictionaries, changes to the
allow the new attribute to be supported and configured by the RADIUS dictionary and policy management code can be required in order to
server. allow the new attribute to be supported by and configured on the
RADIUS server.
Code changes can also be required in the RADIUS server's receive Code changes can also be required in the RADIUS server's receive
path, due to limitations in RADIUS server policy languages, which path, due to limitations in RADIUS server policy languages, which
typically only provide for limited operations (such as comparisons or typically only provide for limited operations (such as comparisons or
arithmetic operations) on the basic data types. Most existing RADIUS arithmetic operations) on the basic data types. Most existing RADIUS
policy languages typically are not capable of parsing sub-elements, policy languages typically are not capable of parsing sub-elements,
or providing sophisticated matching functionality. or providing sophisticated matching functionality.
Given these limitations, the introduction of complex attributes can Given these limitations, the introduction of complex attributes can
require code changes on the RADIUS server which would be unnecessary require code changes on the RADIUS server which would be unnecessary
if basic data types were used instead. In addition, attribute- if basic data types had been used instead. In addition, attribute-
specific parsing means more complex software to develop and maintain, specific parsing means more complex software to develop and maintain.
and more complexity can lead to more error prone implementations. More complexity can lead to more error prone implementations, and
This can increase costs to network administrators as well as reducing interoperatibility problems. This issues can increase costs to
reliability and introducing deployment barriers. As a result, the network administrators as well as reducing reliability and
introduction of new complex data types within RADIUS attribute introducing deployment barriers. As a result, the introduction of
specifications SHOULD be avoided. new complex data types within RADIUS attribute specifications SHOULD
be avoided, except in the case of complex attributes involve
authentication or security functionality.
The exception to this recommendation are attributes which can be As can be seen in Appendix B, most of the complex attributes involve
treated as opaque data, such as the EAP-Message attribute, defined in authentication or security functionality. Supporting this
[RFC3579] Section 3.1. Since these attributes do not need to be functionality requires code changes on both the RADIUS client and
parsed by the RADIUS server, the issues arising from policy language server, regardless of the attribute format. As a result, in most
limitations do not arise. Similarly, since these attributes can be cases, the use of complex attributes to represent these methods is
configured on the server using a data type of String, dictionary acceptable, and does not create additional interoperability or
limitations are also not encountered. deployment issues.
The only other exception to the recommendation against complex types
is for types that can be treated as opaque data by the RADIUS server.
For example, the EAP-Message attribute, defined in [RFC3579] Section
3.1 contains a complex data type that is an EAP packet. Since these
complex types do not need to be parsed by the RADIUS server, the
issues arising from policy language limitations do not arise.
Similarly, since attributes of these complex types can be configured
on the server using a data type of String, dictionary limitations are
also not encountered. Section A.1 below includes a series of
checklists that may be used to analyze a design for RECOMMENDED and
NOT RECOMMENDED behavior in relation to complex types.
If the RADIUS Server simply passes the contents of an attribute to
some non-RADIUS portion of the network, then the data is opaque, and
SHOULD be defined to be of type String. A concrete way of judging
this requirement is whether or not the attribute definition in the
RADIUS document contains delineated fields for sub-parts of the data.
If those fields need to be delineated in RADIUS, then the data is not
opaque, and it SHOULD be separated into individual RADIUS attributes.
An examination of existing RADIUS RFCs discloses a number of complex An examination of existing RADIUS RFCs discloses a number of complex
attributes that have already been defined. Appendix A includes a attributes that have already been defined. Appendix B includes a
listing of complex attributes utilized within [RFC2865], [RFC2868], listing of complex attributes used within [RFC2865], [RFC2868],
[RFC2869], [RFC3162], [RFC4818], and [RFC4675]. [RFC2869], [RFC3162], [RFC4818], and [RFC4675]. The discussion of
these attributes includes reasons why a complex type is acceptable,
or suggestions for how the attribute could have been defined to
follow the RADIUS data model.
As can be seen in Appendix A, in most cases complex attributes In other cases, the data in the complex type are described textually.
involve authentication or security functionality that requires code This is possible because the data types are not sent within the
changes on both the RADIUS client and server, regardless of the attributes, but are a matter for endpoint interpretation. An
attribute format. As a result, in most cases the use of complex implementation can define additional data types (e.g., IPv6 address),
attributes did not create additional interoperability or deployment and use these data types today by matching them to the attribute's
issues. textual description.
In other cases the data are described textually. This is possible 2.1.4. Service definitions and RADIUS
because the data types are not sent within the attributes, but are a
matter for endpoint interpretation. An implementation can define RADIUS specifications define how an existing service or protocol can
additional data types (e.g. IPv6 address), and use these data types be provisioned using RADIUS. Therefore, it is expected that a RADIUS
today by matching them to the attribute's textual description. attribute specification will reference documents defining the
protocol or service to be provisioned. Within the IETF, a RADIUS
attribute specification SHOULD NOT be used to define the protocol or
service being provisioned. New services using RADIUS for
provisioning SHOULD be defined elsewhere and referenced in the RADIUS
specification.
RADIUS also SHOULD NOT be extended to new commands via attributes.
RADIUS attributes are intended to:
* authenticate users
* authorize users (i.e., service provisioning or changes to
provisioning)
* account for user activity (i.e., logging of session activity)
New commands (i.e., the Code field in the packet header) are
allocated only through "IETF Consensus" as noted in [RFC3575] Section
2.1. Specifications SHOULD NOT use new attributes to modify the
interpretation of existing RADIUS commands.
2.2. Vendor Space 2.2. Vendor Space
As noted in [RFC2865] Section 5.26, the VSA format is defined as As noted in [RFC2865] Section 5.26, the VSA format is defined as
follows: follows:
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 | Vendor-Id | Type | Length | Vendor-Id
skipping to change at page 9, line 4 skipping to change at page 10, line 18
As noted in [RFC2865] Section 5.26, the VSA format is defined as As noted in [RFC2865] Section 5.26, the VSA format is defined as
follows: follows:
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 | Vendor-Id | Type | Length | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | String... Vendor-Id (cont) | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
The high-order octet of the Vendor-Id field is 0 and the low-order 3 The high-order octet of the Vendor-Id field is 0 and the low-order 3
octets are the SMI Network Management Private Enterprise Code of the octets are the Structure of Management Information (SMI) Network
Vendor in network byte order. Management Private Enterprise Code (PEC) of the Vendor in network
byte order.
While the format of the String field is defined by the vendor, While the format of the String field is defined by the vendor,
[RFC2865] Section 5.26 notes: [RFC2865] Section 5.26 notes:
It SHOULD be encoded as a sequence of vendor type / vendor length It SHOULD be encoded as a sequence of vendor type / vendor length
/ value fields, as follows. The Attribute-Specific field is / value fields, as follows. The Attribute-Specific field is
dependent on the vendor's definition of that attribute. An dependent on the vendor's definition of that attribute. An
example encoding of the Vendor-Specific attribute using this example encoding of the Vendor-Specific attribute using this
method follows: method follows:
skipping to change at page 9, line 30 skipping to change at page 10, line 46
| Type | Length | Vendor-Id | Type | Length | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | Vendor type | Vendor length | Vendor-Id (cont) | Vendor type | Vendor length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute-Specific... | Attribute-Specific...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Multiple sub-attributes MAY be encoded within a single Vendor- Multiple sub-attributes MAY be encoded within a single Vendor-
Specific attribute, although they do not have to be. Specific attribute, although they do not have to be.
Note that the Vendor type field in the recommended format, like the Note that the Vendor type field in the recommended VSA format is only
RADIUS type field, is only a single octet. While this results in an a single octet, like the RADIUS type field. While this limitation
efficient encoding, there are situations in which a vendor or SDO results in an efficient encoding, there are situations in which a
will eventually wish to define more than 255 attributes. Also, an vendor or SDO will eventually wish to define more than 255
SDO can be comprised of multiple subgroups, each of whom can desire attributes. Also, an SDO can be comprised of multiple subgroups,
autonomy over the definition of attributes within their group. In each of whom can desire autonomy over the definition of attributes
such a situation, a 16-bit Vendor type field would be more within their group. In such a situation, a 16-bit Vendor type field
appropriate: would be more appropriate:
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 | Vendor-Id | Type | Length | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | Vendor type | Vendor-Id (cont) | Vendor type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor length | Attribute-Specific... | Vendor length | Attribute-Specific...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 48 skipping to change at page 11, line 16
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 | Vendor-Id | Type | Length | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | Vendor type | Vendor-Id (cont) | Vendor type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor length | Attribute-Specific... | Vendor length | Attribute-Specific...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Other attribute formats are NOT RECOMMENDED. Examples of NOT Other attribute formats are NOT RECOMMENDED. Examples of NOT
RECOMMENDED formats include Vendor types of more than 16 bits, Vendor RECOMMENDED formats include Vendor types of more than 16 bits, Vendor
lengths of less than 8 bits, Vendor lengths of more than 8 bits, and lengths of less than 8 bits, Vendor lengths of more than 8 bits, and
Vendor-Specific contents that are not in Type-Length-Value format. Vendor-Specific contents that are not in Type-Length-Value format.
In order to be compatible with the above recommendations for attribute
definitions, it is RECOMMENDED that RADIUS servers support attributes
using a 16-bit Vendor type field.
3. Data Model Issues 3. Data Model Issues
Since the closure of the RADIUS Working Group, the popularity and Since the closure of the RADIUS Working Group, the popularity and
prevalence of RADIUS has continued to grow. In addition to prevalence of RADIUS has continued to grow. In addition to
increasing demand for allocation of attributes within the RADIUS increasing demand for allocation of attributes within the RADIUS
standard attribute space, the number of vendors and SDOs creating new standard attribute space, the number of vendors and SDOs creating new
attributes within the vendor-specific attribute space has grown, and attributes within the Vendor-Specific attribute space has grown, and
this has lead to some divergence in approaches to RADIUS attribute this has lead to some divergence in approaches to RADIUS attribute
design. design.
In general, standard RADIUS attributes have a more constrained data In general, standard RADIUS attributes have a more constrained data
model than attributes within the vendor space. For example, vendors model than attributes within the vendor space. For example, vendors
have evolved the data model to support new functions such as and SDOs have evolved the data model to support new functions such as
attribute grouping and attribute fragmentation, with different attribute grouping and attribute fragmentation, with different groups
vendors taking different approaches. taking different approaches.
Given these enhancements, it has become difficult for vendors or SDOs Given these enhancements, it has become difficult for vendors or SDOs
to translate attributes from the vendor space to the more stringent to translate attributes from the vendor space to the more stringent
standards space. For example, a vendor-specific attribute utilizing standards space. For example, a Vendor-Specific attribute using sub-
sub-elements could require allocation of several standard space elements could require allocation of several standard space
attributes utilizing basic data types. In this case not only would attributes using basic data types. In this case not only would
translation require substantial additional work, it would further translation require substantial additional work, it would further
deplete the RADIUS standard attribute space. Given these deplete the RADIUS standard attribute space. Given these
limitations, translation of vendor attributes to the standards space limitations, translation of vendor attributes to the standards space
is not necessarily desirable, particularly if the VSA specification is not necessarily desirable, particularly if the VSA specification
is publicly available and can be implemented within existing RADIUS is publicly available and can be implemented within existing RADIUS
clients and servers. In such situations the costs may substantially clients and servers. In such situations, the costs may substantially
outweigh the benefits. While it is possible that some of the outweigh the benefits. While it is possible that some of the
enhancements made within the vendor space may eventually become enhancements made within the vendor space may eventually become
available within the standard attribute space, the divergence of the available within the standard attribute space, the divergence of the
standard and vendor attribute spaces is most likely a permanent standard and vendor attribute spaces is most likely a permanent
feature, and should be recognized as such. feature, and should be recognized as such.
For future work, any extensions to the RADIUS data model should be Recent extensions to the RADIUS data model such as [EXTEN] make it
used to minimize the use of complex attributes. possible to minimize the use of complex attributes. New
specifications seeking to extend the standard RADIUS data model
SHOULD examine [EXTEN] to see if their needs fit within the extended
RADIUS data model.
3.1. Vendor Space 3.1. Vendor Space
The usage model for RADIUS VSAs is described in [RFC2865] Section The usage model for RADIUS VSAs is described in [RFC2865] Section
6.2: 6.2:
Note that RADIUS defines a mechanism for Vendor-Specific Note that RADIUS defines a mechanism for Vendor-Specific
extensions (Attribute 26) and the use of that should be encouraged extensions (Attribute 26) and the use of that should be encouraged
instead of allocation of global attribute types, for functions instead of allocation of global attribute types, for functions
specific only to one vendor's implementation of RADIUS, where no specific only to one vendor's implementation of RADIUS, where no
interoperability is deemed useful. interoperability is deemed useful.
Nevertheless, many new attributes have been defined in the vendor Nevertheless, many new attributes have been defined in the vendor
specific space in situations where interoperability is not only specific space in situations where interoperability is not only
useful, but is required. For example, Standards Development useful, but is required. For example, Standards Development
Organizations (SDOs) outside the IETF (such as the IEEE 802 and the Organizations (SDOs) outside the IETF (such as the IEEE 802 and the
3rd Generation Partnership Project (3GPP)) have been assigned Vendor- 3rd Generation Partnership Project (3GPP)) have been assigned Vendor-
Ids, enabling them to define their own VSA format and assign Vendor Ids, enabling them to define their own VSA format and assign Vendor
types within their own space. types within their own space.
The utilization of VSAs by SDOs outside the IETF has gained in The use of VSAs by SDOs outside the IETF has gained in popularity for
popularity for several reasons: several reasons:
Efficiency Efficiency
As with SNMP, which defines an "Enterprise" Object Identifier (OID) As with SNMP, which defines an "Enterprise" Object Identifier (OID)
space suitable for use by vendors as well as other SDOs, the space suitable for use by vendors as well as other SDOs, the
definition of RADIUS attributes has become a common occurrence as definition of Vendor-Specific RADIUS attributes has become a common
part of standards activity outside the IETF. For reasons of occurrence as part of standards activity outside the IETF. For
efficiency, it is easiest for RADIUS attributes required to manage reasons of efficiency, it is easiest if the RADIUS attributes
a standard to be developed within the same SDO that develops the required to manage a standard are developed within the same SDO
standard itself. As noted in "Transferring MIB Work from IETF that develops the standard itself. As noted in "Transferring MIB
Bridge MIB WG to IEEE 802.1 WG" [RFC4663], today few vendors are Work from IETF Bridge MIB WG to IEEE 802.1 WG" [RFC4663], today few
willing to simultaneously fund individuals to participate within an vendors are willing to simultaneously fund individuals to
SDO to complete a standard, as well as to participate in IETF in participate within an SDO to complete a standard, as well as to
order to complete the associated RADIUS attributes specification. participate in IETF in order to complete the associated RADIUS
attributes specification.
Attribute scarcity Attribute scarcity
The standard RADIUS attribute space is limited to approximately 250 The standard RADIUS attribute space is limited to 255 unique
unique attributes; of these, only about half remain available for attributes. Of these, only about half remain available for
allocation. In the vendor specific space, the number of attributes allocation. In the Vendor-Specific space, the number of attributes
available is a function of the format of the attribute (the size of available is a function of the format of the attribute (the size of
the type field). the Vendor type field).
Along with these advantages, some limitations of VSA usage are noted Along with these advantages, some limitations of VSA usage are noted
in [RFC2865] Section 5.26: in [RFC2865] Section 5.26:
This Attribute is available to allow vendors to support their own This Attribute is available to allow vendors to support their own
extended Attributes not suitable for general usage. It MUST not extended Attributes not suitable for general usage. It MUST not
affect the operation of the RADIUS protocol. affect the operation of the RADIUS protocol.
Servers not equipped to interpret the vendor-specific information Servers not equipped to interpret the vendor-specific information
sent by a client MUST ignore it (although it may be reported). sent by a client MUST ignore it (although it may be reported).
Clients which do not receive desired vendor-specific information Clients which do not receive desired vendor-specific information
SHOULD make an attempt to operate without it, although they may do SHOULD make an attempt to operate without it, although they may do
so (and report they are doing so) in a degraded mode. so (and report they are doing so) in a degraded mode.
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 proved less of a constraint, since operate in the absence of VSAs has proven to be less of a constraint,
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
reset. reset.
Therefore, RFC 2865 provides considerable latitude for development of Therefore, RFC 2865 provides considerable latitude for development of
new attributes within the vendor space, while prohibiting development new attributes within the vendor space, while prohibiting development
of protocol variants. This flexibility implies that RADIUS of protocol variants. This flexibility implies that RADIUS
attributes can often be developed within the vendor space without attributes can often be developed within the vendor space without
loss (and possibly even gain) in functionality. loss (and possibly even gain) in functionality.
As a result, translation of RADIUS attributes developed within the As a result, translation of RADIUS attributes developed within the
vendor space into the standard space may provide only modest vendor space into the standard space may provide only modest
benefits, while accelerating the exhaustion of the standard attribute benefits, while accelerating the exhaustion of the standard attribute
space. Rather than expecting all RADIUS attribute specifications space. Rather than expecting all RADIUS attribute specifications
requiring interoperability to be developed within the IETF and requiring interoperability to be developed within the IETF and
expecting that they be allocated within the standards space, a more expecting that they be allocated within the standards space, a more
scalable approach is to recognize the flexibility of the vendor space scalable approach is to recognize the flexibility of the vendor space
while working toward improvements in the quality and availability of while working toward improvements in the quality and availability of
RADIUS attribute specifications, regardless of where they are RADIUS attribute specifications, regardless of where they are
developed. developed.
In particular, it is RECOMMENDED that RADIUS Attribute specifications 3.1.1. Interoperability Considerations
allocate attributes from the vendor space, rather than requesting an
allocation from the RADIUS standard attribute space, for attributes Vendors and SDOs are reminded that the standard RADIUS attribute ID
matching any of the following criteria: space, and the enumerated value space for enumerated attributes, are
* attributes relying on data types not defined within RADIUS * reserved for allocation through work published via the IETF, as noted
attributes intended primarily for use within an SDO * attributes in [RFC3575] Section 2.1. Some vendors and SDOs have in the past
intended primarily for use within a group of SDOs. performed self-allocation by assigning vendor-specific meaning to
"unused" values from the standard RADIUS attribute ID or enumerated
value space. This self-allocation results in interoperability
issues, and is counter-productive. Similarly, the Vendor-Specific
enumeration practice discussed in [RFC2882] Section 2.2.1 is NOT
RECOMMENDED.
If it is not possible to follow the above procedure, vendors and SDOs
they SHOULD self-allocate an attribute from their Vendor-Specific
space, and define an appropriate value for it.
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
undertaken with the same level of care as standard RADIUS attributes.
Specifically, the provisions of this document that apply to standard
RADIUS attributes also apply to SSAs or VSAs for multi-vendor usage.
3.1.2. Vendor Allocations
Vendor RADIUS Attribute specifications SHOULD allocate attributes
from the vendor space, rather than requesting an allocation from the
RADIUS standard attribute space.
As discussed in [RFC2865] Section 5.26, the vendor space is intended
for vendors to support their own extended attributes not suitable for
general use. However, it is RECOMMENDED that vendors follow the
guidelines outlined here, which are intended to enable maximum
interoperability with minimal changes to existing systems.
Following these guidelines means that RADIUS servers can be updated
to support the vendor's equipment by editing a RADIUS dictionary. If
these guidelines are not followed, then the vendor's equipment can
only be supported via code changes in RADIUS server implementations.
Such code changes add complexity and delay to implementations.
3.1.3. SDO Allocations
SDO RADIUS Attribute specifications SHOULD 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:
* attributes relying on data types not defined within RADIUS
* attributes intended primarily for use within an SDO
* attributes intended primarily for use within a group of SDOs.
The recommendation for SDOs to allocate attributes from a vendor
space rather than via IETF process is a recognition that SDOs may
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. Further allocation of attributes
inside of the VSA space defined by that Vendor-Id is subject solely
to the discretion of the SDO. Similarly, the use of data types
(complex or not) within that VSA space is solely under the discretion
of the SDO. It is RECOMMENDED that SDOs follow the guidelines
outlined here, which are intended to enable maximum interoperability
with minimal changes to existing systems.
It should be understood that SDOs do not have to rehost VSAs into the
standards space solely for the purpose of obtaining IETF review.
Rehosting puts pressure on the standards space, and may be harmful to
interoperability, since it can create two ways to provision the same
service. Rehosting may also require changes to the RADIUS data model
which will affect implementations that do not intend to support the
SDO specifications
3.1.4. Publication of specifications
SDOs are encouraged to seek early review of SSA specifications by the
IETF. This review may be initiated by sending mail to the AAA
Doctors list (aaa-doctors@ops.ietf.org). Since the IETF is not a
membership organization, in order to enable the RADIUS SSA
specification to be reviewed, it is RECOMMENDED that it be made
publicly available; this also encourages interoperability. Where the
RADIUS SSA specification is embedded within a larger document which
cannot be made public, the RADIUS attribute and value definitions
SHOULD be published instead as an Informational RFC, as with
[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
publicly available, for maximum interoperability. However, it is not
necessary for them to request publication of their VSA specifications
as Informational RFCs by the IETF.
All other specifications, including new authentication and/or
security mechanisms SHOULD be allocated via the standard RADIUS
space, as noted in [RFC3575] Section 2.1.
3.2. Polymorphic Attributes 3.2. Polymorphic Attributes
A polymorphic attribute is one whose format is dynamic. For example, A polymorphic attribute is one whose format or meaning is dynamic.
rather than using a fixed data format, an attribute's format might For example, rather than using a fixed data format, an attribute's
change based on the contents of another attribute. Or, the meaning format might change based on the contents of another attribute. Or,
of an attribute may be dependent on earlier packets in a sequence. the meaning of an attribute may depend on earlier packets in a
sequence.
Typically RADIUS server dictionary entries are static, enabling the RADIUS server dictionary entries are typically static, enabling the
user to enter the contents of an attribute, without support for user to enter the contents of an attribute without support for
changing the format based on dynamic conditions. However, this does changing the format based on dynamic conditions. However, this
not prevent implementations from returning different attributes based limitation on static types does not prevent implementations from
on the contents of received attributes; this is a common feature of implementing policies that return different attributes based on the
existing RADIUS implementations. contents of received attributes; this is a common feature of existing
RADIUS implementations.
In general, polymorphism is NOT RECOMMENDED. Polymorphism rarely In general, polymorphism is NOT RECOMMENDED. Polymorphism rarely
enables capabilities that would not be available through use of enables capabilities that would not be available through use of
multiple attributes, while requiring code changes in the RADIUS multiple attributes. Polymorphism requires code changes in the
server in situations where attributes with fixed formats will not. RADIUS server in situations where attributes with fixed formats would
Thus, polymorphism increases complexity while decreasing generality, not require such changes. Thus, polymorphism increases complexity
without delivering any corresponding benefits. while decreasing generality, without delivering any corresponding
benefits.
Note that changing an attribute's format dynamically is not the same Note that changing an attribute's format dynamically is not the same
thing as utilizing a fixed format and computing the attribute itself thing as using a fixed format and computing the attribute itself
dynamically. RADIUS authentication attributes such as User-Password, dynamically. RADIUS authentication attributes such as User-Password,
EAP-Message, etc. while being computed dynamically, utilize a fixed EAP-Message, etc. while being computed dynamically, use a fixed
format. format.
4. IANA Considerations 4. IANA Considerations
This document defines the use of a RADIUS type 26 attribute code in This document requires no action by IANA.
the Diameter Protocol space as defined in [RFC3588] and [RFC4005].
5. Security Considerations 5. Security Considerations
This specification provides guidelines for the design of RADIUS This specification provides guidelines for the design of RADIUS
attributes used in authentication, authorization and accounting. attributes used in authentication, authorization and accounting.
Threats and security issues for this application are described in Threats and security issues for this application are described in
[RFC3579] and [RFC3580]; security issues encountered in roaming are [RFC3579] and [RFC3580]; security issues encountered in roaming are
described in [RFC2607]. described in [RFC2607].
Encryption of RADIUS attributes on a per-attribute basis is necessary Encryption of RADIUS attributes on a per-attribute basis is necessary
in some cases. The current standard mechanism for this is described in some cases. The current standard mechanism for this is described
in [RFC2865] Section 5.2 (for obscuring User-Password values) and is in [RFC2865] Section 5.2 (for obscuring User-Password values) and is
based on the MD5 algorithm specified in [RFC1321]. The MD5 algorithm based on the MD5 algorithm specified in [RFC1321]. The MD5 algorithm
has recently become a focus of scrutiny and concern in security has recently become a focus of scrutiny and concern in security
circles, and as a result, the use of this technique in new attributes circles, and as a result, the use of this technique in new attributes
is NOT RECOMMENDED. is NOT RECOMMENDED.
Where new RADIUS attributes utilize cryptographic algorithms, Where new RADIUS attributes use cryptographic algorithms, algorithm
algorithm negotiation SHOULD be supported. Specification of a negotiation SHOULD be supported. Specification of a mandatory-to-
mandatory-to-implement algorithm is REQUIRED, and it is RECOMMENDED implement algorithm is REQUIRED, and it is RECOMMENDED that the
that the mandatory-to-implement algorithm be certifiable under FIPS mandatory-to-implement algorithm be certifiable under FIPS 140
140. [FIPS].
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June Authentication Dial In User Service (RADIUS)", RFC 2865, June
skipping to change at page 14, line 33 skipping to change at page 18, line 14
[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",
RFC 2869, June 2000. RFC 2869, June 2000.
[RFC2882] Mitton, D, "Network Access Servers Requirements: Extended
RADIUS Practices", RFC 2882, July 2000.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC
3162, August 2001. 3162, August 2001.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
In User Service) Support For Extensible Authentication In User Service) Support For Extensible Authentication
Protocol (EAP)", RFC 3579, September 2003. Protocol (EAP)", RFC 3579, September 2003.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE
802.1X Remote Authentication Dial In User Service (RADIUS) 802.1X Remote Authentication Dial In User Service (RADIUS)
Usage Guidelines", RFC3580, September 2003. Usage Guidelines", RFC3580, September 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 3629, November 2003. RFC 3629, November 2003.
[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB
Documents", RFC 4181, September 2005. Documents", RFC 4181, September 2005.
[RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge MIB WG [RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge MIB WG
to IEEE 802.1 WG", RFC 4663, September 2006. to IEEE 802.1 WG", RFC 4663, September 2006.
[RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for [RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for
Virtual LAN and Priority Support", RFC 4675, September 2006. Virtual LAN and Priority Support", RFC 4675, September 2006.
[RFC4679] Mammoliti, V., et al., "DSL Forum Vendor-Specific RADIUS
Attributes", RFC 4679, September 2006.
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
Attribute", RFC 4818, April 2007. Attribute", RFC 4818, April 2007.
[FIXES] Nelson, D. and DeKok, A, "Common Remote Authentication Dial In [RFC5080] Nelson, D. and DeKok, A, "Common Remote Authentication Dial In
User Service (RADIUS) Implementation Issues and Suggested User Service (RADIUS) Implementation Issues and Suggested
Fixes", RFC XXXX, DATE YYYY Fixes", RFC 5080, December 2007.
[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.
Appendix A - Complex Attributes [EXTEN] Li, Y., et al., "Extended Remote Authentication Dial In User
Service (RADIUS) Attributes", draft-ietf-radext-extended-
attributes-00.txt (work in progress).
[FIPS] FIPS 140-3 (DRAFT), "Security Requirements for Cryptographic
Modules", http://csrc.nist.gov/publications/fips/fips140-3/
Appendix A - Design Guidelines
The following text provides guidelines for the design of attributes
used by the RADIUS protocol. Specifications that follow these
guidelines are expected to achieve maximum interoperability with
minimal changes to existing systems.
A.1. Types matching the RADIUS data model
A.1.1. Transport of simple data
Does the data fit within the existing RADIUS data model, as outlined
below? If so, it SHOULD be encapsulated in a [RFC2865] format RADIUS
attribute, or in a [RFC2865] format RADIUS VSA.
* 32-bit unsigned integer, most significant octet first.
* Enumerated data types, represented as a 32-bit unsigned integer
with a list of name to value mappings. (e.g., Service-Type)
* 64-bit unsigned integer, most significant octet first.
* IPv4 address in network byte order.
* IPv6 address in network byte order.
* IPv6 prefix.
* time as 32 bit unsigned value, most significant octet first, in
seconds since 00:00:00 UTC, January 1, 1970.
* string (i.e., binary data), totalling 253 octets or less in
length. This includes the opaque encapsulation of data
structures defined outside of RADIUS. See also Section A.1.3,
below.
* UTF-8 text, totalling 253 octets or less in length.
* Complex data types for authentication and/or security.
These attributes SHOULD be defined only within the RADIUS
attribute space, and SHOULD NOT be defined within the VSA space.
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-
Specific format.
A.1.2. Extended data types
Where possible, the data types defined above in Section A.1.2 SHOULD
be used. The extended data types SHOULD be used only where there is
no clear method of expressing the data using existing types.
Does the data fit within the extended RADIUS data model, as outlined
below? If so, it SHOULD be encapsulated in a [EXTEN] format RADIUS
VSA.
* Attributes grouped into a logical container.
This does not included nested groups.
* Attributes requiring the transport of more than 247 octets of
Text or String data. This includes the opaque encapsulation
of data structures defined outside of RADIUS. See also Section
A.1.3, below.
A.1.3. Complex data types
Does the attribute encapsulate an existing data structure defined
outside of the RADIUS specifications? Can the attribute be treated
as opaque data by RADIUS servers (including proxies?) If both
questions can be answered affirmatively, a complex structure MAY be
used in a RADIUS specification.
The specification of the attribute SHOULD define the encapsulating
attribute to be of type String. The specification SHOULD refer to an
external document defining the structure. The specification SHOULD
NOT define or describe the structure, as discussed above in Section
2.1.3.
A.2. Improper Data Types
All data types other than the ones described above in Section A.1
SHOULD NOT be used. This section describes in detail a number of
data types that are NOT RECOMMENDED in new RADIUS specifications.
Where possible, replacement data types are suggested.
A.2.1. Simple Data Types
Does the attribute use any of the following data types? If so, the
data type SHOULD be replaced with the suggested alternatives, or
SHOULD NOT be used at all.
* Signed integers of any size.
SHOULD NOT be used. SHOULD be replaced with one or more
unsigned integer attributes. The definition of the attribute
can contain information that would otherwise go into the sign
value of the integer.
* 8 bit unsigned integers.
SHOULD be replaced with 32-bit unsigned integer. There is
insufficient justification to save three bytes.
* 16 bit unsigned integers.
SHOULD be replaced with 32-bit unsigned integer. There is
insufficient justification to save two bytes.
* Unsigned integers of size other than 32 or 64.
SHOULD be replaced by an unsigned integer of 32 or 64 bits.
There is insufficient justification to define a new size of
integer.
* Integers of any size in non-network byte order
SHOULD be replaced by unsigned integer of 32 or 64 bits,
in network byte order. There is no reason to transport integers
in any format other than network byte order.
* Tagged data types as described in [RFC2868].
These data types SHOULD NOT be used in new specifications. The
attribute grouping method defined in [EXTEN] SHOULD be used
instead.
* Complex data structures defined only within RADIUS.
The additional functionality defined in [EXTEN] SHOULD be used
instead. This recommendation does not apply to new attributes
for authentication or security, as described below in Section
A.2.2.
* Multi-field text strings.
Each field SHOULD be encapsulated in a separate attribute.
Where grouping of fields is desired, the additional
functionality defined in [EXTEN] SHOULD be used instead.
* Polymorphic attributes.
Multiple attributes, each with a static data type SHOULD be
defined instead.
A.2.2. Complex Data Types
Does the attribute define a complex data type for purposes other than
authentication or security? If so, this data type SHOULD be replaced
with simpler types, as discussed above in Section A.2.1. Also see
Section 2.1.3 for a discussion of why complex types are problematic.
A.3. Vendor-Specific formats
Does the specification contain Vendor-Specific attributes that match
any of the following criteria? If so, the data type should be
replaced with the suggested alternatives, or should not be used at
all.
* Vendor types of more than 16 bits.
SHOULD NOT be used. Vendor types of 8 or 16 bits SHOULD be used
instead.
* Vendor lengths of less than 8 bits. (i.e., zero bits)
SHOULD NOT be used. Vendor types of 8 or 16 bits SHOULD be used
instead.
* Vendor lengths of more than 8 bits.
SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used
instead.
* Vendor-Specific contents that are not in Type-Length-Value
format.
SHOULD NOT be used. Vendor-Specific attributes SHOULD be in
Type-Length-Value format.
We recognize that SDOs may require more than 256 attributes, which is
the limit of the 8-bit [RFC2865] Vendor-Specific space. Those SDOs
SHOULD use Vendor types of 16 bits. However, SDOs SHOULD NOT use
Vendor types of 16 bits unless there are immediate requirements.
Future-proofing a specification is insufficient grounds for using
16-bit Vendor types.
In general, Vendor-Specific attributes SHOULD follow the [RFC2865]
suggested format, or the [EXTEN] format if more functionality, or a
larger attribute space is necessary.
A.4. New functionality in RADIUS.
Does the specification extend RADIUS by adding new functionality, as
outlined in the list below? If so, it SHOULD NOT use RADIUS.
Another method of achieving the design objectives SHOULD be used.
* Defining new commands in RADIUS using attributes.
This restriction includes new commands created by overloading
the Service-Type attribute to define new values that modify
the functionality of Access-Request packets.
* Using RADIUS as a transport protocol for non-AAA data.
This restriction is partially a subset of the previous one.
Note that using RADIUS to transport authentication methods
(e.g., EAP) is explicitly permitted, even if those methods
require the transport of relatively large amounts of data.
* Extending the RADIUS packet length limitation past 4096 octets.
A multi-packet sequence of Access-Request / Access-Challenge
SHOULD be used instead. If that is not possible, then a method
other than RADIUS SHOULD be used to transport the data.
A.5. Allocation of attributes
Does the attribute have a limited scope of applicability, as outlined
below? If so, then the attributes SHOULD be allocated from the
Vendor-Specific space.
* attributes intended for a vendor to support their own systems,
and not suitable for general usage
* attributes relying on data types not defined within RADIUS
* attributes intended primarily for use within an SDO
* attributes intended primarily for use within a group of SDOs.
Note that the points listed above do not relax the recommendations
discussed in this document. Instead, they recognize that the RADIUS
data model has limitations. In certain situations where
interoperability can be strongly constrained, a data model extended
by the SDO or vendor MAY be used. We recommend, however, that the
RADIUS data model SHOULD be used, even if it is marginally less
efficient than alternatives.
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 with existing RFCs. that are defined in existing RFCs.
A.1 CHAP-Password B.1. CHAP-Password
[RFC2865] Section 5.3 defines the CHAP-Password Attribute which is [RFC2865] Section 5.3 defines the CHAP-Password Attribute which is
sent from the RADIUS client to the RADIUS server in an Access- sent from the RADIUS client to the RADIUS server in an Access-
Request. The the data type of the CHAP Identifier is not given, only Request. The the data type of the CHAP Identifier is not given, only
the one octet length: the one octet length:
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 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 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | CHAP Ident | String ... | Type | Length | CHAP Ident | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Since this is an authentication attribute, code changes would have Since this is an authentication attribute, code changes are required
been required on the RADIUS client and server, regardless of the on the RADIUS client and server to support it, regardless of the
attribute format. attribute format. Therefore, this complex data type is acceptable in
this situation.
A.2 CHAP-Challenge B.2. CHAP-Challenge
[RFC2865] Section 5.40 defines the CHAP-Challenge Attribute which is [RFC2865] Section 5.40 defines the CHAP-Challenge Attribute which is
sent from the RADIUS client to the RADIUS server in an Access- sent from the RADIUS client to the RADIUS server in an Access-
Request. While the data type of the CHAP Identifier is given, the Request. While the data type of the CHAP Identifier is given, the
text also says text also says
If the CHAP challenge value is 16 octets long it MAY be placed in If the CHAP challenge value is 16 octets long it MAY be placed in
the Request Authenticator field instead of using this attribute. the Request Authenticator field instead of using this attribute.
Defining attributes to contain values taken from the RADIUS packet Defining attributes to contain values taken from the RADIUS packet
header is NOT RECOMMENDED. Attributes should have values that are header is NOT RECOMMENDED. Attributes should have values that are
packed into a RADIUS AVP. packed into a RADIUS AVP.
A.3 Tunnel-Password B.3. Tunnel-Password
[RFC2868] Section 3.5 defines the Tunnel-Password Attribute, which is [RFC2868] Section 3.5 defines the Tunnel-Password Attribute, which is
sent from the RADIUS server to the client in an Access-Accept. This sent from the RADIUS server to the client in an Access-Accept. This
attribute includes Tag and Salt fields, as well as a String field attribute includes Tag and Salt fields, as well as a string field
which consists of three logical sub-fields: the Data-Length (one which consists of three logical sub-fields: the Data-Length (one
octet) and Password sub-fields (both of which are required), and the octet) and Password sub-fields (both of which are required), and the
optional Padding sub-field. The attribute appears as follows: optional Padding sub-field. The attribute appears as follows:
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 | Salt | Type | Length | Tag | Salt
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Salt (cont) | String ... Salt (cont) | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Given that the String field is encrypted, this attribute would have Since this is a security attribute and is encrypted, code changes are
required code changes on the RADIUS client and server, regardless of required on the RADIUS client and server to support it, regardless of
the format. the attribute format. Therefore, this complex data type is
acceptable in this situation.
A.4 ARAP-Password B.4. ARAP-Password
[RFC2869] Section 5.4 defines the ARAP-Password attribute, which is [RFC2869] Section 5.4 defines the ARAP-Password attribute, which is
sent from the RADIUS client to the server in an Access-Request. It sent from the RADIUS client to the server in an Access-Request. It
contains four 4 octet values, instead of having a single Value field: contains four 4 octet values, instead of having a single Value field:
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 | Value1 | Type | Length | Value1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 17, line 37 skipping to change at page 26, line 39
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value4 | Value4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As with the CHAP-Password attribute, this is an authentication As with the CHAP-Password attribute, this is an authentication
attribute which would have required code changes on the RADIUS client attribute which would have required code changes on the RADIUS client
and server regardless of format. and server regardless of format.
A.5 ARAP-Features B.5. ARAP-Features
[RFC2869] Section 5.5 defines the ARAP-Features Attribute, which is [RFC2869] Section 5.5 defines the ARAP-Features Attribute, which is
sent from the RADIUS server to the client in an Access-Accept or sent from the RADIUS server to the client in an Access-Accept or
Access-Challenge. It contains a compound string of two single octet Access-Challenge. It contains a compound string of two single octet
values, plus three 4-octet values, which the RADIUS client values, plus three 4-octet values, which the RADIUS client
encapsulates in a feature flags packet in the ARAP protocol: encapsulates in a feature flags packet in the ARAP protocol:
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 | Value1 | Value2 | | Type | Length | Value1 | Value2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value3 | | Value3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value4 | | Value4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value5 | | Value5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unlike previous attributes, this attribute contains no encrypted Unlike the previous attributes, this attribute contains no encrypted
component nor is it directly involved in authentication. The component, nor is it directly involved in authentication. The
individual sub-fields therefore could have been encapsulated in individual sub-fields therefore could have been encapsulated in
separate attributes, although this would have required creation of an separate attributes.
8 bit data type.
A.6 Connect-Info B.6. Connect-Info
[RFC2869] Section 5.11 defines the Connect-Info attribute, which is [RFC2869] Section 5.11 defines the Connect-Info attribute, which is
used to indicate the nature of the connection. used to indicate the nature of the connection.
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Text... | Type | Length | Text...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Even though the type is Text, the rest of the description indicates Even though the type is Text, the rest of the description indicates
skipping to change at page 18, line 42 skipping to change at page 27, line 43
first attribute with the transmit speed first (the speed the NAS first attribute with the transmit speed first (the speed the NAS
modem transmits at), a slash (/), the receive speed, then modem transmits at), a slash (/), the receive speed, then
optionally other information. optionally other information.
For example, "28800 V42BIS/LAPM" or "52000/31200 V90" For example, "28800 V42BIS/LAPM" or "52000/31200 V90"
More than one Connect-Info attribute may be present in an More than one Connect-Info attribute may be present in an
Accounting-Request packet to accommodate expected efforts by ITU Accounting-Request packet to accommodate expected efforts by ITU
to have modems report more connection information in a standard to have modems report more connection information in a standard
format that might exceed 252 octets. format that might exceed 252 octets.
This attribute contains no encrypted component nor is it directly This attribute contains no encrypted component, and is it not
involved in authentication. The individual sub-fields therefore directly involved in authentication. The individual sub-fields could
could have been encapsulated in separate attributes therefore have been encapsulated in separate attributes.
A.7 Framed-IPv6-Prefix B.7. Framed-IPv6-Prefix
[RFC3162] Section 2.3 defines the Framed-IPv6-Prefix Attribute and [RFC3162] Section 2.3 defines the Framed-IPv6-Prefix Attribute and
[RFC4818] Section 3 reuses this format for the Delegated-IPv6-Prefix [RFC4818] Section 3 reuses this format for the Delegated-IPv6-Prefix
Attribute; these attributes are sent from the RADIUS server to the Attribute; these attributes are sent from the RADIUS server to the
client in an Access-Accept. client in an Access-Accept.
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 | Reserved | Prefix-Length | | Type | Length | Reserved | Prefix-Length |
skipping to change at page 19, line 25 skipping to change at page 28, line 26
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix | Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sub-fields encoded in these attributes are strongly related, and The sub-fields encoded in these attributes are strongly related, and
there was no previous definition of this data structure that could be there was no previous definition of this data structure that could be
referenced. Support for this attribute requires code changes on both referenced. Support for this attribute requires code changes on both
the client and server, due to a new data type being defined. In this the client and server, due to a new data type being defined. In this
case it appears to be acceptable to encode them in one attribute. case it appears to be acceptable to encode them in one attribute.
A.8 Egress-VLANID B.8. Egress-VLANID
[RFC4675] Section 2.1 defines the Egress-VLANID Attribute which can [RFC4675] Section 2.1 defines the Egress-VLANID Attribute which can
be sent by a RADIUS client or server. be sent by a RADIUS client or server.
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 | Value | Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) | Value (cont) |
skipping to change at page 20, line 8 skipping to change at page 29, line 10
The length of the VLANID field is defined by the [IEEE-802.1Q] The length of the VLANID field is defined by the [IEEE-802.1Q]
specification. The Tag indicator field is either 0x31 or 0x32, for specification. The Tag indicator field is either 0x31 or 0x32, for
compatibility with the Egress-VLAN-Name, as discussed below. The compatibility with the Egress-VLAN-Name, as discussed below. The
complex structure of Egress-VLANID overlaps with that of the base complex structure of Egress-VLANID overlaps with that of the base
Integer data type, meaning that no code changes are required for a Integer data type, meaning that no code changes are required for a
RADIUS server to support this attribute. Code changes are required RADIUS server to support this attribute. Code changes are required
on the NAS, if only to implement the VLAN ID enforcement. on the NAS, if only to implement the VLAN ID enforcement.
Given the IEEE VLAN requirements and the limited data model of Given the IEEE VLAN requirements and the limited data model of
RADIUS, the chosen method is likely the best of the possible RADIUS, the chosen method is likely the best of the possible
alternatives. alternatives. Future specifications that attempt to obtain similar
functionality SHOULD use the extended types from [EXTEN].
A.9 Egress-VLAN-Name B.9. Egress-VLAN-Name
[RFC4675] Section 2.3 defines the Egress-VLAN-Name Attribute which [RFC4675] Section 2.3 defines the Egress-VLAN-Name Attribute which
can be sent by a RADIUS client or server. can be sent by a RADIUS client or server.
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. Future
specifications that attempt to obtain similar functionality SHOULD
use the extended types from [EXTEN].
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 and Glen Zorn for contributions to this
document. document.
Authors' Addresses Authors' Addresses
Greg Weber Greg Weber
Cisco Systems
10850 Murdock Road
Knoxville, TN 37932 Knoxville, TN 37932
USA USA
Email: gdweber@cisco.com Email: gdweber@gmail.com
Alan DeKok Alan DeKok
The FreeRADIUS Server Project The FreeRADIUS Server Project
http://freeradius.org/ http://freeradius.org/
Email: aland@freeradius.org Email: aland@freeradius.org
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
 End of changes. 86 change blocks. 
206 lines changed or deleted 612 lines changed or added

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