< draft-ietf-radext-design-08.txt   draft-ietf-radext-design-09.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-08.txt> Individual Contributor <draft-ietf-radext-design-09.txt> Individual Contributor
Expires: March 6, 2010 Expires: April 12, 2010
6 September 2009 12 October 2009
RADIUS Design Guidelines RADIUS Design Guidelines
draft-ietf-radext-design-08 draft-ietf-radext-design-09
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and document may not be modified outside the IETF Standards Process, and
skipping to change at page 1, line 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 March 6, 2010. This Internet-Draft will expire on April 12, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 19 skipping to change at page 3, line 19
1.2. Requirements Language ............................... 4 1.2. Requirements Language ............................... 4
1.3. Applicability ....................................... 5 1.3. Applicability ....................................... 5
2. RADIUS Data Model ........................................ 6 2. RADIUS Data Model ........................................ 6
2.1. Standard Space ...................................... 6 2.1. Standard Space ...................................... 6
2.1.1. Basic Data Types ............................... 6 2.1.1. Basic Data Types ............................... 6
2.1.2. Tagging Mechanism .............................. 8 2.1.2. Tagging Mechanism .............................. 8
2.1.3. Complex Attribute Usage ........................ 8 2.1.3. Complex Attribute Usage ........................ 8
2.1.4. Complex Attributes and Security ................ 11 2.1.4. Complex Attributes and Security ................ 11
2.1.5. Service definitions and RADIUS ................. 11 2.1.5. Service definitions and RADIUS ................. 11
2.2. Vendor Space ........................................ 12 2.2. Vendor Space ........................................ 12
3. Data Model Issues ........................................ 13 3. Data Model Issues ........................................ 14
3.1. Vendor Space ........................................ 14 3.1. Vendor Space ........................................ 14
3.1.1. Interoperability Considerations ................ 16 3.1.1. Interoperability Considerations ................ 16
3.1.2. Vendor Allocations ............................. 16 3.1.2. Vendor Allocations ............................. 17
3.1.3. SDO Allocations ................................ 17 3.1.3. SDO Allocations ................................ 17
3.1.4. Publication of specifications .................. 18 3.1.4. Publication of specifications .................. 18
3.2. Polymorphic Attributes .............................. 18 3.2. Polymorphic Attributes .............................. 18
3.3. RADIUS Operational Model ............................ 19 3.3. RADIUS Operational Model ............................ 19
4. IANA Considerations ...................................... 22 4. IANA Considerations ...................................... 22
5. Security Considerations .................................. 22 5. Security Considerations .................................. 22
6. References ............................................... 23 6. References ............................................... 23
6.1. Normative References ................................ 23 6.1. Normative References ................................ 23
6.2. Informative References .............................. 23 6.2. Informative References .............................. 23
Appendix A - Design Guidelines ............................... 26 Appendix A - Design Guidelines ............................... 26
A.1. Types matching the RADIUS data model ................. 26 A.1. Types matching the RADIUS data model ................. 26
A.1.1. Transport of simple data ........................ 26 A.1.1. Transport of simple data ........................ 26
A.1.2. Opaque data types ............................... 26 A.1.2. Transport of Authentication and Security Data ... 27
A.1.3. Opaque data types ............................... 27
A.2. Improper Data Types .................................. 27 A.2. Improper Data Types .................................. 27
A.2.1. Simple Data Types ............................... 27 A.2.1. Simple Data Types ............................... 28
A.2.2. Complex Data Types .............................. 28 A.2.2. Complex Data Types .............................. 29
A.3. Vendor-Specific formats .............................. 28 A.3. Vendor-Specific formats .............................. 29
A.4. Changes to the RADIUS Operational Model .............. 29 A.4. Changes to the RADIUS Operational Model .............. 29
A.5. Allocation of attributes ............................. 30 A.5. Allocation of attributes ............................. 31
Appendix B - Complex Attributes .............................. 31 Appendix B - Complex Attributes .............................. 32
B.1. CHAP-Password ........................................ 31 B.1. CHAP-Password ........................................ 32
B.2. CHAP-Challenge ....................................... 31 B.2. CHAP-Challenge ....................................... 32
B.3. Tunnel-Password ...................................... 31 B.3. Tunnel-Password ...................................... 32
B.4. ARAP-Password ........................................ 32 B.4. ARAP-Password ........................................ 33
B.5. ARAP-Features ........................................ 32 B.5. ARAP-Features ........................................ 33
B.6. Connect-Info ......................................... 33 B.6. Connect-Info ......................................... 34
B.7. Framed-IPv6-Prefix ................................... 34 B.7. Framed-IPv6-Prefix ................................... 35
B.8. Egress-VLANID ........................................ 34 B.8. Egress-VLANID ........................................ 35
B.9. Egress-VLAN-Name ..................................... 35 B.9. Egress-VLAN-Name ..................................... 36
1. Introduction 1. Introduction
This document provides guidelines for the design of RADIUS attributes This document provides guidelines for the design of RADIUS attributes
both within the IETF as well as within other SDOs. By articulating both within the IETF as well as within other SDOs. By articulating
RADIUS design guidelines, it is hoped that this document will RADIUS design guidelines, it is hoped that this document will
encourage the development and publication of high quality RADIUS encourage the development and publication of high quality RADIUS
attribute specifications. attribute specifications.
However, the advice in this document will not be helpful unless it is However, the advice in this document will not be helpful unless it is
skipping to change at page 6, line 26 skipping to change at page 6, line 26
Section 2.1. Section 2.1.
2. RADIUS Data Model 2. RADIUS Data Model
The Remote Authentication Dial In User Service (RADIUS) defined in The Remote Authentication Dial In User Service (RADIUS) defined in
[RFC2865] and [RFC2866] uses elements known as attributes in order to [RFC2865] and [RFC2866] uses elements known as attributes in order to
represent authentication, authorization and accounting data. represent authentication, authorization and accounting data.
Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does
not define a formal data definition language. A handful of basic not define a formal data definition language. A handful of basic
data types are provided, and a data type is associated with an data types are in common use, and a data type is associated with an
attribute when the attribute is defined. attribute when the attribute is defined.
Two distinct attribute spaces are defined: the standard space, and a Two distinct attribute spaces are defined: the standard space, and a
Vendor-Specific space. Attributes in the standard space generally Vendor-Specific space. Attributes in the standard space generally
are composed of a type, length, value (TLV) triplet, although complex are composed of a type, length, value (TLV) triplet, although complex
attributes have also been defined. The Vendor-Specific space is attributes have also been defined. The Vendor-Specific space is
encapsulated within a single attribute type (Vendor-Specific encapsulated within a single attribute type (Vendor-Specific
Attribute). The format of this space is defined by individual Attribute). The format of this space is defined by individual
vendors, but the same TLV encoding used by the standard space is vendors, but the same TLV encoding used by the standard space is
recommended in [RFC2865] Section 5.26. The similarity between recommended in [RFC2865] Section 5.26. The similarity between
skipping to change at page 8, line 31 skipping to change at page 8, line 31
Other limitations of the tagging mechanism are that when integer Other limitations of the tagging mechanism are that when integer
values are tagged, the value portion is reduced to three bytes values are tagged, the value portion is reduced to three bytes
meaning only 24-bit numbers can be represented. The tagging meaning only 24-bit numbers can be represented. The tagging
mechanism does not offer an ability to create nested groups of mechanism does not offer an ability to create nested groups of
attributes. Some RADIUS implementations treat tagged attributes as attributes. Some RADIUS implementations treat tagged attributes as
having additional data types tagged-string and tagged-integer. These having additional data types tagged-string and tagged-integer. These
types increase the complexity of implementing and managing RADIUS types increase the complexity of implementing and managing RADIUS
systems. systems.
New attributes SHOULD NOT use this tagging method because of the For these reasons, the tagging scheme described in RFC 2868 is NOT
limitations described above. RECOMMENDED for use as a generic grouping mechanism.
2.1.3. Complex Attribute Usage 2.1.3. Complex Attribute Usage
The RADIUS attribute encoding is summarized in [RFC2865]: The RADIUS attribute encoding is summarized in [RFC2865]:
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Value ... | Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
skipping to change at page 13, line 7 skipping to change at page 13, line 13
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | Vendor type | Vendor length | Vendor-Id (cont) | Vendor type | Vendor length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute-Specific... | Attribute-Specific...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Multiple sub-attributes MAY be encoded within a single Vendor- Multiple sub-attributes MAY be encoded within a single Vendor-
Specific attribute, although they do not have to be. Specific attribute, although they do not have to be.
Note that the Vendor type field in the recommended VSA format is only Note that the Vendor type field in the recommended VSA format is only
a single octet, like the RADIUS type field. While this limitation a single octet, like the RADIUS type field. While this limitation
results in an efficient encoding, there are situations in which a results in an efficient encoding, there are situations in which a
vendor or SDO will eventually wish to define more than 255 vendor or SDO will eventually wish to define more than 255
attributes. Also, an SDO can be comprised of multiple subgroups, attributes. Also, an SDO can be comprised of multiple subgroups, each
each of whom can desire autonomy over the definition of attributes of whom can desire autonomy over the definition of attributes within
within their group. In such a situation, a 16-bit Vendor type field their group. The most interoperable way to address these issues is
would be more appropriate: for the vendor or SDO to request allocation of multiple Vendor
identifiers.
0 1 2 3 However, instead of doing this, vendors have defined the following
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 non-standard VSA formats:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | Vendor type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor length | Attribute-Specific...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Other attribute formats are NOT RECOMMENDED. Examples of NOT * Vendor types of 16 bits, followed by an 8 bit length and
RECOMMENDED formats include Vendor types of more than 16 bits, Vendor then attribute-specific data.
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.
In order to be compatible with the above recommendations for * Vendor types of 32 bits, followed by no length field, and
attribute definitions, it is RECOMMENDED that RADIUS servers support then attribute-specific data.
attributes using a 16-bit Vendor type field.
* 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 Although [RFC2865] does not mandate it, implementations commonly
assume that the Vendor Id can be used as a key to determine the on- 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 the-wire format of a VSA. Vendors therefore SHOULD NOT use multiple
formats for VSAs that are associated with a particular Vendor Id. A formats for VSAs that are associated with a particular Vendor Id. A
vendor wishing to use multiple VSA formats, SHOULD request one Vendor vendor wishing to use multiple VSA formats SHOULD request one Vendor
Id for each VSA format that they will use. Id for each VSA format that they will use.
3. Data Model Issues 3. Data Model Issues
Since the closure of the RADIUS Working Group, the popularity and Since the closure of the RADIUS Working Group, the popularity and
prevalence of RADIUS has continued to grow. In addition to prevalence of RADIUS has continued to grow. In addition to
increasing demand for allocation of attributes within the RADIUS increasing demand for allocation of attributes within the RADIUS
standard attribute space, the number of vendors and SDOs creating new standard attribute space, the number of vendors and SDOs creating new
attributes within the Vendor-Specific attribute space has grown, and attributes within the Vendor-Specific attribute space has grown, and
this has lead to some divergence in approaches to RADIUS attribute this has lead to some divergence in approaches to RADIUS attribute
skipping to change at page 26, line 22 skipping to change at page 26, line 22
A.1. Types matching the RADIUS data model A.1. Types matching the RADIUS data model
A.1.1. Transport of simple data A.1.1. Transport of simple data
Does the data fit within the existing RADIUS data model, as outlined Does the data fit within the existing RADIUS data model, as outlined
below? If so, it SHOULD be encapsulated in a [RFC2865] format RADIUS below? If so, it SHOULD be encapsulated in a [RFC2865] format RADIUS
attribute, or in a [RFC2865] format RADIUS VSA that uses one of the attribute, or in a [RFC2865] format RADIUS VSA that uses one of the
existing RADIUS data types. existing RADIUS data types.
* 32-bit unsigned integer, 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)
* 64-bit unsigned integer, in network byte order. * 64-bit unsigned integer, in network byte order.
* IPv4 address in network byte order. * IPv4 address in network byte order.
* IPv6 address in network byte order. * IPv6 address in network byte order.
* IPv6 prefix. * IPv6 prefix.
* time as 32 bit unsigned value, in network byte order, and in * time as 32 bit unsigned value, in network byte order, and in
seconds since 00:00:00 UTC, January 1, 1970. seconds since 00:00:00 UTC, January 1, 1970.
* string (i.e., binary data), totalling 253 octets or less in * string (i.e., binary data), totalling 253 octets or less in
length. This includes the opaque encapsulation of data length. This includes the opaque encapsulation of data
structures defined outside of RADIUS. See also Appendix A.1.2, 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.
* Complex data types for authentication and/or security.
These attributes SHOULD be defined only within the RADIUS
attribute space, and SHOULD NOT be defined within the VSA space.
Note that the length limitations for VSAs of type String and Text are 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.
* Attributes grouped into a logical container. The following data also qualifies as "simple data types":
This does not include nested groups.
* Attributes grouped into a logical container, using the
[RFC2868] tagging mechanism. This approach is NOT
RECOMMENDED (see Section 2.1.2), but is permissible where
the alternatives are worse.
* Attributes requiring the transport of more than 247 octets of * Attributes requiring the transport of more than 247 octets of
Text or String data. This includes the opaque encapsulation Text or String data. This includes the opaque encapsulation
of data structures defined outside of RADIUS. See also Section of data structures defined outside of RADIUS. See also Section
A.1.2, below. A.1.3, below.
A.1.2. Opaque data types Nested groups or attributes do not qualify as "simple data types",
and SHOULD NOT be used.
A.1.2. Transport of Authentication and Security Data
Does the data provide authentication and/or security capabilities, as
outlined below? If so, it SHOULD be encapsulated in a [RFC2865]
format RADIUS attribute. It SHOULD NOT be encapsulated in a
[RFC2865] format RADIUS VSA.
* Complex data types that carry authentication methods which
RADIUS servers are expected to parse and verify as part of
an authentication process.
* Complex data types that carry security information intended
to increase the security of the RADIUS protocol itself.
Any data type carrying authentication and/or security data that is
not meant to be parsed by a RADIUS server is an "opaque data type",
as defined below.
A.1.3. Opaque data types
Does the attribute encapsulate an existing data structure defined Does the attribute encapsulate an existing data structure defined
outside of the RADIUS specifications? Can the attribute be treated outside of the RADIUS specifications? Can the attribute be treated
as opaque data by RADIUS servers (including proxies?) If both as opaque data by RADIUS servers (including proxies?) If both
questions can be answered affirmatively, a complex structure MAY be questions can be answered affirmatively, a complex structure MAY be
used in a RADIUS specification. used in a RADIUS specification.
The specification of the attribute SHOULD define the encapsulating The specification of the attribute SHOULD define the encapsulating
attribute to be of type String. The specification SHOULD refer to an attribute to be of type String. The specification SHOULD refer to an
external document defining the structure. The specification SHOULD external document defining the structure. The specification SHOULD
skipping to change at page 27, line 33 skipping to change at page 28, line 16
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.
* 8 bit unsigned integers. * 8 bit unsigned integers.
SHOULD be replaced with 32-bit unsigned integer. There is SHOULD be replaced with 32-bit unsigned integer. There is
insufficient justification to save three bytes. insufficient justification to save three bytes.
* 16 bit unsigned integers. * 16 bit unsigned integers.
SHOULD be replaced with 32-bit unsigned integer. There is SHOULD be replaced with 32-bit unsigned integer. There is
insufficient justification to save two bytes. insufficient justification to save two bytes.
* Unsigned integers of size other than 32 or 64. * Unsigned integers of size other than 32 or 64.
SHOULD be replaced by an unsigned integer of 32 or 64 bits. SHOULD be replaced by an unsigned integer of 32 or 64 bits.
There is insufficient justification to define a new size of There is insufficient justification to define a new size of
integer. integer.
* Integers of any size in non-network byte order * Integers of any size in non-network byte order
SHOULD be replaced by unsigned integer of 32 or 64 bits, SHOULD be replaced by unsigned integer of 32 or 64 bits,
in network byte order. There is no reason to transport integers in network byte order. There is no reason to transport integers
in any format other than network byte order. in any format other than network byte order.
* Tagged data types as described in [RFC2868]. * Tagged data types as described in [RFC2868].
These data types SHOULD NOT be used in new specifications. These data types SHOULD NOT be used in new specifications.
* Complex data structures defined only within RADIUS. * Complex data structures defined only within RADIUS.
SHOULD NOT be used. This recommendation does not apply to new SHOULD NOT be used. This recommendation does not apply to new
attributes for authentication or security, as described below attributes for authentication or security, as described below
in Section A.2.2. in Section A.2.2.
* Multi-field text strings. * Multi-field text strings.
Each field SHOULD be encapsulated in a separate attribute. Each field SHOULD be encapsulated in a separate attribute.
* Polymorphic attributes. * Polymorphic attributes.
Multiple attributes, each with a static data type SHOULD be Multiple attributes, each with a static data type SHOULD be
defined instead. defined instead.
* Nested AVPs. * Nested AVPs.
Attributes should be defined in a flat typespace, possibly using Attributes should be defined in a flat typespace, possibly using
a 16-bit Vendor type field (see Section 2.3). a 16-bit Vendor type field (see Section 2.3).
A.2.2. Complex Data Types A.2.2. Complex Data Types
Does the attribute define a complex data type for purposes other than Does the attribute:
authentication or security? If so, this data type SHOULD be replaced
with simpler types, as discussed above in Appendix A.2.1. Also see * define a complex data type
Section 2.1.3 for a discussion of why complex types are problematic.
* That a RADIUS server and/or client is expected to parse?
i.e. A type that cannot be treated as opaque data (Section A.1.3)
* for purposes other than authentication or security?
If so, this data type SHOULD be replaced with simpler types, as
discussed above in Appendix A.2.1. Also see Section 2.1.3 for a
discussion of why complex types are problematic.
A.3. Vendor-Specific formats A.3. Vendor-Specific formats
Does the specification contain Vendor-Specific attributes that match Does the specification contain Vendor-Specific attributes that match
any of the following criteria? If so, the data type should be any of the following criteria? If so, the data type should be
replaced with the suggested alternatives, or should not be used at replaced with the suggested alternatives, or should not be used at
all. all.
* Vendor types of more than 16 bits. * Vendor types of more than 8 bits.
SHOULD NOT be used. Vendor types of 8 or 16 bits SHOULD be used SHOULD NOT be used. Vendor types of 8 bits SHOULD be used
instead. instead.
* Vendor lengths of less than 8 bits. (i.e., zero bits) * Vendor lengths of less than 8 bits. (i.e., zero bits)
SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used
instead. instead.
* Vendor lengths of more than 8 bits. * Vendor lengths of more than 8 bits.
SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used SHOULD NOT be used. Vendor lengths of 8 bits SHOULD be used
instead. instead.
* Vendor-Specific contents that are not in Type-Length-Value * Vendor-Specific contents that are not in Type-Length-Value
format. format.
SHOULD NOT be used. Vendor-Specific attributes SHOULD be in SHOULD NOT be used. Vendor-Specific attributes SHOULD be in
Type-Length-Value format. Type-Length-Value format.
In general, Vendor-Specific attributes SHOULD follow the [RFC2865] In general, Vendor-Specific attributes SHOULD follow the [RFC2865]
suggested format. However, we recognize that SDOs may require more suggested format. Vendor extensions to non-standard formats are NOT
than 256 attributes, which is the limit of the 8-bit [RFC2865] RECOMMENDED as they can negatively affect interoperability.
Vendor-Specific space. Those SDOs SHOULD use Vendor types of 16
bits, as described in Section 2.3. However, SDOs SHOULD NOT use
Vendor types of 16 bits unless there are immediate requirements.
Future-proofing a specification is insufficient grounds for using
16-bit Vendor types.
A.4. Changes to the RADIUS Operational Model A.4. Changes to the RADIUS Operational Model
Does the specification change the RADIUS operation model, as outlined Does the specification change the RADIUS operation model, as outlined
in the list below? If so, then another method of achieving the in the list below? If so, then another method of achieving the
design objectives SHOULD be used. Potential problem areas include: design objectives SHOULD be used. Potential problem areas include:
* Defining new commands in RADIUS using attributes. * Defining new commands in RADIUS using attributes.
The addition of new commands to RADIUS MUST be handled via The addition of new commands to RADIUS MUST be handled via
allocation of a new Code, and not by the use of an attribute. allocation of a new Code, and not by the use of an attribute.
 End of changes. 44 change blocks. 
68 lines changed or deleted 121 lines changed or added

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