draft-ietf-radext-extended-attributes-04.txt   draft-ietf-radext-extended-attributes-05.txt 
Network Working Group Y. Li Network Working Group Y. Li
Internet-Draft A. Lior Internet-Draft A. Lior
Intended status: Standards Track BWS Intended status: Standards Track BWS
Expires: January 8, 2009 G. Zorn Expires: May 6, 2009 G. Zorn
NetCube Technologies Network Zen
July 7, 2008 November 2, 2008
Extended Remote Authentication Dial In User Service (RADIUS) Attributes Extended Remote Authentication Dial In User Service (RADIUS) Attributes
draft-ietf-radext-extended-attributes-04.txt draft-ietf-radext-extended-attributes-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 January 8, 2009. This Internet-Draft will expire on May 6, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
For the Remote Authentication Dial In User Service (RADIUS) protocol For the Remote Authentication Dial In User Service (RADIUS) protocol
to continue to support new applications the RADIUS attribute type to continue to support new applications, the RADIUS attribute type
space must be extended beyond the current limit of 255 possible space must be extended beyond the current limit of 255 possible
attribute types while maintaining backwards compatibility with the attribute types while maintaining backwards compatibility with the
existing protocol. This document defines a mechanism to accomplish existing protocol. This document defines a mechanism to accomplish
that task, along with standard methods to group together related that task, along with standard methods to group together related
attributes and to encode values that don't fit into 253 octets. attributes and to encode values that don't fit into 253 octets.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. RADIUS Type Extension . . . . . . . . . . . . . . . . . . . . 4 4. RADIUS Type Extension . . . . . . . . . . . . . . . . . . . . 4
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Diameter Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 13
1. Introduction 1. Introduction
The Remote Authentication Dial In User Service (RADIUS) Protocol The Remote Authentication Dial In User Service (RADIUS) Protocol
[RFC2865] defines two classes of attributes: standard and vendor- [RFC2865] defines two classes of attributes: standard and vendor-
specific. specific.
Vendor-specific Attributes (VSAs) allow vendors (including Standards Vendor-specific Attributes (VSAs) allow vendors (including Standards
Development Organizations (SDOs)) to define their own Attributes, Development Organizations (SDOs)) to define their own Attributes,
which may not be suitable for general usage; on the other hand, the which may not be suitable for general usage; on the other hand, the
attributes that belong to the standard RADIUS space are controlled by attributes that belong to the standard RADIUS space are controlled by
the IETF and are intended to be of general utility. These attributes the IETF and are intended to be of general utility. These attributes
are defined in RFCs and are assigned type codes by the Internet are defined in RFCs and are assigned type codes by the Internet
Assigned Number Authority (IANA)[IANA]. Assigned Number Authority (IANA)[IANA].
The standard RADIUS attribute type code is 8 bits in length; hence The standard RADIUS attribute type code is 8 bits in length; hence
RADIUS is limited to 255 attribute types. Of these 255 attribute RADIUS is limited to 255 attribute types. Of these 255 attribute
types, 101 or so have been assigned. According to RFC 3575 types, approximately 101 have been assigned as of this writing.
[RFC3575], types 192-223 are reserved for experimental use; types According to RFC 3575 [RFC3575], types 192-223 are reserved for
224-240 are reserved for implementation-specific use; and values 241- experimental use; types 224-240 are reserved for implementation-
255 are reserved and should not be used. Therefore, as of this specific use; and values 241-255 are reserved and should not be used.
writing there are approximately 90 type codes that can be allocated Therefore, as of this writing there are approximately 90 type codes
to new attributes. that can be allocated to new attributes.
RADIUS evolution must not be hindered by the inability to define new RADIUS evolution must not be hindered by the inability to define new
standard RADIUS attributes. This document defines a mechanism to standard RADIUS attributes. This document defines a mechanism to
extend the standard RADIUS Attribute space by defining a new scheme extend the standard RADIUS Attribute space by defining a new scheme
to allocate attribute type codes. In addition, mechanisms are to allocate attribute type codes. In addition, mechanisms are
defined to support both the grouping of related attributes and the defined to support both the grouping of related attributes and the
encoding of attribute values the length of which exceed the current encoding of attribute values the length of which exceed the current
limit of 253 octets. limit of 253 octets.
2. Terminology 2. Terminology
skipping to change at page 4, line 35 skipping to change at page 4, line 35
extensible in the event that it is. extensible in the event that it is.
Furthermore, the scheme SHOULD align with the Diameter NASReq Furthermore, the scheme SHOULD align with the Diameter NASReq
Application [RFC4005], thereby allowing the two AAA standards to Application [RFC4005], thereby allowing the two AAA standards to
interoperate. interoperate.
A need to group related RADIUS attributes together has become A need to group related RADIUS attributes together has become
prevalent in current work. Therefore, the proposed scheme SHOULD prevalent in current work. Therefore, the proposed scheme SHOULD
provide a mechanism to group related attributes together. provide a mechanism to group related attributes together.
In recent years, attribute sizes have been threatening the limit of In recent years, attribute sizes have been pushing the current limit
253 octets. Fragmentation of RADIUS attributes has always been of 253 octets. Fragmentation of RADIUS attributes has always been
possible by extending the value into another attribute of the same possible by extending the value into another attribute of the same
type; however, this approach does not always work (for example, if type; however, this approach does not always work (for example, if
more than one instance of an attribute occurs in the same RADIUS more than one instance of an attribute occurs in the same RADIUS
packet). The proposed scheme SHOULD enable the transmission of packet). The proposed scheme SHOULD enable the transmission of
attributes longer than 253 octets. attributes longer than 253 octets.
4. RADIUS Type Extension 4. RADIUS Type Extension
The solution described in this document takes the recommended VSA The solution described in this document takes the recommended VSA
format [RFC2865] as a basis for the RADIUS Extended Attributes. format [RFC2865] as a basis for the RADIUS Extended Attributes.
skipping to change at page 5, line 25 skipping to change at page 5, line 25
o The first octet contains the Type which is always Vendor-Specific o The first octet contains the Type which is always Vendor-Specific
(26) (26)
o The second octet contains the length (in octets) of the entire o The second octet contains the length (in octets) of the entire
Extended Attribute, including the Extended Attribute header and Extended Attribute, including the Extended Attribute header and
all encapsulated TLVs all encapsulated TLVs
o The next 4 octets contain the Vendor-Id (0) o The next 4 octets contain the Vendor-Id (0)
o The final octet of the header contains the More flag and Tag 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 field. If the one-bit More flag is set (1) this indicates that
the encapsulated TLV is continued in the following Extended the encapsulated TLV is continued in the following Extended
Attribute; if the More flag is clear (0) then all of the Attribute; if the More flag is clear (0) then all of the
encapsulated TLVs fit into the current Extended Attribute. The encapsulated TLVs fit into the current Extended Attribute. The
More flag MUST NOT be set if the Extended Attribute contains more 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 than one TLV. The Tag field is used to combine sets of related
Extended Attributes into simple groups. Extended Attributes into simple, one level groups.
o The Data field is an abstract container for TLVs; the Data field o The Data field is an abstract container for TLVs; the Data field
MUST contain at least one TLV. MUST contain at least one TLV.
TLVs are encoded as follows: TLVs are encoded as follows:
o The first two octets contain the Ext-Type field o The first two octets contain the Ext-Type field
o The next octet is the Ext-Length field, representing the length of o The next octet is the Ext-Len field, representing the length of
the entire TLV, including the length of the Ext-Type field (2 the entire TLV, including the length of the Ext-Type field (2
octets), the length of the Ext-Length field itself (1 octet) and octets), the length of the Ext-Len field itself (1 octet) and the
the length of the Value field (1 or more octets) length of the Value field (1 or more octets)
o The Value field consists of one or more octets comprising the o The Value field consists of one or more octets comprising the
actual data to be transmitted actual data to be transmitted
5. Formal Syntax 5. Formal Syntax
This section describes the encoding scheme used for RADIUS Extended This section describes the encoding scheme used for RADIUS Extended
Attributes. The basis of this encoding is the format recommended for Attributes. The basis of this encoding is the format recommended for
Vendor Specific Attributes in RFC 2865 [RFC2865]. Vendor Specific Attributes in RFC 2865 [RFC2865].
skipping to change at page 6, line 24 skipping to change at page 6, line 24
Type Type
26 for Vendor-Specific 26 for Vendor-Specific
Length Length
>=11 >=11
Vendor ID Vendor ID
The high-order octet is zero (0) and the low-order 3 octets are The Vendor Id field is 4 octets in length and MUST be zero
zeros (0)s representing an extended IETF RADIUS attribute (0x0000), signifying an extended IETF RADIUS attribute
M (More) M (More)
The More Flag is one (1) bit in length and MUST be present. When The More Flag is one (1) bit in length and MUST be present. When
a value to be transmitted exceeds 246 octets in length it is a value to be transmitted exceeds 246 octets in length it is
fragmented over two or more Extended Attributes. If the More Flag fragmented over two or more Extended Attributes. If the More Flag
is set (1), this indicates that the Value field of the Extended is set (1), this indicates that the Value field of the Extended
Attribute contains a fragment of a larger value, which is Attribute contains a fragment of a larger value, which MUST be
continued in the next Extended Attribute of the same Ext-Type. continued in the next Extended Attribute of the same Ext-Type.
When the More Flag is clear (0), the final (or only) fragment of When the More Flag is clear (0), the final (or only) fragment of
the value is contained in the Extended Attribute. the value is contained in the Extended Attribute. Any Extended
Attributes containing multiple fragments of the same value MUST be
in order and MUST be consecutive attributes in the packet.
Tag Tag
The Tag field is 7 bits long and MUST be present. It is used to The Tag field is 7 bits long and MUST be present. It is used to
group Extended Attributes. Extended Attributes with the same non- group Extended Attributes. Extended Attributes with the same non-
zero value in the Tag field belong to the same group. A Tag value 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 of zero (0) indicates that the attribute is not grouped. A Tag
value of all ones (0x7F) is reserved. value of all ones (0x7F) is reserved.
Data Data
skipping to change at page 7, line 15 skipping to change at page 7, line 17
1 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Type | Ext-Len | Value... | Ext-Type | Ext-Len | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ext-Type Ext-Type
Two (2) octets. Up-to-date values of the Ext-Type field are Two (2) octets. Up-to-date values of the Ext-Type field are
specified in the most recent "Assigned Numbers" [IANA]. Values specified in the most recent "Assigned Numbers" [IANA]. Values
XXXX-YYYY are reserved. 64512-65535 (0xFC00-0xFFFF) are reserved.
Ext-Len Ext-Len
>= 4. The length of the Extended Attribute, including the Ext- >= 3. The length of the Type-Length-Value tuple in octets,
Type, Ext-Length and Value fields. including the Ext-Type, Ext-Len and Value fields.
Value Value
One or more octets. One or more octets.
6. Examples 6. Examples
Consider an attribute called Foo of type String. Foo has been Consider an attribute called Foo of type String. Foo has been
allocated an Extended-Type 0f 257 by IANA. The following figure allocated an Extended-Type of 257 by IANA. The following figure
shows the encoding of Foo(0,4) = "Hello": illustrates the encoding of the string "Hello":
1 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (26) | Length | Vendor-Id | Type (26) | Length | Vendor-Id
| | (7 + 8 = 15) | (0) | | (7 + 8 = 15) | (0)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) |M| Tag | Ext-Type Vendor-Id (cont) |M| Tag | Ext-Type
|0| (0) | (0) |0| (0) | (0X01)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ext-Type (cont)| Ext-Length | Value | | Ext-Type (cont)| Ext-Len | Value | |
(257) | (3 + 5 = 8) | (H) | (e) | (0X01) | (3 + 5 = 8) | (H) | (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | |
| (l) | (l) | (o) | | (l) | (l) | (o) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Figure 1
Now consider another instantiation of the Foo Extended Attribute, Now consider another instantiation of the Foo Extended Attribute,
this one with a length of 251 octets. In this case the value is this one with a length of 251 octets. In this case the value is
fragmented over two Extended Attributes. The first 245 octets are fragmented over two Extended Attributes. The first 245 octets are
included in the first fragment which has the More bit set and the included in the first fragment which has the More bit set and the
remaining 6 octets appear in the second attribute. Figure 2 below remaining 6 octets appear in the second attribute. Figure 2 below
illustrates the encoding of the first 7 octets of the first Extended 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, while Figure 3 shows how the second attribute (containing
attribute (Foo(246,250) = "e end.") is encoded. the string "e end.") is encoded.
1 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (26) | Length | Vendor-Id | Type (26) | Length | Vendor-Id
| |(7 + 248 = 255)| (0) | |(7 + 248 = 255)| (0)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) |M| Tag | Ext-Type Vendor-Id (cont) |M| Tag | Ext-Type
(0) |1| (0) | (0) (0) |1| (0) | (0X01)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ext-Type (cont)| Ext-Length | Value | | Ext-Type (cont)| Ext-Len | Value | |
(257) |(3 + 245 = 248)| (H) | (e) | (0X01) |(3 + 245 = 248)| (H) | (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | |
| (l) | (l) | (o) | ( ) | | (l) | (l) | (o) | ( ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| (W) | ... | (W) | ...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 2 Figure 2
1 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (26) | Length | Vendor-Id | Type (26) | Length | Vendor-Id
| | (7 + 9 = 15) | (0) | | (7 + 9 = 16) | (0)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) |M| Tag | Ext-Type Vendor-Id (cont) |M| Tag | Ext-Type
(0) |0| (0) | (0) (0) |0| (0) | (0X01)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ext-Type (cont)| Ext-Length | Value | | Ext-Type (cont)| Ext-Len | Value | |
(256) | (3 + 6 = 9) | (e) | ( ) | (0X00 | (3 + 6 = 9) | (e) | ( ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | |
| (e) | (n) | (d) | (.) | | (e) | (n) | (d) | (.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Figure 3
The next example illustrates several of the features of Extended The next example illustrates several of the features of Extended
Attributes: Attributes:
o encapsulation of values greater than 253 octets in length o encapsulation of values greater than 253 octets in length
o grouping of related Extended Attributes using tags o grouping of related Extended Attributes using tags
o encapsulation of more than one TLV in a single Extended Attribute o encapsulation of more than one TLV in a single Extended Attribute
Consider the following structure: Consider the following structure:
skipping to change at page 9, line 20 skipping to change at page 9, line 21
o encapsulation of more than one TLV in a single Extended Attribute o encapsulation of more than one TLV in a single Extended Attribute
Consider the following structure: Consider the following structure:
struct struct
Integer a; Integer a;
String b; String b;
Integer c; Integer c;
endStruct endStruct
Element a is assigned an Extended Type of 290. Element b is assigned Element 'a' is assigned an Extended Type of 290 (0x0122). Element
an Extended Type of 259 and element c is assigned an Extended Type of 'b' is assigned an Extended Type of 259 (0x0103) and element 'c' is
271. The following figure illustrates the coding where a(0,20) = assigned an Extended Type of 271 (0x010F). The following figure
0xDEADDEAD, b(0,1) = "He", b(243,250) = "The end." and is of length illustrates the encoding where the value of 'a' contains 0xDEADDEAD,
251 octets; and c(0,27) = 0x12345678. The attributes are grouped the first two octets of 'b' contain the string "He", octets 243-250
together with TAG=42. For the sake of brevity, the value of b(3,241) of 'b' contain "The end." and the value of 'c' is 0x12345678. The
is omitted. attributes are grouped together with TAG=42. For the sake of
brevity, octets 3-241 of the value of 'b' are omitted from the
diagram.
1 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (26) | Length | Vendor-Id | Type (26) | Length | Vendor-Id
| | (7 + 7 = 14) | (0) | | (7 + 7 = 14) | (0)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) |M| Tag | Ext-Type Vendor-Id (cont) |M| Tag | Ext-Type
(0) |0| (42) | (0) (0) |0| (42) | (0x01)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ext-Type (cont)| Ext-Length | Value | | Ext-Type (cont)| Ext-Len | Value | |
(290) | (3 + 4 = 7) | (0xDE) | (0xAD) | (0x22) | (3 + 4 = 7) | (0xDE) | (0xAD) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| (0xDE | (0xAD) | | (0xDE) | (0xAD) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (26) | Length | Vendor-Id | Type (26) | Length | Vendor-Id
| |(7 + 248 = 255)| (0) | |(7 + 248 = 255)| (0)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) |M| Tag | Ext-Type Vendor-Id (cont) |M| Tag | Ext-Type
(0) |1| (42) | (0) (0) |1| (42) | (0x01)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ext-Type (cont)| Ext-Length | Value | | Ext-Type (cont)| Ext-Len | Value | |
(259) |(3 + 245 = 248)| (H) | (e) | (0x03) |(3 + 245 = 248)| (H) | (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
1 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (26) | Length | Vendor-Id | Type (26) | Length | Vendor-Id
| | (7+8+7=22) | (0) | | (7+8+7=22) | (0)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) |M| Tag | Ext-Type Vendor-Id (cont) |M| Tag | Ext-Type
(0) |0| (42) | (0) (0) |0| (42) | (0x01)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ext-Type (cont)| Ext-Length | Value | | Ext-Type (cont)| Ext-Len | Value | |
(259) | (3 + 5 = 8) | ( ) | (e) | (0x03) | (3 + 5 = 8) | ( ) | (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | Ext-Type | | | | Ext-Type
| (n) | (d) | (.) | (0) | (n) | (d) | (.) | (0x01)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ext-Type (cont)| Ext-Length | Value | | Ext-Type (cont)| Ext-Len | Value | |
(271) | (3 + 4 = 7) | (0x12) | (0x34) | (0x0F) | (3 + 4 = 7) | (0x12) | (0x34) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| (0x78) | (0x56) | | (0x78) | (0x56) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 Figure 4
7. Security Considerations 7. Diameter Considerations
TBD
8. IANA Considerations
This solution requires that the Vendor-Type of zero be allocated to
the IETF.
It also requires that IANA set up a new registry for the RADIUS Since the Extended Attributes are encoded as Vendor-Specific RADIUS
Extended Attribute Types. Attributes (see [IANA]), no special handling is required by Diameter
[RFC3588] entities; see [RFC4005] for details on the Diameter
treatment of RADIUS VSAs.
9. Open Issues 8. Security Considerations
What is the numbering scheme for attributes that will be used by RFC This document does not introduce any new security issues into the
writers going forward? For example today we write user-name(1). RADIUS protocol; for known security problems with RADIUS, see
[RFC2865], [RFC2869] and [RFC2607].
Going forward, will we write foo-bar(0,1)? 9. IANA Considerations
What is the numbering plan for these attributes? What (if any) range This standard requires that the Vendor-Id of zero be allocated to the
should be reserved? What should the IANA policy for allocation new IETF.
Vendor-Ids to the IETF?
It seems like RFC 4005 covers most of the question regarding Diameter It also requires that IANA set up a new registry for the RADIUS
compatibility, but a few questions remain. For example, should we Extended Types, reserving the values 64512-65535 (0xFC00-0xFFFF) for
require that the 'M' bit be set or not? future purposes. Values in this registry should be allocated using
the "IETF Review" policy [RFC5226].
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000. RFC 2865, June 2000.
10.2. Informative References 10.2. Informative References
[IANA] Internet Assigned Number Authority, "RADIUS TYPES", [IANA] Internet Assigned Number Authority, "RADIUS TYPES",
August 2007, August 2008,
<http://www.iana.org/assignments/radius-types>. <http://www.iana.org/assignments/radius-types>.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS
Extensions", RFC 2869, June 2000.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575, Authentication Dial In User Service)", RFC 3575,
July 2003. July 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005, "Diameter Network Access Server Application", RFC 4005,
August 2005. August 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Authors' Addresses Authors' Addresses
Yong Li Yong Li
Bridgewater Systems Corporation Bridgewater Systems Corporation
303 Terry Fox Drive 303 Terry Fox Drive
Suite 100 Suite 100
Ottawa, Ontario K2K 3J1 Ottawa, Ontario K2K 3J1
Canada Canada
Phone: +1 (613) 591-6655 Phone: +1 (613) 591-6655
skipping to change at page 12, line 30 skipping to change at page 12, line 32
303 Terry Fox Drive 303 Terry Fox Drive
Suite 100 Suite 100
Ottawa, Ontario K2K 3J1 Ottawa, Ontario K2K 3J1
Canada Canada
Phone: +1 (613) 591-6655 Phone: +1 (613) 591-6655
Email: avi@bridgewatersystems.com Email: avi@bridgewatersystems.com
URI: http://www.bridgewatersystems.com/ URI: http://www.bridgewatersystems.com/
Glen Zorn Glen Zorn
NetCube Technologies Network Zen
77/440 Soi Phoomjit 1310 East Thomas Street
Rama IV Road Seattle, Washington 98102
Phrakanong Klongtoie US
Bangkok 10110
Thailand
Phone: +66 (0) 6600 6480 Phone: +1 (206) 377-9035
Email: gwz@netcube.com Email: gwz@net-zen.net
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 52 change blocks. 
95 lines changed or deleted 104 lines changed or added

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