draft-ietf-radext-radius-extensions-10.txt   draft-ietf-radext-radius-extensions-11.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, 6158 Updates: 2865, 2866, 3575, 5176, 6158
<draft-ietf-radext-radius-extensions-10.txt> <draft-ietf-radext-radius-extensions-11.txt>
Expires: August 1, 2013 Expires: August 1, 2013
1 February 2013 1 February 2013
Remote Authentication Dial In User Service (RADIUS) Protocol Remote Authentication Dial In User Service (RADIUS) Protocol
Extensions Extensions
draft-ietf-radext-radius-extensions-10.txt draft-ietf-radext-radius-extensions-11.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 3, line 23 skipping to change at page 3, line 23
2. Extensions to RADIUS ..................................... 9 2. Extensions to RADIUS ..................................... 9
2.1. Extended Type ....................................... 10 2.1. Extended Type ....................................... 10
2.2. Long Extended Type .................................. 11 2.2. Long Extended Type .................................. 11
2.3. TLV Data Type ....................................... 14 2.3. TLV Data Type ....................................... 14
2.3.1. TLV Nesting .................................... 16 2.3.1. TLV Nesting .................................... 16
2.4. EVS Data Type ....................................... 16 2.4. EVS Data Type ....................................... 16
2.5. Integer64 Data Type ................................. 18 2.5. Integer64 Data Type ................................. 18
2.6. Vendor-ID Field ..................................... 18 2.6. Vendor-ID Field ..................................... 18
2.7. Attribute Naming and Type Identifiers ............... 19 2.7. Attribute Naming and Type Identifiers ............... 19
2.7.1. Attribute and TLV Naming ....................... 19 2.7.1. Attribute and TLV Naming ....................... 19
2.7.2. Attribute Type Identifiers ..................... 19 2.7.2. Attribute Type Identifiers ..................... 20
2.7.3. TLV Identifiers ................................ 20 2.7.3. TLV Identifiers ................................ 20
2.7.4. VSA Identifiers ................................ 20 2.7.4. VSA Identifiers ................................ 20
2.8. Invalid Attributes .................................. 21 2.8. Invalid Attributes .................................. 21
3. Attribute Definitions .................................... 22 3. Attribute Definitions .................................... 22
3.1. Extended-Type-1 ..................................... 22 3.1. Extended-Type-1 ..................................... 22
3.2. Extended-Type-2 ..................................... 23 3.2. Extended-Type-2 ..................................... 23
3.3. Extended-Type-3 ..................................... 24 3.3. Extended-Type-3 ..................................... 24
3.4. Extended-Type-4 ..................................... 25 3.4. Extended-Type-4 ..................................... 25
3.5. Long-Extended-Type-1 ................................ 26 3.5. Long-Extended-Type-1 ................................ 26
3.6. Long-Extended-Type-2 ................................ 27 3.6. Long-Extended-Type-2 ................................ 27
skipping to change at page 11, line 4 skipping to change at page 11, line 4
A RADIUS server MAY ignore Attributes with an unknown A RADIUS server MAY ignore Attributes with an unknown
"Type.Extended-Type". "Type.Extended-Type".
A RADIUS client MAY ignore Attributes with an unknown A RADIUS client MAY ignore Attributes with an unknown
"Type.Extended-Type". "Type.Extended-Type".
Value 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. The format of the data SHOULD be defined in [RFC2865] Section 5. The format of the data MUST be a
a valid RADIUS data type. valid RADIUS data type.
The Value field is one or more octets. Implementations not The Value field is one or more octets. Implementations not
supporting this specification SHOULD support the field as supporting this specification SHOULD support the field as
undistinguished octets. undistinguished octets.
Implementations supporting this specification MUST use the Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type" to determine the interpretation Identifier of "Type.Extended-Type" to determine the interpretation
of the Value field. of the Value field.
The addition of the Extended-Type field decreases the maximum The addition of the Extended-Type field decreases the maximum
length for attributes of type "text" or "string" from 253 to 252 length for attributes of type "text" or "string" from 253 to 252
octets. Where an Attribute needs to carry more than 252 octets of octets. Where an Attribute needs to carry more than 252 octets of
data, the "Long Extended Type" format SHOULD be used. data, the "Long Extended Type" format MUST be used.
Experience has shown that the "experimental" and "implementation Experience has shown that the "experimental" and "implementation
specific" attributes defined in [RFC2865] Section 5 have had little specific" attributes defined in [RFC2865] Section 5 have had little
practical value. We therefore do not continue that practice here practical value. We therefore do not continue that practice here
with the Extended-Type field. with the Extended-Type field.
2.2. Long Extended Type 2.2. Long Extended Type
This section defines a new attribute format, called "Long Extended This section defines a new attribute format, called "Long Extended
Type". It leverages the "Extended Type" format in order to permit Type". It leverages the "Extended Type" format in order to permit
skipping to change at page 13, line 51 skipping to change at page 13, line 51
If multiple Attributes with the same Type are present, the order If multiple Attributes with the same Type are present, the order
of Attributes with the same Type MUST be preserved by any proxies. of Attributes with the same Type MUST be preserved by any proxies.
The order of Attributes of different Types is not required to be The order of Attributes of different Types is not required to be
preserved. A RADIUS server or client MUST NOT have any preserved. A RADIUS server or client MUST NOT have any
dependencies on the order of attributes of different types. A dependencies on the order of attributes of different types. A
RADIUS server or client MUST NOT require attributes of the same RADIUS server or client MUST NOT require attributes of the same
type to be contiguous. type to be contiguous.
These requirements also apply to the "Long Extended Type" attribute, These requirements also apply to the "Long Extended Type" attribute,
including fragments. Implementations SHOULD be able to process non- including fragments. Implementations MUST be able to process non-
contiguous fragments. That is, fragments which are mixed together contiguous fragments -- that is, fragments which are mixed together
with other attributes of a different Type. with other attributes of a different Type. This will allow them to
accept packets, so long as the attributes can be correctly decoded.
2.3. TLV Data Type 2.3. TLV Data Type
We define a new data type in RADIUS, called "tlv". The "tlv" data We define a new data type in RADIUS, called "tlv". The "tlv" data
type is an encapsulation layer which permits the "Value" field of an type is an encapsulation layer which permits the "Value" field of an
Attribute to contain new sub-Attributes. These sub-Attributes can in Attribute to contain new sub-Attributes. These sub-Attributes can in
turn contain "Value"s of data type TLV. This capability both extends turn contain "Value"s of data type TLV. This capability both extends
the attribute space, and permits "nested" attributes to be used. the attribute space, and permits "nested" attributes to be used.
This nesting can be used to encapsulate or group data into one or This nesting can be used to encapsulate or group data into one or
more logical containers. more logical containers.
skipping to change at page 16, line 22 skipping to change at page 16, line 22
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 in Section to be an "invalid attribute", and handled as described in Section
2.8, below. 2.8, 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. They have not been demonstrated to be necessary in
practice, and they appear to make implementations more complex.
Reception of packets with such deeply nest TLVs may indicate
implementation errors or deliberate attacks. Where implementations
do not support deep nesting of TLVs, it is RECOMMENDED that the
unsupported layers are treated as "invalid attributes".
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
which permits the "Value" field of an Attribute to contain a Vendor- which permits the "Value" field of an Attribute to contain a Vendor-
Id, followed by a Vendor-Type, and then vendor-defined data. This Id, followed by a Vendor-Type, and then vendor-defined data. This
data can in turn contain valid RADIUS data types, or any other data data can in turn contain valid RADIUS data types, or any other data
as determined by the vendor. as determined by the vendor.
skipping to change at page 21, line 23 skipping to change at page 21, line 26
be uniquely identified as 26.429.32768, and again cannot be uniquely be uniquely identified as 26.429.32768, and again cannot be uniquely
identified by name. identified by name.
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.Vendor-Id.Vendor-Type.TLV1.TLV2.TLV3 where "TLVn" are the above: 26.Vendor-Id.Vendor-Type.TLV1.TLV2.TLV3 where "TLVn" are the
numerical values assigned by the vendor to the different nested TLVs. numerical values assigned by the vendor to the different nested TLVs.
2.8. Invalid Attributes 2.8. Invalid Attributes
The term "invalid attribute" is new to this specification. It is The term "invalid attribute" is new to this specification. It is
defined to mean that the Length field of an Attribute is valid (as defined to mean that the Length field of an Attribute permits the
per [RFC2865], Section 5, top of page 25). However, the Value field packet to be accepted as not being "malformed". However, the Value
of the attribute does not follow the format required by the data type field of the attribute does not follow the format required by the
defined for that Attribute. e.g. an Attribute of data type "address" data type defined for that Attribute, and therefore the attribute is
which encapsulates less than four, or more than four octets of data. "malformed". In order to distinguish the two cases, we refer to
Or, an IPV6 Prefix attribute which has a Prefix value of more than "malformed" packets, and "invalid attributes".
128. Many other forms of an "invalid attribute" are possible, but
are not enumerated here.
While the content of these attributes is malformed, we emphasize that For example, an implementation receives a packet which is well-
the encapsulating RADIUS packet, or attribute, or TLV, is well formed. That packet contains an Attribute allegedly of data type
formed, and can be correctly decoded. The existence of an "invalid "address", but which has Length not equal to four. In that
attribute" in a packet MUST NOT result in the implementation situation, the packet is well formed, but the attribute is not.
discarding the entire packet, or treating the packet as a negative Therefore, it is an "invalid attribute".
acknowledgement. Instead, only the "invalid attribute" is treated
differently. A similar analysis can be performed when an attribute carries TLVs.
The encapsulating attribute may be well formed, but the TLV may be an
"invalid attribute". The existence of an "invalid attribute" in a
packet or attribute MUST NOT result in the implementation discarding
the entire packet, or treating the packet as a negative
acknowledgment. Instead, only the "invalid attribute" is treated
specially.
When an implementation receives an "invalid attribute", it SHOULD be When an implementation receives an "invalid attribute", it SHOULD be
silently discarded, except when the implementation is acting as a silently discarded, except when the implementation is acting as a
proxy (see Section 5.2 for discussion of proxy servers). If it is proxy (see Section 5.2 for discussion of proxy servers). If it is
not discarded, it MUST NOT be handled in the same manner as a well- not discarded, it MUST NOT be handled in the same manner as a well-
formed attribute. For example, receiving an Attribute of data type formed attribute. For example, receiving an Attribute of data type
"address" containing less than four octets, or more than four octets "address" containing less than four octets, or more than four octets
of data means that the Attribute MUST NOT be treated as being of data of data means that the Attribute MUST NOT be treated as being of data
type "address". The reason here is that if the attribute does not type "address". The reason here is that if the attribute does not
carry an IPv4 address, the receiver has no idea what format the data carry an IPv4 address, the receiver has no idea what format the data
skipping to change at page 42, line 10 skipping to change at page 42, line 10
* Specifications of an attribute which always encode less than 253 * Specifications of an attribute which always encode less than 253
octets of data MUST NOT request allocation from the long extended octets of data MUST NOT request allocation from the long extended
space. The standard space, or the short extended space MUST be space. The standard space, or the short extended space MUST be
used instead. used instead.
* Specifications of an attribute which encodes 253 octets or more of * Specifications of an attribute which encodes 253 octets or more of
data MUST request allocation from the "long extended space". data MUST request allocation from the "long extended space".
* When the extended space is nearing exhaustion, a new specification * When the extended space is nearing exhaustion, a new specification
will have to be written which requests allocation of one or more will have to be written which requests allocation of one or more
RADIUS Attributes from the "Reserved" portion of the standard space, RADIUS Attributes from the "Reserved" portion of the standard
values 247-255, using an appropriate format ("Short Extended Type", space, values 247-255, using an appropriate format ("Short
or "Long Extended Type") Extended Type", or "Long Extended Type")
An allocation request made in a specification SHOULD use one of the An allocation request made in a specification SHOULD use one of the
following formats when allocating an attribute type code: following formats when allocating an attribute type code:
* TBDn - request allocation of an attribute from the "standard * TBDn - request allocation of an attribute from the "standard
space". The value "n" should be "1" or more, to track individual space". The value "n" should be "1" or more, to track individual
attributes which are to be allocated. attributes which are to be allocated.
* SHORT-TBDn - request allocation of an attribute from the "short * SHORT-TBDn - request allocation of an attribute from the "short
extended space". The value "n" should be "1" or more, to track extended space". The value "n" should be "1" or more, to track
 End of changes. 10 change blocks. 
28 lines changed or deleted 38 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/