Network Working Group Y. Li
Internet-Draft A. Lior
Intended status: Standards Track BWS
Expires: May 13, 2008 G. Zorn
NetCube
November 10, 2007
Extended Remote Authentication Dial In User Service (RADIUS) Attributes
draft-ietf-radext-extended-attributes-00.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 May 13, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
In order for the Remote Authentication Dial In User Service (RADIUS)
protocol to continue to support new applications the RADIUS attribute
type space must be extended beyond the current limit of 255 possible
attribute types while maintaining backwards compatibility with
existing RADIUS implementations. This document defines a mechanism
to accomplish that task, along with standard methods to group related
Li, et al. Expires May 13, 2008 [Page 1]
Internet-Draft Extended RADIUS Attributes November 2007
attributes together and to encode values that don't fit into 253
octets.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. RADIUS Type Extension . . . . . . . . . . . . . . . . . . . . 4
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Li, et al. Expires May 13, 2008 [Page 2]
Internet-Draft Extended RADIUS Attributes November 2007
1. Introduction
The Remote Authentication Dial In User Service (RADIUS) Protocol
[RFC2865] defines two classes of attributes: standard and vendor-
specific.
Vendor-specific Attributes (VSAs) allow vendors (including Standards
Development Organizations (SDOs)) to define their own Attributes,
which may not be suitable for general usage; on the other hand, the
attributes that belong to the standard RADIUS space are controlled by
the IETF and are intended to be of general utility. These attributes
are defined in RFCs and are assigned type codes by the Internet
Assigned Number Authority (IANA)[IANA].
The standard RADIUS attribute type code is 8 bits in length; hence
RADIUS is limited to 255 attribute types. Of these 255 attribute
types, 101 or so have been assigned. Types 192-223 are reserved for
experimental use; types 224-240 are reserved for implementation-
specific use; and values 241-255 are reserved and should not be used.
Therefore, as of this writing there are approximately 90 type codes
that can be allocated to new attributes.
RADIUS evolution must not be hindered by the inability to define new
standard RADIUS attributes. This document defines a mechanism to
extend the standard RADIUS Attribute space by defining a new scheme
to allocate attribute type codes. In addition, mechanisms are
defined to support both the grouping of related attributes and the
encoding of attribute values the length of which exceed the current
limit of 253 octets.
2. Terminology
Extended Attribute
The term used for the new RADIUS attributes that are defined in
this document
Extended Type
The type code assigned to an Extended Attribute
2.1. Requirements Language
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. 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].
Li, et al. Expires May 13, 2008 [Page 3]
Internet-Draft Extended RADIUS Attributes November 2007
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.
An implementation that satisfies all the MUST, MUST NOT, SHOULD, and
SHOULD NOT requirements for its protocols is said to be
"unconditionally compliant"; one that satisfies all the MUST and MUST
NOT requirements but not all the SHOULD or SHOULD NOT requirements
for its protocols is said to be "conditionally compliant".
3. Problem Statement
A fundamental requirement for extending the RADIUS attribute space is
the maintenance of 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 be
compliant with the various RADIUS RFCs such as [RFC2865] and RADIUS
Accounting [RFC2866], etc.
The scheme SHOULD ensure that the size of the standard type space
extension is large enough that it will not be quickly exhausted or is
extensible in the event that it is.
Furthermore, the scheme SHOULD align with the Diameter NASReq
Application [RFC4005], thereby allowing the two AAA standards to
interoperate.
A need to group related RADIUS attributes together has become
prevalent in current work. Therefore, the proposed scheme SHOULD
provide a mechanism to group related attributes together.
In recent years, attribute sizes have been 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 (for example, if
more than one instance of an attribute occurs in the same RADIUS
packet). The proposed scheme SHOULD enable the transmission of
attributes longer than 253 octets.
4. RADIUS Type Extension
The solution described in this document takes the recommended VSA
format [RFC2865] as a model for 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 SDOs have done in
registering their own Vendor-Id.
Li, et al. Expires May 13, 2008 [Page 4]
Internet-Draft Extended RADIUS Attributes November 2007
Extended Attributes consist of an attribute header similar to that
recommended by RFC 2865 [RFC2865] for Vendor Specific Attributes
followed by a non-empty sequence of Type-Length-Value (TLV) triples
(see below). If an Extended Attribute contains more than one TLV
then all of the encapsulated TLVs MUST fit completely within the
Extended Attribute.
The Extended Attribute header is 7 octets in length and is encoded as
follows:
o The first octet contains the Type which is always Vendor-Specific
(26)
o The second octet contains the length (in octets) of the entire
Extended Attribute, including the Extended Attribute header and
all encapsulated TLVs
o The next 4 octets contain the Vendor-Id (0)
o The final octet of the header contains the More flag and Tag
field. If the one bit More flag is set (1) this indicates that
the encapsulated TLV is continued in the following Extended
Attribute; if the More flag is clear (0) then all of the
encapsulated TLVs fit into the current Extended Attribute. The
More flag MUST NOT be set if the Extended Attribute contains more
than one TLV. The Tag field is used to combine sets of related
Extended Attributes into simple groups.
TLVs are encoded as follows:
o The first octet is the Ext-Type field
o The second octet is the Ext-Length field, representing of the
entire TLV, including the length of the Ext-Type field (1 octet),
the length of the Ext-Length field itself (1 octet) and the length
of the Value field (1 or more octets)
5. Formal Syntax
This section describes the encoding scheme used for RADIUS Extended
Attributes. The basis of this encoding is the format recommended for
Vendor Specific Attributes in RFC 2865 [RFC2865].
Li, et al. Expires May 13, 2008 [Page 5]
Internet-Draft Extended RADIUS Attributes November 2007
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) |M| Tag | Ext-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Length | 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
M (More)
The More Flag is one (1) bit in length. When a value to be
transmitted exceeds 246 octets in length it is fragmented over two
or more Extended Attributes. If the More Flag is set (1), this
indicates that the Value field of the Extended Attribute contains
a fragment of a larger value, which is continued in the next
Extended Attribute of the same Ext-Type. When the More Flag is
clear (0), the final (or only) fragment of the value is contained
in the Extended Attribute.
Tag
The Tag field is 7 bits long and MUST be present. It is used to
group Extended Attributes. Extended Attributes with the same non-
zero value in the Tag field 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.
Ext-Type
One (1) octet. Up-to-date values of the Ext-Type field are
specified in the most recent "Assigned Numbers" [IANA]. Values
XXXX-YYYY are reserved.
Li, et al. Expires May 13, 2008 [Page 6]
Internet-Draft Extended RADIUS Attributes November 2007
Ext-Length
>= 4. The length of the Extended Attribute, including the Ext-
Type, Ext-Length and Value fields.
Value
One or more octets.
6. 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,4) = "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 |
| | (7 + 7 = 14) | (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |M| Tag | Ext-Type |
| (0) |0| (0) | (10) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Length | Value | | |
| (2 + 5 = 7) | (H) | (e) | (l) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| (l) | (o) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
Now consider another instantiation of the Foo Extended Attribute,
this one with a length of 251 octets. In this case the value is
fragmented over two Extended Attributes. The first 246 octets are
included in the first fragment which has the More bit set and the
remaining 5 octets appear in the second attribute. Figure 2 below
illustrates the encoding of the first 7 octets of the first Extended
Attribute (Foo(0,6) = "Hello W"), while Figure 3 shows how the second
attribute (Foo(246,250) = " end.") is encoded.
Li, et al. Expires May 13, 2008 [Page 7]
Internet-Draft Extended RADIUS Attributes November 2007
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 |
| |(7 + 248 = 255)| (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |M| Tag | Ext-Type |
| (0) |1| (0) | (10) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Length | Value | | |
|(2 + 246 = 248)| (H) | (e) | (l) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| (l) | (o) | ( ) | (W) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
Figure 2
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 |
| | (7 + 7 = 14) | (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |M| Tag | Ext-Type |
| (0) |0| (0) | (10) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Length | Value | | |
| (2 + 5 = 7) | ( ) | (e) | (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| (d) | (.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3
The next example illustrates several of the features of Extended
Attributes:
o encapsulation of values greater than 253 octets in length
o grouping of related Extended Attributes using tags
o encapsulation of more than one TLV in a single Extended Attribute
Consider the following structure:
Li, et al. Expires May 13, 2008 [Page 8]
Internet-Draft Extended RADIUS Attributes November 2007
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 Extended Type of
27. The following figure illustrates the coding where a(0,20) =
0xDEADDEAD, b(0,1) = "He", b(243,250) = "The end." and is of length
251 octets; and c(0,27) = 0x12345678. The attributes are grouped
together with TAG=42. For the sake of brevity, the value of b(3,241)
is omitted.
Li, et al. Expires May 13, 2008 [Page 9]
Internet-Draft Extended RADIUS Attributes November 2007
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 |
| | (7 + 6 = 13) | (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |M| Tag | Ext-Type |
| (0) |0| (42) | (20) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Length | Value | | |
| (2 + 4 = 6) | (0xDE) | (0xAD) | (0xDE) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| (0xAD) |
+-+-+-+-+-+-+-+-+
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 |
| |(7 + 248 = 255)| (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |M| Tag | Ext-Type |
| (0) |1| (42) | (25) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Length | Value | |
|(2 + 246 = 248)| (H) | (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
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 |
| | (7+7+6=20) | (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |M| Tag | Ext-Type |
| (0) |0| (42) | (25) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Length | Value | | |
| (2 + 5 = 7) | ( ) | (e) | (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Ext-Type | Ext-Length |
| (d) | (.) | (27) | (2 + 4 = 6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | | |
| (0x12) | (0x34) | (0x56) | (0x78) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Li, et al. Expires May 13, 2008 [Page 10]
Internet-Draft Extended RADIUS Attributes November 2007
Figure 4
7. Security Considerations
TBD
8. IANA Considerations
This solution requires that the IETF be allocated Vendor-Type of zero
to the IETF.
It also requires that IANA set up a new registry for the RADIUS
Extended Attribute Types.
9. 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 octet for Extended Type. Is that too little?
Note, if we run out the IETF can request another enterprise number.
10. References
10.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)",
RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
10.2. Informative References
[IANA] Internet Assigned Number Authority, "RADIUS TYPES",
August 2007,
<http://www.iana.org/assignments/radius-types>.
Li, et al. Expires May 13, 2008 [Page 11]
Internet-Draft Extended RADIUS Attributes November 2007
[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: +1 (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: +1 (613) 591-6655
Email: avi@bridgewatersystems.com
URI: http://www.bridgewatersystems.com/
Glen Zorn
NetCube
1310 East Thomas Street
#306
Seattle, WA 98102
United States of America
Phone: +1 (206) 377-9035
Email: glenzorn@comcast.net
Li, et al. Expires May 13, 2008 [Page 12]
Internet-Draft Extended RADIUS Attributes November 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 May 13, 2008 [Page 13]
