Network Working Group E. van Bergen Internet-Draft E-Advies Expires: August 27, 2006 February 23, 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 27, 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 27, 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 27, 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 27, 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 27, 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 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 | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type van Bergen Expires August 27, 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 27, 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 who has an SMI Private Enterprise Number (TBD: ref) automatically gets one number space, and every standards development organisation can get either one or 2^24 number spaces. 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 27, 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... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ STD This field designates the standard or organization that governs the number space for the Vendor and Type fields. 0x00: The Vendor field contains a SMI Private Enterprise Numbers (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 non-IETF process to assign type numbers. (TBD: I'm not aware of any SDO registry at the IANA yet - 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. 0xc0: The Vendor and Type numbers are governed by this document or any later backwards compatible revision and are described below. van Bergen Expires August 27, 2006 [Page 8] Internet-Draft Extended RADIUS Attributes February 2006 All other values are reserved. Values should be allocated using the highest order bits first, ie. the next value assigned should be 0x20. Vendor If the STD field described above is 0xc0, this value MUST be set to zero upon transmission, and MUST be ignored upon reception. (TBD: alternatively, see below) 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; 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. If the STD field is 0xc0 and the Vendor field is 0, then types 0-255 are shared with RADIUS and are assigned using the assignment process given in section 6 of [RFC2865]; all other types are shared with DIAMETER. A light weight common assignment process 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, should be used at the IANA. TBD: Alternatively, DIAMETER and (extended) RADIUS could be separated by using STD 0xc0 and Vendor 1 for DIAMETER instead. The disadvantage is then that you can then represent standard RADIUS attributes in three ways instead of two: as RADIUS attributes, as extended RADIUS attributes and as DIAMETER attributes. This may be the only option if a shared yet sufficiently light weight assigment process is infeasible though. 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, van Bergen Expires August 27, 2006 [Page 9] Internet-Draft Extended RADIUS Attributes February 2006 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. 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. 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 van Bergen Expires August 27, 2006 [Page 10] Internet-Draft Extended RADIUS Attributes February 2006 the attribute type. van Bergen Expires August 27, 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 27, 2006 [Page 12] Internet-Draft Extended RADIUS Attributes February 2006 6. IANA Considerations TBD van Bergen Expires August 27, 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 27, 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 27, 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 27, 2006 [Page 16]