draft-ietf-radext-design-11.txt   draft-ietf-radext-design-12.txt 
Network Working Group Alan DeKok (ed.) Network Working Group Alan DeKok (ed.)
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Category: Best Current Practice G. Weber Category: Best Current Practice G. Weber
<draft-ietf-radext-design-11.txt> Individual Contributor <draft-ietf-radext-design-12.txt> Individual Contributor
Expires: August 18, 2010 Expires: September 22, 2010
19 February 2010 22 March 2010
RADIUS Design Guidelines RADIUS Design Guidelines
draft-ietf-radext-design-11 draft-ietf-radext-design-12
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 18, 2010. This Internet-Draft will expire on September 22, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info/) in effect on the date of (http://trustee.ietf.org/license-info/) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 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 ............................................. 4 1. Introduction ............................................. 5
1.1. Terminology ......................................... 4 1.1. Terminology ......................................... 5
1.2. Requirements Language ............................... 4 1.2. Requirements Language ............................... 5
1.3. Applicability ....................................... 5 1.3. Applicability ....................................... 6
2. RADIUS Data Model ........................................ 6 2. Guidelines ............................................... 7
2.1. Standard Space ...................................... 6 2.1. Data Types .......................................... 8
2.1.1. Basic Data Types Defined in RFC 2865 ........... 7 2.2. Vendor-Specific Space ............................... 9
2.1.2. Tagging Mechanism .............................. 8 2.3. Service definitions and RADIUS ...................... 10
2.1.3. Complex Attribute Usage ........................ 9 2.4. Translation of Vendor Specifications ................ 10
2.1.4. ....................................................... 11 3. Rationale ................................................ 11
2.2. Vendor Space ........................................ 12 3.1. RADIUS Operational Model ............................ 11
3. Data Model Issues ........................................ 14 3.2. Data Model Issues ................................... 14
3.1. Vendor Space ........................................ 14 3.2.1. Basic Data Types ............................... 14
3.1.1. Interoperability Considerations ................ 16 3.2.2. Tagging Mechanism .............................. 16
3.1.2. Vendor Allocations ............................. 17 3.2.3. Complex Data Types ............................. 16
3.1.3. SDO Allocations ................................ 17 3.3. Vendor Space ........................................ 19
3.1.4. Publication of specifications .................. 18 3.3.1. Interoperability Considerations ................ 20
3.2. Polymorphic Attributes .............................. 18 3.3.2. Vendor Allocations ............................. 21
3.3. RADIUS Operational Model ............................ 19 3.3.3. SDO Allocations ................................ 21
4. IANA Considerations ...................................... 22 3.3.4. Publication of specifications .................. 22
5. Security Considerations .................................. 22 3.4. Polymorphic Attributes .............................. 22
5.1. Complex Attributes .................................. 23 4. IANA Considerations ...................................... 23
6. References ............................................... 24 5. Security Considerations .................................. 23
6.1. Normative References ................................ 24 5.1. New Data Types and Complex Attributes ............... 24
6.2. Informative References .............................. 24 6. References ............................................... 25
Appendix A - Design Guidelines ............................... 27 6.1. Normative References ................................ 25
A.1. Types matching the RADIUS data model ................. 27 6.2. Informative References .............................. 25
A.1.1. Transport of simple data ........................ 27 Appendix A - Design Guidelines ............................... 28
A.1.2. Transport of Authentication and Security Data ... 28 A.1. Types matching the RADIUS data model ................. 28
A.1.3. Opaque data types ............................... 28 A.1.1. Transport of basic data types ................... 28
A.2. Improper Data Types .................................. 28 A.1.2. Transport of Authentication and Security Data ... 29
A.2.1. Simple Data Types ............................... 29 A.1.3. Opaque data types ............................... 29
A.2.2. Complex Data Types .............................. 29 A.2. Improper Data Types .................................. 29
A.3. Vendor-Specific formats .............................. 30 A.2.1. Basic Data Types ................................ 30
A.4. Changes to the RADIUS Operational Model .............. 30 A.2.2. Complex Data Types .............................. 30
A.5. Allocation of attributes ............................. 32 A.3. Vendor-Specific formats .............................. 31
Appendix B - Complex Attributes .............................. 33 A.4. Changes to the RADIUS Operational Model .............. 31
B.1. CHAP-Password ........................................ 33 A.5. Allocation of attributes ............................. 33
B.2. CHAP-Challenge ....................................... 33 Appendix B - Complex Attributes .............................. 34
B.3. Tunnel-Password ...................................... 33 B.1. CHAP-Password ........................................ 34
B.4. ARAP-Password ........................................ 34 B.2. CHAP-Challenge ....................................... 34
B.5. ARAP-Features ........................................ 34 B.3. Tunnel-Password ...................................... 34
B.6. Connect-Info ......................................... 35 B.4. ARAP-Password ........................................ 35
B.7. Framed-IPv6-Prefix ................................... 36 B.5. ARAP-Features ........................................ 35
B.8. Egress-VLANID ........................................ 36 B.6. Connect-Info ......................................... 36
B.9. Egress-VLAN-Name ..................................... 37 B.7. Framed-IPv6-Prefix ................................... 37
B.8. Egress-VLANID ........................................ 37
B.9. Egress-VLAN-Name ..................................... 38
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 6, line 16 skipping to change at page 7, line 16
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 discussed below in Section 3.3. Such changes operational model as discussed below in Section ZZZ. Such changes
MUST NOT be undertaken outside the IETF and when handled within the MUST NOT be undertaken outside the IETF and when handled within the
IETF require "IETF Consensus" for adoption, as noted in [RFC3575] IETF require "IETF Consensus" for adoption, as noted in [RFC3575]
Section 2.1. Section 2.1.
2. RADIUS Data Model 2. Guidelines
The Remote Authentication Dial In User Service (RADIUS) defined in The Remote Authentication Dial In User Service (RADIUS) defined in
[RFC2865] and [RFC2866] uses elements known as attributes in order to [RFC2865] and [RFC2866] uses elements known as attributes in order to
represent authentication, authorization and accounting data. represent authentication, authorization and accounting data.
Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does
not define a formal data definition language. The data type of not define a formal data definition language. The data type of
RADIUS attributes is not transported on the wire. Rather, the data RADIUS attributes is not transported on the wire. Rather, the data
type of a RADIUS attribute is fixed when an attribute is defined. type of a RADIUS attribute is fixed when an attribute is defined.
Based on the RADIUS attribute type code, RADIUS clients and servers Based on the RADIUS attribute type code, RADIUS clients and servers
can determine the data type based on preconfigured entries within a can determine the data type based on preconfigured entries within a
data dictionary. data dictionary.
Two distinct attribute spaces are defined: the standard space, and a To explain the implications of this early RADIUS design decision we
Vendor-Specific space. Attributes in the standard space generally distinguish two types of data types, namely "basic" and "complex".
are composed of a type, length, value (TLV) triplet, although complex Basic data types use one of the existing RADIUS data types as defined
attributes have also been defined. The Vendor-Specific space is below, encapsulated in a [RFC2865] format RADIUS attribute, or in a
encapsulated within a single attribute type (Vendor-Specific [RFC2865] format RADIUS VSA. All other data formats are "complex
Attribute). The format of this space is defined by individual types".
vendors, but the same TLV encoding used by the standard space is
recommended in [RFC2865] Section 5.26. The similarity between
attribute formats has enabled implementations to leverage common
parsing functionality, although in some cases the attributes in the
Vendor-Specific space have begun to diverge from the common format.
2.1. Standard Space RADIUS attributes are also divided into two distinct attribute
spaces: the standard space, and a Vendor-Specific space. Attributes
in the standard space follow the [RFC2865] attribute format, with
allocation managed by the Internet Assigned Number Authority (IANA).
The following subsections describe common data types and formats The Vendor-Specific space is defined to be the contents of the
within the RADIUS standard attribute space. Common exceptions are "String" field of the Vendor-Specific Attribute ([RFC2865] Section
identified. 5.26). See Section 2.2, below, for a more in-depth discussion.
2.1.1. Basic Data Types Defined in RFC 2865 2.1. Data Types
RADIUS defines a limited set of data types, defined as "basic data
types". The following data qualifies as "basic data types":
* 32-bit unsigned integer, in network byte order.
* Enumerated data types, represented as a 32-bit unsigned integer
with a list of name to value mappings. (e.g., Service-Type)
* Interface-Id (8 octet string in network byte order)
* IPv4 address in network byte order.
* IPv6 address in network byte order.
* IPv6 prefix.
* time as 32 bit unsigned value, in network byte order, and 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 Appendix A.1.3,
below.
* UTF-8 text, totalling 253 octets or less in length.
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.
The following data also qualifies as "basic data types":
* Attributes grouped into a logical container, using the
[RFC2868] tagging mechanism. This approach is NOT RECOMMENDED,
but is permissible where the alternatives are worse.
* 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.
Nested groups or attributes do not qualify as "basic data types", and
SHOULD NOT be used.
All other data formats are defined to be "complex data types", and
are NOT RECOMMENDED. However, there may be situations where complex
attributes are beneficial because they reduce complexity in the non-
RADIUS systems. Unfortunately, there are no "hard and fast" rules
for where the complexity would best be located. Each situation has
to be decided on a case-by-case basis.
See Appendix B for an audit of existing attributes of complex data
types, including a discussion of benefits and drawbacks.
2.2. Vendor-Specific Space
The Vendor-Specific space is defined to be the contents of the
"String" field of the Vendor-Specific Attribute ([RFC2865] Section
5.26). As discussed there, it is intended for vendors to support
their own Attributes not suitable for general use. 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.
Vendor RADIUS Attribute specifications SHOULD allocate attributes
from the vendor space, rather than requesting an allocation from the
RADIUS standard attribute space.
All VSA schemes that do not follow the [RFC2865] recommendations are
NOT RECOMMENDED. All data formats other than described above as
"basic data types" are NOT RECOMMENDED. These non-standard formats
will typically not be implementable without RADIUS server code
changes.
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.
Notwithstanding the above recommendations, the format of the Vendor-
Specific space is under the complete control of individual vendors
and SDOs. The guidelines outlined here are only recommendations, and
do not define any requirements or restrictions on the Vendor-Specific
space.
2.3. Service definitions and RADIUS
RADIUS specifications define how an existing service or protocol can
be provisioned using RADIUS. Therefore, it is expected that a RADIUS
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.
New attributes, or new values of existing attributes, SHOULD NOT be
used to define new RADIUS commands. 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 also SHOULD NOT use new attributes to modify the
interpretation of existing RADIUS commands.
2.4. Translation of Vendor Specifications
The limitation on changes to the RADIUS protocol effectively
prohibits VSAs from changing fundamental aspects of RADIUS operation,
such as modifying RADIUS packet sequences, or adding new commands.
However, the requirement for clients and servers to be able to
operate in the absence of VSAs has proven to be less of a constraint,
since it is still possible for a RADIUS client and server to mutually
indicate support for VSAs, after which behavior expectations can be
reset.
Therefore, RFC 2865 provides considerable latitude for development of
new attributes within the vendor space, while prohibiting development
of protocol variants. This flexibility implies that RADIUS
attributes can often be developed within the vendor space without
loss (and possibly even with gain) in functionality.
As a result, translation of RADIUS attributes developed within the
vendor space into the standard space may provide only modest
benefits, while accelerating the exhaustion of the standard attribute
space. We do not expect that all RADIUS attribute specifications
requiring interoperability will be developed within the IETF, and
allocated from the standards space. A more scalable approach is to
recognize the flexibility of the vendor space, while working toward
improvements in the quality and availability of RADIUS attribute
specifications, regardless of where they are developed.
It is therefore NOT RECOMMENDED that specifications intended solely
for use by a vendor or SDO use be translated into the standard space.
3. Rationale
This section outlines the rationale behind the above recommendations.
3.1. RADIUS Operational Model
The RADIUS operational model includes several assumptions:
* The RADIUS protocol is stateless;
* Provisioning of services is not possible within an
Access-Reject;
* There is a distinction between authorization checks and user
authentication;
* The protocol provices for authentication and integrity
protection of packets;
* The RADIUS protocol is a Request/Response protocol;
* The protocol defines packet length restrictions.
While RADIUS server implementations may keep state, the RADIUS
protocol is stateless, although information may be passed from one
protocol transaction to another via the State Attribute. As a
result, documents which require stateful protocol behavior without
use of the State Attribute are inherently incompatible with RADIUS as
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
Attribute.
As noted in [RFC5080] Section 2.6, the intent of an Access-Reject is
to deny access to the requested service. As a result, RADIUS does
not allow the provisioning of services within an Access-Reject.
Documents which include provisioning of services within an Access-
Reject are inherently incompatible with RADIUS, and need to be
redesigned.
As noted in [RFC5080] Section 2.1.1, a RADIUS Access-Request may not
contain user authentication attributes or a State Attribute linking
the Access-Request to an earlier user authentication. Such an
Access-Request, known as an authorization check, provides no
assurance that it corresponds to a live user. RADIUS specifications
defining attributes containing confidential information (such as
Tunnel-Password) should be careful to prohibit such attributes from
being returned in response to an authorization check. Also,
[RFC5080] Section 2.1.1 notes that authentication mechanisms need to
tie a sequence of Access-Request/Access-Challenge packets together
into one authentication session. The State Attribute is RECOMMENDED
for this purpose.
While [RFC2865] did not require authentication and integrity
protection of RADIUS Access-Request packets, subsequent
authentication mechanism specifications such as RADIUS/EAP [RFC3579]
and Digest Authentication [RFC5090] have mandated authentication and
integrity protection for certain RADIUS packets. [RFC5080] Section
2.1.1 makes this behavior RECOMMENDED for all Access-Request packets,
including Access-Request packets performing authorization checks. It
is expected that specifications for new RADIUS authentication
mechanisms will continue this practice.
The RADIUS protocol as defined in [RFC2865] is a request-response
protocol spoken between RADIUS clients and servers. A single RADIUS
Access-Request packet will solicit in response at most a single
Access-Accept, Access-Reject or Access-Challenge packet, sent to the
IP address and port of the RADIUS Client that originated the Access-
Request. Similarly, a single Change-of-Authorization (CoA)-Request
packet [RFC5176] will solicit in response at most a single CoA-ACK or
CoA-NAK packet, sent to the IP address and port of the Dynamic
Authorization Client (DAC) that originated the CoA-Request. A single
Disconnect-Request packet will solicit in response at most a single
Disconnect-ACK or Disconnect-NAK packet, sent to the IP address and
port of the Dynamic Authorization Client (DAC) that originated the
Disconnect-Request. Changes to this model are likely to require
major revisions to existing implementations and so this practice is
NOT RECOMMENDED.
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
packet is 4096 octets. As a result, attribute designers SHOULD NOT
assume that a RADIUS implementation can successfully process RADIUS
packets larger than 4096 octets.
Even when packets are less than 4096 octets, they may be larger than
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.
For RADIUS authentication, a sequence of Access-Request/ Access-
Challenge packets would be used. For this to be feasible,
attribute designers need to enable inclusion of attributes that
can consume considerable space within Access-Challenge packets.
To maintain compatibility with existing NASes, either the use of
Access-Challenge packets needs to be permissible (as with
RADIUS/EAP, defined in [RFC3579]), or support for receipt of an
Access-Challenge needs to be indicated by the NAS (as in RADIUS
Location [RFC5580]). Also, the specification needs to clearly
describe how attribute splitting is to be signalled and how
attributes included within the sequence are to be interpreted,
without requiring stateful operation. Unfortunately, previous
specifications have not always exhibited the required foresight.
For example, even though very large filter rules are
conceivable, the NAS-Filter-Rule Attribute defined in [RFC4849]
is not permitted in an Access-Challenge packet, nor is a
mechanism specified to allow a set of NAS-Filter-Rule attributes
to be split across an Access-Request/Access-Challenge sequence.
In the case of RADIUS accounting, transporting large amounts of
data would require a sequence of Accounting-Request packets.
This is a non-trivial change to RADIUS, since RADIUS accounting
clients would need to be modified to split the attribute stream
across multiple Accounting-Requests, and billing servers would
need to be modified to re-assemble and interpret the attribute
stream.
2. Utilization of names rather than values.
Where an attribute relates to a policy that could conceivably be
pre-provisioned on the NAS, then the name of the pre-provisioned
policy can be transmitted in an attribute, rather than the
policy itself, which could be quite large. An example of this
is the Filter-Id Attribute defined in [RFC2865] Section 5.11,
which enables a set of pre-provisioned filter rules to be
referenced by name.
3. Utilization of Packetization Layer Path MTU Discovery
techniques, as specified in [RFC4821]. As a last resort, where
the above techniques cannot be made to work, it may be possible
to apply the techniques described in [RFC4821] to discover the
maximum supported RADIUS packet size on the path between a
RADIUS client and a home server. While such an approach can
avoid the complexity of utilization of a sequence of packets,
dynamic discovery is likely to be time consuming and cannot be
guaranteed to work with existing RADIUS implementations. As a
result, this technique is not generally applicable.
3.2. Data Model Issues
The RADIUS data types are poorly defined. While [RFC2865] Section 5
defines basic data types, later specifications did not follow this
practice. This led implementations to define their own names for
data types, leading to non-standard names for those types.
In addition, the number of vendors and SDOs creating new attributes
within the Vendor-Specific attribute space has grown, and this has
lead to some divergence in approaches to RADIUS attribute design.
For example, vendors and SDOs have evolved the data model to support
new functions such as more data types, along with attribute grouping
and attribute fragmentation, with different groups taking different
approaches. These approaches are often incompatible, leading to
additional complexity in RADIUS implementations.
This section describes the history of the RADIUS data model, in an
attempt to codify existing practices, and to avoid repeating old
mistakes.
3.2.1. Basic Data Types
[RFC2865] and [RFC2866] utilize data types defined in [RFC2865] [RFC2865] and [RFC2866] utilize data types defined in [RFC2865]
Section 5, which states the following: Section 5, which states the following:
The format of the value field is one of five data types. Note The format of the value field is one of five data types. Note
that type "text" is a subset of type "string". that type "text" is a subset of type "string".
text 1-253 octets containing UTF-8 encoded 10646 [RFC3629] text 1-253 octets containing UTF-8 encoded 10646 [RFC3629]
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.
skipping to change at page 7, line 30 skipping to change at page 15, line 12
address 32 bit value, most significant octet first. 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 --
seconds since 00:00:00 UTC, January 1, 1970. The seconds since 00:00:00 UTC, January 1, 1970. The
standard Attributes do not use this data type but it is standard Attributes do not use this data type but it is
presented here for possible use in future attributes. presented here for possible use in future attributes.
In addition to the data types defined in [RFC2865], subsequent RADIUS Subsequent RADIUS specifications also defined attributes using new
specifications defined attributes using additional basic data types. data types. These specifications did not explicitly define those
These specifications did not explicitly define new data types as was data types as was done in [RFC2865]. They did not consistently
done in [RFC2865]. They did not consistently indicate the format of indicate the format of the value field using the same conventions as
the value field using the same conventions as [RFC2865]. As a [RFC2865]. As a result, the data type is ambiguous in some cases,
result, the data type is ambiguous in some cases, and may not be and may not be consistent among different implementations.
consistent among different implementations.
It is out of the scope of this document to resolve all potential It is out of the scope of this document to resolve all potential
ambiguities within existing RADIUS specifications. However in order ambiguities within existing RADIUS specifications. However in order
to prevent future ambiguities, it is recommended that future RADIUS to prevent future ambiguities, it is recommended that future RADIUS
attribute specifications explicitly define newly created data types attribute specifications explicitly define newly created data types
at the beginning of the document, and indicate clearly the data type at the beginning of the document, and indicate clearly the data type
to be used for each attribute. to be used for each attribute.
[RFC3162] utilizes but does not explicitly define the following data [RFC3162] utilizes but does not explicitly define the following data
types: types:
skipping to change at page 8, line 35 skipping to change at page 16, line 15
It is worth noting that since RADIUS only supports unsigned integers It is worth noting that since RADIUS only supports unsigned integers
of 32 bits, attributes using signed integer data types or unsigned of 32 bits, attributes using signed integer data types or unsigned
integer types of other sizes will require code changes, and SHOULD be integer types of other sizes will require code changes, and SHOULD be
avoided. avoided.
For [RFC2865] RADIUS VSAs, the length limitation of the String and For [RFC2865] RADIUS VSAs, the length limitation of the String and
Text types is 247 octets instead of 253 octets, due to the additional Text types is 247 octets instead of 253 octets, due to the additional
overhead of the Vendor-Specific Attribute. overhead of the Vendor-Specific Attribute.
2.1.2. Tagging Mechanism 3.2.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).
skipping to change at page 9, line 10 skipping to change at page 16, line 39
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.
For these reasons, the tagging scheme described in RFC 2868 is NOT For these reasons, the tagging scheme described in RFC 2868 is NOT
RECOMMENDED for use as a generic grouping mechanism. RECOMMENDED for use as a generic grouping mechanism.
2.1.3. Complex Attribute Usage 3.2.3. Complex Data Types
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 use sub-fields instead of using a basic data type as
known as "complex attributes". As described below, the definition of discussed in the above sections are defined to be "complex types".
complex attributes can lead to interoperability and deployment As described below in this section the creation of complex types can
issues, so they need to be introduced with care. lead to interoperability and deployment issues, so they need to be
introduced with care.
In general, complex attributes sent from the RADIUS server to the In general, complex types sent from the RADIUS server to the client
client can be supported by concatenating the values into a String can be supported by concatenating the values into a String data type
data type field. However, separating these values into different field. However, separating these values into different attributes,
attributes, each with its own type and length, would have the each with its own type and length, would have the following benefits:
following benefits:
* it is easier for the user to enter the data as well-known * it is easier for the user to enter the data as well-known
types, rather than complex structures; types, rather than complex structures;
* it enables additional error checking by leveraging the * it enables additional error checking by leveraging the
parsing and validation routines for well-known types; parsing and validation routines for well-known types;
* it simplifies implementations by eliminating special-case * it simplifies implementations by eliminating special-case
attribute-specific parsing. attribute-specific parsing.
skipping to change at page 10, line 32 skipping to change at page 18, line 15
Code changes can also be required in policy management and in the Code changes can also be required in policy management and in the
RADIUS server's receive path. These changes are due to limitations RADIUS server's receive path. These changes are due to limitations
in RADIUS server policy languages, which typically only provide for in RADIUS server policy languages, which typically only provide for
limited operations (such as comparisons or arithmetic operations) on limited operations (such as comparisons or arithmetic operations) on
the existing data types. Many existing RADIUS policy languages the existing data types. Many existing RADIUS policy languages
typically are not capable of parsing sub-elements, or providing typically are not capable of parsing sub-elements, or providing
sophisticated matching functionality. sophisticated matching functionality.
Given these limitations, the introduction of new types can require Given these limitations, the introduction of new types can require
code changes on the RADIUS server which would be unnecessary if basic code changes on the RADIUS server which would be unnecessary if basic
data types had been used instead. In addition, attribute-specific data types had been used instead. In addition if "ad-hoc" types are
parsing means more complex software to develop and maintain. More used, attribute-specific parsing means more complex software to
complexity can lead to more error prone implementations, develop and maintain. More complexity can lead to more error prone
interoperability problems, and even security vulnerabilities. These implementations, interoperability problems, and even security
issues can increase costs to network administrators as well as vulnerabilities. These issues can increase costs to network
reducing reliability and introducing deployment barriers. We administrators as well as reducing reliability and introducing
therefore RECOMMEND that the introduction of new complex data types deployment barriers. We therefore RECOMMEND that the introduction of
within RADIUS attribute specifications be avoided. A potential new types and complex data types within RADIUS attribute
exception to this recommendation occurs for attributes that specifications be avoided. A potential exception to this
inherently require code changes on both the client and server. For recommendation occurs for attributes that inherently require code
example, as described in Appendix B, complex attributes have been changes on both the client and server. For example, as described in
used in situations involving authentication and security attributes Appendix B, complex attributes have been used in situations involving
that need to be dynamically computed and verified. authentication and security attributes that need to be dynamically
computed and verified.
As can be seen in Appendix B, most of the existing complex attributes As can be seen in Appendix B, most of the existing complex attributes
involve authentication or security functionality. Supporting this involve authentication or security functionality. Supporting this
functionality requires code changes on both the RADIUS client and functionality requires code changes on both the RADIUS client and
server, regardless of the attribute format. As a result, in most server, regardless of the attribute format. As a result, in most
cases, the use of complex attributes to represent these methods is cases, the use of complex attributes to represent these methods is
acceptable, and does not create additional interoperability or acceptable, and does not create additional interoperability or
deployment issues. deployment issues.
The only other exception to the recommendation against complex types The only other exception to the recommendation against complex types
skipping to change at page 11, line 46 skipping to change at page 19, line 29
attributes, but are a matter for endpoint interpretation. An attributes, but are a matter for endpoint interpretation. An
implementation can define additional data types, and use these data implementation can define additional data types, and use these data
types today by matching them to the attribute's textual description. types today by matching them to the attribute's textual description.
Despite the above caveats, there may be situations where complex Despite the above caveats, there may be situations where complex
attributes are beneficial because they reduce complexity in the non- attributes are beneficial because they reduce complexity in the non-
RADIUS systems. Unfortunately, there are no "hard and fast" rules RADIUS systems. Unfortunately, there are no "hard and fast" rules
for where the complexity would best be located. Each situation has for where the complexity would best be located. Each situation has
to be decided on a case-by-case basis. to be decided on a case-by-case basis.
2.1.4. 3.3. Vendor Space
RADIUS specifications define how an existing service or protocol can
be provisioned using RADIUS. Therefore, it is expected that a RADIUS
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.
New attributes, or new values of existing attributes, SHOULD NOT be
used to define new RADIUS commands. 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 also SHOULD NOT use new attributes to modify the
interpretation of existing RADIUS commands.
2.2. Vendor Space
As noted in [RFC2865] Section 5.26, the VSA format is defined as
follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
The high-order octet of the Vendor-Id field is 0 and the low-order 3
octets are the Structure of Management Information (SMI) Network
Management Private Enterprise Code (PEC) of the Vendor in network
byte order.
While the format of the String field is defined by the vendor,
[RFC2865] Section 5.26 notes:
It SHOULD be encoded as a sequence of vendor type / vendor length
/ value fields, as follows. The Attribute-Specific field is
dependent on the vendor's definition of that attribute. An
example encoding of the Vendor-Specific attribute using this
method follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | Vendor type | Vendor length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute-Specific...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Multiple sub-attributes MAY be encoded within a single Vendor-
Specific attribute, although they do not have to be.
Note that the Vendor type field in the recommended VSA format is only
a single octet, like the RADIUS type field. While this limitation
results in an efficient encoding, there are situations in which a
vendor or SDO will eventually wish to define more than 255
attributes. Also, an SDO can be comprised of multiple subgroups, each
of whom can desire autonomy over the definition of attributes within
their group. The most interoperable way to address these issues is
for the vendor or SDO to request allocation of multiple Vendor
identifiers.
However, instead of doing this, vendors have defined the following
non-standard VSA formats:
* Vendor types of 16 bits, followed by an 8 bit length and
then attribute-specific data.
* Vendor types of 32 bits, followed by no length field, and
then attribute-specific data.
* Vendor types of the RFC format, but where some VSAs are
defined as "grouped" or TLV attributes. These attributes
are then used to carry sub-attributes.
* "Bare" ASCII strings that immediately follow the Vendor-Id,
without using a Vendor type or Vendor length.
All VSA schemes that do not follow the [RFC2865] recommendations are
NOT RECOMMENDED. These non-standard formats will typically not be
implementable without RADIUS server code changes. This includes all
the above formats, as well as Vendor types of more than 8 bits,
vendor 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.
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
Since the closure of the RADIUS Working Group, the popularity and
prevalence of RADIUS has continued to grow. In addition to
increasing demand for allocation of attributes within the RADIUS
standard attribute space, the number of vendors and SDOs creating new
attributes within the Vendor-Specific attribute space has grown, and
this has lead to some divergence in approaches to RADIUS attribute
design.
In general, standard RADIUS attributes have a more constrained data
model than attributes within the vendor space. For example, vendors
and SDOs have evolved the data model to support new functions such as
attribute grouping and attribute fragmentation, with different groups
taking different approaches.
Given these enhancements, it has become difficult for vendors or SDOs
to translate attributes from the vendor space to the more stringent
standards space. For example, a Vendor-Specific attribute using sub-
elements could require allocation of several standard space
attributes using basic data types. In this case not only would
translation require substantial additional work, it would further
deplete the RADIUS standard attribute space. Given these
limitations, translation of vendor attributes to the standards space
is not necessarily desirable, particularly if the VSA specification
is publicly available and can be implemented within existing RADIUS
clients and servers. In such situations, the costs may substantially
outweigh the benefits. It is possible that some of the enhancements
made within the vendor space may eventually become available within
the standard attribute space. However, the divergence of the
standard and vendor attribute spaces is most likely a permanent
feature, and should be recognized as such.
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 15, line 50 skipping to change at page 20, line 36
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 3.3.1. Interoperability Considerations
prohibits VSAs from changing fundamental aspects of RADIUS operation,
such as modifying RADIUS packet sequences, or adding new commands.
However, the requirement for clients and servers to be able to
operate in the absence of VSAs has proven to be less of a constraint,
since it is still possible for a RADIUS client and server to mutually
indicate support for VSAs, after which behavior expectations can be
reset.
Therefore, RFC 2865 provides considerable latitude for development of
new attributes within the vendor space, while prohibiting development
of protocol variants. This flexibility implies that RADIUS
attributes can often be developed within the vendor space without
loss (and possibly even with gain) in functionality.
As a result, translation of RADIUS attributes developed within the
vendor space into the standard space may provide only modest
benefits, while accelerating the exhaustion of the standard attribute
space. We do not expect that all RADIUS attribute specifications
requiring interoperability will be developed within the IETF, and
allocated from the standards space. A more scalable approach is to
recognize the flexibility of the vendor space, while working toward
improvements in the quality and availability of RADIUS attribute
specifications, regardless of where they are developed.
3.1.1. Interoperability Considerations
Vendors and SDOs are reminded that the standard RADIUS attribute Vendors and SDOs are reminded that the standard RADIUS attribute
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
skipping to change at page 17, line 10 skipping to change at page 21, line 19
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
better describes this use case is SDO-Specific Attribute (SSA). better describes this use case is SDO-Specific Attribute (SSA).
The design and specification of VSAs for multi-vendor usage SHOULD be The design and specification of VSAs for multi-vendor usage SHOULD be
undertaken with the same level of care as standard RADIUS attributes. undertaken with the same level of care as standard RADIUS attributes.
Specifically, the provisions of this document that apply to standard Specifically, the provisions of this document that apply to standard
RADIUS attributes also apply to SSAs or VSAs for multi-vendor usage. RADIUS attributes also apply to SSAs or VSAs for multi-vendor usage.
3.1.2. Vendor Allocations 3.3.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 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 3.3.3. SDO Allocations
SDO RADIUS Attribute specifications SHOULD allocate attributes from SDO RADIUS Attribute specifications SHOULD allocate attributes from
the vendor space, rather than requesting an allocation from the the vendor space, rather than requesting an allocation from the
RADIUS standard attribute space, for attributes matching any of the RADIUS standard attribute space, for attributes matching any of the
following criteria: following criteria:
* attributes relying on data types not defined within RADIUS * attributes relying on data types not defined within RADIUS
* attributes intended primarily for use within an SDO * attributes intended primarily for use within an SDO
skipping to change at page 18, line 18 skipping to change at page 22, line 13
with minimal changes to existing systems. with minimal changes to existing systems.
It should be understood that SDOs do not have to rehost VSAs into the It should be understood that SDOs do not have to rehost VSAs into the
standards space solely for the purpose of obtaining IETF review. standards space solely for the purpose of obtaining IETF review.
Rehosting puts pressure on the standards space, and may be harmful to Rehosting puts pressure on the standards space, and may be harmful to
interoperability, since it can create two ways to provision the same interoperability, since it can create two ways to provision the same
service. Rehosting may also require changes to the RADIUS data model service. Rehosting may also require changes to the RADIUS data model
which will affect implementations that do not intend to support the which will affect implementations that do not intend to support the
SDO specifications. SDO specifications.
3.1.4. Publication of specifications 3.3.4. Publication of specifications
SDOs are encouraged to seek early review of SSA specifications by the SDOs are encouraged to seek early review of SSA specifications by the
IETF. This review may be initiated by sending mail to the AAA IETF. This review may be initiated by sending mail to the AAA
Doctors list [DOCTORS], with the understanding that this review is a Doctors list [DOCTORS], with the understanding that this review is a
voluntary-based service offered on best-effort basis. Since the IETF voluntary-based service offered on best-effort basis. Since the IETF
is not a membership organization, in order to enable the RADIUS SSA is not a membership organization, in order to enable the RADIUS SSA
specification to be reviewed, it is RECOMMENDED that it be made specification to be reviewed, it is RECOMMENDED that it be made
publicly available; this also encourages interoperability. Where the publicly available; this also encourages interoperability. Where the
RADIUS SSA specification is embedded within a larger document which RADIUS SSA specification is embedded within a larger document which
cannot be made public, the RADIUS attribute and value definitions cannot be made public, the RADIUS attribute and value definitions
skipping to change at page 18, line 42 skipping to change at page 22, line 37
Similarly, vendors are encouraged to make their specifications Similarly, vendors are encouraged to make their specifications
publicly available, for maximum interoperability. However, it is not publicly available, for maximum interoperability. However, it is not
necessary for them to request publication of their VSA specifications necessary for them to request publication of their VSA specifications
as Informational RFCs by the IETF. as Informational RFCs by the IETF.
All other specifications, including new authentication, All other specifications, including new authentication,
authorization, and/or security mechanisms SHOULD be allocated via the authorization, and/or security mechanisms SHOULD be allocated via the
standard RADIUS space, as noted in [RFC3575] Section 2.1. standard RADIUS space, as noted in [RFC3575] Section 2.1.
3.2. Polymorphic Attributes 3.4. Polymorphic Attributes
A polymorphic attribute is one whose format or meaning is dynamic. A polymorphic attribute is one whose format or meaning is dynamic.
For example, rather than using a fixed data format, an attribute's For example, rather than using a fixed data format, an attribute's
format might change based on the contents of another attribute. Or, format might change based on the contents of another attribute. Or,
the meaning of an attribute may depend on earlier packets in a the meaning of an attribute may depend on earlier packets in a
sequence. sequence.
RADIUS server dictionary entries are typically static, enabling the RADIUS server dictionary entries are typically static, enabling the
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 changing the format based on dynamic conditions. However, this
skipping to change at page 19, line 24 skipping to change at page 23, line 19
not require such changes. Thus, polymorphism increases complexity not require such changes. Thus, polymorphism increases complexity
while decreasing generality, without delivering any corresponding while decreasing generality, without delivering any corresponding
benefits. 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 using 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, use a fixed EAP-Message, etc. while being computed dynamically, use a fixed
format. format.
3.3. RADIUS Operational Model
The RADIUS operational model includes several assumptions:
* The RADIUS protocol is stateless;
* Provisioning of services is not possible within an
Access-Reject;
* There is a distinction between authorization checks and user
authentication;
* The protocol provices for authentication and integrity
protection of packets;
* The RADIUS protocol is a Request/Response protocol;
* The protocol defines packet length restrictions.
While RADIUS server implementations may keep state, the RADIUS
protocol is stateless, although information may be passed from one
protocol transaction to another via the State Attribute. As a
result, documents which require stateful protocol behavior without
use of the State Attribute are inherently incompatible with RADIUS as
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
Attribute.
As noted in [RFC5080] Section 2.6, the intent of an Access-Reject is
to deny access to the requested service. As a result, RADIUS does
not allow the provisioning of services within an Access-Reject.
Documents which include provisioning of services within an Access-
Reject are inherently incompatible with RADIUS, and need to be
redesigned.
As noted in [RFC5080] Section 2.1.1, a RADIUS Access-Request may not
contain user authentication attributes or a State Attribute linking
the Access-Request to an earlier user authentication. Such an
Access-Request, known as an authorization check, provides no
assurance that it corresponds to a live user. RADIUS specifications
defining attributes containing confidential information (such as
Tunnel-Password) should be careful to prohibit such attributes from
being returned in response to an authorization check. Also,
[RFC5080] Section 2.1.1 notes that authentication mechanisms need to
tie a sequence of Access-Request/Access-Challenge packets together
into one authentication session. The State Attribute is RECOMMENDED
for this purpose.
While [RFC2865] did not require authentication and integrity
protection of RADIUS Access-Request packets, subsequent
authentication mechanism specifications such as RADIUS/EAP [RFC3579]
and Digest Authentication [RFC5090] have mandated authentication and
integrity protection for certain RADIUS packets. [RFC5080] Section
2.1.1 makes this behavior RECOMMENDED for all Access-Request packets,
including Access-Request packets performing authorization checks. It
is expected that specifications for new RADIUS authentication
mechanisms will continue this practice.
The RADIUS protocol as defined in [RFC2865] is a request-response
protocol spoken between RADIUS clients and servers. A single RADIUS
Access-Request packet will solicit in response at most a single
Access-Accept, Access-Reject or Access-Challenge packet, sent to the
IP address and port of the RADIUS Client that originated the Access-
Request. Similarly, a single Change-of-Authorization (CoA)-Request
packet [RFC5176] will solicit in response at most a single CoA-ACK or
CoA-NAK packet, sent to the IP address and port of the Dynamic
Authorization Client (DAC) that originated the CoA-Request. A single
Disconnect-Request packet will solicit in response at most a single
Disconnect-ACK or Disconnect-NAK packet, sent to the IP address and
port of the Dynamic Authorization Client (DAC) that originated the
Disconnect-Request. Changes to this model are likely to require
major revisions to existing implementations and so this practice is
NOT RECOMMENDED.
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
packet is 4096 octets. As a result, attribute designers SHOULD NOT
assume that a RADIUS implementation can successfully process RADIUS
packets larger than 4096 octets.
Even when packets are less than 4096 octets, they may be larger than
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.
For RADIUS authentication, a sequence of Access-Request/ Access-
Challenge packets would be used. For this to be feasible,
attribute designers need to enable inclusion of attributes that
can consume considerable space within Access-Challenge packets.
To maintain compatibility with existing NASes, either the use of
Access-Challenge packets needs to be permissible (as with
RADIUS/EAP, defined in [RFC3579]), or support for receipt of an
Access-Challenge needs to be indicated by the NAS (as in RADIUS
Location [RFC5580]). Also, the specification needs to clearly
describe how attribute splitting is to be signalled and how
attributes included within the sequence are to be interpreted,
without requiring stateful operation. Unfortunately, previous
specifications have not always exhibited the required foresight.
For example, even though very large filter rules are
conceivable, the NAS-Filter-Rule Attribute defined in [RFC4849]
is not permitted in an Access-Challenge packet, nor is a
mechanism specified to allow a set of NAS-Filter-Rule attributes
to be split across an Access-Request/Access-Challenge sequence.
In the case of RADIUS accounting, transporting large amounts of
data would require a sequence of Accounting-Request packets.
This is a non-trivial change to RADIUS, since RADIUS accounting
clients would need to be modified to split the attribute stream
across multiple Accounting-Requests, and billing servers would
need to be modified to re-assemble and interpret the attribute
stream.
2. Utilization of names rather than values.
Where an attribute relates to a policy that could conceivably be
pre-provisioned on the NAS, then the name of the pre-provisioned
policy can be transmitted in an attribute, rather than the
policy itself, which could be quite large. An example of this
is the Filter-Id Attribute defined in [RFC2865] Section 5.11,
which enables a set of pre-provisioned filter rules to be
referenced by name.
3. Utilization of Packetization Layer Path MTU Discovery
techniques, as specified in [RFC4821]. As a last resort, where
the above techniques cannot be made to work, it may be possible
to apply the techniques described in [RFC4821] to discover the
maximum supported RADIUS packet size on the path between a
RADIUS client and a home server. While such an approach can
avoid the complexity of utilization of a sequence of packets,
dynamic discovery is likely to be time consuming and cannot be
guaranteed to work with existing RADIUS implementations. As a
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, which: affects the IANA, which:
* includes specific guidelines for Expert Reviewers appointed * includes specific guidelines for Expert Reviewers appointed
under the IANA considerations of [RFC3575] under the IANA considerations of [RFC3575]
* includes guidelines that recommend against self allocation from * includes guidelines that recommend against self allocation from
skipping to change at page 23, line 20 skipping to change at page 24, line 14
cryptographic community. cryptographic community.
Where new RADIUS attributes use cryptographic algorithms, algorithm Where new RADIUS attributes use cryptographic algorithms, algorithm
negotiation SHOULD be supported. Specification of a mandatory-to- negotiation SHOULD be supported. Specification of a mandatory-to-
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 5.1 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, which says that client implementations SHOULD [RFC5080] 2.2.2, which says that client implementations SHOULD
include a Message-Authenticator attribute in every Access-Request. 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 Implementations not following the suggestions outlined in this
document may be subject to a problems such as ambiguous protocol document may be subject to a problems such as ambiguous protocol
decoding, packet loss leading to loss of billing information, and decoding, packet loss leading to loss of billing information, and
denial of service attacks. denial of service attacks.
5.1. Complex Attributes 5.1. New Data Types and Complex Attributes
The introduction of complex data types brings the potential for the The introduction of complex data types brings the potential for the
introduction of new security vulnerabilities. Experience shows that introduction of new security vulnerabilities. Experience shows that
the common data types have few security vulnerabilities, or else that the common data types have few security vulnerabilities, or else that
all known issues have been found and fixed. New data types require all known issues have been found and fixed. New data types require
new code, which may introduce new bugs, and therefore new attack new code, which may introduce new bugs, and therefore new attack
vectors. vectors.
Some systems permit complex attributes to be defined via a method Some systems permit complex attributes to be defined via a method
that is more capable than traditional RADIUS dictionaries. These that is more capable than traditional RADIUS dictionaries. These
skipping to change at page 27, line 14 skipping to change at page 28, line 14
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 basic data types
Does the data fit within the basic data types described in Section Does the data fit within the basic data types described in Section
2.1.1, as outlined below? If so, it SHOULD be encapsulated in a 2.1.1, as outlined below? If so, it SHOULD be encapsulated in a
[RFC2865] format RADIUS attribute, or in a [RFC2865] format RADIUS [RFC2865] format RADIUS attribute, or in a [RFC2865] format RADIUS
VSA that uses one of the existing RADIUS data types. VSA that uses one of the existing RADIUS data types:
* 32-bit unsigned integer, in network byte order. * 32-bit unsigned integer, in network byte order.
* Enumerated data types, represented as a 32-bit unsigned integer * Enumerated data types, represented as a 32-bit unsigned integer
with a list of name to value mappings. (e.g., Service-Type) with a list of name to value mappings. (e.g., Service-Type)
* Interface-Id (8 octet string in network byte order) * Interface-Id (8 octet string in network byte order)
* IPv4 address in network byte order. * IPv4 address in network byte order.
skipping to change at page 27, line 48 skipping to change at page 28, line 48
length. This includes the opaque encapsulation of data length. This includes the opaque encapsulation of data
structures defined outside of RADIUS. See also Appendix A.1.3, structures defined outside of RADIUS. See also Appendix A.1.3,
below. below.
* UTF-8 text, totalling 253 octets or less in length. * UTF-8 text, totalling 253 octets or less in length.
Note that the length limitations for VSAs of type String and Text are Note that the length limitations for VSAs of type String and Text are
less than 253 octets, due to the additional overhead of the Vendor- less than 253 octets, due to the additional overhead of the Vendor-
Specific format. Specific format.
The following data also qualifies as "simple data types": The following data also qualifies as "basic data types":
* Attributes grouped into a logical container, using the * Attributes grouped into a logical container, using the
[RFC2868] tagging mechanism. This approach is NOT [RFC2868] tagging mechanism. This approach is NOT
RECOMMENDED (see Section 2.1.2), but is permissible where RECOMMENDED (see Section 2.1.2), but is permissible where
the alternatives are worse. the alternatives are worse.
* Attributes requiring the transport of more than 247 octets of * Attributes requiring the transport of more than 247 octets of
Text or String data. This includes the opaque encapsulation Text or String data. This includes the opaque encapsulation
of data structures defined outside of RADIUS. See also Section of data structures defined outside of RADIUS. See also Section
A.1.3, below. A.1.3, below.
Nested groups or attributes do not qualify as "simple data types", Nested groups or attributes do not qualify as "basic data types", and
and SHOULD NOT be used. SHOULD NOT be used.
A.1.2. Transport of Authentication and Security Data A.1.2. Transport of Authentication and Security Data
Does the data provide authentication and/or security capabilities for Does the data provide authentication and/or security capabilities for
the RADIUS protocol, as outlined below? If so, it SHOULD be the RADIUS protocol, as outlined below? If so, it SHOULD be
encapsulated in a [RFC2865] format RADIUS attribute. It SHOULD NOT encapsulated in a [RFC2865] format RADIUS attribute. It SHOULD NOT
be encapsulated in a [RFC2865] format RADIUS VSA. be encapsulated in a [RFC2865] format RADIUS VSA.
* Complex data types that carry authentication methods which * Complex data types that carry authentication methods which
RADIUS servers are expected to parse and verify as part of RADIUS servers are expected to parse and verify as part of
skipping to change at page 29, line 6 skipping to change at page 30, line 6
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 Appendix A.1 All data types other than the ones described above in Appendix A.1
and Appendix B SHOULD NOT be used. This section describes in detail and Appendix B SHOULD NOT be used. This section describes in detail
a number of data types that are NOT RECOMMENDED in new RADIUS a number of data types that are NOT RECOMMENDED in new RADIUS
specifications. Where possible, replacement data types are specifications. Where possible, replacement data types are
suggested. suggested.
A.2.1. Simple Data Types A.2.1. Basic 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.
* Signed integers of any size. * Signed integers of any size.
SHOULD NOT be used. SHOULD be replaced with one or more SHOULD NOT be used. SHOULD be replaced with one or more
unsigned integer attributes. The definition of the attribute unsigned integer attributes. The definition of the attribute
can contain information that would otherwise go into the sign can contain information that would otherwise go into the sign
value of the integer. value of the integer.
 End of changes. 30 change blocks. 
440 lines changed or deleted 431 lines changed or added

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