draft-ietf-radext-design-16.txt   draft-ietf-radext-design-17.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-16.txt> Individual Contributor <draft-ietf-radext-design-17.txt> Individual Contributor
Expires: February 9, 2011 Expires: February 26, 2011
9 July 2010 26 July 2010
RADIUS Design Guidelines RADIUS Design Guidelines
draft-ietf-radext-design-16 draft-ietf-radext-design-17
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).
Status of this Memo Status of this Memo
skipping to change at page 1, line 42 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 February 9, 2011. This Internet-Draft will expire on February 26, 2011.
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 21 skipping to change at page 3, line 21
1.3.1. Reviews ........................................ 7 1.3.1. Reviews ........................................ 7
2. Guidelines ............................................... 8 2. Guidelines ............................................... 8
2.1. Data Types .......................................... 9 2.1. Data Types .......................................... 9
2.2. Vendor-Specific Attribute Space ..................... 10 2.2. Vendor-Specific Attribute Space ..................... 10
2.3. Service definitions and RADIUS ...................... 10 2.3. Service definitions and RADIUS ...................... 10
2.4. Translation of Vendor Specifications ................ 11 2.4. Translation of Vendor Specifications ................ 11
3. Rationale ................................................ 12 3. Rationale ................................................ 12
3.1. RADIUS Operational Model ............................ 12 3.1. RADIUS Operational Model ............................ 12
3.2. Data Model Issues ................................... 15 3.2. Data Model Issues ................................... 15
3.2.1. Issues with Definitions of Types ............... 15 3.2.1. Issues with Definitions of Types ............... 15
3.2.2. Tagging Mechanism .............................. 16 3.2.2. Tagging Mechanism .............................. 17
3.2.3. Complex Data Types ............................. 17 3.2.3. Complex Data Types ............................. 17
3.3. Vendor Space ........................................ 20 3.2.4. Complex Data Type Exceptions ................... 18
3.3.1. Interoperability Considerations ................ 21 3.3. Vendor Space ........................................ 19
3.3.1. Interoperability Considerations ................ 20
3.3.2. Vendor Allocations ............................. 21 3.3.2. Vendor Allocations ............................. 21
3.3.3. SDO Allocations ................................ 21 3.3.3. SDO Allocations ................................ 21
3.4. Polymorphic Attributes .............................. 22 3.4. Polymorphic Attributes .............................. 22
4. IANA Considerations ...................................... 23 4. IANA Considerations ...................................... 22
5. Security Considerations .................................. 23 5. Security Considerations .................................. 23
5.1. New Data Types and Complex Attributes ............... 24 5.1. New Data Types and Complex Attributes ............... 23
6. References ............................................... 24 6. References ............................................... 24
6.1. Normative References ................................ 24 6.1. Normative References ................................ 24
6.2. Informative References .............................. 25 6.2. Informative References .............................. 24
Appendix A - Design Guidelines ............................... 28 Appendix A - Design Guidelines ............................... 27
A.1. Types matching the RADIUS data model ................. 28 A.1. Types matching the RADIUS data model ................. 27
A.1.1. Transport of basic data types ................... 28 A.1.1. Transport of basic data types ................... 27
A.1.2. Transport of Authentication and Security Data ... 28 A.1.2. Transport of Authentication and Security Data ... 27
A.1.3. Opaque data types ............................... 28 A.1.3. Opaque data types ............................... 27
A.1.4. Pre-existing data types ......................... 28 A.1.4. Pre-existing data types ......................... 27
A.2. Improper Data Types .................................. 29 A.2. Improper Data Types .................................. 28
A.2.1. Basic Data Types ................................ 29 A.2.1. Simple Data Types ............................... 28
A.2.2. Complex Data Types .............................. 30 A.2.2. More Complex Data Types ......................... 29
A.3. Vendor-Specific formats .............................. 30 A.3. Vendor-Specific formats .............................. 29
A.4. Changes to the RADIUS Operational Model .............. 31 A.4. Changes to the RADIUS Operational Model .............. 30
A.5. Allocation of attributes ............................. 32 A.5. Allocation of attributes ............................. 31
Appendix B - Complex Attributes .............................. 33 Appendix B - Complex Attributes .............................. 32
B.1. CHAP-Password ........................................ 33 B.1. CHAP-Password ........................................ 32
B.2. CHAP-Challenge ....................................... 33 B.2. CHAP-Challenge ....................................... 32
B.3. Tunnel-Password ...................................... 33 B.3. Tunnel-Password ...................................... 32
B.4. ARAP-Password ........................................ 34 B.4. ARAP-Password ........................................ 33
B.5. ARAP-Features ........................................ 34 B.5. ARAP-Features ........................................ 33
B.6. Connect-Info ......................................... 35 B.6. Connect-Info ......................................... 34
B.7. Framed-IPv6-Prefix ................................... 36 B.7. Framed-IPv6-Prefix ................................... 35
B.8. Egress-VLANID ........................................ 36 B.8. Egress-VLANID ........................................ 35
B.9. Egress-VLAN-Name ..................................... 37 B.9. Egress-VLAN-Name ..................................... 36
B.10. Digest-* ............................................ 37 B.10. Digest-* ............................................ 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 8, line 20 skipping to change at page 8, line 20
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.
To explain the implications of this early RADIUS design decision we To explain the implications of this early RADIUS design decision we
distinguish two types of data types, namely "basic" and "complex". distinguish two kinds of data types, namely "basic" and "complex".
Basic data types use one of the existing RADIUS data types defined in Basic data types use one of the existing RADIUS data types defined in
Section 2.1, encapsulated in a [RFC2865] RADIUS attribute, or in a Section 2.1, encapsulated in a [RFC2865] RADIUS attribute, or in a
[RFC2865] RADIUS VSA. All other data formats are "complex types". [RFC2865] RADIUS VSA. All other data formats are "complex types".
RADIUS attributes can be classified into one of three broad RADIUS attributes can be classified into one of three broad
categories: categories:
* Attributes that are of interest to a single vendor, e.g., for a * Attributes that are of interest to a single vendor, e.g., for a
product or product line. Minimal cross-vendor interoperability product or product line. Minimal cross-vendor interoperability
is needed. is needed.
skipping to change at page 10, line 39 skipping to change at page 10, line 39
data types" can typically be accomplished by editing a RADIUS data types" can typically be accomplished by editing a RADIUS
dictionary, whereas "complex data types" typically require RADIUS dictionary, whereas "complex data types" typically require RADIUS
server code changes, which can add complexity and delays in server code changes, which can add complexity and delays in
implementation. implementation.
Vendor RADIUS Attribute specifications SHOULD self-allocate Vendor RADIUS Attribute specifications SHOULD self-allocate
attributes from the vendor space, rather than requesting an attributes from the vendor space, rather than requesting an
allocation (or self-allocating) from within the RADIUS standard allocation (or self-allocating) from within the RADIUS standard
attribute space. attribute space.
VSA encodings that do not follow the [RFC2865] Section 5.26 scheme VSA encodings that do not follow the [RFC2865] Section 5.26 encoding
are NOT RECOMMENDED. Although [RFC2865] does not mandate it, scheme are NOT RECOMMENDED. Although [RFC2865] does not mandate it,
implementations commonly assume that the Vendor Id can be used as a implementations commonly assume that the Vendor Id can be used as a
key to determine the on-the-wire encoding of a VSA. Vendors key to determine the on-the-wire encoding of a VSA. Vendors
therefore SHOULD NOT use multiple encodings for VSAs that are therefore SHOULD NOT use multiple encodings for VSAs that are
associated with a particular Vendor Id. A vendor wishing to use associated with a particular Vendor Id. A vendor wishing to use
multiple VSA encodings SHOULD request one Vendor Id for each VSA multiple VSA encodings SHOULD request one Vendor Id for each VSA
encoding that they will use. encoding that they will use.
2.3. Service definitions and RADIUS 2.3. Service definitions and RADIUS
RADIUS specifications define how an existing service or protocol can RADIUS specifications define how an existing service or protocol can
be provisioned using RADIUS. Therefore, it is expected that a RADIUS be provisioned using RADIUS, usually via the Service-Type attribute.
attribute specification will reference documents defining the Therefore, it is expected that a RADIUS attribute specification will
protocol or service to be provisioned. Within the IETF, a RADIUS reference documents defining the protocol or service to be
attribute specification SHOULD NOT be used to define the protocol or provisioned. Within the IETF, a RADIUS attribute specification
service being provisioned. New services using RADIUS for SHOULD NOT be used to define the protocol or service being
provisioning SHOULD be defined elsewhere and referenced in the RADIUS provisioned. New services using RADIUS for provisioning SHOULD be
specification. defined elsewhere and referenced in the RADIUS specification.
New attributes, or new values of existing attributes, SHOULD NOT be New attributes, or new values of existing attributes, SHOULD NOT be
used to define new RADIUS commands. RADIUS attributes are intended used to define new RADIUS commands. RADIUS attributes are intended
to: to:
* authenticate users * authenticate users
* authorize users (i.e., service provisioning or changes to * authorize users (i.e., service provisioning or changes to
provisioning) provisioning)
skipping to change at page 12, line 30 skipping to change at page 12, line 30
This section outlines the rationale behind the above recommendations. This section outlines the rationale behind the above recommendations.
3.1. RADIUS Operational Model 3.1. 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 or Disconnect-Request;
* There is a distinction between authorization checks and user * There is a distinction between authorization checks and user
authentication; authentication;
* The protocol provides for authentication and integrity * The protocol provides for authentication and integrity
protection of packets; protection of packets;
* The RADIUS protocol is a Request/Response protocol; * The RADIUS protocol is a Request/Response protocol;
* The protocol defines packet length restrictions. * The protocol defines packet length restrictions.
While RADIUS server implementations may keep state, the RADIUS While RADIUS server implementations may keep state, the RADIUS
protocol is stateless, although information may be passed from one protocol is stateless, although information may be passed from one
protocol transaction to another via the State Attribute. As a protocol transaction to another via the State Attribute. As a
result, documents which require stateful protocol behavior without result, documents which require stateful protocol behavior without
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 SHOULD be redesigned. See [RFC5080] defined in [RFC2865], and MUST be redesigned. See [RFC5080] Section
Section 2.1.1 for additional discussion surrounding the use of the 2.1.1 for additional discussion surrounding the use of the State
State Attribute. Attribute.
As noted in [RFC5080] Section 2.6, the intent of an Access-Reject is 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 to deny access to the requested service. As a result, RADIUS does
not allow the provisioning of services within an Access-Reject. not allow the provisioning of services within an Access-Reject or
Documents which include provisioning of services within an Access- Disconnect-Request. Documents which include provisioning of services
Reject are inherently incompatible with RADIUS, and SHOULD be within an Access-Reject or Disconnect-Request are inherently
redesigned. incompatible with RADIUS, and SHOULD be redesigned.
As noted in [RFC5176] Section 3:
A Disconnect-Request MUST contain only NAS and session
identification attributes. If other attributes are included in a
Disconnect- Request, implementations MUST send a Disconnect-NAK;
an Error-Cause Attribute with value "Unsupported Attribute" MAY be
included.
As a result, documents which include provisioning of services within
a Disconnect-Request are inherently incompatible with RADIUS, and
SHOULD be redesigned.
As noted in [RFC5080] Section 2.1.1, a RADIUS Access-Request may not As noted in [RFC5080] Section 2.1.1, a RADIUS Access-Request may not
contain user authentication attributes or a State Attribute linking contain user authentication attributes or a State Attribute linking
the Access-Request to an earlier user authentication. Such an the Access-Request to an earlier user authentication. Such an
Access-Request, known as an authorization check, provides no Access-Request, known as an authorization check, provides no
assurance that it corresponds to a live user. RADIUS specifications assurance that it corresponds to a live user. RADIUS specifications
defining attributes containing confidential information (such as defining attributes containing confidential information (such as
Tunnel-Password) should be careful to prohibit such attributes from Tunnel-Password) should be careful to prohibit such attributes from
being returned in response to an authorization check. Also, being returned in response to an authorization check. Also,
[RFC5080] Section 2.1.1 notes that authentication mechanisms need to [RFC5080] Section 2.1.1 notes that authentication mechanisms need to
skipping to change at page 13, line 35 skipping to change at page 13, line 47
authentication mechanism specifications such as RADIUS/EAP [RFC3579] authentication mechanism specifications such as RADIUS/EAP [RFC3579]
and Digest Authentication [RFC5090] have mandated authentication and and Digest Authentication [RFC5090] have mandated authentication and
integrity protection for certain RADIUS packets. [RFC5080] Section integrity protection for certain RADIUS packets. [RFC5080] Section
2.1.1 makes this behavior RECOMMENDED for all Access-Request packets, 2.1.1 makes this behavior RECOMMENDED for all Access-Request packets,
including Access-Request packets performing authorization checks. It including Access-Request packets performing authorization checks. It
is expected that specifications for new RADIUS authentication is expected that specifications for new RADIUS authentication
mechanisms will continue this practice. mechanisms will continue this practice.
The RADIUS protocol as defined in [RFC2865] is a request-response The RADIUS protocol as defined in [RFC2865] is a request-response
protocol spoken between RADIUS clients and servers. A single RADIUS protocol spoken between RADIUS clients and servers. A single RADIUS
Access-Request packet will solicit in response at most a single request packet ([RFC2865], [RFC2866], or [RFC5176]) will solicit in
Access-Accept, Access-Reject or Access-Challenge packet, sent to the response at most a single response packet, sent to the IP address and
IP address and port of the RADIUS Client that originated the Access- port of the RADIUS client that originated the request. Changes to
Request. Similarly, a single Change-of-Authorization (CoA)-Request this model are likely to require major revisions to existing
packet [RFC5176] will solicit in response at most a single CoA-ACK or implementations and so this practice is NOT RECOMMENDED.
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] 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. packets larger than 4096 octets.
Even when packets are less than 4096 octets, they may be larger than Even when packets are less than 4096 octets, they may be larger than
the Path Maximum Transmission Unit (PMTU). Any packet larger than the Path Maximum Transmission Unit (PMTU). Any packet larger than
the PMTU will be fragmented, making communications more brittle as the PMTU will be fragmented, making communications more brittle as
skipping to change at page 16, line 9 skipping to change at page 16, line 11
Subsequent RADIUS specifications defined attributes by using type Subsequent RADIUS specifications defined attributes by using type
names not defined in [RFC2865], without defining the new names as was names not defined in [RFC2865], without defining the new names as was
done in [RFC2865]. They did not consistently indicate the format of done in [RFC2865]. They did not consistently indicate the format of
the value field using the same conventions as [RFC2865]. As a the value field using the same conventions as [RFC2865]. As a
result, the data type is ambiguous in some cases, and may not be result, the data type is ambiguous in some cases, 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.
For example, [RFC3162] utilizes but does not explicitly define a type For example, [RFC3162] utilizes but does not explicitly define a type
which encapsulates an IPv6 address (Section 2.1 and 2.4), and another which encapsulates an IPv6 address (Section 2.1 and 2.4), and another
type which encapsulates an IPv6 prefix (Section 2.3). The IPv6 type which encapsulates an IPv6 prefix (Section 2.3). The IPv6
address attributes confusingly are referenced as type "Address" in address attributes confusingly are referenced as type "Address" in
the document. This is a similar name as the "address" type defined the document. This is a similar name as the "address" type defined
in [RFC2865], which was defined to refer solely to IPv4 addresses. in [RFC2865], which was defined to refer solely to IPv4 addresses.
skipping to change at page 17, line 26 skipping to change at page 17, line 31
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.
3.2.3. Complex Data Types 3.2.3. Complex Data Types
The RADIUS attribute encoding is summarized in [RFC2865]: As described in this section, the creation of complex types can lead
to interoperability and deployment issues, so they need to be
introduced with care. For example, 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 encoding. However, some standard attributes pack multiple sub-fields into the
Attributes that use an encoding other than the basic data types as "Value" field, resulting in the creation of a complex type.
discussed above are defined to be "complex types". As described Separating these sub-fields into different attributes, each with its
below in this section, the creation of complex types can lead to own type and length, would have the following benefits:
interoperability and deployment issues, so they need to be introduced
with care.
In general, complex types containing multiple sub-fields can be
supported by concatenating the sub-fields into a String data type
field. However, separating these sub-fields into different
attributes, each with its own type and length, would have the
following benefits:
* it is easier for an administator to enter the data as well-known * when manual data entry is required, it is easier for an
types, rather than complex structures; administator to enter the data as well-known types, rather than
as 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.
One of the fundamental goals of the RADIUS protocol design was to One of the fundamental goals of the RADIUS protocol design was to
allow RADIUS servers to be configured to support new attributes allow RADIUS servers to be configured to support new attributes
without requiring server code changes. RADIUS server implementations without requiring server code changes. RADIUS server implementations
typically provide support for basic data types, and define attributes typically provide support for basic data types, and define attributes
in a data dictionary. This architecture enables a new attribute to in a data dictionary. This architecture enables a new attribute to
be supported by the addition of a dictionary entry, without requiring be supported by the addition of a dictionary entry, without requiring
other RADIUS server code changes. other RADIUS server code changes.
Code changes can also be required in policy management systems and in
the RADIUS server's receive path. These changes are due to
limitations in RADIUS server policy languages, which commonly provide
for limited operations (such as comparisons or arithmetic operations)
on the existing data types. Many existing RADIUS policy languages
typically are not capable of parsing sub-elements, or providing more
sophisticated matching functionality.
On the RADIUS client, code changes are typically required in order to On the RADIUS client, code changes are typically required in order to
implement a new attribute. The RADIUS client typically has to implement a new attribute. The RADIUS client typically has to
compose the attribute dynamically when sending. When receiving, a compose the attribute dynamically when sending. When receiving, a
RADIUS client needs to be able to parse the attribute and carry out RADIUS client needs to be able to parse the attribute and carry out
the requested service. As a result, a detailed understanding of the the requested service. As a result, a detailed understanding of the
new attribute is required on clients, and data dictionaries are less new attribute is required on clients, and data dictionaries are less
useful on clients than on servers. useful on clients than on servers.
Given these considerations, the introduction of a new basic or
complex attribute will typically require code changes on the RADIUS
client. The magnitude of changes for the complex attribute could be
greater, due to the potential need for custom parsing logic.
The RADIUS server can be configured to send a new static attribute by
entering its type and data format in the RADIUS server dictionary,
and then filling in the value within a policy based on the attribute
name, data type and type-specific value. For data types not
supported by current RADIUS server dictionaries, changes to the
dictionary code can be required in order to allow the new type to be
supported by and configured on the RADIUS server.
Code changes can also be required in policy management and in the
RADIUS server's receive path. These changes are due to limitations
in RADIUS server policy languages, which typically only provide for
limited operations (such as comparisons or arithmetic operations) on
the existing data types. Many existing RADIUS policy languages
typically are not capable of parsing sub-elements, or providing
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 if "ad-hoc" types are data types had been used instead. In addition if "ad-hoc" types are
used, attribute-specific parsing means more complex software to used, attribute-specific parsing is required, which means more
develop and maintain. More complexity can lead to more error prone complex software to develop and maintain. More complexity can lead
implementations, interoperability problems, and even security to more error prone implementations, interoperability problems, and
vulnerabilities. These issues can increase costs to network even security vulnerabilities. These issues can increase costs to
administrators as well as reducing reliability and introducing network administrators as well as reducing reliability and
deployment barriers. introducing deployment barriers.
3.2.4. Complex Data Type Exceptions
As described in Section 2.1, the introduction of complex data types As described in Section 2.1, the introduction of complex data types
is discouraged where viable alternatives are available. A potential is discouraged where viable alternatives are available. A potential
exception is attributes that inherently require code changes on both exception is attributes that inherently require code changes on both
the client and server. For example, as described in Appendix B, the client and server. For example, as described in Appendix B,
complex attributes have been used in situations involving complex attributes have been used in situations involving
authentication and security attributes that need to be dynamically authentication and security attributes which need to be dynamically
computed and verified. computed and verified. Supporting this functionality requires code
changes on both the RADIUS client and server, regardless of the
As can be seen in Appendix B, most of the existing complex attributes attribute format. As a result, in most cases, the use of complex
involve authentication or security functionality. Supporting this attributes to represent these methods is acceptable, and does not
functionality requires code changes on both the RADIUS client and create additional interoperability or deployment issues.
server, regardless of the attribute format. As a result, in most
cases, the use of complex attributes to represent these methods is
acceptable, and does not create additional interoperability or
deployment issues.
Another exception to the recommendation against complex types is for Another exception to the recommendation against complex types is for
types that can be treated as opaque data by the RADIUS server. For types that can be treated as opaque data by the RADIUS server. For
example, the EAP-Message attribute, defined in [RFC3579] Section 3.1 example, the EAP-Message attribute, defined in [RFC3579] Section 3.1
contains a complex data type that is an EAP packet. Since these 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 server limitations do not arise. Similarly,
Similarly, since attributes of these complex types can be configured since attributes of these complex types can be configured on the
on the server using a data type of String, dictionary limitations are server using a data type of String, dictionary limitations are also
also not encountered. Appendix A.1 below includes a series of not encountered. Appendix A.1 below includes a series of checklists
checklists that may be used to analyze a design for RECOMMENDED and that may be used to analyze a design for RECOMMENDED and NOT
NOT RECOMMENDED behavior in relation to complex types. 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 to
SHOULD be defined to be of type String. A concrete way of judging RADIUS, and SHOULD be defined to be of type String. A concrete way
this requirement is whether or not the attribute definition in the of judging this requirement is whether or not the attribute
RADIUS document contains delineated fields for sub-parts of the data. definition in the RADIUS document contains delineated fields for sub-
If those fields need to be delineated in RADIUS, then the data is not parts of the data. If those fields need to be delineated in RADIUS,
opaque, and it SHOULD be separated into individual RADIUS attributes. then the data is not opaque to RADIUS, and it SHOULD be separated
into individual RADIUS attributes.
An examination of existing RADIUS RFCs discloses a number of complex An examination of existing RADIUS RFCs discloses a number of complex
attributes that have already been defined. Appendix B includes a attributes that have already been defined. Appendix B includes a
listing of complex attributes used within [RFC2865], [RFC2868], listing of complex attributes used within [RFC2865], [RFC2868],
[RFC2869], [RFC3162], [RFC4818], and [RFC4675]. The discussion of [RFC2869], [RFC3162], [RFC4818], and [RFC4675]. The discussion of
these attributes includes reasons why a complex type is acceptable, these attributes includes reasons why a complex type is acceptable,
or suggestions for how the attribute could have been defined to or suggestions for how the attribute could have been defined to
follow the RADIUS data model. follow the RADIUS data model.
In other cases, the data in the complex type are described textually. In other cases, the data in the complex type are described textually.
skipping to change at page 20, line 29 skipping to change at page 20, line 16
Nevertheless, many new attributes have been defined in the vendor Nevertheless, many new attributes have been defined in the vendor
specific space in situations where interoperability is not only specific space in situations where interoperability is not only
useful, but is required. For example, SDOs outside the IETF (such as useful, but is required. For example, SDOs outside the IETF (such as
the IEEE 802 and the 3rd Generation Partnership Project (3GPP)) have the IEEE 802 and the 3rd Generation Partnership Project (3GPP)) have
been assigned Vendor-Ids, enabling them to define their own VSA been assigned Vendor-Ids, enabling them to define their own VSA
encoding and assign Vendor types within their own space. encoding and assign Vendor types within their own space.
The use of VSAs by SDOs outside the IETF has gained in popularity for The use of VSAs by SDOs outside the IETF has gained in popularity for
several reasons: several reasons:
Efficiency Efficiency
As with SNMP, which defines an "Enterprise" Object Identifier (OID) As with SNMP, which defines an "Enterprise" Object Identifier
space suitable for use by vendors as well as other SDOs, the (OID) space suitable for use by vendors as well as other SDOs, the
definition of Vendor-Specific RADIUS attributes has become a common definition of Vendor-Specific RADIUS attributes has become a
occurrence as part of standards activity outside the IETF. For common occurrence as part of standards activity outside the IETF.
reasons of efficiency, it is easiest if the RADIUS attributes For reasons of efficiency, it is easiest if the RADIUS attributes
required to manage a standard are developed within the same SDO required to manage a standard are developed within the same SDO
that develops the standard itself. As noted in "Transferring MIB that develops the standard itself. As noted in "Transferring MIB
Work from IETF Bridge MIB WG to IEEE 802.1 WG" [RFC4663], today few Work from IETF Bridge MIB WG to IEEE 802.1 WG" [RFC4663], today
vendors are willing to simultaneously fund individuals to few vendors are willing to simultaneously fund individuals to
participate within an SDO to complete a standard, as well as to participate within an SDO to complete a standard, as well as to
participate in the IETF in order to complete the associated RADIUS participate in the IETF in order to complete the associated RADIUS
attributes specification. attributes specification.
Attribute scarcity Attribute scarcity
The standard RADIUS attribute space is limited to 255 unique The standard RADIUS attribute space is limited to 255 unique
attributes. Of these, only about half remain available for attributes. Of these, only about half remain available for
allocation. In the vendor space, the number of attributes allocation. In the vendor space, the number of attributes
available is a function of the encoding of the attribute (the size available is a function of the encoding of the attribute (the size
of the Vendor type field). of the Vendor type field).
3.3.1. Interoperability Considerations 3.3.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
skipping to change at page 24, line 33 skipping to change at page 24, line 22
but they do not remove it entirely. but they do not remove it entirely.
RADIUS servers are highly valued targets, as they control network RADIUS servers are highly valued targets, as they control network
access and interact with databases that store usernames and access and interact with databases that store usernames and
passwords. An extreme outcome of a vulnerability due to a new, passwords. An extreme outcome of a vulnerability due to a new,
complex type would be that an attacker is capable of taking complete complex type would be that an attacker is capable of taking complete
control over the RADIUS server. control over the RADIUS server.
The use of attributes representing opaque data does not reduce this The use of attributes representing opaque data does not reduce this
threat. The threat merely moves from the RADIUS server to the system threat. The threat merely moves from the RADIUS server to the system
that consumes that opaque data. that consumes that opaque data. The threat is particularly severe
when the opaque data originates from the user, and is not validated
The threat is particularly severe when the opaque data originates by the NAS. In those cases, the RADIUS server is potentially exposed
from the user, and is not validated by the NAS. In those cases, the to attack by malware residing on an unauthenticated host.
RADIUS server is potentially exposed to attack by malware residing on
an unauthenticated host.
Any system consuming opaque data that originates from a RADIUS system Any system consuming opaque data that originates from a RADIUS system
SHOULD be properly isolated from that RADIUS system, and SHOULD run SHOULD be properly isolated from that RADIUS system, and SHOULD run
with minimal privileges. Any potential vulnerabilities in the non- with minimal privileges. Any potential vulnerabilities in the non-
RADIUS system will then have minimal impact on the security of the RADIUS system will then have minimal impact on the security of the
system as a whole. system as a whole.
6. References 6. References
6.1. Normative References 6.1. Normative References
skipping to change at page 29, line 13 skipping to change at page 28, line 13
A.1.4. Pre-existing data types A.1.4. Pre-existing data types
There is a trade-off in design between re-using existing formats for There is a trade-off in design between re-using existing formats for
historical compatibility, or choosing new formats for a "better" historical compatibility, or choosing new formats for a "better"
design. This trade-off does not always require the "better" design design. This trade-off does not always require the "better" design
to be used. As a result. pre-existing complex data types described to be used. As a result. pre-existing complex data types described
in Appendix B MAY be used. in Appendix B MAY be used.
A.2. Improper Data Types A.2. Improper Data Types
This section suggests alternatives to data types which do not fall This section suggests alternatives to data types which do not fall
within the "basic data type" definition. within the "basic data type" definition. Section A.2.1 describes
simple data types which should be replaced by basic data types.
Section A.2.2 descibes more complex data types which should be
replaced by multiple attributes using the basic data types.
A.2.1. Basic 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.
* 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.
skipping to change at page 29, line 49 skipping to change at page 29, line 4
* 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 bits in network SHOULD be replaced by unsigned integer of 32 bits in network
There is no reason to transport integers in any format other There is no reason to transport integers in any format other
than network byte order. than network byte order.
* 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.
* 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. Attributes should be defined in a flat typespace.
A.2.2. Complex Data Types A.2.2. More Complex Data Types
Does the attribute: Does the attribute:
* define a complex data type not described in Appendix B, * define a complex data type not described in Appendix B,
* that a RADIUS server and/or client is expected to parse, * that a RADIUS server and/or client is expected to parse,
validate, or create the contents of via a dynamic computation? validate, or create the contents of via a dynamic computation?
i.e. A type that cannot be treated as opaque data (Section A.1.3) i.e. A type that cannot be treated as opaque data (Section A.1.3)
* involve functionality that could be implemented without code * involve functionality that could be implemented without code
skipping to change at page 31, line 40 skipping to change at page 30, line 43
Attribute designers cannot assume that RADIUS implementations Attribute designers cannot assume that RADIUS implementations
can successfully handle packets larger than 4096 octets. can successfully handle packets larger than 4096 octets.
If a specification could lead to a RADIUS packet larger than If a specification could lead to a RADIUS packet larger than
4096 octets, then the alternatives described in Section 3.3 4096 octets, then the alternatives described in Section 3.3
SHOULD be considered. SHOULD be considered.
* Stateless operation. The RADIUS protocol is stateless, and * Stateless operation. The RADIUS protocol is stateless, and
documents which require stateful protocol behavior without the documents which require stateful protocol behavior without the
use of the State Attribute need to be redesigned. use of the State Attribute need to be redesigned.
* Provisioning of service in an Access-Reject. Such provisioning * Provisioning of service in an Access-Reject or
is not permitted, and MUST NOT be used. If limited access needs Disconnect-Request. Such provisioning is not permitted, and
to be provided, then an Access-Accept with appropriate MUST NOT be used. If limited access needs to be provided, then
authorizations can be used instead. an Access-Accept with appropriate authorizations can be used
instead.
* Provisioning of service in a Disconnect-Request.
Such provisioning is not permitted, and MUST NOT be used.
If limited access needs to be provided, then a CoA-Request
with appropriate authorizations can be used instead.
* Lack of user authentication or authorization restrictions. * Lack of user authentication or authorization restrictions.
In an authorization check, where there is no demonstration of a In an authorization check, where there is no demonstration of a
live user, confidential data cannot be returned. Where there live user, confidential data cannot be returned. Where there
is a link to a previous user authentication, the State attribute is a link to a previous user authentication, the State attribute
SHOULD be present. SHOULD be present.
* Lack of per-packet integrity and authentication. * Lack of per-packet integrity and authentication.
It is expected that documents will support per-packet It is expected that documents will support per-packet
integrity and authentication. integrity and authentication.
* Modification of RADIUS packet sequences. * Modification of RADIUS packet sequences.
In RADIUS, each request is encapsulated in its own packet, and In RADIUS, each request is encapsulated in its own packet, and
elicits a single response that is sent to the requester. Since elicits a single response that is sent to the requester. Since
changes to this paradigm are likely to require major changes to this paradigm are likely to require major
modifications to RADIUS client and server implementations, they modifications to RADIUS client and server implementations, they
SHOULD be avoided if possible. SHOULD be avoided if possible.
For further details, see Section 3.1. For further details, see Section 3.1.
skipping to change at page 36, line 18 skipping to change at page 35, line 18
Accounting-Request packet to accommodate expected efforts by ITU Accounting-Request packet to accommodate expected efforts by ITU
to have modems report more connection information in a standard to have modems report more connection information in a standard
format that might exceed 252 octets. format that might exceed 252 octets.
This attribute contains no encrypted component, and is it not This attribute contains no encrypted component, and is it not
directly involved in authentication. The individual sub-fields could directly involved in authentication. The individual sub-fields could
therefore have been encapsulated in separate attributes. therefore have been encapsulated in separate attributes.
However, since the definition refers to potential standardization However, since the definition refers to potential standardization
activity within ITU, the Connect-Info attribute can also be thought activity within ITU, the Connect-Info attribute can also be thought
of opaque data whose definition is provided elsewhere. The Connect- of as opaque data whose definition is provided elsewhere. The
Info attribute could therefore qualify for an exception as described Connect-Info attribute could therefore qualify for an exception as
in Section 3.2.3. described in Section 3.2.3.
B.7. Framed-IPv6-Prefix B.7. Framed-IPv6-Prefix
[RFC3162] Section 2.3 defines the Framed-IPv6-Prefix Attribute and [RFC3162] Section 2.3 defines the Framed-IPv6-Prefix Attribute and
[RFC4818] Section 3 reuses this format for the Delegated-IPv6-Prefix [RFC4818] Section 3 reuses this format for the Delegated-IPv6-Prefix
Attribute; these attributes are sent from the RADIUS server to the Attribute; these attributes are sent from the RADIUS server to the
client in an Access-Accept. client in an Access-Accept.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 End of changes. 35 change blocks. 
166 lines changed or deleted 160 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/