Network Working Group E. van Bergen Internet-Draft E-Advies Expires: August 5, 2006 February 2006 Extended RADIUS Attributes draft-evbergen-radext-extended-attributes.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 August 5, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document presents a mechanism to remove certain limitations of the RADIUS protocol, in terms of attribute number space and attribute size. Special attention is given to backward compatibility. Additionally, a simple attribute grouping mechanism is proposed. Extending the standard attribute space is desireable because the current standard space is very limited, and because practice has shown that vendors are reluctant to adopt vendor specific attributes defined by other vendors, leading to needless duplication of work and van Bergen Expires August 5, 2006 [Page 1] Internet-Draft Extended RADIUS Attributes February 2006 reduced interoperability. Reasons vary between lack of trust in other vendors' management of their attribute space and unwillingness to advertise for other vendors using their private enterprise code or name. A larger standard attribute space allows for a more lightweight assignment process than the current space, in which only about 90 attributes remain unassigned; it also demands a more organized and centralized process for assignment than a vendor's own number space, which hopefully makes vendors more comfortable when adopting attributes devised by others. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. RADIUS attributes . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Extended-Attribute . . . . . . . . . . . . . . . . . . . . 5 4. Extended Attribute space . . . . . . . . . . . . . . . . . . . 7 4.1. Extended Attribute format . . . . . . . . . . . . . . . . 7 5. Design issues . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. DIAMETER considerations . . . . . . . . . . . . . . . . . 12 5.2. RADIUS compatibility . . . . . . . . . . . . . . . . . . . 12 5.3. Structured data . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 van Bergen Expires August 5, 2006 [Page 2] Internet-Draft Extended RADIUS Attributes February 2006 1. Requirements notation 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]. van Bergen Expires August 5, 2006 [Page 3] Internet-Draft Extended RADIUS Attributes February 2006 2. Introduction This document relates to the RADIUS protocol as described in [RFC2865] and assumes the following goals: 1. to expand the common attribute number space, in order to encourage vendors to build upon each others work and improve interoperability; 2. to expand the current maximum attribute size of 253 bytes, which is insufficient to carry a standard DNS domain name, an EAP packet, many packet filtering rules and location data; 3. to create a light weight grouping method, in order to allow packets to contain multiple independent data structures consisting of an unordered set of one or more RADIUS attributes, as done earlier in [RFC2868]. This document does not intend to address all real and perceived shortcomings of RADIUS, as DIAMETER does, nor does it discard accumulated experience by inventing new or subtly transformed approaches for things that already work well. It attempts to solve only a few essential problems, and thereby to provide a foundation for further solutions. van Bergen Expires August 5, 2006 [Page 4] Internet-Draft Extended RADIUS Attributes February 2006 3. RADIUS attributes The data structures involved in this proposal are described before anything else, because that likely makes the rest of the discussion easier to follow. A new RADIUS attribute is proposed, the Extended-Attribute. This attribute may occur zero or more times in any RADIUS packet. Whenever multiple instances of this attribute are found, the contents of all instances must be concatenated before any further decoding is done, similar to the way EAP-Message [RFC2869] is treated. Concatenation during decoding takes up all instances and splitting during encoding may happen at arbitrary boundaries. Thus, at most one extended attribute space can exist in a single RADIUS packet. Concatenation renders a virtual data field, called the extended attribute space. This space can be as large as is possible considering the maximum size of a RADIUS packet, which is currently 4096 bytes. It can never be larger than the length of a single RADIUS packet. An encapsulating attribute that follows the standard RADIUS format allows us to overcome the limit of 253 octets without violating the RADIUS protocol, and allows clients, proxies and servers that do not implement support for the extended attribute format to transparently pass any set of extended attributes as opaque data. 3.1. Extended-Attribute Description This RADIUS attribute encapsulates the Extended Attribute space as described in Section 4. It follows the standard RADIUS format for opaque octet strings. A summary of this attribute is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type van Bergen Expires August 5, 2006 [Page 5] Internet-Draft Extended RADIUS Attributes February 2006 TBD for Extended-Attribute Length >= 3 String The String field contains the Extended Attribute space as defined in Section 4. If multiple instances of the Extended-Attribute are present in a packet, their values MUST be concatenated before any attempt to interpret the value is made. van Bergen Expires August 5, 2006 [Page 6] Internet-Draft Extended RADIUS Attributes February 2006 4. Extended Attribute space The Extended Attribute space is a single virtual field of which at most one may be present in any RADIUS packet. It is encapsulated by one or more instances of the RADIUS Extended-Attribute as described in Section 3.1, each instance covering up to 253 octets of this virtual field. The Extended Attribute space contains one or more Extended RADIUS attributes. Extended RADIUS attributes exist on the same conceptual level as a normal RADIUS attributes and have the same semantics, but allow for more attribute types, separate number spaces, longer values and tags contained in a fixed field that does not share a function as a flag, a tag and the first octet of the value, as in [RFC2868]. 4.1. Extended Attribute format Description Each extended attribute specifies the number space for the attribute type field, the attribute type, an optional tag, an optional reference to another set of tagged attributes, a value length and an optional value. Each attribute type number space is able to contain 2^32 attribute types. Every vendor that has been assigned an SMI Private Enterprise Number (TBD: ref) from the IANA automatically gets a number space, and every standards development organisation can get either one or 2^24 number spaces, depending on its requirements. The format for vendor-specific and non-vendor specific extended RADIUS attributes is the same, contrary to RADIUS, where each vendor is effectively assigned only one attribute. Most vendors have used their given space wisely and have adopted the standard RADIUS attribute encoding for their attribute sets, but others have not. In the extended RADIUS attribute space, each vendor gets a full number space of 2^32 attribute types, which, along with the other features offered by the extended attribute format, hopefully removes the need for re-creating a simple (but inaccessible without prior knowledge) TLV structure of their own in their values. While the syntax of the value remains entirely dependent on the attribute type in question, client vendors are strongly encouraged to follow the example of RADIUS as defined by the IETF and use standard data types whenever possible; eg. UTF-8 for strings van Bergen Expires August 5, 2006 [Page 7] Internet-Draft Extended RADIUS Attributes February 2006 intended for human consumption, binary values contained in either 4 or 8 bytes in network order for ordinal values, an so on, to allow quick adoption of their new attributes by dictionary driven server implementations. Opaque strings are not discouraged, as long as any standard authentication and authorization process can be performed using equality testing against and assignment from a stored value in a database. The format of the extended attribute is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | STD | Vendor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag | Child-Tag | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields of this structure are described as follows: STD The STD field defines the number spaces for the Vendor and Type fields. It MUST be set to one of the following values upon transmission: 0x00: The Vendor field contains a SMI Private Enterprise Number (TBD: ref) as assigned by the IANA; the Type number space is governed by the private entity designated by the Vendor number. 0x40: The Vendor number designates a Standards Development Organization (SDO) or other publically recognised process outside the IETF to assign type numbers. (TBD: I'm not aware of any SDO registry at the IANA - is there one?); the Type number space is governed by the SDO or standard process designated by the Vendor number. 0x80: The Vendor number space is governed by the IETF. Any IETF standard that wants to create a distinct Type space may be assigned a new Vendor number after expert review. Any backwards compatible revision of such a standard MUST keep the same Vendor number, otherwise a new Vendor number MUST be obtained for this van Bergen Expires August 5, 2006 [Page 8] Internet-Draft Extended RADIUS Attributes February 2006 purpose from the IANA. 0xc0: The Vendor and Type numbers are governed by this document or any later backwards compatible revision. All other values are reserved. Values should be allocated using the highest order bits first, ie. the next value assigned would be 0x20. Attributes containing a value in this field that is not understood by the recipient MUST be ignored. Vendor Together with the STD field, the Vendor field defines the number space for the Type field. The interpretation of the Vendor field depends on the value of the STD field as described above. It can contain either a SMI Private Enterprise Number (STD=0x00), a number designating an SDO (STD=0x40), a number referring to an IETF standard that requires its own Type space (STD=0x80), or one of the following values (std=0xc0): 0: The Type number space is shared with DIAMETER, where types 0-255 are RADIUS attributes and assigned using the process given in section 6 of [RFC2865]; types 256 through 2^32-1 should ideally be assigned using a light weight assignment process at the IANA that reserves a number in both the DIAMETER space and the extended attribute space, even when an attribute is in practice only meaningful in either DIAMETER or RADIUS context. 1: Reserved. This value MUST NOT be set upon transmission. Alternatively, if sharing the extended RADIUS space and DIAMETER is undesireable or politically infeasible, Vendor=0 could be used for attributes in the RADIUS and Extended RADIUS attribute type number space only and Vendor=1 for attributes from the DIAMETER number space. (Decision TBD) 2: The Type number space is defined by the parent attribute. This value SHOULD be used when an attribute has no meaning except as a member of a structured set of attributes attached to another attribute. See the description of the Tag and Child-Tag fields. All other values MUST NOT be set upon transmission except when a future revision of this document specifies otherwise; if a recipient does not understand the meaning of the value of this van Bergen Expires August 5, 2006 [Page 9] Internet-Draft Extended RADIUS Attributes February 2006 field, the attribute MUST be ignored. Type The attribute type number. There are 2^32 possible attribute types available for assignment in each of the 2^32 number spaces created by the STD and Vendor fields. The word Type may be confusing but is historic in RADIUS. In DIAMETER, this field is referred to as the AVP Code. In any case, each Type represents a particular attribute or data item, not a data type. Multiple instances of each attribute type may exist; the relative ordering among instances of the same attribute type MUST be preserved by all parties. Tag The Tag is a number that groups attributes of different types together into a single data structure. Using this field, up to 255 of these data structures can exist in any RADIUS packet containing the extended RADIUS attribute space. This facility allows structures composed of a set of RADIUS attributes without relying on relative attribute ordering, removing the need for each instance of such a compound data structure to include the same number of instances of each attribute type. See also [RFC2868], which uses the same concept but a different way to represent the tags. A Tag value of zero does not represent any particular group. When no grouping is intended, the Tag field MUST be set to zero. Child-Tag If the value of this field is non-zero, the attribute containing this field refers to a data structure consisting of the set attributes tagged with the same value. This facility allows any attribute to refer to a particular set of tagged attributes as its subordinates, and thus allows structures of arbitrary depth, without recursive parsing and while preserving a flat list of attributes and a flat, numbered list of compound structures. Using this facility, each instance of any attribute type gets the ability to convey both its own value and a unique set of attributes. van Bergen Expires August 5, 2006 [Page 10] Internet-Draft Extended RADIUS Attributes February 2006 Splitting a data structure into subattributes by tagging them and having the parent attribute refer to the tag value using Child- Tag, allows for deeper access by dictionary driven implementations into compound data structures, which would otherwise require specific knowledge about the particular attribute. Attributes can either have a normal value and refer to at most one tagged set of attributes using its Child-Tag field, or refer to a list of tagged sets of attributes, by having one or more tags as their value. Example: a IPv6 prefix to route to a user, could be given by an attribute Ext-Framed-IPv6-Route (999), containing a subattribute 1 that specifies a prefix length in bits and a subattribute 2 that specifies the prefix, as follows: STD VND Type Tag Child-Tag Length Data 0xc0 0x00 999 0 1 12 0xc0 0x02 1 1 0 13 96 0xc0 0x02 2 1 0 24 <12 octets IPv6 prefix> Length The total length of the attribute, excluding padding to a multiple of 4 octets. The next attribute can thus be found at (length + 3) & ~ 3 octets from the beginning of the current attribute. Value The value of the attribute. The size of this field in octets is given by the value of the Length field after subtracting the size of the attribute header (8 octets). All values MUST be padded on the right to a multiple of 4 octets. Zero-sized values are allowed. The meaning of each possible value depends entirely on the attribute type. van Bergen Expires August 5, 2006 [Page 11] Internet-Draft Extended RADIUS Attributes February 2006 5. Design issues This proposal involves a number of design choices. The following ones are addressed in more detail: o sharing the attribute number space with DIAMETER vs. adopting the DIAMETER TLV format and flag semantics; o whether or not to allow existing attributes to use the proposed new encoding; o structured data types in vales vs. creating a structure containing attributes; 5.1. DIAMETER considerations Blah. 5.2. RADIUS compatibility Blah. 5.3. Structured data Blah. van Bergen Expires August 5, 2006 [Page 12] Internet-Draft Extended RADIUS Attributes February 2006 6. IANA Considerations TBD van Bergen Expires August 5, 2006 [Page 13] Internet-Draft Extended RADIUS Attributes February 2006 7. Security Considerations Since neither a new authentication mechanism is proposed nor any new attribute protection scheme is suggested, this document is not believed to add or remove any security in the RADIUS protocol. 8. 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. [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000. van Bergen Expires August 5, 2006 [Page 14] Internet-Draft Extended RADIUS Attributes February 2006 Author's Address Emile van Bergen E-Advies Heysterbachstraat 92 3312 JL Dordrecht The Netherlands Email: emile@e-advies.nl van Bergen Expires August 5, 2006 [Page 15] Internet-Draft Extended RADIUS Attributes February 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. van Bergen Expires August 5, 2006 [Page 16]