draft-ietf-radext-radius-extensions-01.txt   draft-ietf-radext-radius-extensions-02.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, 5176 BWS Updates: 2865, 2866, 5176 BWS
<draft-ietf-radext-radius-extensions-01.txt> <draft-ietf-radext-radius-extensions-02.txt>
Expires: January 6, 2012 Expires: January 6, 2012
6 June 2011 25 October 2011
Remote Authentication Dial In User Service (RADIUS) Protocol Remote Authentication Dial In User Service (RADIUS) Protocol
Extensions Extensions
draft-ietf-radext-radius-extensions-01.txt draft-ietf-radext-radius-extensions-02.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.
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 November January 6, 2012. This Internet-Draft will expire on January 6, 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
skipping to change at page 3, line 39 skipping to change at page 3, line 39
4. Vendor Specific Attributes ............................... 24 4. Vendor Specific Attributes ............................... 24
4.1. Extended-Vendor-Specific-1 .......................... 24 4.1. Extended-Vendor-Specific-1 .......................... 24
4.2. Extended-Vendor-Specific-2 .......................... 25 4.2. Extended-Vendor-Specific-2 .......................... 25
4.3. Extended-Vendor-Specific-3 .......................... 26 4.3. Extended-Vendor-Specific-3 .......................... 26
4.4. Extended-Vendor-Specific-4 .......................... 28 4.4. Extended-Vendor-Specific-4 .......................... 28
4.5. Extended-Vendor-Specific-5 .......................... 29 4.5. Extended-Vendor-Specific-5 .......................... 29
4.6. Extended-Vendor-Specific-6 .......................... 30 4.6. Extended-Vendor-Specific-6 .......................... 30
5. Compatibility with traditional RADIUS .................... 32 5. Compatibility with traditional RADIUS .................... 32
5.1. Attribute Allocation ................................ 32 5.1. Attribute Allocation ................................ 32
5.2. Proxy Servers ....................................... 33 5.2. Proxy Servers ....................................... 33
6. Guidelines ............................................... 33 6. Guidelines ............................................... 34
6.1. Updates to RFC 6158 ................................. 34 6.1. Updates to RFC 6158 ................................. 34
6.2. Guidelines For the New Types ........................ 34 6.2. Guidelines For the New Types ........................ 34
6.3. Allocation Request Guidelines ....................... 34 6.3. Allocation Request Guidelines ....................... 34
6.4. TLV Guidelines ...................................... 35 6.4. TLV Guidelines ...................................... 35
6.5. Implementation Guidelines ........................... 36 6.5. Implementation Guidelines ........................... 36
6.6. Vendor Guidelines ................................... 36 6.6. Vendor Guidelines ................................... 36
7. Rationale ................................................ 36 7. Rationale ................................................ 36
7.1. Attribute Audit ..................................... 36 7.1. Attribute Audit ..................................... 37
8. Examples ................................................. 37 8. Examples ................................................. 37
8.1. Extended Type ....................................... 38 8.1. Extended Type ....................................... 38
8.2. Extended Type with Flags ............................ 39 8.2. Extended Type with Flags ............................ 40
9. IANA Considerations ...................................... 42 9. IANA Considerations ...................................... 42
9.1. Attribute Allocations ............................... 42 9.1. Attribute Allocations ............................... 42
9.2. RADIUS Attribute Type Tree .......................... 42 9.2. RADIUS Attribute Type Tree .......................... 43
9.3. Assignment Policy ................................... 43 9.3. Extending the Attribute Type Tree ................... 44
9.4. Extending the Attribute Type Tree ................... 44 10. Security Considerations ................................. 44
9.5. Extending the RADIUS Attribute Type Space ........... 44 11. References .............................................. 44
10. Security Considerations ................................. 45 11.1. Normative references ............................... 44
11. References .............................................. 45 11.2. Informative references ............................. 45
11.1. Normative references ............................... 45 Appendix A - Extended Attribute Generator Program ............ 46
11.2. Informative references ............................. 46
Appendix A - Extended Attribute Generator Program ............ 47
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 5, line 39 skipping to change at page 5, line 39
* allocating 4 attributes as using the format of "Extended Type". * allocating 4 attributes as using the format of "Extended Type".
This allocation extends the RADIUS Attribute Type Space by This allocation extends the RADIUS Attribute Type Space by
approximately 1000 values. approximately 1000 values.
* defining an "Extended Type with Flags" format, which inserts * defining an "Extended Type with Flags" format, which inserts
an additional "Flags" octet between the "Extended Type" octet, an additional "Flags" octet between the "Extended Type" octet,
and the "Value" field. This method gives us a general way of and the "Value" field. This method gives us a general way of
adding additional functionality to the protocol. adding additional functionality to the protocol.
* defining method which uses the "Flags" field to indicate data * defining a method which uses the "Flags" field to indicate data
fragmentation across multiple Attributes. This method provides a fragmentation across multiple Attributes. This method provides a
standard way for an Attribute to carry more than 253 octets of standard way for an Attribute to carry more than 253 octets of
data. data.
* allocating 2 attributes as using the format of "Extended Type with * allocating 2 attributes as using the format of "Extended Type with
Flags". This allocation extends the RADIUS Attribute Type Space Flags". This allocation extends the RADIUS Attribute Type Space
by an additional 500 values. by an additional 500 values.
* defining a new "Type Length Value" (TLV) data type. The data type * defining a new "Type Length Value" (TLV) data type. The data type
allows an attribute to carry TLVs as "sub-attributes", which can in allows an attribute to carry TLVs as "sub-attributes", which can in
skipping to change at page 12, line 41 skipping to change at page 12, line 41
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
attributes of data type "tlv", which allows for simple grouping attributes of data type "tlv", which allows for simple grouping
and multiple layers of nesting. and multiple layers of nesting.
The TLV-Value field is limited to containing 253 or fewer octets The TLV-Value field is limited to containing 253 or fewer octets
of data. Specifications which require a TLV to contain more than of data. Specifications which require a TLV to contain more than
253 octets of data are incompatible with RADIUS, and need to be 253 octets of data are incompatible with RADIUS, and need to be
redesigned. Specifications which require the transport of empty redesigned. Specifications which require the transport of empty
Values (i.e. Length = 2) are incomaptible with RADIUS, and need to Values (i.e. Length = 2) are incompatible with RADIUS, and need to
be redesigned. be redesigned.
The TLV-Value field MUST NOT contain data using the "Extended The TLV-Value field MUST NOT contain data using the "Extended
Type" formats defined in this document. The base Extended Type" formats defined in this document. The base Extended
Attributes format allows for sufficient flexibility that nesting Attributes format allows for sufficient flexibility that nesting
them inside of a TLV offers little additional value. them inside of a TLV offers little additional value.
This TLV definition is compatible with the suggested format of the This TLV definition is compatible with the suggested format of the
"String" field of the Vendor-Specific attribute, as defined in "String" field of the Vendor-Specific attribute, as defined in
[RFC2865] Section 5.26, though that specification does not discuss [RFC2865] Section 5.26, though that specification does not discuss
skipping to change at page 15, line 30 skipping to change at page 15, line 30
fields are transmitted from left to right. fields are 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ... | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attributes having data type "integer64" MUST have the relevant Length Attributes having data type "integer64" MUST have the relevant Length
field set to eight more than the length of the Attribute header. For field set to eight more than the length of the Attribute header. For
standard space Attributes and TLVs, this means that the Length field standard space Attributes and TLVs, this means that the Length field
MUST be set to ten (10). For "Extended Type" Attributes, the Length MUST be set to ten (10). For "Extended Type" Attributes, the Length
field MUST be set to eleven (11). For "Extended Type with Flags" field MUST be set to eleven (11). For "Extended Type with Flags"
Attributes, the Length field MUST be set to twelve (12). Attributes, the Length field MUST be set to twelve (12).
2.6. Attribute Naming and Type Identifiers 2.6. Attribute Naming and Type Identifiers
Attributes have traditionally been identified by a unique name and Attributes have traditionally been identified by a unique name and
number. For example, the attribute named "User-Name" has been number. For example, the attribute named "User-Name" has been
allocated number one (1). This scheme needs to be extended in order allocated number one (1). This scheme needs to be extended in order
to be able to refer to attributes of Extended Type, and to TLVs. It to be able to refer to attributes of Extended Type, and to TLVs. It
will also be used by IANA for allocating RADIUS Attribute Type will also be used by IANA for allocating RADIUS Attribute Type
values. values.
skipping to change at page 32, line 14 skipping to change at page 32, line 14
determine the interpretation of the String field. determine the interpretation of the String field.
5. Compatibility with traditional RADIUS 5. Compatibility with traditional RADIUS
There are a number of potential compatibility issues with traditional There are a number of potential compatibility issues with traditional
RADIUS. This section describes them. RADIUS. This section describes them.
5.1. Attribute Allocation 5.1. Attribute Allocation
Some vendors have used Attribute Type codes from the "Reserved" Some vendors have used Attribute Type codes from the "Reserved"
space, as Vendor Specific Attributes. This practice is considered space, as part of vendor-defined dictionaries. This practice is
anti-social behavior, as noted in [RFC6158]. These vendor considered anti-social behavior, as noted in [RFC6158]. These vendor
definitions conflict with the attributes in the RADIUS Attribute Type definitions conflict with the attributes in the RADIUS Attribute Type
space. The conflicting definitions may make it difficult for space. The conflicting definitions may make it difficult for
implementations to support both those Vendor Attributes, and the new implementations to support both those Vendor Attributes, and the new
Extended Attribute formats. Extended Attribute formats.
We RECOMMEND that RADIUS client and server implementations delete all We RECOMMEND that RADIUS client and server implementations delete all
references to these improperly defined attributes. Failing that, we references to these improperly defined attributes. Failing that, we
RECOMMEND that RADIUS server implementations have a per-client RECOMMEND that RADIUS server implementations have a per-client
configurable flag which indicates which type of attributes are being configurable flag which indicates which type of attributes are being
sent from the client. If the flag is set one way, the conflicting sent from the client. If the flag is set one way, the conflicting
skipping to change at page 33, line 5 skipping to change at page 32, line 51
the improper Attributes. the improper Attributes.
RADIUS clients will have fewer issues than servers. Clients MUST NOT RADIUS clients will have fewer issues than servers. Clients MUST NOT
send improperly defined Attributes in a request. For replies, send improperly defined Attributes in a request. For replies,
clients MUST interpret attributes as being of the Extended Attributes clients MUST interpret attributes as being of the Extended Attributes
format, instead of the improper definitions. These requirements format, instead of the improper definitions. These requirements
impose no change in the RADIUS specifications, as such usage by impose no change in the RADIUS specifications, as such usage by
vendors has always been in conflict with the standard requirements vendors has always been in conflict with the standard requirements
and the standards process. and the standards process.
Existing clients that send these improperly defined attributes
usually have a configuration setting which can disable this behavior.
We RECOMMEND that vendors ship products with the default set to
"disabled". We RECOMMEND that administrators set this flag to
"disabled" on all equipment that they manage.
5.2. Proxy Servers 5.2. Proxy Servers
RADIUS Proxy servers will need to forward Attributes having the new RADIUS Proxy servers will need to forward Attributes having the new
format, even if they do not implement support for the encoding and format, even if they do not implement support for the encoding and
decoding of those attributes. We remind implementors of the decoding of those attributes. We remind implementors of the
following text in [RFC2865] Section 2.3: following text in [RFC2865] Section 2.3:
The forwarding server MUST NOT change the order of any attributes The forwarding server MUST NOT change the order of any attributes
of the same type, including Proxy-State. of the same type, including Proxy-State.
skipping to change at page 35, line 28 skipping to change at page 35, line 32
standard Attribute Type Space (i.e. Attributes 1 through 255). standard Attribute Type Space (i.e. Attributes 1 through 255).
That space is deprecated, and is not to be used. That space is deprecated, and is not to be used.
* Attributes which encode 252 octets or less of data SHOULD * Attributes which encode 252 octets or less of data SHOULD
request allocation from the Type spaces of 241.*, 242.*, 243.*, request allocation from the Type spaces of 241.*, 242.*, 243.*,
or 244.*. or 244.*.
* Attributes which encode 253 octets or more of data MUST request * Attributes which encode 253 octets or more of data MUST request
allocation from the Type spaces of 245.* or 246.*. allocation from the Type spaces of 245.* or 246.*.
* Where a group of TLVs is strictly defined, and not expected to
change, and and totals less than 247 octets of data, they SHOULD
request allocation from the Type spaces of 241.*, 242.*, 243.*, or
244.*.
* Where a group of TLVs is loosely defined, or is expected to change,
they SHOULD request allocation from the Type spaces of 245.* or
246.*.
6.4. TLV Guidelines 6.4. 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.
* Specifications SHOULD that the interpretation of an attribute * Interpretation of an attribute depends only on its type
depends only on its OID, and not on its encoding in the RADIUS definition (e.g. Type.Extended-Type.TLV-Type, etc.), and
packet. not on its encoding or location in the RADIUS packet.
* Where a group of TLVs is strictly defined, and not expected to
change, and and totals less than 247 octets of data, they SHOULD
request allocation from the Type spaces of 241.*, 242.*, 243.*, or
244.*.
* Where a group of TLVs is loosely defined, or is expected to change,
they SHOULD request allocation from the Type spaces of 245.* or
246.*.
6.5. Implementation Guidelines 6.5. Implementation Guidelines
* RADIUS Server implementations SHOULD support this specification * RADIUS client implementations SHOULD support this specification
as soon as possible. as soon as possible.
* RADIUS Proxy servers SHOULD forward all attributes, even ones * RADIUS server implementations SHOULD support this specification
as soon as possible.
* 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 * Any attribute which is allocated from the Type spaces of 245.* or
246.*, of data type "text", "string", or "tlv" can end up carrying 246.*, of data type "text", "string", or "tlv" can end up carrying
more than 251 octets of data, up to the maximum RADIUS packet more than 251 octets of data, up to the maximum RADIUS packet
length (~4096 octets). Specifications defining such attributes length (~4096 octets). Specifications defining such attributes
SHOULD define a maximum length. SHOULD define a maximum length.
6.6. Vendor Guidelines 6.6. 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 be widely attributes, as this specification may take time to become widely
deployed. deployed.
* Vendors SHOULD implement this specification as soon as
possible. The changes to RADIUS are relatively small, and are
likely to quickly be used in new specifications.
7. Rationale 7. Rationale
The path to extending the RADIUS protocol has been long and arduous. The path to extending the RADIUS protocol has been long and arduous.
A number of proposals have been made and discarded by the RADEXT A number of proposals have been made and discarded by the RADEXT
working group. These proposals have been judged to be either too working group. These proposals have been judged to be either too
bulky, too complex, too simple, or to be unworkable in practice. We bulky, too complex, too simple, or to be unworkable in practice. We
do not otherwise explain here why earlier proposals did not obtain do not otherwise explain here why earlier proposals did not obtain
working group consensus. working group consensus.
This proposal has the benefit of being simple, as the "Extended Type" The changes outlined here have the benefit of being simple, as the
format requires only a one octet change to the Attribute format. "Extended Type" format requires only a one octet change to the
Attribute format. The downside is that the "Extended Type with
Flags" format is awkward, and the 7 bits of Flags will likey never be
used for anything.
7.1. Attribute Audit 7.1. Attribute Audit
An audit of almost five thousand publicly available attributes An audit of almost five thousand publicly available attributes
[ATTR], shows the statistics summarized below. The attributes include [ATTR], shows the statistics summarized below. The attributes include
over 100 Vendor dictionaries, along with the IANA assigned over 100 Vendor dictionaries, along with the IANA assigned
attributes: attributes:
Count Data Type Count Data Type
----- --------- ----- ---------
2257 integer 2257 integer
1762 text 1762 text
273 IPv4 Address 273 IPv4 Address
235 string 225 string
96 other data types 96 other data types
35 IPv6 Address 35 IPv6 Address
18 date 18 date
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]. The "other data types" row encompasses data types not [RFC6158], along with "integer64". The "other data types" row
recommended by that document. encompasses other data types.
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. The "Extended Type with Flags" number of standard Attributes. While the "Extended Type with Flags"
formats is therefore important, but "long" attributes have had format is therefore important, "long" attributes have had limited
limited deployment. deployment
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 of the new attribute formats. These examples are not encoding of the new attribute formats. These examples are not
intended to be exhaustive, as many others are possible. For intended to be exhaustive, as many others are possible. For
simplicity, we do not show complete packets, only attributes. simplicity, we do not 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,
skipping to change at page 38, line 16 skipping to change at page 38, line 29
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 field(s); and there is no requirement for consistency
from one example to the next. For example, it can be used to encode from one example to the next. For example, it can be used to encode
a User-Name attribute which contains non-UTF8 data, or a Framed-IP- a 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
cannot be used to create RADIUS Attributes for transport in a RADIUS MUST NOT be used to create RADIUS Attributes for transport in a
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 can therefore be used to
encode example attributes from input which is humanly readable. encode example attributes from input which is 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, and not consistent meaning.
A particular attribute type code may be used to demonstrate two A particular attribute type code may be used to demonstrate two
different formats. In real specifications, attributes have a static different formats. In real specifications, attributes have a static
skipping to change at page 42, line 23 skipping to change at page 42, line 38
This document has multiple impacts on IANA, in the "RADIUS Attribute This document has multiple impacts on IANA, in the "RADIUS Attribute
Types" registry. Attribute types which were previously reserved are Types" registry. Attribute types which were previously reserved are
now allocated, previously free attributes are marked deprecated, and now allocated, previously free attributes are marked deprecated, and
the registry is extended from a simple 8-bit array to a tree-like the registry is extended from a simple 8-bit array to a tree-like
structure, up to a maximum depth of 125 nodes. structure, up to a maximum depth of 125 nodes.
9.1. Attribute Allocations 9.1. Attribute Allocations
IANA is requested to move the "Unassigned" numbers in the range IANA is requested to move the "Unassigned" numbers in the range
144-191 from "Unassigned" to "Deprecated". This status means that 144-191 from "Unassigned" to "Deprecated". New allocations are
allocations SHOULD NOT be made from this space. Instead, allocations normally taken from the Extended Type space, starting with lower
SHOULD be taken from the Extended Type space, starting with lower
numbered attributes. However, allocation from the "Deprecated" space numbered attributes. However, allocation from the "Deprecated" space
MAY still be performed by publication of an IETF specification, where can still be performed by publication of an IETF specification, where
that specification requests allocation from the "Deprecated" space, that specification requests allocation from the "Deprecated" space,
and gives reasons why use of the Extended Type space is impossible. and gives reasons why use of the Extended Type space is impossible.
IANA is requested to move the following numbers from "Reserved", to IANA is requested to move the following numbers from "Reserved", to
allocated, with the following names: 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 attributes serve as an encapsulation layer for the new RADIUS These attributes 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 attributes allocated above extends the "RADIUS Attribute Each of the attributes allocated above extends the "RADIUS Attribute
Types" to an N-ary tree, via a "dotted number" notation. Each number Types" to an N-ary tree, via a "dotted number" notation. Each number
in the tree is an 8-bit value (1 to 255). The value zero (0) MUST in the tree is an 8-bit value (1 to 255). The value zero (0) is not
NOT be used. Currently, only one level of the tree is defined: used. Currently, only one level of the tree is defined:
* 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
* 242.{1-25} Unassigned * 242.{1-25} Unassigned
* 242.26 Extended-Vendor-Specific-2 * 242.26 Extended-Vendor-Specific-2
* 242.{27-240} Unassigned * 242.{27-240} Unassigned
* 243 Extended-Attribute-3 * 243 Extended-Attribute-3
* 242.{241-255} Reserved * 242.{241-255} Reserved
* 243.{1-25} Unassigned * 243.{1-25} Unassigned
* 243.26 Extended-Vendor-Specific-3 * 243.26 Extended-Vendor-Specific-3
* 243.{27-240} Unassigned * 243.{27-240} Unassigned
* 243.{241-255} Reserved * 243.{241-255} Reserved
* 244 Extended-Attribute-4 * 244 Extended-Attribute-4
* 244.{1-25} Unassigned * 244.{1-25} Unassigned
* 244.26 Extended-Vendor-Specific-4 * 244.26 Extended-Vendor-Specific-4
* 244.{27-240} Unassigned * 244.{27-240} Unassigned
* 244.{241-255} Reserved * 244.{241-255} Reserved
* 245 Extended-Attribute-5 * 245 Extended-Attribute-5
* 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 The values marked "Unassigned" above are available for assignment by
IANA in future RADIUS specifications. The values marked "Reserved" IANA in future RADIUS specifications. The values marked "Reserved"
are reserved for future use. are reserved for future use.
9.3. Assignment Policy 9.3. Extending the Attribute Type Tree
Attributes which are known to always require 252 octets or less of
data MUST be assigned from the lowest unassigned number, e.g. 241.1,
241.2, 241.3, etc. Attributes have the potential to transport more
than 252 octets of data MUST be assigned from the 245.* or 246.*
spaces, again using the lowest unassigned number, and MUST request
assignment from the appropriate Attribute Type Space.
The above policy can be difficult to enforce in the case of TLVs.
For exaple, a set of TLVs may define a logical structure which totals
less than 252 octets of data. Later extensions could assign
additional sub-TLVs, and extend the structure to more than 252 octets
of data. This capability means that TLV definitions SHOULD generally
request assignment from the 245.* or 246.* space.
9.4. Extending the Attribute Type Tree
New specifications may request that the tree be extended to an When specifications request allocation of an attribute of data type
additional level or levels. The attribute MUST be of type "tlv". "tlv", that allocation extends the Attribute Type Tree by one more
level. The value zero (0) is not used. Values 254 and 255 are
Reserved. All other values are available for allocation.
For example, a specification may request that an "Example-TLV" For example, if a new attribute "Example-TLV" of data type "tlv" is
attribute be assigned, of data type "tlv". If it is assigned the assigned the identifier "245.1", then the extended tree will be
number 245.1, then it will define an extension to the registry as allocation as below:
follows:
* 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 number zero (0) MUST NOT be used. The last two numbers (254 and
255) MUST be reserved for future use. All other numbers are
available for assignment by IANA.
The Attribute Type Tree can be extended multiple levels in one The Attribute Type Tree can be extended multiple levels in one
specification. For example, the "Example-TLV" above could contain specification when the specification requests allocation of nested
another attribute, "Example-Nested-TLV", of type "tlv". It would TLVs.
define an additional extension to the registry as follows:
* 245.1.1 Example-Nested-TLV
* 245.1.1.{1-253} Unassigned
* 245.1.1.{254-255} Reserved
This process may be continued to additional levels of nesting.
Again, this example does not define an "Example-Nested-TLV"
attribute.
9.5. Extending the RADIUS Attribute Type Space
The extended RADIUS Attribute Type space may eventually approach
exhaustion. When necessary, the space SHOULD be extended by
publication of a specification which allocates new attributes of
either the "Extended Type", or the "Extended Type with flags" format.
The specification SHOULD request allocation of a specific number from
the "Reserved" RADIUS Attribute type space, such as 247. The
attribute(s) SHOULD be given a name which follows the naming
convention used in this document. The Extended-Type value of 26 MUST
be allocated to a "Vendor Specific" attribute, of data type "esv".
The Extended-Type values of 241 through 255 MUST be marked as
"Reserved".
IANA SHOULD allocate the attribute(s) as requested. For example, if
allocation of attribute 247 is requested, the following definitions
MUST be made in the specification, and allocated by IANA.
* 247.1 Extended-Attribute-7
* 247.{1-25} Unassigned
* 247.26 Extended-Vendor-Specific-7
* 247.{27-240} Unassigned
* 247.{241-255} Reserved
We note,however, that the above list is an example, and we do not
request or perform allocation of attribute 247 in this document.
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
 End of changes. 39 change blocks. 
128 lines changed or deleted 87 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/