Network Working Group Y. Li
Internet-Draft A. Lior
Expires: December 14, 2007 BWS
G. Zorn
Cisco
June 12, 2007
Remote Authentication Dial In User Service (RADIUS) Attribute Type
Extension
draft-lior-radius-attribute-type-extension-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 14, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
In order for the Remote Authentication Dial In User Service protocol
to continue to support new applications, the RADIUS attribute space
must be extended beyond the current limit of 255 possible attribute
types. This document defines a mechanism to extend the base RADIUS
attribute types while maintaining backwards compatibility as well as
Li, et al. Expires December 14, 2007 [Page 1]
Internet-Draft RADIUS Attribute Type Extension June 2007
compatibility with Diameter.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. RADIUS Type Extension . . . . . . . . . . . . . . . . . . . . 4
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Li, et al. Expires December 14, 2007 [Page 2]
Internet-Draft RADIUS Attribute Type Extension June 2007
1. Introduction
The Remote Authentication Dial In User Service (RADIUS) Protocol
[RFC2865] defines two classes of attributes: attributes that belong
to the standard RADIUS space; and vendor specific attributes (VSAs).
VSAs are available to allow vendors (historically including Standards
Development Organizations) to support their own extended attributes
not suitable for general usage, whereas the attributes that belong to
the standard RADIUS space are controlled by the IETF are intended to
be suitable for general use. These attributes are defined in RFCs
and are assigned type codes by Internet Assigned Number Authority
(IANA)IANA [RFC3575].
Attributes that belong to the RADIUS space are allocated a type code
that is a single octet and hence RADIUS is limited to 255 attribute
types. Of these, 101 or so have already been assigned and 61 are
reserved. Therefore, as of this writing there are less than 100 type
codes that can be allocated to new attributes.
RADIUS evolution must not be hindered by the inability to define new
RADIUS attributes. This document defines a mechanism to extend the
RADIUS Attribute space by means of a new scheme for allocating
attribute type codes.
1.1. Terminology
The term RADIUS Extended Attribute is the name given to the new
RADIUS attribute types that are enabled by this document. The RADIUS
Extended Type contains the new type code that is assigned to the
RADIUS Extended Attributes.
Other terms used in this document are explained below:
To be completed...
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Requirements
This informative section describes the requirements that drive the
solution used to create the RADIUS Extended Attribute types.
Li, et al. Expires December 14, 2007 [Page 3]
Internet-Draft RADIUS Attribute Type Extension June 2007
A fundamental requirement for extending the RADIUS attribute space is
to maintain backwards compatibility. This means that RADIUS servers
and proxies must be able to continue to decode and encode messages
even though they may not need to understand an attribute that has
been extended. More specifically, the scheme MUST to be compatible
with both RADIUS [RFC2865] and RADIUS Accounting [RFC2866].
The scheme SHOULD ensure that the size of the type-space extension is
large enough that it will not be exhausted in the foreseeable future
or is itself easily extensible in the event of type code exhaustion.
Furthermore, the scheme should align with the Diameter Network Access
Server Application [RFC4005], thereby allowing the two IETF AAA
standards to interoperate.
Although according to the specification the allocation of RADIUS
attribute type codes has been controlled by IANA, this has not been
the case in reality. In the real world, certain vendors have grabbed
attribute type codes that they shouldn't have. The result is that
many RADIUS deployments have had to work around these attribute
collisions. Therefore, each time a new attribute type is introduced
it raises the possibility that something will break. The proposed
scheme must be impervious to this artifact.
A need to group RADIUS attributes together has become more prevalent
in current work. Therefore, the proposed scheme NUST provide a
mechanism to group attributes.
In recent years, attribute sizes are threatening the limit of 253
octets. Fragmentation of RADIUS attributes has always been possible
by extending the value into another attribute of the same type.
However this approach does not always work, especially if the
attribute type repeats in the RADIUS packet. The proposed scheme
SHOULD address attribute fragmentation.
3. RADIUS Type Extension
The solution described in this document uses the Vendor-Specific
attribute [RFC2865]as a basis for the creation of the RADIUS Extended
Attributes.
We allocate RADIUS the Vendor-Id of zero (0). In essence we are
assigning the IETF a Vendor-Id which is what other Standard
Development Organization have done in registering their own
Vendor-Id.
Vendor Specific attributes are encoded by using the Vendor-Specific
Li, et al. Expires December 14, 2007 [Page 4]
Internet-Draft RADIUS Attribute Type Extension June 2007
(26) type code, followed by Length (1 octet), a 4 octet Vendor-Id
identified using 3 octets (4 octets really) and a string which is
vendor-specific [RFC2865].
The string part is encoded as follows:
o The first octet represents the RADIUS Extended Type
o The next octet is the length of the Extended Attribute, which
represents the length of the Extended Type field (1 octet), the
length of the length itself (1 octet), the length of the
Fragmentation and Tag field (1 octet) and the length of the Value
field (1 or more octet(s)
o The third octet is the Fragmentation/Tag field (1 octet)
o The value is 1 or more octets
4. Formal Syntax
The following represents the encoding scheme used for RADIUS Extended
Attribute(s). It is based upon the Vendor Specific (26) encoding
[RFC2865].
+---------------------------------------------------------------+
| 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|
+---------------+---------------+-------------------------------+
| Type (26) | Length | Vendor-Id (0) |
+---------------+---------------+-------------------------------+
| Vendor-Id(0) | Extended-Type | Length |
+---------------+---------------+---------------+---------------+
|F| TAG | Value
+---------------+---------------
Type 26 for Vendor-Specific.
Length >= 10
Vendor-Id
The high-order octet is zero (0) and the low-order 3 octets are zeros
(0)s representing an extended IETF RADIUS attribute.
Extended-Type
Li, et al. Expires December 14, 2007 [Page 5]
Internet-Draft RADIUS Attribute Type Extension June 2007
One (1) Octet. Up-to-date values of the RADIUS Extended-Type field
are specified in the most recent "Assigned Numbers" IANA [RFC3575] .
Values XXXX-YYYY are reserved.
Length >= 4 The length of the Extended-Type, Length, Fragmentation
and Tag fields and the length of the Value field
Fragmentation (F):
When set(1) the attribute is fragmented. When clear (0), the
attribute is not fragmented. When the value portion of an extended
attribute exceeds 246 octets the value is fragmented over one or more
extended attribute. In this case the Fragmentation Flag is set on
the attribute(s) that contain the value fragments.
Tag
The Tag field is 7-bits and MUST always be present. It is used to
group extended attributes. Attributes with the same non-zero value
belong to the same group. A tag value of zero(0) indicates that the
attribute is not grouped. A tag value of all-ones (0x7F) is
reserved.
Value
One or more octets.
5. Examples
Consider an attribute called Foo of type String. Foo is allocated an
Extended-Type by IANA of 10. The following figure shows the encoding
of Foo(0,10) = "Hello":
+---------------------------------------------------------------+
| 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|
+---------------+---------------+-------------------------------+
| Type (26) | Length | Vendor-Id (0) |
| | (6+8 = 14) | |
+---------------+---------------+-------------------------------+
| Vendor-Id(0) | Extended-Type | Length |
| | (10) | (3 + 5 = 8) |
+---------------+---------------+---------------+---------------+
|F| TAG | Value | | |
|0| (0) | (H) | (e) | (l) |
+---------------+---------------+-------------------------------+
| (l) | (o) |
Li, et al. Expires December 14, 2007 [Page 6]
Internet-Draft RADIUS Attribute Type Extension June 2007
+---------------+---------------+
The next figure shows the encoding of Foo when the length of Foo is
251 octets. Foo(0,10) = "Hello W...end.". In this case the value is
fragmented over two attributes. The first 246 octets are included in
the first fragment and the remaining 5 octets appear in the second
attributes which has the Fragmentation bit set to 1.
+---------------------------------------------------------------+
| 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|
+---------------+---------------+-------------------------------+
| Type (26) | Length | Vendor-Id (0) |
| |(6 + 249 = 255)| |
+---------------+---------------+-------------------------------+
| Vendor-Id(0) | Extended-Type | Length |
| | (10) |(3 + 246 = 249)|
+---------------+---------------+---------------+---------------+
|F| TAG | Value | | |
|0| (0) | (H) | (e) | (l) |
+---------------+---------------+-------------------------------+
| (l) | (o) | | (W) |
+---------------+---------------+---------------+---------------+
................
+---------------+---------------+-------------------------------+
| Type (26) | Length | Vendor-Id (0) |
| | (6+8 = 14) | |
+---------------+---------------+-------------------------------+
| Vendor-Id(0) | Extended-Type | Length |
| | (10) | (3 + 5 = 8) |
+---------------+---------------+---------------+---------------+
|F| TAG | Value | | |
|1| (0) | ( ) | (e) | (n) |
+---------------+---------------+-------------------------------+
| (d) | (.) |
+---------------+---------------+
Next consider the following structure:
struct
Integer a;
String b;
Integer c;
endStruct
Element 'a' is assigned an extended type of 20. Element 'b' is
assigned an extended type of 25 and element 'c' is assigned an
Li, et al. Expires December 14, 2007 [Page 7]
Internet-Draft RADIUS Attribute Type Extension June 2007
extended type of 27. The following figure illustrates the coding
where a(0,20) = 0xDEADDEAD, b(0,25) = "He.....The end." and is of
length 251 octets; and c(0,27) = 0x12345678. The attributes are
grouped together with TAG=42.
+---------------------------------------------------------------+
| 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|
+---------------+---------------+-------------------------------+
| Type (26) | Length | Vendor-Id (0) |
| |(6 + 7 = 13) | |
+---------------+---------------+-------------------------------+
| Vendor-Id(0) | Extended-Type | Length |
| | (20) |(3 + 4 = 7) |
+-+-------------+---------------+---------------+---------------+
|F| TAG | Value | | |
|0| (42) | (0xde) | (0xad) | (0xde) |
+-+-------------+---------------+-------------------------------+
| (0xad) | Type(26) | Length | Vendor-Id(0) |
| | | (6 + 249 = 255| |
+---------------+---------------+---------------+---------------+
| Vendor-Id (0) | Extended-Type |
| | (25) |
+---------------+-+-------------+---------------+---------------+
| Length |F| TAG | Value | Value |
| (3+246) = 249 |0| (42) | (H) | (e) |
+---------------+-+-------------+---------------+---------------+
...........
+---------------+---------------+---------------+---------------+
| Value | Value | Value | Value |
| (.) | (T) | (h) | (e) |
+---------------+---------------+---------------+---------------+
| Type (26) | Length | Vendor-Id (0) |
| | (6+8 = 14) | |
+---------------+---------------+-------------------------------+
| Vendor-Id(0) | Extended-Type | Length |
| | (25) | (3 + 5 = 8) |
+---------------+---------------+---------------+---------------+
|F| TAG | Value | | |
|1| (42) | ( ) | (e) | (n) |
+---------------+---------------+---------------+---------------+
| (d) | (.) | Type (26) | Length |
| | | | (6+7 = 13) |
+---------------+---------------+---------------+---------------+
| Vendor-Id (0) |
| |
+---------------+---------------+-+-------------+---------------+
Li, et al. Expires December 14, 2007 [Page 8]
Internet-Draft RADIUS Attribute Type Extension June 2007
|Extended-Type | Length |F| TAG | Value |
| (27) | (3+4 = 7) |0| (42) | (0x12) |
+---------------+---------------+-+-------------+---------------+
| Value | Value | Value |
| (0x34) | (0x56) | (0x78) |
+---------------+---------------+---------------+
6. Security Considerations
TBD
7. IANA Considerations
This solution requires that the IETF be allocated Vendor-Type of zero
to the IETF.
It also requires that IANA be set up to manage the RADIUS Extended
Attributes.
The allocation rules for extended RADIUS attributes align with the
rules for allocation of the standard RADIUS attributes.
8. Open Issues
What is the numbering scheme for attributes that will be used by RFC
writers going forward? For example today we write user-name(1).
Going forward, will we write foo-bar(0,1)?
What is the numbering plan for these attributes? What range should
be reserved?
We have allocated 1 octets for Extended Type. Is that too little?
Note, if we run out the IETF can take out another Vendor-Id.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
Li, et al. Expires December 14, 2007 [Page 9]
Internet-Draft RADIUS Attribute Type Extension June 2007
RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575,
July 2003.
9.2. Informative References
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005,
August 2005.
Authors' Addresses
Yong Li
Bridgewater Systems Corporation
303 Terry Fox Drive
Suite 100
Ottawa, Ontario K2K 3J1
Canada
Phone: (613) 591-6655
Email: yongli@bridgewatersystems.com
URI: http://www.bridgewatersystems.com/
Avi Lior
Bridgewater Systems Corporation
303 Terry Fox Drive
Suite 100
Ottawa, Ontario K2K 3J1
Canada
Phone: (613) 591-6655
Email: avi@bridgewatersystems.com
URI: http://www.bridgewatersystems.com/
Li, et al. Expires December 14, 2007 [Page 10]
Internet-Draft RADIUS Attribute Type Extension June 2007
Glen Zorn
Cisco Systems
2901 Third Avenue, Suite 600
SEA1/5/
Seattle, WA 98121
United States of America
Phone:
Email: gwz@cisco.com
URI: http://www.cisco.com/
Li, et al. Expires December 14, 2007 [Page 11]
Internet-Draft RADIUS Attribute Type Extension June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Li, et al. Expires December 14, 2007 [Page 12]