draft-ietf-radext-radius-extensions-03.txt   draft-ietf-radext-radius-extensions-04.txt 
Network Working Group Alan DeKok Network Working Group Alan DeKok
INTERNET-DRAFT Network RADIUS INTERNET-DRAFT Network RADIUS
Category: Proposed Standard Avi Lior Category: Proposed Standard Avi Lior
Updates: 2865, 2866, 3575, 5176 BWS Updates: 2865, 2866, 3575, 5176, 6158 BWS
<draft-ietf-radext-radius-extensions-03.txt> <draft-ietf-radext-radius-extensions-04.txt>
Expires: May 15, 2012 Expires: July 2, 2012
15 November 2011 2 January 2012
Remote Authentication Dial In User Service (RADIUS) Protocol Remote Authentication Dial In User Service (RADIUS) Protocol
Extensions Extensions
draft-ietf-radext-radius-extensions-03.txt draft-ietf-radext-radius-extensions-04.txt
Abstract Abstract
The Remote Authentication Dial In User Service (RADIUS) protocol is The Remote Authentication Dial In User Service (RADIUS) protocol is
nearing exhaustion of its current 8-bit attribute type space. In nearing exhaustion of its current 8-bit Attribute Type space. In
addition, experience shows a growing need for complex grouping, along addition, experience shows a growing need for complex grouping, along
with attributes which can carry more than 253 octets of data. This with attributes which can carry more than 253 octets of data. This
document defines changes to RADIUS which address all of the above document defines changes to RADIUS which address all of the above
problems. problems.
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.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 May 15, 2012. This Internet-Draft will expire on July 2, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ............................................. 5 1. Introduction ............................................. 5
1.1. Terminology ......................................... 6 1.1. Unmet Requirements .................................. 6
1.2. Requirements Language ............................... 6 1.2. Terminology ......................................... 6
2. Extensions to RADIUS ..................................... 8 1.3. Requirements Language ............................... 7
2.1. Extended Type ....................................... 8 2. Extensions to RADIUS ..................................... 9
2.2. Extended Type with Flags ............................ 9 2.1. Extended Type ....................................... 9
2.3. TLV Data Type ....................................... 11 2.2. Extended Type with Flags ............................ 10
2.3.1. TLV Nesting .................................... 13 2.3. TLV Data Type ....................................... 12
2.4. EVS Data Type ....................................... 13 2.3.1. TLV Nesting .................................... 14
2.4. EVS Data Type ....................................... 14
2.5. Integer64 Data Type ................................. 15 2.5. Integer64 Data Type ................................. 15
2.6. Attribute Naming and Type Identifiers ............... 15 2.6. Attribute Naming and Type Identifiers ............... 16
2.6.1. Attribute and TLV Naming ....................... 16 2.6.1. Attribute and TLV Naming ....................... 16
2.6.2. Attribute Type Identifiers ..................... 16 2.6.2. Attribute Type Identifiers ..................... 17
2.6.3. TLV Identifiers ................................ 16 2.6.3. TLV Identifiers ................................ 17
2.6.4. VSA Identifiers ................................ 17 2.6.4. VSA Identifiers ................................ 18
3. Attribute Definitions .................................... 18 2.7. Invalid Attributes .................................. 18
3.1. Extended-Type-1 ..................................... 18 3. Attribute Definitions .................................... 19
3.2. Extended-Type-2 ..................................... 19 3.1. Extended-Type-1 ..................................... 20
3.3. Extended-Type-3 ..................................... 20 3.2. Extended-Type-2 ..................................... 21
3.4. Extended-Type-4 ..................................... 21 3.3. Extended-Type-3 ..................................... 21
3.5. Extended-Type-Flagged-1 ............................. 21 3.4. Extended-Type-4 ..................................... 22
3.6. Extended-Type-Flagged-2 ............................. 23 3.5. Extended-Type-Flagged-1 ............................. 23
4. Vendor Specific Attributes ............................... 24 3.6. Extended-Type-Flagged-2 ............................. 24
4.1. Extended-Vendor-Specific-1 .......................... 24 4. Vendor Specific Attributes ............................... 25
4.2. Extended-Vendor-Specific-2 .......................... 25 4.1. Extended-Vendor-Specific-1 .......................... 26
4.3. Extended-Vendor-Specific-3 .......................... 26 4.2. Extended-Vendor-Specific-2 .......................... 27
4.4. Extended-Vendor-Specific-4 .......................... 28 4.3. Extended-Vendor-Specific-3 .......................... 28
4.5. Extended-Vendor-Specific-5 .......................... 29 4.4. Extended-Vendor-Specific-4 .......................... 29
4.6. Extended-Vendor-Specific-6 .......................... 30 4.5. Extended-Vendor-Specific-5 .......................... 31
5. Compatibility with traditional RADIUS .................... 32 4.6. Extended-Vendor-Specific-6 .......................... 32
5.1. Attribute Allocation ................................ 32 5. Compatibility with traditional RADIUS .................... 33
5.2. Proxy Servers ....................................... 33 5.1. Attribute Allocation ................................ 34
6. Guidelines ............................................... 34 5.2. Proxy Servers ....................................... 35
6.1. Updates to RFC 6158 ................................. 34 6. Guidelines ............................................... 35
6.2. Guidelines For the New Types ........................ 34 6.1. Updates to RFC 6158 ................................. 36
6.3. Allocation Request Guidelines ....................... 34 6.2. Guidelines for Simple Data Types .................... 36
6.4. TLV Guidelines ...................................... 35 6.3. Guidelines for Complex Data Types ................... 36
6.5. Implementation Guidelines ........................... 36 6.4. Guidelines For the New Types ........................ 37
6.6. Vendor Guidelines ................................... 36 6.5. Allocation Request Guidelines ....................... 38
7. Rationale ................................................ 36 6.6. TLV Guidelines ...................................... 39
7.1. Attribute Audit ..................................... 37 6.7. Implementation Guidelines ........................... 39
8. Examples ................................................. 37 6.8. Vendor Guidelines ................................... 40
8.1. Extended Type ....................................... 38 7. Rationale ................................................ 40
8.2. Extended Type with Flags ............................ 40 7.1. Attribute Audit ..................................... 40
9. IANA Considerations ...................................... 42 8. Examples ................................................. 41
9.1. Attribute Allocations ............................... 42 8.1. Extended Type ....................................... 42
9.2. RADIUS Attribute Type Tree .......................... 43 8.2. Extended Type with Flags ............................ 43
9.3. Allocation of TLV Data Types ........................ 44 9. IANA Considerations ...................................... 46
9.4. Allocation within a TLV ............................. 44 9.1. Attribute Allocations ............................... 46
9.5. Allocation of Extended Type with Flags format ....... 45 9.2. RADIUS Attribute Type Tree .......................... 47
9.6. Allocation of Other Data Types ...................... 45 9.3. Allocation Instructions ............................. 48
10. Security Considerations ................................. 45 9.3.1. Requested Allocation from the Standard Space ... 48
11. References .............................................. 45 9.3.2. Requested Allocation from the short extended spa 48
11.1. Normative references ............................... 46 9.3.3. Requested Allocation from the long extended spac 48
11.2. Informative references ............................. 46 9.3.4. Allocation Preferences ......................... 48
Appendix A - Extended Attribute Generator Program ............ 47 9.3.5. Extending the Type Space via TLV Data Type ..... 49
9.3.6. Allocation within a TLV ........................ 50
9.3.7. Allocation of Other Data Types ................. 50
10. Security Considerations ................................. 50
11. References .............................................. 50
11.1. Normative references ............................... 50
11.2. Informative references ............................. 51
Appendix A - Extended Attribute Generator Program ............ 52
1. Introduction 1. Introduction
Under current allocation pressure, we expect that the RADIUS Under current allocation pressure, we expect that the RADIUS
Attribute Type space will be exhausted by 2014 or 2015. We therefore Attribute Type space will be exhausted by 2014 or 2015. We therefore
need a way to extend the type space, so that new specifications may need a way to extend the type space, so that new specifications may
continue to be developed. Other issues have also been shown with continue to be developed. Other issues have also been shown with
RADIUS. The attribute grouping method defined in [RFC2868] has been RADIUS. The attribute grouping method defined in [RFC2868] has been
shown to be imnpractical, and a more powerful mechanism is needed. shown to be imnpractical, and a more powerful mechanism is needed.
Multiple attributes have been defined which transport more than the Multiple attributes have been defined which transport more than the
253 octets of data originally envisioned with the protocol. Each of 253 octets of data originally envisioned with the protocol. Each of
skipping to change at page 6, line 13 skipping to change at page 6, line 13
creates a standard way to group a set of Attributes. creates a standard way to group a set of Attributes.
* defining a new "extended Vendor-Specific" (EVS) data type. The * defining a new "extended Vendor-Specific" (EVS) data type. The
data type allows an attribute to carry Vendor-Specific Attributes data type allows an attribute to carry Vendor-Specific Attributes
(VSAs) inside of the new attribute formats. (VSAs) inside of the new attribute formats.
* defining a new "integer64" data type. The data type allows * defining a new "integer64" data type. The data type allows
counters which track more than 2^32 octets of data. counters which track more than 2^32 octets of data.
* allocating 6 attributes using the new EVS data type. This * allocating 6 attributes using the new EVS data type. This
allocation extends the Vendor-Specific Attribute type space by allocation extends the Vendor-Specific Attribute Type space by
over 1500 values. over 1500 values.
As with any protocol change, the changes defined here are the result As with any protocol change, the changes defined here are the result
of a series of compromises. We have tried to find a balance between of a series of compromises. We have tried to find a balance between
flexibility, space in the RADIUS message, compatibility with existing flexibility, space in the RADIUS message, compatibility with existing
deployments, and implementation difficulty. deployments, and implementation difficulty.
1.1. Terminology 1.1. Unmet Requirements
One requirement which was not met by the above modifications is to
have an incentive for standards to use the new space. We would
ideally like to deprecate the "Unassigned" attributes in the standard
space, which would permit allocation, but under more stringent
guidelines. However, [RFC5226] has no provisions for a "Deprecated"
entry in an IANA managed registry.
It is RECOMMENDED that implementations support this specification as
soon as possible. It is RECOMMENDED that new specifications use the
formats defined in this specification.
The alternative to the above recommendations is a circular argument
of not implementing this specification because no other standards
reference it, and also not defining new standards referencing this
specification because no implementations exist.
1.2. Terminology
This document uses the following terms: This document uses the following terms:
silently discard silently discard
This means the implementation discards the packet without further This means the implementation discards the packet without further
processing. The implementation MAY provide the capability of processing. The implementation MAY provide the capability of
logging the error, including the contents of the silently discarded logging the error, including the contents of the silently discarded
packet, and SHOULD record the event in a statistics counter. packet, and SHOULD record the event in a statistics counter.
invalid attribute invalid attribute
This means that the Length field of an Attribute is valid (as per This means that the Length field of an Attribute is valid (as per
[RFC2865], Section 5, top of page 25). However, the Value field of [RFC2865], Section 5, top of page 25). However, the Value field of
the attribute does not follow the format required by the data type the attribute does not follow the format required by the data type
defined for that Attribute. e.g. an Attribute of type "address" defined for that Attribute. e.g. an Attribute of type "address"
which encapsulates more than four, or less than four, octets of which encapsulates more than four, or less than four, octets of
data. data. See Section 2.7 for a more complete definition.
1.2. Requirements Language Standard space
Codes in the RADIUS Attribute Type Space that are allocated by IANA
and that follow the format defined in Section 5 of RFC 2865
[RFC2865].
Extended space
Codes in the RADIUS Attribute Type Space that require the
extensions defined in this document, and are an extension of the
standard space, but which cannot be represented within the standard
space.
Short extended space
Codes in the extended space which use the "Extended Type" format.
Long extended space
Codes in the extended space which use the "Extended Type with
Flags" format.
The following terms are used here with the meanings defined in BCP
26: "name space", "assigned value", "registration".
The following terms are used here with the meanings defined in BCP
26: "Private Use", "Reserved", "Unassigned".
The following policies are used here with the meanings defined in
BCP 26: "Private Use", "IETF Review", "Standards Action".
1.3. Requirements Language
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. The key words "MUST", "MUST NOT", "REQUIRED", of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in and "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
An implementation is not compliant if it fails to satisfy one or more An implementation is not compliant if it fails to satisfy one or more
of the must or must not requirements for the protocols it implements. of the must or must not requirements for the protocols it implements.
An implementation that satisfies all the MUST, MUST NOT, SHOULD, and An implementation that satisfies all the MUST, MUST NOT, SHOULD, and
SHOULD NOT requirements for its protocols is said to be SHOULD NOT requirements for its protocols is said to be
"unconditionally compliant"; one that satisfies all the MUST and MUST "unconditionally compliant"; one that satisfies all the MUST and MUST
NOT requirements but not all the SHOULD or SHOULD NOT requirements NOT requirements but not all the SHOULD or SHOULD NOT requirements
for its protocols is said to be "conditionally compliant". for its protocols is said to be "conditionally compliant".
2. Extensions to RADIUS 2. Extensions to RADIUS
This section defines two new attribute formats; "Extended Type"; and This section defines two new attribute formats; "Extended Type"; and
"Extended Type with Flags". The formats are defined below. "Extended Type with Flags". It defines a new Type-Length-Value (TLV)
data type, an Extended-Vendor-Specific (EVS) data type, and an
Integer64 data type. It defines a new method for naming attributes
and identifying Attributes using the new attribute formats. It
finally defines the new term "invalid attribute", and describes how
it affects implementations.
2.1. Extended Type 2.1. Extended Type
This section defines a new attribute format, called "Extended Type". This section defines a new attribute format, called "Extended Type".
A summary of the Attribute format is shown below. The fields are A summary of the Attribute format is shown below. The fields are
transmitted from left to right. transmitted from left to right.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 33 skipping to change at page 9, line 38
This field is identical to the Type field of the Attribute format This field is identical to the Type field of the Attribute format
defined in [RFC2865] Section 5. defined in [RFC2865] Section 5.
Length Length
This field is identical to the Length field of the Attribute This field is identical to the Length field of the Attribute
format defined in [RFC2865] Section 5. Permitted values are format defined in [RFC2865] Section 5. Permitted values are
between 4 and 255. If a client or server receives an Extended between 4 and 255. If a client or server receives an Extended
Attribute with a Length of 2 or 3, then that Attribute MUST be Attribute with a Length of 2 or 3, then that Attribute MUST be
deemed to be an "invalid attribute", it SHOULD be silently deemed to be an "invalid attribute", and handled as per Section
discarded. If it is not discarded, it MUST NOT be handled in the XXX, below.
same manner as a well-formed attribute.
Note that an "invalid attribute" does not cause the entire packet
to be discarded, or to be treated as a negative acknowledgement.
Instead, only the "invalid attribute" is discarded.
Extended-Type Extended-Type
The Extended-Type field is one octet. Up-to-date values of this The Extended-Type field is one octet. Up-to-date values of this
field are specified by IANA. Unlike the Type field defined in field are specified by IANA. Unlike the Type field defined in
[RFC2865] Section 5, no values are allocated for experimental or [RFC2865] Section 5, no values are allocated for experimental or
implementation-specific use. Values 241-255 are reserved and implementation-specific use. Values 241-255 are reserved and
SHOULD NOT be used. SHOULD NOT be used.
The Extended-Type is meaningful only within a context defined by The Extended-Type is meaningful only within a context defined by
skipping to change at page 10, line 5 skipping to change at page 11, line 5
This field is identical to the Type field of the Attribute format This field is identical to the Type field of the Attribute format
defined in [RFC2865] Section 5. defined in [RFC2865] Section 5.
Length Length
This field is identical to the Length field of the Attribute This field is identical to the Length field of the Attribute
format defined in [RFC2865] Section 5. Permitted values are format defined in [RFC2865] Section 5. Permitted values are
between 5 and 255. If a client or server receives an "Extended between 5 and 255. If a client or server receives an "Extended
Attribute with Flags" with a Length of 2, 3, or 4, then that Attribute with Flags" with a Length of 2, 3, or 4, then that
Attribute MUST be deemed to be an "invalid attribute", it SHOULD Attribute MUST be deemed to be an "invalid attribute", and be
be silently discarded. If it is not discarded, it MUST NOT be handled as per Section 2.7, below.
handled in the same manner as a well-formed attribute.
Note that an "invalid attribute" does not cause the entire packet
to be discarded, or to be treated as a negative acknowledgement.
Instead, only the "invalid attribute" is discarded.
Extended-Type Extended-Type
This field is identical to the Extended-Type field defined above This field is identical to the Extended-Type field defined above
in Section 2.1. in Section 2.1.
M (More) M (More)
The More Flag is one (1) bit in length, and indicates whether or The More Flag is one (1) bit in length, and indicates whether or
not the current attribute contains "more" than 251 octets of data. not the current attribute contains "more" than 251 octets of data.
skipping to change at page 10, line 42 skipping to change at page 11, line 37
of the same value MUST be in order and MUST be consecutive of the same value MUST be in order and MUST be consecutive
attributes in the packet, and the last attribute in a packet MUST attributes in the packet, and the last attribute in a packet MUST
NOT have the More flag set (1). NOT have the More flag set (1).
When the Length field of an attribute has value less than 255, the When the Length field of an attribute has value less than 255, the
More flag SHOULD be clear (0). More flag SHOULD be clear (0).
If a client or server receives an attribute fragment with the If a client or server receives an attribute fragment with the
"More" flag set (1), but for which no subsequent fragment can be "More" flag set (1), but for which no subsequent fragment can be
found, then the fragmented attribute is deemed to be an "invalid found, then the fragmented attribute is deemed to be an "invalid
attribute" and the entire set of fragments SHOULD be silently attribute", and handled as per Section 2.7, below.
discarded. If the fragmented attribute is not discarded, it MUST
NOT be handled in the same manner as a well-formed attribute.
Flags Flags
This field is 7 bits long, and is reserved for future use. This field is 7 bits long, and is reserved for future use.
Implementations MUST set it to zero (0) when encoding an attribute Implementations MUST set it to zero (0) when encoding an attribute
for sending in a packet. The contents SHOULD be ignored on for sending in a packet. The contents SHOULD be ignored on
reception. reception.
Value Future specifications may define additional meaning for this
field. Implementations therefore MUST NOT treat this field as
invalid if it is non-zero.
Value
This field is similar to the Value field of the Attribute format This field is similar to the Value field of the Attribute format
defined in [RFC2865] Section 5. It may contain a complete set of defined in [RFC2865] Section 5. It may contain a complete set of
data (when the Length field has value less than 255), or it may data (when the Length field has value less than 255), or it may
contain a fragment of data (when the More field is set). contain a fragment of data (when the More field is set).
Any interpretation of the resulting data MUST occur after the Any interpretation of the resulting data MUST occur after the
fragments have been reassembled. The length of the data MUST be fragments have been reassembled. The length of the data MUST be
taken as the sum of the lengths of the fragments (i.e. Value taken as the sum of the lengths of the fragments (i.e. Value
fields) from which it is constructed. The format of the data fields) from which it is constructed. The format of the data
SHOULD be a valid RADIUS data type. SHOULD be a valid RADIUS data type.
skipping to change at page 11, line 46 skipping to change at page 12, line 43
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV-Type | TLV-Length | TLV-Value ... | TLV-Type | TLV-Length | TLV-Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV-Type TLV-Type
The Type field is one octet. Up-to-date values of this field are The Type field is one octet. Up-to-date values of this field are
specified by IANA. Values of zero (0) MUST NOT be used. Values specified by IANA. Values of zero (0) MUST NOT be used. Values
254-255 are "Reserved" for use by future extensions to RADIUS. 254-255 are "Reserved" for use by future extensions to RADIUS.
The value 26 has no special meaning. The value 26 has no special meaning, and MUST NOT be treated as a
Vendor Specific attribute.
As with Extended-Type above, the TLV-Type is meaningful only As with Extended-Type above, the TLV-Type is meaningful only
within a context defined by "Type" fields of the encapsulating within the context defined by "Type" fields of the encapsulating
Attributes. That is, the field may be thought of as defining a Attributes. That is, the field may be thought of as defining a
new type space of the form "Type.Extended-Type.TLV-Type". Where new type space of the form "Type.Extended-Type.TLV-Type". Where
TLVs are nested, the type space is of the form "Type.Extended- TLVs are nested, the type space is of the form "Type.Extended-
Type.TLV-Type.TLV-Type", etc. Type.TLV-Type.TLV-Type", etc.
A RADIUS server MAY ignore Attributes with an unknown "TLV-Type". A RADIUS server MAY ignore Attributes with an unknown "TLV-Type".
A RADIUS client MAY ignore Attributes with an unknown "TLV-Type". A RADIUS client MAY ignore Attributes with an unknown "TLV-Type".
A RADIUS proxy SHOULD forward Attributes with an unknown "TLV-
Type" verbatim.
TLV-Length TLV-Length
The TLV-Length field is one octet, and indicates the length of The TLV-Length field is one octet, and indicates the length of
this TLV including the TLV-Type, TLV-Length and TLV-Value fields. this TLV including the TLV-Type, TLV-Length and TLV-Value fields.
It MUST have a value between 3 and 255. If a client or server It MUST have a value between 3 and 255. If a client or server
receives a TLV with an invalid TLV-Length, then the attribute receives a TLV with an invalid TLV-Length, then the attribute
which encapsulates that TLV MUST be deemed to be an "invalid which encapsulates that TLV MUST be deemed to be an "invalid
attribute", it SHOULD be silently discarded. If the encapsulating attribute", and handled as per Section 2.7, below.
attribute is not discarded, it MUST NOT be handled in the same
manner as a well-formed attribute.
Note that an "invalid attribute" does not cause the entire packet
to be discarded, or to be treated as a negative acknowledgement.
Instead, only the "invalid attribute" is discarded.
TLV-Value TLV-Value
The Value field is one or more octets and contains information The Value field is one or more octets and contains information
specific to the Attribute. The format and length of the TLV-Value specific to the Attribute. The format and length of the TLV-Value
field is determined by the TLV-Type and TLV-Length fields. field is determined by the TLV-Type and TLV-Length fields.
The TLV-Value field SHOULD encapsulate a previously defined RADIUS The TLV-Value field SHOULD encapsulate a previously defined RADIUS
data type. Using non-standard data types is NOT RECOMMENDED. We data type. Using non-standard data types is NOT RECOMMENDED. We
note that the TLV-Value field MAY also contain one or more note that the TLV-Value field MAY also contain one or more
skipping to change at page 13, line 17 skipping to change at page 14, line 12
Attribute. We RECOMMEND using type "tlv" for VSAs, in preference to Attribute. We RECOMMEND using type "tlv" for VSAs, in preference to
any other format. any other format.
2.3.1. TLV Nesting 2.3.1. TLV Nesting
TLVs may contain other TLVs. When this occurs, the "container" TLV TLVs may contain other TLVs. When this occurs, the "container" TLV
MUST be completely filled by the "contained" TLVs. That is, the MUST be completely filled by the "contained" TLVs. That is, the
"container" TLV-Length field MUST be exactly two (2) more than the "container" TLV-Length field MUST be exactly two (2) more than the
sum of the "contained" TLV-Length fields. If the "contained" TLVs sum of the "contained" TLV-Length fields. If the "contained" TLVs
over-fill the "container" TLV, the "container" TLV MUST be considered over-fill the "container" TLV, the "container" TLV MUST be considered
to be an "invalid attribute", and handled as described above. to be an "invalid attribute", and handled as described in Section
XXX, below.
The depth of TLV nesting is limited only by the restrictions on the The depth of TLV nesting is limited only by the restrictions on the
TLV-Length field. The limit of 253 octets of data results in a limit TLV-Length field. The limit of 253 octets of data results in a limit
of 126 levels of nesting. However, nesting depths of more than 4 are of 126 levels of nesting. However, nesting depths of more than 4 are
NOT RECOMMENDED. NOT RECOMMENDED.
2.4. EVS Data Type 2.4. EVS Data Type
We define a new data type in RADIUS, called "evs", for "Extended We define a new data type in RADIUS, called "evs", for "Extended
Vendor-Specific". The "evs" data type is an encapsulation layer Vendor-Specific". The "evs" data type is an encapsulation layer
skipping to change at page 14, line 31 skipping to change at page 15, line 26
The Vendor-Type field is one octet. Values are assigned at the The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the Vendor. sole discretion of the Vendor.
Value Value
The Value field is one or more octets. It SHOULD encapsulate a The Value field is one or more octets. It SHOULD encapsulate a
previously defined RADIUS data type. Using non-standard data previously defined RADIUS data type. Using non-standard data
types is NOT RECOMMENDED. We note that the Value field may be of types is NOT RECOMMENDED. We note that the Value field may be of
data type "tlv". However, it MUST NOT be of data type "evs", as data type "tlv". However, it MUST NOT be of data type "evs", as
the use cases are unclear for one vendor delegating attribute type the use cases are unclear for one vendor delegating Attribute Type
space to another vendor. space to another vendor.
The actual format of the information is site or application The actual format of the information is site or application
specific, and a robust implementation SHOULD support the field as specific, and a robust implementation SHOULD support the field as
undistinguished octets. We recognise that Vendors have complete undistinguished octets. We recognise that Vendors have complete
control over the contents and format of the Value field, while at control over the contents and format of the Value field, while at
the same time recommending that good practices be followed. the same time recommending that good practices be followed.
Further codification of the range of allowed usage of this field Further codification of the range of allowed usage of this field
is outside the scope of this specification. is outside the scope of this specification.
skipping to change at page 17, line 39 skipping to change at page 18, line 34
26. It in turn carries a 24-bit Vendor-Id, and possibly additional 26. It in turn carries a 24-bit Vendor-Id, and possibly additional
VSAs. Where the VSAs follow the [RFC2865] Section 5.26 recommended VSAs. Where the VSAs follow the [RFC2865] Section 5.26 recommended
format, a VSA can be identified as "26.Vendor-Id"."Vendor-Type". format, a VSA can be identified as "26.Vendor-Id"."Vendor-Type".
For example, Livingston has Vendor-Id 307, and has defined an For example, Livingston has Vendor-Id 307, and has defined an
attribute "IP-Pool" as number 6. This VSA can be uniquely identified attribute "IP-Pool" as number 6. This VSA can be uniquely identified
as 26.307.6. as 26.307.6.
Note that there is no restriction on the size of the numerical values Note that there is no restriction on the size of the numerical values
in this notation. The Vendor-Id is a 24-bit number, and the VSA may in this notation. The Vendor-Id is a 24-bit number, and the VSA may
have been assigned from a 16-bit vendor-specific Attribute type have been assigned from a 16-bit vendor-specific Attribute Type
space. space.
For example, the company USR has been allocated Vendor-Id 429, and For example, the company USR has been allocated Vendor-Id 429, and
has defined a "Version-Id" attribute as number 32768. This VSA can has defined a "Version-Id" attribute as number 32768. This VSA can
be uniquely identified as 26.429.32768. be uniquely identified as 26.429.32768.
Where a VSA is a TLV, the "dotted number" notation can be used as Where a VSA is a TLV, the "dotted number" notation can be used as
above: 26.VID.VSA.TLV1.TLV2.TLV3 where "TLVn" are the numerical above: 26.VID.VSA.TLV1.TLV2.TLV3 where "TLVn" are the numerical
values assigned by the vendor to the different nested TLVs. values assigned by the vendor to the different nested TLVs.
2.7. Invalid Attributes
The term "invalid attribute" is new to this specification. It is
defined to mean that the Length field of an Attribute is valid (as
per [RFC2865], Section 5, top of page 25). However, the Value field
of the attribute does not follow the format required by the data type
defined for that Attribute. e.g. an Attribute of data type "address"
which encapsulates more than four, or less than four, octets of data.
Or, an IPV6 Prefix attribute which has a Prefix value of more than
128.
While the content of these attributes is malformed, we emphasize that
the encapsulating RADIUS packet (or TLV) is well formed, and can be
correctly decoded. The existence of an "invalid attribute" in a
packet MUST NOT result in the implementation discarding the entire
packet, or treating the packet as a negative acknowledgement.
Instead, only the "invalid attribute" is treated differently.
When an implementation receives an "invalid attribute", it SHOULD be
silently discarded. If it is not discarded, it MUST NOT be handled
in the same manner as a well-formed attribute. For example,
receiving an Attribute of data type "address" containing more than
four, or less than four octets of data means that the Attribute MUST
NOT be treated as being of data type "address".
For Attributes of type "Extended Type with Flags", an Attribute is
deemed to be an "invalid attribute" when does not match the criteria
set out in Section 2.2, above.
For Attributes of type "TLV", an Attribute is deemed to be an
"invalid attribute" when the TLV-Length field is valid, but the TLV-
Value field does not match the criteria for that Attribute.
Implementations SHOULD NOT treat the "invalid attribute" property as
being transitive. That is, the encapsulating Attribute SHOULD NOT be
treated as being an "invalid attribute" if it encapsulates an
"invalid attribute".
3. Attribute Definitions 3. Attribute Definitions
We define four (4) attributes of "Extended Type", which are allocated We define four (4) attributes of "Extended Type", which are allocated
from the "Reserved" Attribute Type codes of 241, 242, 243, and 244. from the "Reserved" Attribute Type codes of 241, 242, 243, and 244.
We also define two (2) attributes of "Extended Type with Flags", We also define two (2) attributes of "Extended Type with Flags",
which are allocated from the "Reserved" Attribute Type codes of 245 which are allocated from the "Reserved" Attribute Type codes of 245
and 246. and 246.
Type Name Type Name
---- ---- ---- ----
skipping to change at page 34, line 9 skipping to change at page 36, line 4
246) define them as being of data type "string", and delete all other 246) define them as being of data type "string", and delete all other
local definitions for those attributes. local definitions for those attributes.
This last change should enable wider usage of the Extended Attributes This last change should enable wider usage of the Extended Attributes
format. format.
6. Guidelines 6. Guidelines
This specification proposes a number of changes to RADIUS, and This specification proposes a number of changes to RADIUS, and
therefore requires a set of guidelines, as has been done in therefore requires a set of guidelines, as has been done in
[RFC6158]. [RFC6158].
6.1. Updates to RFC 6158 6.1. Updates to RFC 6158
This specification updates [RFC6158] by adding the data types "evs", This specification updates [RFC6158] by adding the data types "evs",
"tlv" and "integer64"; defining them to be "basic" data types; and "tlv" and "integer64"; defining them to be "basic" data types; and
permitting their use subject to the restrictions outlined below. permitting their use subject to the restrictions outlined below.
All other recommendations given in [RFC6158] are unchanged. New The recommendations for the use of the new data types and attribute
recommendations for the use of the new data types and attribute formats are given below. All other recommendations given in
formats are given below. [RFC6158] are unchanged.
6.2. Guidelines For the New Types 6.2. Guidelines for Simple Data Types
[RFC6158] Section A.2.1 says in part:
* Unsigned integers of size other than 32 bits.
SHOULD be replaced by an unsigned integer of 32 bits. There is
insufficient justification to define a new size of integer.
We update that specification to permit unsigned integers of 64 bits,
for the reasons defined above in Section 2.5. The updated text is as
follows:
* Unsigned integers of size other than 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 integer.
That section later continues with the following list item:
* Nested attribute-value pairs (AVPs).
Attributes should be defined in a flat typespace.
We update that specification to permit nested TLVs, as defined in
this document:
* Nested attribute-value pairs (AVPs) using the extended
attribute format MAY be used. All other nested AVP or TLV
formats MUST NOT be used.
6.3. Guidelines for Complex Data Types
[RFC6158] Section 2.1 says:
Complex data types MAY be used in situations where they reduce
complexity in non-RADIUS systems or where using the basic data
types
would be awkward (such as where grouping would be required in
order
to link related attributes).
Since the extended attribute format allows for grouping of complex
types via TLVs, the guidelines for complex data types need to be
updated as follows:
Complex data types MAY be used where they reduce complexity in
non-RADIUS systems, though this practice is NOT RECOMMENDED. The
complex data type exceptions of [RFC6158] Section 3.2.4 still
apply. In all other situations, complex data types MUST NOT be
used. Instead, complex data types MUST be decomposed into TLVs,
using the extended attribute format.
The checklist in Appendix A.2.2 is similarly updated to add a new
requirement at the top of that section,
Does the attribute:
* define a complex type which can be represented via TLVs?
If so, this data type MUST be represented via TLVs.
Note that this requirement does not over-ride Section A.1, which
permits the transport of complex types in certain situations.
6.4. Guidelines For the New Types
We recommend the following guidelines when designing attributes using We recommend the following guidelines when designing attributes using
the new format. The items listed below are not exhaustive. As the new format. The items listed below are not exhaustive. As
experience is gained with the new formats, later specifications may experience is gained with the new formats, later specifications may
define additional guidelines. define additional guidelines.
* The data type "evs" MUST NOT be used for standard RADIUS * The data type "evs" MUST NOT be used for standard RADIUS
Attributes, or for TLVs, or for VSAs. Attributes, or for TLVs, or for VSAs.
* The data type "tlv" SHOULD NOT be used for standard RADIUS * The data type "tlv" SHOULD NOT be used for standard RADIUS
skipping to change at page 34, line 44 skipping to change at page 38, line 9
attributes using the Extended-Type format. attributes using the Extended-Type format.
* [RFC2866] "tagged" attributes MUST NOT be defined in the * [RFC2866] "tagged" attributes MUST NOT be defined in the
Extended-Type space. The "tlv" data type should be used instead to Extended-Type space. The "tlv" data type should be used instead to
group attributes. group attributes.
* The "integer64" data type MAY be used in any RADIUS attribute. * The "integer64" data type MAY be used in any RADIUS attribute.
The use of 64-bit integers is NOT RECOMMENDED by [RFC6158], but The use of 64-bit integers is NOT RECOMMENDED by [RFC6158], but
their utility is now evident. their utility is now evident.
* Any attribute which is allocated from the Type spaces of 245.* or
246.*, of data type "text", "string", or "tlv" can end up carrying
more than 251 octets of data, up to the maximum RADIUS packet
length (~4096 octets). Specifications defining such attributes
SHOULD define a maximum length.
* For all other circumstances, the guidelines in [RFC6158] MUST * For all other circumstances, the guidelines in [RFC6158] MUST
be followed. be followed.
6.3. Allocation Request Guidelines 6.5. Allocation Request Guidelines
The following items give guidelines for allocation requests made in a The following items give guidelines for allocation requests made in a
RADIUS specification. RADIUS specification.
* Discretion is RECOMMENDED when requesting allocation of attributes. * Discretion is RECOMMENDED when requesting allocation of attributes.
The new space is much larger than the old one, but it is not The new space is much larger than the old one, but it is not
infinite. infinite.
* When the Type spaces of 241.*, 242.*, 243.*, or 244.* are nearing * Specifications which request ten (10) or more attributes MUST
exhaustion, a new specification SHOULD be written which requests NOT request that all be allocated from the standard space.
allocation of one or more RADIUS Attributes from the "Reserved" That space is under allocation pressure, and the extended space
space, using the "Extended Type" format. This process is is more suitable for large allocations.
preferable to allocating "small" attributes from the 256.* and
246.* Type spaces.
* When the Type spaces of 245.* or 246.* are nearing exhaustion, a * New specifications SHOULD NOT request allocation from the standard
new specification SHOULD be written which requests allocation of Attribute Type Space (i.e. Attributes 1 through 255). That space
one or more RADIUS Attributes from the "Reserved" space, using the is deprecated.
"Extended Type with flags" format.
* All other specifications SHOULD NOT request allocation from the * It is RECOMMENDED that specifications do not request allocation
standard Attribute Type Space (i.e. Attributes 1 through 255). from a specific space. The IANA considerations given in
That space is deprecated, and is not to be used. Section 9, below, should be sufficient for attribute allocation.
* Attributes which encode 252 octets or less of data SHOULD * Specifications of an ttribute which encodes 252 octets or less
request allocation from the Type spaces of 241.*, 242.*, 243.*, of data MAY request allocation from the exended space, using
or 244.*. format "Extended Type"
* Attributes which encode 253 octets or more of data MUST request * Specifications of an attribute which can always encode less than
allocation from the Type spaces of 245.* or 246.*. 253 octets of data MUST NOT request allocation from the long
extended space. The standard space, or the short extended space
MUST be used instead.
6.4. TLV Guidelines * Specifications of an attribute which encodes 253 octets or more of
data MUST request allocation from the long extended space.
* When the extended space is nearing exhaustion, a new specification
SHOULD be written which requests allocation of one or more RADIUS
Attributes from the "Reserved" portion of the standard space,
values 247-255, using an appropriate format ("Extended Type", or
"Extended Type with Flags")
6.6. TLV Guidelines
The following items give guidelines for specifications using TLVs. The following items give guidelines for specifications using TLVs.
* when multiple attributes are intended to be grouped or managed * when multiple attributes are intended to be grouped or managed
together, the use of TLVs to group related attributes is together, the use of TLVs to group related attributes is
RECOMMENDED. RECOMMENDED.
* more than 4 layers (depth) of TLV nesting is NOT RECOMMENDED. * more than 4 layers (depth) of TLV nesting is NOT RECOMMENDED.
* Interpretation of an attribute depends only on its type * Interpretation of an attribute depends only on its type
definition (e.g. Type.Extended-Type.TLV-Type, etc.), and definition (e.g. Type.Extended-Type.TLV-Type), and
not on its encoding or location in the RADIUS packet. not on its encoding or location in the RADIUS packet.
* Where a group of TLVs is strictly defined, and not expected to * Where a group of TLVs is strictly defined, and not expected to
change, and and totals less than 247 octets of data, they SHOULD change, and and totals less than 247 octets of data, they SHOULD
request allocation from the Type spaces of 241.*, 242.*, 243.*, or request allocation from the Type spaces of 241.*, 242.*, 243.*, or
244.*. 244.*.
* Where a group of TLVs is loosely defined, or is expected to change, * Where a group of TLVs is loosely defined, or is expected to change,
they SHOULD request allocation from the Type spaces of 245.* or they SHOULD request allocation from the Type spaces of 245.* or
246.*. 246.*.
6.5. Implementation Guidelines 6.7. Implementation Guidelines
* RADIUS client implementations SHOULD support this specification * RADIUS client implementations SHOULD support this specification
as soon as possible. as soon as possible.
* RADIUS server implementations SHOULD support this specification * RADIUS server implementations SHOULD support this specification
as soon as possible. as soon as possible.
* RADIUS proxy servers SHOULD forward all attributes, even ones * RADIUS proxy servers SHOULD forward all attributes, even ones
which they do not understand, or which are not in a local which they do not understand, or which are not in a local
dictionary. These attributes SHOULD be forwarded verbatim, with dictionary. These attributes SHOULD be forwarded verbatim, with
no modifications or changes. no modifications or changes.
* Any attribute which is allocated from the Type spaces of 245.* or * When forwarding attributes, RADIUS proxy servers SHOULD forward
246.*, of data type "text", "string", or "tlv" can end up carrying the "Flag" field unchanged. That is, they SHOULD NOT assume that
more than 251 octets of data, up to the maximum RADIUS packet the "Flag" field is always set to zero on transmission.
length (~4096 octets). Specifications defining such attributes
SHOULD define a maximum length.
6.6. Vendor Guidelines 6.8. Vendor Guidelines
* Vendors SHOULD use the existing Vendor-Specific Attribute Type * Vendors SHOULD use the existing Vendor-Specific Attribute Type
space in preference to the new Extended-Vendor-Specific space in preference to the new Extended-Vendor-Specific
attributes, as this specification may take time to become widely attributes, as this specification may take time to become widely
deployed. deployed.
* Vendors SHOULD implement this specification as soon as * Vendors SHOULD implement this specification as soon as
possible. The changes to RADIUS are relatively small, and are possible. The changes to RADIUS are relatively small, and are
likely to quickly be used in new specifications. likely to quickly be used in new specifications.
skipping to change at page 37, line 29 skipping to change at page 41, line 7
35 IPv6 Address 35 IPv6 Address
18 date 18 date
10 integer64 10 integer64
4 Interface Id 4 Interface Id
3 IPv6 Prefix 3 IPv6 Prefix
4683 Total 4683 Total
The entries in the "Data Type" column are data types recommended by The entries in the "Data Type" column are data types recommended by
[RFC6158], along with "integer64". The "other data types" row [RFC6158], along with "integer64". The "other data types" row
encompasses other data types. encompasses all other data types, including complex data types and
data types transporting opaque data.
We see that over half of the attributes encode less than 16 octets of
data. It is therefore important to have an extension mechanism which
adds as little as possible to the size of these attributes. Another
result is that the overwhelming majority of attributes use simple
data types.
Of the attributes defined above, 177 were declared as being inside of
a TLV. This is approximately 4% of the total. We did not
investigate whether additional attributes were defined in a flat name
space, but could have been defined as being inside of a TLV. We
expect that the number could be as high as 10% of attributes.
Manual inspection of the dictionaries shows that approximately 20 (or Manual inspection of the dictionaries shows that approximately 20 (or
0.5%) attributes have the ability to transport more than 253 octets 0.5%) attributes have the ability to transport more than 253 octets
of data. These attributes are divided between VSAs, and a small of data. These attributes are divided between VSAs, and a small
number of standard Attributes. While the "Extended Type with Flags" number of standard Attributes such as EAP-Message.
format is therefore important, "long" attributes have had limited
deployment The results of this audit and analysis is reflected in the design of
the extended attributes. The extended format has minimal overhead,
it permits TLVs, and it has support for "long" attributes.
8. Examples 8. Examples
A few examples are presented here, in order to illustrate the A few examples are presented here in order to illustrate the encoding
encoding of the new attribute formats. These examples are not of the new attribute formats. These examples are not intended to be
intended to be exhaustive, as many others are possible. For exhaustive, as many others are possible. For simplicity, we do not
simplicity, we do not show complete packets, only attributes. show complete packets, only attributes.
The examples are given using a domain-specific language implemented The examples are given using a domain-specific language implemented
by the program given in Appendix A. The language is line oriented, by the program given in Appendix A. The language is line oriented,
and composed of a sequence of lines matching the grammar ([RFC5234]) and composed of a sequence of lines matching the grammar ([RFC5234])
given below: given below:
Identifier = 1*DIGIT *( "." 1*DIGIT ) Identifier = 1*DIGIT *( "." 1*DIGIT )
HEXCHAR = HEXDIG HEXDIG HEXCHAR = HEXDIG HEXDIG
STRING = DQUOTE 1*CHAR DQUOTE STRING = DQUOTE 1*CHAR DQUOTE
TLV = "{" 1*DIGIT DATA "}" TLV = "{" 1*DIGIT DATA "}"
DATA = 1*HEXCHAR / 1*TLV / STRING DATA = 1*HEXCHAR / 1*TLV / STRING
LINE = Identifier DATA LINE = Identifier DATA
The progam has additional restrictions on its input that are not The progam has additional restrictions on its input that are not
reflected in the above grammar. For example, the portions of the reflected in the above grammar. For example, the portions of the
Identifier which refer to Type and Extended-Type are limited to Identifier which refer to Type and Extended-Type are limited to
values between 1 and 255. We trust that the source code in Appendix values between 1 and 255. We trust that the source code in Appendix
A is clear, and that these restrictions do not negatively affect the A is clear, and that these restrictions do not negatively affect the
comprehensability of the examples. comprehensability of the examples.
The program reads the input text, and interprets it as a set of The program reads the input text, and interprets it as a set of
skipping to change at page 38, line 25 skipping to change at page 42, line 19
values between 1 and 255. We trust that the source code in Appendix values between 1 and 255. We trust that the source code in Appendix
A is clear, and that these restrictions do not negatively affect the A is clear, and that these restrictions do not negatively affect the
comprehensability of the examples. comprehensability of the examples.
The program reads the input text, and interprets it as a set of The program reads the input text, and interprets it as a set of
instructions to create RADIUS Attributes. It then prints the hex instructions to create RADIUS Attributes. It then prints the hex
encoding of those attributes. It implements the minimum set of encoding of those attributes. It implements the minimum set of
functionality which achieves that goal. This minimalism means that functionality which achieves that goal. This minimalism means that
it does not use attribute dictionaries; it does not implement support it does not use attribute dictionaries; it does not implement support
for RADIUS data types; it can be used to encode attributes with for RADIUS data types; it can be used to encode attributes with
invalid data field(s); and there is no requirement for consistency invalid data fields; and there is no requirement for consistency from
from one example to the next. For example, it can be used to encode one example to the next. For example, it can be used to encode a
a User-Name attribute which contains non-UTF8 data, or a Framed-IP- User-Name attribute which contains non-UTF8 data, or a Framed-IP-
Address which contains 253 octets of ASCII data. As a result, it Address which contains 253 octets of ASCII data. As a result, it
MUST NOT be used to create RADIUS Attributes for transport in a MUST NOT be used to create RADIUS Attributes for transport in a
RADIUS message. RADIUS message.
However, the program correctly encodes the RADIUS attribute fields of However, the program correctly encodes the RADIUS attribute fields of
"Type", "Length", "Extended-Type", "More", "Flags", "Vendor-Id", "Type", "Length", "Extended-Type", "More", "Flags", "Vendor-Id",
"Vendor-Type", and "Vendor-Length". It can therefore be used to "Vendor-Type", and "Vendor-Length". It encodes RADIUS attribute data
encode example attributes from input which is humanly readable. types "evs" and TLV. It can therefore be used to encode example
attributes from inputs which are humanly readable.
We do not give examples of "malformed" or "invalid attributes". We We do not give examples of "malformed" or "invalid attributes". We
also note that the examples show format, and not consistent meaning. also note that the examples show format, rather than consistent
A particular attribute type code may be used to demonstrate two meaning. A particular Attribute Type code may be used to demonstrate
different formats. In real specifications, attributes have a static two different formats. In real specifications, attributes have a
definitions based on their type code. static definitions based on their type code.
The examples given below are strictly for demonstration purposes The examples given below are strictly for demonstration purposes
only, and do not provide a standard of any kind. only, and do not provide a standard of any kind.
8.1. Extended Type 8.1. Extended Type
The following are a series of examples of the "Extended Type" format. The following are a series of examples of the "Extended Type" format.
Attribute encapsulating textual data. Attribute encapsulating textual data.
skipping to change at page 42, line 30 skipping to change at page 46, line 23
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 17 1a 00 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 17 1a 00 bb
bb bb bb bb cc cc cc cc cc cc cc cc cc cc 13 45 67 89 bb bb bb bb cc cc cc cc cc cc cc cc cc cc 13 45 67 89
9. IANA Considerations 9. IANA Considerations
This document updates [RFC3575] in that it adds new IANA This document updates [RFC3575] in that it adds new IANA
considerations for RADIUS Attributes. These considerations extend considerations for RADIUS Attributes. These considerations modify
the IANA considerations for RADIUS, rather than replacing them. and extend the IANA considerations for RADIUS, rather than replacing
Specifically, assignment of Attribute Type values 241-255 requires them.
Standards Action, and allocation of values for existing attributes is
done by the process given in [RFC3575].
The IANA considerations of this document are limited to the "RADIUS The IANA considerations of this document are limited to the "RADIUS
Attribute Types" registry. Attribute Type values which were Attribute Types" registry. Some Attribute Type values which were
previously marked reserved are now allocated, Attribute Type values previously marked "Reserved" are now allocated, and the registry is
previously marked unassigned are now deprecated, and the registry is
extended from a simple 8-bit array to a tree-like structure, up to a extended from a simple 8-bit array to a tree-like structure, up to a
maximum depth of 125 nodes. Detailed recommendations are given maximum depth of 125 nodes. Detailed instructions are given below.
below.
9.1. Attribute Allocations 9.1. Attribute Allocations
IANA is requested to move the "Unassigned" values in the range IANA is requested to move the following Attribute Type values from
144-191 from "Unassigned" to "Deprecated". Allocation from the "Reserved", to "Allocated", with the corresponding names:
"Deprecated" space can still be performed by publication of an IETF
specification, subject to the recommendations of {RFC3575], and where
that specification requests allocation from the "Deprecated" space,
and also gives reasons why use of the Extended Type space is
impossible.
IANA is requested to move the following values from "Reserved", to
"Allocated", with the following names:
* 241 Extended-Type-1 * 241 Extended-Type-1
* 242 Extended-Type-2 * 242 Extended-Type-2
* 243 Extended-Type-3 * 243 Extended-Type-3
* 244 Extended-Type-4 * 244 Extended-Type-4
* 245 Extended-Type-Flagged-1 * 245 Extended-Type-Flagged-1
* 246 Extended-Type-Flagged-2 * 246 Extended-Type-Flagged-2
These values serve as an encapsulation layer for the new RADIUS These values serve as an encapsulation layer for the new RADIUS
Attribute Type tree. Attribute Type tree.
9.2. RADIUS Attribute Type Tree 9.2. RADIUS Attribute Type Tree
Each of the Attribute Type values allocated above extends the "RADIUS Each of the Attribute Type values allocated above extends the "RADIUS
Attribute Types" to an N-ary tree, via a "dotted number" notation. Attribute Types" to an N-ary tree, via a "dotted number" notation.
Allocation of an Attribute Type value "VALUE" using the new Extended Allocation of an Attribute Type value "TYPE" using the new Extended
type format results in allocation of 255 new Attribute Type values, type format results in allocation of 255 new Attribute Type values,
of format "VALUE.1" through "VALUE.255". The value zero "VALUE.0" is of format "TYPE.1" through "TYPE.255". The value zero "TYPE.0" is not
not used. Value twenty-six (26) is assigned as "Vendor Specific". used. Value twenty-six (26) is assigned as "Extended-Vendor-
Values 241-255 are marked "Reserved". All other values are Specific-*". Values "TYPE.241" through "TYPE.255" are marked
"Unassigned". "Reserved". All other values are "Unassigned".
The initial set of Attribute Type values and names assigned by this The initial set of Attribute Type values and names assigned by this
document is given below. document is given below.
* 241 Extended-Attribute-1 * 241 Extended-Attribute-1
* 241.{1-25} Unassigned * 241.{1-25} Unassigned
* 241.26 Extended-Vendor-Specific-1 * 241.26 Extended-Vendor-Specific-1
* 241.{27-240} Unassigned * 241.{27-240} Unassigned
* 241.{241-255} Reserved * 241.{241-255} Reserved
* 242 Extended-Attribute-2 * 242 Extended-Attribute-2
skipping to change at page 44, line 18 skipping to change at page 47, line 50
* 245.{1-25} Unassigned * 245.{1-25} Unassigned
* 245.26 Extended-Vendor-Specific-5 * 245.26 Extended-Vendor-Specific-5
* 245.{27-240} Unassigned * 245.{27-240} Unassigned
* 245.{241-255} Reserved * 245.{241-255} Reserved
* 246 Extended-Attribute-6 * 246 Extended-Attribute-6
* 246.{1-25} Unassigned * 246.{1-25} Unassigned
* 245.26 Extended-Vendor-Specific-6 * 245.26 Extended-Vendor-Specific-6
* 246.{27-240} Unassigned * 246.{27-240} Unassigned
* 246.{241-255} Reserved * 246.{241-255} Reserved
The values marked "Unassigned" above are available for assignment by As per [RFC5226], the values marked "Unassigned" above are available
IANA in future RADIUS specifications. The values marked "Reserved" via for assignment by IANA in future RADIUS specifications. The
are reserved for future use. values marked "Reserved" are reserved for future use.
9.3. Allocation of TLV Data Types The Extended-Vendor-Specific spaces (TYPE.26) are for Private Use,
and allocations are not managed by IANA.
Allocation of Reserved entries in the extended space requires
Standards Action.
All other allocations in the extended space require IETF Review.
9.3. Allocation Instructions
This section defines what actions IANA needs to take when allocating
new attributes. Different actions are required when allocating
attributes from the standard space, attributes of Extended Type
format, attributes of Extended Type with Flags format, perferential
allocations, attributes of data type TLV, attributes within a TLV,
and attributes of other data types.
9.3.1. Requested Allocation from the Standard Space
Specifications can request allocation of an Attribute from within the
standard space (e.g. Attribute Type Codes 1 through 255), subject to
the considerations of [RFC3575] and this document.
9.3.2. Requested Allocation from the short extended space
Specifications can request allocation of an Attribute which requires
the format Extended Type, by specifying the short extended space In
that case, IANA should assign the lowest Unassigned number from the
Attribute Type space with the relevant format.
9.3.3. Requested Allocation from the long extended space
Specifications can request allocation of an Attribute which requires
the format Extended Type with Flags, by specifying the extended space
(long). In that case, IANA should assign the lowest Unassigned
number from the Attribute Type space with the relevant format.
9.3.4. Allocation Preferences
Specifications which make no request for allocation from a specific
Type Space should have Attributes allocated using the following
criteria:
* when the standard space has no more Unassigned attributes,
all allocations should be performed from the extended space.
* specifications which allocate a small number of attributes
(i.e. less than ten) should have all allocations made from
the standard space.
* specifications which allocate a large number of attributes
(i.e. ten or more) should have all allocations made from the
extended space.
* specifications which request allocation of an Attribute of
data type TLV should have that attribute allocated from the
extended space.
* specifications which request allocation of an attribute
which can transport 253 or more octets of data should have
that attribute allocated from within the long extended space,
We note that Section 6.5, above requires specifications to
request this allocation.
There is otherwise no requirement that all attributes within a
specification be allocated from one type space or another.
Specifications can simultaneously allocate attributes from both the
standard space and the extended space.
9.3.5. Extending the Type Space via TLV Data Type
When specifications request allocation of an attribute of data type When specifications request allocation of an attribute of data type
"tlv", that allocation extends the Attribute Type Tree by one more "tlv", that allocation extends the Attribute Type Tree by one more
level. Allocation of an Attribute Type value "TYPE.TLV", with Data level. Allocation of an Attribute Type value "TYPE.TLV", with Data
Type TLV, results in allocation of 255 new Attribute Type values, of Type TLV, results in allocation of 255 new Attribute Type values, of
format "TYPE.TLV.1" through "TYPE.TLV.255". The value zero "VALUE.0" format "TYPE.TLV.1" through "TYPE.TLV.255". The value zero "VALUE.0"
is not used. Values 254-255 are marked "Reserved". All other values is not used. Values 254-255 are marked "Reserved". All other values
are "Unassigned". are "Unassigned". Value 26 has no special meaning.
For example, if a new attribute "Example-TLV" of data type "tlv" is For example, if a new attribute "Example-TLV" of data type "tlv" is
assigned the identifier "245.1", then the extended tree will be assigned the identifier "245.1", then the extended tree will be
allocation as below: allocated as below:
* 245.1 Example-TLV * 245.1 Example-TLV
* 245.1.{1-253} Unassigned * 245.1.{1-253} Unassigned
* 245.1.{254-255} Reserved * 245.1.{254-255} Reserved
Note that this example does not define an "Example-TLV" attribute. Note that this example does not define an "Example-TLV" attribute.
The Attribute Type Tree can be extended multiple levels in one The Attribute Type Tree can be extended multiple levels in one
specification when the specification requests allocation of nested specification when the specification requests allocation of nested
TLVs, as discussed below. TLVs, as discussed below.
9.4. Allocation within a TLV 9.3.6. Allocation within a TLV
Specifications can request allocation of Attribute Type values within Specifications can request allocation of Attribute Type values within
an Attribute of Data Type TLV. The encapsulating TLV can be an Attribute of Data Type TLV. The encapsulating TLV can be
allocated in the same specification, or it can have been previously allocated in the same specification, or it can have been previously
allocated. allocated.
Specifications need to request allocation within a specific Attribute Specifications need to request allocation within a specific Attribute
Type value (e.g. "TYPE.TLV.*"). Allocations are performed from the Type value (e.g. "TYPE.TLV.*"). Allocations are performed from the
smallest Unassigned value, proceeding to the largest Unassigned smallest Unassigned value, proceeding to the largest Unassigned
value. value.
Where the Attribute being allocated is of Data Type TLV, the Where the Attribute being allocated is of Data Type TLV, the
Attribute Type tree is extended by one level, as given in the Attribute Type tree is extended by one level, as given in the
previous section. Allocations can then be made within that level. previous section. Allocations can then be made within that level.
9.5. Allocation of Extended Type with Flags format 9.3.7. Allocation of Other Data Types
Specifications can request allocation of an Attribute which requires
the format Extended Type with Flags. In that case, IANA should
assign the lowest Unassigned number from the 245.* or 246.* Attribute
Type space. If those spaces are full, the specification should
explicitly request allocation from an Attribute Type space of the
relevant format.
9.6. Allocation of Other Data Types
Attribute Type value allocations are otherwise allocated from the Attribute Type value allocations are otherwise allocated from the
smallest Unassigned value, starting from 241.1, proceeding through smallest Unassigned value, proceeding to the largest Unassigned
241.255, then to 242.1, through 242.255, etc. value. e.g. Starting from 241.1, proceeding through 241.255, then to
242.1, through 242.255, etc.
10. Security Considerations 10. Security Considerations
This document defines new formats for data carried inside of RADIUS, This document defines new formats for data carried inside of RADIUS,
but otherwise makes no changes to the security of the RADIUS but otherwise makes no changes to the security of the RADIUS
protocol. protocol.
Attacks on cryptographic hashes are well known, and are getting Attacks on cryptographic hashes are well known, and are getting
better with time, as discussed in[RFC4270]. RADIUS uses the MD5 hash better with time, as discussed in[RFC4270]. RADIUS uses the MD5 hash
[RFC1321] for packet authentication and attribute obfuscation. There [RFC1321] for packet authentication and attribute obfuscation. There
skipping to change at page 46, line 4 skipping to change at page 50, line 48
for the RADIUS protocol. for the RADIUS protocol.
As with any protocol change, code changes are required in order to As with any protocol change, code changes are required in order to
implement the new features. These code changes have the potential to implement the new features. These code changes have the potential to
introduce new vulnerabilities in the software. Since the RADIUS introduce new vulnerabilities in the software. Since the RADIUS
server performs network authentication, it is an inviting target for server performs network authentication, it is an inviting target for
attackers. We RECOMMEND that access to RADIUS servers be kept to a attackers. We RECOMMEND that access to RADIUS servers be kept to a
minimum. minimum.
11. References 11. References
11.1. Normative references 11.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997. Requirement Levels", RFC 2119, March, 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000. 2000.
[RFC5226] Narten, T. and Alvestrand, H, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 5226, May 2008.
11.2. Informative references 11.2. Informative references
[RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321,
April, 1992 April, 1992
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2868] Zorn, G., et al, " RADIUS Attributes for Tunnel Protocol [RFC2868] Zorn, G., et al, " RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000. Support", RFC 2868, June 2000.
 End of changes. 63 change blocks. 
189 lines changed or deleted 419 lines changed or added

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