draft-ietf-radext-design-07.txt   draft-ietf-radext-design-08.txt 
Network Working Group G. Weber Network Working Group Alan DeKok (ed.)
INTERNET-DRAFT Individual Contributor INTERNET-DRAFT FreeRADIUS
Category: Best Current Practice Alan DeKok (ed.) Category: Best Current Practice G. Weber
<draft-ietf-radext-design-07.txt> FreeRADIUS <draft-ietf-radext-design-08.txt> Individual Contributor
Expires: September 5, 2009 Expires: March 6, 2010
6 September 2009
RADIUS Design Guidelines RADIUS Design Guidelines
draft-ietf-radext-design-08
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and document may not be modified outside the IETF Standards Process, and
skipping to change at page 1, line 39 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 5, 2009. This Internet-Draft will expire on March 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 7 skipping to change at page 3, line 7
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
reviewers of future RADIUS attribute specifications, both within the reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs). IETF as well as other Standards Development Organizations (SDOs).
Table of Contents Table of Contents
1. Introduction ............................................. 5 1. Introduction ............................................. 4
1.1. Applicability ....................................... 5 1.1. Terminology ......................................... 4
1.2. Terminology ......................................... 6 1.2. Requirements Language ............................... 4
1.3. Requirements Language ............................... 7 1.3. Applicability ....................................... 5
2. RADIUS Data Model ........................................ 7 2. RADIUS Data Model ........................................ 6
2.1. Standard Space ...................................... 7 2.1. Standard Space ...................................... 6
2.1.1. Basic Data Types ............................... 7 2.1.1. Basic Data Types ............................... 6
2.1.2. Tagging Mechanism .............................. 9 2.1.2. Tagging Mechanism .............................. 8
2.1.3. Complex Attribute Usage ........................ 9 2.1.3. Complex Attribute Usage ........................ 8
2.1.4. Complex Attributes and Security ................ 12 2.1.4. Complex Attributes and Security ................ 11
2.1.5. Service definitions and RADIUS ................. 12 2.1.5. Service definitions and RADIUS ................. 11
2.2. Extended RADIUS Attributes .......................... 13 2.2. Vendor Space ........................................ 12
2.3. Vendor Space ........................................ 13 3. Data Model Issues ........................................ 13
3. Data Model Issues ........................................ 14 3.1. Vendor Space ........................................ 14
3.1. Vendor Space ........................................ 15 3.1.1. Interoperability Considerations ................ 16
3.1.1. Interoperability Considerations ................ 17 3.1.2. Vendor Allocations ............................. 16
3.1.2. Vendor Allocations ............................. 18 3.1.3. SDO Allocations ................................ 17
3.1.3. SDO Allocations ................................ 18 3.1.4. Publication of specifications .................. 18
3.1.4. Publication of specifications .................. 19 3.2. Polymorphic Attributes .............................. 18
3.2. Polymorphic Attributes .............................. 19 3.3. RADIUS Operational Model ............................ 19
3.3. RADIUS Operational Model ............................ 20
4. IANA Considerations ...................................... 22 4. IANA Considerations ...................................... 22
5. Security Considerations .................................. 23 5. Security Considerations .................................. 22
6. References ............................................... 24 6. References ............................................... 23
6.1. Normative References ................................ 24 6.1. Normative References ................................ 23
6.2. Informative References .............................. 24 6.2. Informative References .............................. 23
Appendix A - Design Guidelines ............................... 27 Appendix A - Design Guidelines ............................... 26
A.1. Types matching the RADIUS data model ................. 27 A.1. Types matching the RADIUS data model ................. 26
A.1.1. Transport of simple data ........................ 27 A.1.1. Transport of simple data ........................ 26
A.1.2. Extended data types ............................. 27 A.1.2. Opaque data types ............................... 26
A.1.3. Opaque data types ............................... 28 A.2. Improper Data Types .................................. 27
A.2. Improper Data Types .................................. 28 A.2.1. Simple Data Types ............................... 27
A.2.1. Simple Data Types ............................... 28 A.2.2. Complex Data Types .............................. 28
A.2.2. Complex Data Types .............................. 29 A.3. Vendor-Specific formats .............................. 28
A.3. Vendor-Specific formats .............................. 29 A.4. Changes to the RADIUS Operational Model .............. 29
A.4. Changes to the RADIUS Operational Model .............. 30 A.5. Allocation of attributes ............................. 30
A.5. Allocation of attributes ............................. 31 Appendix B - Complex Attributes .............................. 31
Appendix B - Complex Attributes .............................. 32 B.1. CHAP-Password ........................................ 31
B.1. CHAP-Password ........................................ 32 B.2. CHAP-Challenge ....................................... 31
B.2. CHAP-Challenge ....................................... 32 B.3. Tunnel-Password ...................................... 31
B.3. Tunnel-Password ...................................... 32 B.4. ARAP-Password ........................................ 32
B.4. ARAP-Password ........................................ 33 B.5. ARAP-Features ........................................ 32
B.5. ARAP-Features ........................................ 33 B.6. Connect-Info ......................................... 33
B.6. Connect-Info ......................................... 34 B.7. Framed-IPv6-Prefix ................................... 34
B.7. Framed-IPv6-Prefix ................................... 35 B.8. Egress-VLANID ........................................ 34
B.8. Egress-VLANID ........................................ 35 B.9. Egress-VLAN-Name ..................................... 35
B.9. Egress-VLAN-Name ..................................... 36
1. Introduction 1. Introduction
This document provides guidelines for the design of RADIUS attributes This document provides guidelines for the design of RADIUS attributes
both within the IETF as well as within other SDOs. By articulating both within the IETF as well as within other SDOs. By articulating
RADIUS design guidelines, it is hoped that this document will RADIUS design guidelines, it is hoped that this document will
encourage the development and publication of high quality RADIUS encourage the development and publication of high quality RADIUS
attribute specifications. attribute specifications.
However, the advice in this document will not be helpful unless it is However, the advice in this document will not be helpful unless it is
skipping to change at page 5, line 31 skipping to change at page 4, line 31
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.
1.1. Applicability 1.1. Terminology
This document uses the following terms:
Network Access Server (NAS)
A device that provides an access service for a user to a network.
RADIUS server
A RADIUS authentication, authorization, and/or accounting (AAA)
server is an entity that provides one or more AAA services to a
NAS.
RADIUS proxy
A RADIUS proxy acts as a RADIUS server to the NAS, and a RADIUS
client to the RADIUS server.
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.3. Applicability
As RADIUS has become more widely accepted as a management protocol, As RADIUS has become more widely accepted as a management protocol,
its usage has become more prevalent, both within the IETF as well as its usage has become more prevalent, both within the IETF as well as
within other SDOs. Given the expanded utilization of RADIUS, it has within other SDOs. Given the expanded utilization of RADIUS, it has
become apparent that requiring SDOs to accomplish all their RADIUS become apparent that requiring SDOs to accomplish all their RADIUS
work within the IETF is inherently inefficient and unscalable. By work within the IETF is inherently inefficient and unscalable. By
articulating guidelines for RADIUS attribute design, this document articulating guidelines for RADIUS attribute design, this document
enables SDOs out of the IETF to design their own RADIUS attributes enables SDOs out of the IETF to design their own RADIUS attributes
within the Vendor-Specific Attribute (VSA) space. within the Vendor-Specific Attribute (VSA) space.
It is RECOMMENDED that SDOs follow the guidelines articulated in this It is RECOMMENDED that SDOs follow the guidelines articulated in this
document. Doing so will ensure the widest possible applicability and document. Doing so will ensure the widest possible applicability and
interoperability of the specifications, while requiring minimal interoperability of the specifications, while requiring minimal
changes to existing systems. Specifications that do not follow the changes to existing systems. Specifications that do not follow the
guidelines articulated herein or in [EXTEN] are NOT RECOMMENDED. guidelines articulated herein are NOT RECOMMENDED. However, we
However, we recognize that there are some situations where SDOs or recognize that there are some situations where SDOs or vendors
vendors require the creation of specifications not following these require the creation of specifications not following these
guidelines. We do not forbid these specifications, but it is guidelines. We do not forbid these specifications, but it is
RECOMMENDED that they are created only if they have a limited scope RECOMMENDED that they are created only if they have a limited scope
of applicability, and all attributes defined in those specifications of applicability, and all attributes defined in those specifications
are VSAs, as discussed Section A.5, below. are VSAs, as discussed Appendix A.5, below.
It is RECOMMENDED that SDOs and vendors seek review of RADIUS It is RECOMMENDED that SDOs and vendors seek review of RADIUS
attribute specifications from the IETF. However, when specifications attribute specifications from the IETF. However, when specifications
are SDO specific, re-use existing data types, and follow these are SDO specific, re-use existing data types, and follow these
guidelines, they do not require IETF review. guidelines, they do not require IETF review.
In order to enable IETF review of such specifications, the authors In order to enable IETF review of such specifications, the authors
recommend that: recommend that:
* SDOs make their RADIUS attribute specifications publicly * SDOs make their RADIUS attribute specifications publicly
skipping to change at page 6, line 39 skipping to change at page 6, line 13
the SDO requirements, and which are also compatible with the the SDO requirements, and which are also compatible with the
traditional data model and uses of RADIUS. While these reviews traditional data model and uses of RADIUS. While these reviews
require access to public specifications, the review process does not require access to public specifications, the review process does not
require publication of an IETF RFC. require publication of an IETF RFC.
The advice in this document applies to attributes used to encode The advice in this document applies to attributes used to encode
service-provisioning or authentication data. RADIUS protocol service-provisioning or authentication data. RADIUS protocol
changes, or specification of attributes (such as Service-Type) that changes, or specification of attributes (such as Service-Type) that
can be used to, in effect, provide new RADIUS commands require can be used to, in effect, provide new RADIUS commands require
greater expertise and deeper review, as do changes to the RADIUS greater expertise and deeper review, as do changes to the RADIUS
operational model, as described in Section 3.3. Such changes MUST operational model as discussed below in Section 3.3. Such changes
NOT be undertaken outside the IETF and when handled within the IETF MUST NOT be undertaken outside the IETF and when handled within the
require "IETF Consensus" for adoption, as noted in [RFC3575] Section IETF require "IETF Consensus" for adoption, as noted in [RFC3575]
2.1. Section 2.1.
1.2. Terminology
This document uses the following terms:
Network Access Server (NAS)
A device that provides an access service for a user to a network.
RADIUS server
A RADIUS authentication, authorization, and/or accounting (AAA)
server is an entity that provides one or more AAA services to a
NAS.
RADIUS proxy
A RADIUS proxy acts as a RADIUS server to the NAS, and a RADIUS
client to the RADIUS server.
1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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] and [RFC2866] uses elements known as attributes in order to [RFC2865] and [RFC2866] uses elements known as attributes in order to
represent authentication, authorization and accounting data. represent authentication, authorization and accounting data.
Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does
not define a formal data definition language. A handful of basic not define a formal data definition language. A handful of basic
data types are provided, and a data type is associated with an data types are provided, and a data type is associated with an
skipping to change at page 8, line 15 skipping to change at page 7, line 16
[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, in network byte order. IPv4 address 32 bit value, in network byte order.
integer 32 bit unsigned value, most significant octet first. integer 32 bit unsigned value, in network byte order.
time 32 bit unsigned value, most significant octet first time 32 bit unsigned value, in network byte order.
-- seconds since 00:00:00 UTC, January 1, 1970. -- seconds since 00:00:00 UTC, January 1, 1970.
In addition to these data types, follow-on RADIUS specifications In addition to these data types, follow-on RADIUS specifications
define attributes using the following additional types: define attributes using the following additional types:
IPv6 address 128 bit value, most significant octet first. IPv6 address 128 bit value, in network byte order.
IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to
128 bits of value, in network byte order. 128 bits of value, in network byte order.
integer64 64 bit unsigned value, most significant octet first. integer64 64 bit unsigned value, in network byte order
This type has also been used to represent an IPv6 This type has also been used to represent an IPv6
interface identifier. interface identifier.
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
skipping to change at page 9, line 31 skipping to change at page 8, line 32
Other limitations of the tagging mechanism are that when integer Other limitations of the tagging mechanism are that when integer
values are tagged, the value portion is reduced to three bytes values are tagged, the value portion is reduced to three bytes
meaning only 24-bit numbers can be represented. The tagging meaning only 24-bit numbers can be represented. The tagging
mechanism does not offer an ability to create nested groups of mechanism does not offer an ability to create nested groups of
attributes. Some RADIUS implementations treat tagged attributes as attributes. Some RADIUS implementations treat tagged attributes as
having additional data types tagged-string and tagged-integer. These having additional data types tagged-string and tagged-integer. These
types increase the complexity of implementing and managing RADIUS types increase the complexity of implementing and managing RADIUS
systems. systems.
New attributes SHOULD NOT use this tagging method because of the New attributes SHOULD NOT use this tagging method because of the
limitations described above. New attributes SHOULD use the grouping limitations described above.
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
skipping to change at page 11, line 32 skipping to change at page 10, line 34
deployment issues. deployment issues.
The only other exception to the recommendation against complex types The only other exception to the recommendation against complex types
is for types that can be treated as opaque data by the RADIUS server. is for types that can be treated as opaque data by the RADIUS server.
For example, the EAP-Message attribute, defined in [RFC3579] Section For example, the EAP-Message attribute, defined in [RFC3579] Section
3.1 contains a complex data type that is an EAP packet. Since these 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 complex types do not need to be parsed by the RADIUS server, the
issues arising from policy language limitations do not arise. issues arising from policy language limitations do not arise.
Similarly, since attributes of these complex types can be configured Similarly, since attributes of these complex types can be configured
on the server using a data type of String, dictionary limitations are on the server using a data type of String, dictionary limitations are
also not encountered. Section A.1 below includes a series of also not encountered. Appendix A.1 below includes a series of
checklists that may be used to analyze a design for RECOMMENDED and checklists that may be used to analyze a design for RECOMMENDED and
NOT RECOMMENDED behavior in relation to complex types. NOT RECOMMENDED behavior in relation to complex types.
If the RADIUS Server simply passes the contents of an attribute to 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 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 SHOULD be defined to be of type String. A concrete way of judging
this requirement is whether or not the attribute definition in the this requirement is whether or not the attribute definition in the
RADIUS document contains delineated fields for sub-parts of the data. 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 If those fields need to be delineated in RADIUS, then the data is not
opaque, and it SHOULD be separated into individual RADIUS attributes. opaque, and it SHOULD be separated into individual RADIUS attributes.
skipping to change at page 13, line 15 skipping to change at page 12, line 15
* authenticate users * authenticate users
* authorize users (i.e., service provisioning or changes to * authorize users (i.e., service provisioning or changes to
provisioning) provisioning)
* account for user activity (i.e., logging of session activity) * account for user activity (i.e., logging of session activity)
New commands (i.e., the Code field in the packet header) are New commands (i.e., the Code field in the packet header) are
allocated only through "IETF Consensus" as noted in [RFC3575] Section allocated only through "IETF Consensus" as noted in [RFC3575] Section
2.1. Specifications also SHOULD NOT use new attributes to modify the 2.1. Specifications also SHOULD NOT use new attributes to modify the
interpretation of existing RADIUS commands. interpretation of existing RADIUS commands.
2.2. Extended RADIUS Attributes 2.2. Vendor Space
The extended RADIUS attribute document [EXTEN] defines a number of
extensions to RADIUS. The standard attribute space is extended by
permitting standard allocations from within a specific subset of the
VSA space; the format of extended attributes is defined; and extended
data types are defined within that format.
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.
2.3. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | String... Vendor-Id (cont) | String...
skipping to change at page 14, line 37 skipping to change at page 13, line 25
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If additional functionality is required, the format defined in
[EXTEN] SHOULD be used, with a non-zero Vendor-Id field.
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 In order to be compatible with the above recommendations for
attribute definitions, it is RECOMMENDED that RADIUS servers support attribute definitions, it is RECOMMENDED that RADIUS servers support
attributes using a 16-bit Vendor type field. attributes using a 16-bit Vendor type field.
Although [RFC2865] does not mandate it, implementations commonly
assume that the Vendor Id can be used as a key to determine the on-
the-wire format of a VSA. Vendors therefore SHOULD NOT use multiple
formats for VSAs that are associated with a particular Vendor Id. A
vendor wishing to use multiple VSA formats, SHOULD request one Vendor
Id for each VSA format that they will use.
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.
skipping to change at page 15, line 33 skipping to change at page 14, line 28
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. It is possible that some of the enhancements outweigh the benefits. It is possible that some of the enhancements
made within the vendor space may eventually become available within made within the vendor space may eventually become available within
the standard attribute space. However, the divergence of the the standard attribute space. However, 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.
Recent extensions to the RADIUS data model such as [EXTEN] make it
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.
skipping to change at page 17, line 36 skipping to change at page 16, line 24
space, and the enumerated value space for enumerated attributes, are space, and the enumerated value space for enumerated attributes, are
reserved for allocation through work published via the IETF, as noted reserved for allocation through work published via the IETF, as noted
in [RFC3575] Section 2.1. Some vendors and SDOs have in the past in [RFC3575] Section 2.1. Some vendors and SDOs have in the past
performed self-allocation by assigning vendor-specific meaning to performed self-allocation by assigning vendor-specific meaning to
"unused" values from the standard RADIUS attribute ID or enumerated "unused" values from the standard RADIUS attribute ID or enumerated
value space. This self-allocation results in interoperability value space. This self-allocation results in interoperability
issues, and is counter-productive. Similarly, the Vendor-Specific issues, and is counter-productive. Similarly, the Vendor-Specific
enumeration practice discussed in [RFC2882] Section 2.2.1 is NOT enumeration practice discussed in [RFC2882] Section 2.2.1 is NOT
RECOMMENDED. RECOMMENDED.
If it is not possible to follow the above procedure, vendors and SDOs If it is not possible to follow the IETF process, vendors and SDOs
SHOULD self-allocate an attribute from their Vendor-Specific space, SHOULD self-allocate an attribute from their Vendor-Specific space,
and define an appropriate value for it. and define an appropriate value for it.
As a side note, [RFC2865] Section 5.26 uses the term "Vendor-Specific 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 Attribute" to refer to an encoding format which can be used by
individual vendors to define attributes not suitable for general individual vendors to define attributes not suitable for general
usage. However, since then VSAs have also become widely used by SDOs usage. However, since then VSAs have also become widely used by SDOs
defining attributes intended for multi-vendor interoperability. As defining attributes intended for multi-vendor interoperability. As
such, these attributes are not specific to any single vendor, and the such, these attributes are not specific to any single vendor, and the
term "Vendor-Specific" may be misleading. An alternate term which term "Vendor-Specific" may be misleading. An alternate term which
skipping to change at page 20, line 26 skipping to change at page 19, line 18
EAP-Message, etc. while being computed dynamically, use a fixed EAP-Message, etc. while being computed dynamically, use a fixed
format. format.
3.3. RADIUS Operational Model 3.3. RADIUS Operational Model
The RADIUS operational model includes several assumptions: The RADIUS operational model includes several assumptions:
* The RADIUS protocol is stateless; * The RADIUS protocol is stateless;
* Provisioning of services is not possible within an * Provisioning of services is not possible within an
Access-Reject; Access-Reject;
* Distinction between authorization checks and user * There is a distinction between authorization checks and user
authentication; authentication;
* Authentication and integrity protection of RADIUS packets; * The protocol provices for authentication and integrity
* The RADIUS protocol is a Request/Response protocol. protection of packets;
* Packet length restriction. * The RADIUS protocol is a Request/Response protocol;
* The protocol defines packet length restrictions.
While RADIUS server implementations may keep state, the RADIUS While RADIUS server implementations may keep state, the RADIUS
protocol is stateless, although information may be passed from one protocol is stateless, although information may be passed from one
protocol transaction to another via the State Attribute. As a protocol transaction to another via the State Attribute. As a
result, documents which require stateful protocol behavior without result, documents which require stateful protocol behavior without
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. See [RFC5080] defined in [RFC2865], and need to be redesigned. See [RFC5080]
Section 2.1.1 for a more in-depth discussion of the use of the State Section 2.1.1 for a more in-depth discussion of the use of the State
Attribute. Attribute.
skipping to change at page 21, line 42 skipping to change at page 20, line 35
Disconnect-ACK or Disconnect-NAK packet, sent to the IP address and Disconnect-ACK or Disconnect-NAK packet, sent to the IP address and
port of the Dynamic Authorization Client (DAC) that originated the port of the Dynamic Authorization Client (DAC) that originated the
Disconnect-Request. Changes to this model are likely to require Disconnect-Request. Changes to this model are likely to require
major revisions to existing implementations and so this practice is major revisions to existing implementations and so this practice is
NOT RECOMMENDED. NOT RECOMMENDED.
The Length field in the RADIUS packet header is defined in [RFC2865] The Length field in the RADIUS packet header is defined in [RFC2865]
Section 3. It is noted there that the maximum length of a RADIUS Section 3. It is noted there that the maximum length of a RADIUS
packet is 4096 octets. As a result, attribute designers SHOULD NOT packet is 4096 octets. As a result, attribute designers SHOULD NOT
assume that a RADIUS implementation can successfully process RADIUS assume that a RADIUS implementation can successfully process RADIUS
packets larger than 4096 octets. If a situation is envisaged where packets larger than 4096 octets.
it may be necessary to carry authentication, authorization or
accounting data in a packet larger than 4096 octets, then one of the Even when packets are less than 4096 octets, they may be larger than
following approaches is RECOMMENDED: the Path Maximum Transmission Unit (PMTU). Any packet larger than
the PMTU will be fragmented, making communications more brittle as
firewalls and filtering devices often discard fragments. Transport
of fragmented UDP packets appears to be a poorly tested code path on
network devices. Some devices appear to be incapable of transporting
fragmented UDP packets, making it difficult to deploy RADIUS in a
network where those devices are deployed. We RECOMMEND that RADIUS
messages be kept as small possible.
If a situation is envisaged where it may be necessary to carry
authentication, authorization or accounting data in a packet larger
than 4096 octets, then one of the following approaches is
RECOMMENDED:
1. Utilization of a sequence of packets. 1. Utilization of a sequence of packets.
For RADIUS authentication, a sequence of Access-Request/ Access- For RADIUS authentication, a sequence of Access-Request/ Access-
Challenge packets would be used. For this to be feasible, Challenge packets would be used. For this to be feasible,
attribute designers need to enable inclusion of attributes that attribute designers need to enable inclusion of attributes that
can consume considerable space within Access-Challenge packets. can consume considerable space within Access-Challenge packets.
To maintain compatibility with existing NASes, either the use of To maintain compatibility with existing NASes, either the use of
Access-Challenge packets needs to be permissible (as with Access-Challenge packets needs to be permissible (as with
RADIUS/EAP, defined in [RFC3579]), or support for receipt of an RADIUS/EAP, defined in [RFC3579]), or support for receipt of an
Access-Challenge needs to be indicated by the NAS (as in RADIUS Access-Challenge needs to be indicated by the NAS (as in RADIUS
Location [RADIUSLOC]). Also, the specification needs to clearly Location [RFC5580]). Also, the specification needs to clearly
describe how attribute splitting is to be signalled and how describe how attribute splitting is to be signalled and how
attributes included within the sequence are to be interpreted, attributes included within the sequence are to be interpreted,
without requiring stateful operation. Unfortunately, previous without requiring stateful operation. Unfortunately, previous
specifications have not always exhibited the required foresight. specifications have not always exhibited the required foresight.
For example, even though very large filter rules are For example, even though very large filter rules are
conceivable, the NAS-Filter-Rule Attribute defined in [RFC4849] conceivable, the NAS-Filter-Rule Attribute defined in [RFC4849]
is not permitted in an Access-Challenge packet, nor is a is not permitted in an Access-Challenge packet, nor is a
mechanism specified to allow a set of NAS-Filter-Rule attributes mechanism specified to allow a set of NAS-Filter-Rule attributes
to be split across an Access-Request/Access-Challenge sequence. to be split across an Access-Request/Access-Challenge sequence.
skipping to change at page 22, line 52 skipping to change at page 22, line 9
RADIUS client and a home server. While such an approach can RADIUS client and a home server. While such an approach can
avoid the complexity of utilization of a sequence of packets, avoid the complexity of utilization of a sequence of packets,
dynamic discovery is likely to be time consuming and cannot be dynamic discovery is likely to be time consuming and cannot be
guaranteed to work with existing RADIUS implementations. As a guaranteed to work with existing RADIUS implementations. As a
result, this technique is not generally applicable. result, this technique is not generally applicable.
4. IANA Considerations 4. IANA Considerations
This document does not require that the IANA update any existing This document does not require that the IANA update any existing
registry or create any new registry, but includes information that registry or create any new registry, but includes information that
affects the IANA, for example: affects the IANA, which:
* includes guidelines that recommend against allocation from the * includes specific guidelines for Expert Reviewers appointed
RADIUS standard attribute space in other SDO RADIUS Attribute under the IANA considerations of [RFC3575]
specifications. * includes guidelines that recommend against self allocation from
the RADIUS standard attribute space in other SDO RADIUS
Attribute specifications.
* recommends that SDOs request a Private Enterprise Code (PEC) * recommends that SDOs request a Private Enterprise Code (PEC)
from the IANA, for use as a Vendor-Id within a Vendor-Specific from the IANA, for use as a Vendor-Id within a Vendor-Specific
attribute. attribute.
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
skipping to change at page 23, line 43 skipping to change at page 22, line 51
implement algorithm is REQUIRED, and it is RECOMMENDED that the implement algorithm is REQUIRED, and it is RECOMMENDED that the
mandatory-to-implement algorithm be certifiable under FIPS 140 mandatory-to-implement algorithm be certifiable under FIPS 140
[FIPS]. [FIPS].
Where new RADIUS attributes encapsulate complex data types, or Where new RADIUS attributes encapsulate complex data types, or
transport opaque data, the security considerations discussed in transport opaque data, the security considerations discussed in
Section 2.1.4 SHOULD be addressed. Section 2.1.4 SHOULD be addressed.
Message authentication in RADIUS is provided largely via the Message- Message authentication in RADIUS is provided largely via the Message-
Authenticator attribute. See [RFC3579] Section 3.2, and also Authenticator attribute. See [RFC3579] Section 3.2, and also
[RFC5080] 2.2.2. [RFC5080] 2.2.2, which says that client implementations SHOULD
include a Message-Authenticator attribute in every Access-Request.
In general, the security of the RADIUS protocol is poor. Robust In general, the security of the RADIUS protocol is poor. Robust
deployments SHOULD support a secure communications protocol such as deployments SHOULD support a secure communications protocol such as
IPSec. See [RFC3579] Section 4, and [RFC3580] Section 5 for a more IPSec. See [RFC3579] Section 4, and [RFC3580] Section 5 for a more
in-depth explanation of these issues. in-depth explanation of these issues.
Implementations not following the suggestions outlined in this
document may be subject to a problems such as ambiguous protocol
decoding, packet loss leading to loss of billing information, and
denial of service attacks.
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
2000. 2000.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575, July 2003. Authentication Dial In User Service)", RFC 3575, July 2003.
[EXTEN] Li, Y., et al., "Extended Remote Authentication Dial In User
Service (RADIUS) Attributes", draft-ietf-radext-extended-
attributes-05.txt, (work in progress).
6.2. Informative References 6.2. Informative References
[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of
management information for TCP/IP-based internets", STD 16, management information for TCP/IP-based internets", STD 16,
RFC 1155, May 1990. RFC 1155, May 1990.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol (SNMP)", STD 15, RFC 1157, May Network Management Protocol (SNMP)", STD 15, RFC 1157, May
1990. 1990.
skipping to change at page 26, line 10 skipping to change at page 25, line 15
[DOCTORS] AAA Doctors Mailing list <aaa-doctors@ops.ietf.org> [DOCTORS] AAA Doctors Mailing list <aaa-doctors@ops.ietf.org>
[FIPS] FIPS 140-3 (DRAFT), "Security Requirements for Cryptographic [FIPS] FIPS 140-3 (DRAFT), "Security Requirements for Cryptographic
Modules", http://csrc.nist.gov/publications/fips/fips140-3/ Modules", http://csrc.nist.gov/publications/fips/fips140-3/
[IEEE-802.1Q] [IEEE-802.1Q]
IEEE Standards for Local and Metropolitan Area Networks: Draft IEEE Standards for Local and Metropolitan Area Networks: Draft
Standard for Virtual Bridged Local Area Networks, Standard for Virtual Bridged Local Area Networks,
P802.1Q-2003, January 2003. P802.1Q-2003, January 2003.
[RADIUSLOC] [RFC5580] Tschofenig, H. (Ed.), "Carrying Location Objects in RADIUS and
Tschofenig, H. (Ed.), "Carrying Location Objects in RADIUS and Diameter", RFC 5580, August 2009.
Diameter", draft-ietf-geopriv-radius-lo-22.txt, (work in
progress)
Appendix A - Design Guidelines Appendix A - Design Guidelines
The following text provides guidelines for the design of attributes The following text provides guidelines for the design of attributes
used by the RADIUS protocol. Specifications that follow these used by the RADIUS protocol. Specifications that follow these
guidelines are expected to achieve maximum interoperability with guidelines are expected to achieve maximum interoperability with
minimal changes to existing systems. minimal changes to existing systems.
A.1. Types matching the RADIUS data model A.1. Types matching the RADIUS data model
A.1.1. Transport of simple data A.1.1. Transport of simple data
Does the data fit within the existing RADIUS data model, as outlined Does the data fit within the existing RADIUS data model, as outlined
below? If so, it SHOULD be encapsulated in a [RFC2865] format RADIUS below? If so, it SHOULD be encapsulated in a [RFC2865] format RADIUS
attribute, or in a [RFC2865] format RADIUS VSA that uses one of the attribute, or in a [RFC2865] format RADIUS VSA that uses one of the
existing RADIUS data types. existing RADIUS data types.
* 32-bit unsigned integer, most significant octet first. * 32-bit unsigned integer, in network byte order.
* Enumerated data types, represented as a 32-bit unsigned integer * Enumerated data types, represented as a 32-bit unsigned integer
with a list of name to value mappings. (e.g., Service-Type) with a list of name to value mappings. (e.g., Service-Type)
* 64-bit unsigned integer, most significant octet first. * 64-bit unsigned integer, in network byte order.
* IPv4 address in network byte order. * IPv4 address in network byte order.
* IPv6 address in network byte order. * IPv6 address in network byte order.
* IPv6 prefix. * IPv6 prefix.
* time as 32 bit unsigned value, most significant octet first, in * time as 32 bit unsigned value, in network byte order, and in
seconds since 00:00:00 UTC, January 1, 1970. seconds since 00:00:00 UTC, January 1, 1970.
* string (i.e., binary data), totalling 253 octets or less in * string (i.e., binary data), totalling 253 octets or less in
length. This includes the opaque encapsulation of data length. This includes the opaque encapsulation of data
structures defined outside of RADIUS. See also Section A.1.3, structures defined outside of RADIUS. See also Appendix A.1.2,
below. below.
* UTF-8 text, totalling 253 octets or less in length. * UTF-8 text, totalling 253 octets or less in length.
* Complex data types for authentication and/or security. * Complex data types for authentication and/or security.
These attributes SHOULD be defined only within the RADIUS These attributes SHOULD be defined only within the RADIUS
attribute space, and SHOULD NOT be defined within the VSA space. attribute space, and SHOULD NOT be defined within the VSA space.
Note that the length limitations for VSAs of type String and Text are Note that the length limitations for VSAs of type String and Text are
less than 253 octets, due to the additional overhead of the Vendor- less than 253 octets, due to the additional overhead of the Vendor-
Specific format. Specific format.
A.1.2. Extended data types
Where possible, the data types defined above in Section A.1.1 SHOULD
be used. The extended data types defined in [EXTEN] 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. * Attributes grouped into a logical container.
This does not include nested groups. This does not include nested groups.
* Attributes requiring the transport of more than 247 octets of * Attributes requiring the transport of more than 247 octets of
Text or String data. This includes the opaque encapsulation Text or String data. This includes the opaque encapsulation
of data structures defined outside of RADIUS. See also Section of data structures defined outside of RADIUS. See also Section
A.1.3, below. A.1.2, below.
A.1.3. Opaque data types A.1.2. Opaque data types
Does the attribute encapsulate an existing data structure defined Does the attribute encapsulate an existing data structure defined
outside of the RADIUS specifications? Can the attribute be treated outside of the RADIUS specifications? Can the attribute be treated
as opaque data by RADIUS servers (including proxies?) If both as opaque data by RADIUS servers (including proxies?) If both
questions can be answered affirmatively, a complex structure MAY be questions can be answered affirmatively, a complex structure MAY be
used in a RADIUS specification. used in a RADIUS specification.
The specification of the attribute SHOULD define the encapsulating The specification of the attribute SHOULD define the encapsulating
attribute to be of type String. The specification SHOULD refer to an attribute to be of type String. The specification SHOULD refer to an
external document defining the structure. The specification SHOULD external document defining the structure. The specification SHOULD
NOT define or describe the structure, as discussed above in Section NOT define or describe the structure, as discussed above in Section
2.1.3. 2.1.3.
A.2. Improper Data Types A.2. Improper Data Types
All data types other than the ones described above in Section A.1 All data types other than the ones described above in Appendix A.1
SHOULD NOT be used. This section describes in detail a number of SHOULD NOT be used. This section describes in detail a number of
data types that are NOT RECOMMENDED in new RADIUS specifications. data types that are NOT RECOMMENDED in new RADIUS specifications.
Where possible, replacement data types are suggested. Where possible, replacement data types are suggested.
A.2.1. Simple Data Types A.2.1. Simple Data Types
Does the attribute use any of the following data types? If so, the Does the attribute use any of the following data types? If so, the
data type SHOULD be replaced with the suggested alternatives, or it data type SHOULD be replaced with the suggested alternatives, or it
SHOULD NOT be used at all. SHOULD NOT be used at all.
skipping to change at page 29, line 10 skipping to change at page 27, line 48
insufficient justification to save two bytes. insufficient justification to save two bytes.
* Unsigned integers of size other than 32 or 64. * Unsigned integers of size other than 32 or 64.
SHOULD be replaced by an unsigned integer of 32 or 64 bits. SHOULD be replaced by an unsigned integer of 32 or 64 bits.
There is insufficient justification to define a new size of There is insufficient justification to define a new size of
integer. integer.
* Integers of any size in non-network byte order * Integers of any size in non-network byte order
SHOULD be replaced by unsigned integer of 32 or 64 bits, SHOULD be replaced by unsigned integer of 32 or 64 bits,
in network byte order. There is no reason to transport integers in network byte order. There is no reason to transport integers
in any format other than network byte order. in any format other than network byte order.
* Tagged data types as described in [RFC2868]. * Tagged data types as described in [RFC2868].
These data types SHOULD NOT be used in new specifications. The These data types SHOULD NOT be used in new specifications.
attribute grouping method defined in [EXTEN] SHOULD be used
instead.
* Complex data structures defined only within RADIUS. * Complex data structures defined only within RADIUS.
The additional functionality defined in [EXTEN] SHOULD be used SHOULD NOT be used. This recommendation does not apply to new
instead. This recommendation does not apply to new attributes attributes for authentication or security, as described below
for authentication or security, as described below in Section in Section A.2.2.
A.2.2.
* Multi-field text strings. * Multi-field text strings.
Each field SHOULD be encapsulated in a separate attribute. 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. * Polymorphic attributes.
Multiple attributes, each with a static data type SHOULD be Multiple attributes, each with a static data type SHOULD be
defined instead. defined instead.
* Nested AVPs. * Nested AVPs.
Attributes should be defined in a flat typespace, possibly using Attributes should be defined in a flat typespace, possibly using
a 16-bit Vendor type field (see Section 2.3). Where grouping of a 16-bit Vendor type field (see Section 2.3).
fields is desired, the additional functionality defined in
[EXTEN] SHOULD be used instead.
A.2.2. Complex Data Types A.2.2. Complex Data Types
Does the attribute define a complex data type for purposes other than Does the attribute define a complex data type for purposes other than
authentication or security? If so, this data type SHOULD be replaced authentication or security? If so, this data type SHOULD be replaced
with simpler types, as discussed above in Section A.2.1. Also see with simpler types, as discussed above in Appendix A.2.1. Also see
Section 2.1.3 for a discussion of why complex types are problematic. Section 2.1.3 for a discussion of why complex types are problematic.
A.3. Vendor-Specific formats A.3. Vendor-Specific formats
Does the specification contain Vendor-Specific attributes that match Does the specification contain Vendor-Specific attributes that match
any of the following criteria? If so, the data type should be any of the following criteria? If so, the data type should be
replaced with the suggested alternatives, or should not be used at replaced with the suggested alternatives, or should not be used at
all. all.
* Vendor types of more than 16 bits. * Vendor types of more than 16 bits.
skipping to change at page 30, line 4 skipping to change at page 28, line 34
any of the following criteria? If so, the data type should be any of the following criteria? If so, the data type should be
replaced with the suggested alternatives, or should not be used at replaced with the suggested alternatives, or should not be used at
all. all.
* Vendor types of more than 16 bits. * Vendor types of more than 16 bits.
SHOULD NOT be used. Vendor types of 8 or 16 bits SHOULD be used SHOULD NOT be used. Vendor types of 8 or 16 bits SHOULD be used
instead. instead.
* Vendor lengths of less than 8 bits. (i.e., zero bits) * Vendor lengths of less than 8 bits. (i.e., zero bits)
SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used
instead. instead.
* Vendor lengths of more than 8 bits. * Vendor lengths of more than 8 bits.
SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used
instead. instead.
* Vendor-Specific contents that are not in Type-Length-Value * Vendor-Specific contents that are not in Type-Length-Value
format. format.
SHOULD NOT be used. Vendor-Specific attributes SHOULD be in SHOULD NOT be used. Vendor-Specific attributes SHOULD be in
Type-Length-Value format. 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, as described in [EXTEN].
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] In general, Vendor-Specific attributes SHOULD follow the [RFC2865]
suggested format, or the [EXTEN] format if more functionality or a suggested format. However, we recognize that SDOs may require more
larger attribute space is necessary. than 256 attributes, which is the limit of the 8-bit [RFC2865]
Vendor-Specific space. Those SDOs SHOULD use Vendor types of 16
bits, as described in Section 2.3. 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.
A.4. Changes to the RADIUS Operational Model A.4. Changes to the RADIUS Operational Model
Does the specification change the RADIUS operation model, as outlined Does the specification change the RADIUS operation model, as outlined
in the list below? If so, then another method of achieving the in the list below? If so, then another method of achieving the
design objectives SHOULD be used. Potential problem areas include: design objectives SHOULD be used. Potential problem areas include:
* Defining new commands in RADIUS using attributes. * Defining new commands in RADIUS using attributes.
The addition of new commands to RADIUS MUST be handled via The addition of new commands to RADIUS MUST be handled via
allocation of a new Code, and not by the use of an attribute. allocation of a new Code, and not by the use of an attribute.
skipping to change at page 34, line 42 skipping to change at page 33, line 42
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
that it is a complex attribute: that it is a complex attribute:
The Text field consists of UTF-8 encoded 10646 [8] characters. The Text field consists of UTF-8 encoded 10646 _8_ characters.
The connection speed SHOULD be included at the beginning of the The connection speed SHOULD be included at the beginning of the
first Connect-Info attribute in the packet. If the transmit and first Connect-Info attribute in the packet. If the transmit and
receive connection speeds differ, they may both be included in the receive connection speeds differ, they may both be included in the
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
skipping to change at page 36, line 30 skipping to change at page 35, line 30
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. Future specifications that attempt to obtain similar alternatives.
functionality SHOULD use the extended types from [EXTEN].
B.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. Future reasons identical to those given for Egress-VLANID.
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
Knoxville, TN 37932 Knoxville, TN 37932
USA USA
 End of changes. 51 change blocks. 
183 lines changed or deleted 161 lines changed or added

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