Network Working Group B. Wolff, Ed. Internet-Draft Databus Inc. Expires: August 30, 2006 G. Weber Cisco Systems February 26, 2006 Extended RADIUS Attributes draft-wolff-radext-ext-attribute-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 August 30, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The RADIUS protocol is being extended beyond the wildest imaginations of its original designers. These extensions are pushing up against the existing limitations on the numbers, length, base types and grouping of RADIUS attributes. This document specifies a method of relaxing those limitations. Wolff & Weber Expires August 30, 2006 [Page 1] Internet-Draft Extended RADIUS Attributes February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Extended-Space Attribute . . . . . . . . . . . . . . . . . . . 3 2.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Attribute Format . . . . . . . . . . . . . . . . . . . . . 4 2.2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 4 2.2.2. Concatenation . . . . . . . . . . . . . . . . . . . . 4 2.2.3. Alignment and Padding . . . . . . . . . . . . . . . . 4 2.2.4. Additional Data Types . . . . . . . . . . . . . . . . 5 2.3. M-bit . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. P-bit . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5. Vendor-Specific Attributes . . . . . . . . . . . . . . . . 5 2.6. Interoperability and Proxy Considerations . . . . . . . . 6 2.7. RADIUS Message Types . . . . . . . . . . . . . . . . . . . 6 3. Diameter Considerations . . . . . . . . . . . . . . . . . . . 6 3.1. Interworking with Diameter . . . . . . . . . . . . . . . . 6 3.2. No RADIUS-Only Attributes . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 8 Appendix B. Encoding Example . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Wolff & Weber Expires August 30, 2006 [Page 2] Internet-Draft Extended RADIUS Attributes February 2006 1. Introduction The Remote Authentication Dial In User Service (RADIUS) protocol [RFC2865] is being extended beyond the wildest imaginations of its original designers. These extensions are pushing up against the existing limitations on the numbers, length, base types and grouping of RADIUS attributes. This document specifies a method of relaxing those limitations. An Extended-Space attribute is defined for RADIUS. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Extended-Space Attribute This document defines a new RADIUS standard attribute, Extended- Space. 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... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +---------------------+------------------------------+ | Field | Description | +---------------------+------------------------------+ | Type | TBD | | Length | >=3 | | String | Formatted as described below | +---------------------+------------------------------+ 2.1. Purpose RADIUS has, from any reasonable perspective, been a successful protocol. However some limitations have become apparent: o We are approaching the point where the limit of 256 possible attribute type numbers may be reached. o In some cases the limit of 253 bytes for attribute value length is inadequate. o The set of standard attribute value types is inadequate. o The facility for attribute grouping (tags) is limited in the number of groups and allows no nesting. Extended-Space removes all of these limitations, as described below. Wolff & Weber Expires August 30, 2006 [Page 3] Internet-Draft Extended RADIUS Attributes February 2006 2.2. Attribute Format The format of the Value portion is a sequence of one or more Diameter-format attributes as specified in Section 4 of [RFC3588]. 2.2.1. Rationale The choice to encapsulate newly-defined attributes rather than change the basic RADIUS TLV attribute format is forced by the requirement for interoperability with existing RADIUS clients, proxies and servers. An older implementation may not understand the contents of the new attribute, but it MUST be able at least to skip over it. The choice to use the Diameter attribute format is motivated by the expectation that interworking between RADIUS and Diameter will be increasingly common, and a conviction that defining facilities and services in RADIUS without also defining them in Diameter is unwise. It would be easy to find another representation (eg, BER [ISO.8825.1990] ) that might in some ways be superior to the Diameter format, or to invent yet another TLV format. Such optimization at the expense of interworking is deemed an unprofitable trade. 2.2.2. Concatenation The concatenation of the values of all instances of Extended-Space in a RADIUS message is a logical Extended-Space attribute, which consists of a sequence of one or more Diameter-format attributes. There is no defined or expected relationship between the boundary of a particular Extended-Space attribute and any enclosed Diameter- format attribute. There is no requirement that all instances of Extended-Space attribute except the last be of maximum length, although the generation of a myriad of tiny Extended-Space instances would reflect badly on the implementor. Note well that the existing length limit for a complete RADIUS message of 4096 bytes continues in effect. 2.2.3. Alignment and Padding In Diameter itself, each attribute starts on a 4-byte boundary. This convenience cannot be maintained in RADIUS, because the TL part of TLV is 2 bytes and there is no requirement that an attribute start on any particular boundary. If an implementation needs assurance of 4-byte alignment, it can copy the concatenated values of the Extended-Space instances to an aligned buffer. Padding as specified in section 4 of [RFC3588] MUST be included. An implementor will naturally be tempted to omit the padding from the Wolff & Weber Expires August 30, 2006 [Page 4] Internet-Draft Extended RADIUS Attributes February 2006 last Extended-Space instance, especially when such padding would require the generation of an extra instance containing only padding. This temptation MUST be resisted, as a proxy might add another instance of its own to the end of a RADIUS message. A RADIUS implementation that receives a message where the total length of the (logically or actually) concatenated value fields of the Extended- Space instances is not a multiple of 4 SHOULD treat this error as it would any other format-related error, such as a TLV length field of less than 2 (or 3, if an empty V is considered a format error). 2.2.4. Additional Data Types Extended-Space is of type String. The extended attribute(s) that it contains may use any of the data types defined for Diameter attributes. 2.2.4.1. Grouping Extended attributes may be of data type Grouped. In this case, as with Diameter attributes, the specification which defines them must include an ABNF specification [RFC4234] describing the contents of each such attribute. 2.3. M-bit The Mandatory bit in the attribute header will be supported by implementations that support Extended-Space. Unlike Diameter, however, proxies that are unaware of Extended-Space will not parse the internal contents of those attributes and thus cannot reject messages based on unknown mandatory attributes. 2.4. P-bit Until use of the P-bit in the Diameter AVP header is defined, it SHOULD be treated as specified for the reserved bits in [RFC3588]. 2.5. Vendor-Specific Attributes The Diameter AVP header includes provision for a Vendor field, allowing vendor-specific attributes. Vendors SHOULD use standard base types and formats in defining vendor-specific attributes, and standard group formats, so that if a vendor-specific attribute attains wide use it can be converted into a standard attribute simply by publishing a specification, assigning a number, setting V=0 and removing the vendor field. Wolff & Weber Expires August 30, 2006 [Page 5] Internet-Draft Extended RADIUS Attributes February 2006 2.6. Interoperability and Proxy Considerations Unless and until support for Extended-Space becomes universal, a RADIUS speaker wishing to use it must face the risk that the recipient, or a proxy, will not understand or support it and may react badly. Some ways to minimize this risk: 1. Receiving an Extended-Space from a given source can be taken as strong evidence that it is safe to reply with one. 2. If RADIUS acquires a capability negotiation or indication mechanism, use of Extended-Space is an obvious subject. 3. Least desirable would be a per-partner or global configuration flag. The implication of the first item above is that a sender of Extended- Space MUST be prepared to accept one. But there is a further implication for proxies, even extending to proxies that do not understand or support Extended-Space: a proxy MUST NOT react differently to Extended-Space in requests and responses. That is, if a proxy silently discards RADIUS messages on the grounds that an unknown attribute has been found, or prunes the attribute from the messages, it MUST do so consistently on both requests and responses. This is in one sense a retroactive requirement, usually a very bad idea. However it seems justified in that inconsistent proxy behavior is unreasonable even in the absence of an explicit requirement. 2.7. RADIUS Message Types Extended-Space MAY be used in all RADIUS messages other than Access- Reject. Extended-Space SHOULD NOT be used in Access-Reject unless the sender is confident that all proxies and the recipient will react well. 3. Diameter Considerations 3.1. Interworking with Diameter Extended-Space, with its encapsulated Diameter-format attributes, should require minimal intelligence from a translating gateway. The gateway MUST remove the encapsulation when translating from RADIUS to Diameter. One open question is the Diameter requirement that new mandatory attributes require a new application id. That would seem to require that the gateway derive the Diameter application id based on what it finds in the encapsulated attributes. 3.2. No RADIUS-Only Attributes The mandate that there be no applications in RADIUS that cannot be handled in Diameter implies that any new RADIUS attributes also be Wolff & Weber Expires August 30, 2006 [Page 6] Internet-Draft Extended RADIUS Attributes February 2006 defined in Diameter. This requirement applies to the attributes that Extended-Space encapsulates. It would seem pointless for Extended- Space itself to be carried in Diameter, but a translating gateway not yet aware of Extended-Space might do so blindly. 4. IANA Considerations All RADIUS attributes in the range 1-255 are automatically included in the Diameter attribute space. With Extended-Space, RADIUS attributes can now be assigned numbers greater than 255. Since any new RADIUS functionality must also be supportable in Diameter, a Diameter attribute number must be allocated for each new RADIUS attribute number. It would appear sensible, and certainly make the job of a translating gateway easier, if the numbers were the same. While anything RADIUS can do Diameter must be able to do, the converse is not true. There are already Diameter attributes that are specific to Diameter and make no sense in RADIUS. It has been suggested that the Diameter attribute number space be partitioned, with a range defined for RADIUS attributes. The advantage would be that a RADIUS implementation receiving an attribute outside the range could issue a more informative error report than simply "unknown attribute". One can also think of such a partitioning as defining a range for Diameter-only attribute numbers. The question of what relative sizes for the partitions are appropriate remains open. Also open is what to do about the existing Diameter attributes, some of which may well be desirable for use in RADIUS. Further, it is not clear that whether a particular attribute will always be Diameter- only can in all cases be known with confidence when the attribute is first defined. The requirements of [RFC3575] remain in effect for attribute numbers 1-255. Requirements for attribute numbers above 255 are stated in section 11.1.1 of [RFC3588]. 5. Security Considerations No new security implications for Extended-Space handling. Wolff & Weber Expires August 30, 2006 [Page 7] Internet-Draft Extended RADIUS Attributes February 2006 6. Table of Attributes +---------+--------+--------+-----------+---------+-----+-----------+ | Request | Accept | Reject | Challenge | Accting | # | Name | +---------+--------+--------+-----------+---------+-----+-----------+ | 0+ | 0+ | 0* | 0+ | 0+* | TBD | Extended- | | | | | | | | Space | +---------+--------+--------+-----------+---------+-----+-----------+ * In Accounting-Ack, rare, and only for vendor-specific attributes. In Access-Reject, Extended-Space SHOULD NOT be used. 7. References 7.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. [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. 7.2. Informative References [ISO.8825.1990] International Organization for Standardization, "Information Processing Systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)", ISO Standard 8825, December 1990. Appendix A. Acknowledgments Many of the issues discussed in this document are a distillation of email threads on the RADEXT WG list which is archived here: Wolff & Weber Expires August 30, 2006 [Page 8] Internet-Draft Extended RADIUS Attributes February 2006 http://ops.ietf.org/lists/radiusext/ Informal discussions with Alan DeKok, Dave Nelson and Emile van Bergen aided immensely in formulating and refining the ideas in this document. The idea to use the Diameter AVP header was Alan's. Appendix B. Encoding Example TBD Wolff & Weber Expires August 30, 2006 [Page 9] Internet-Draft Extended RADIUS Attributes February 2006 Authors' Addresses Barney Wolff (editor) Databus Inc. 15 Victor Drive Irvington, NY 10533-1919 US Email: barney@databus.com Greg Weber Cisco Systems 10850 Murdock Road Knoxville, TN 37932 US Email: gdweber@cisco.com Wolff & Weber Expires August 30, 2006 [Page 10] 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. Wolff & Weber Expires August 30, 2006 [Page 11]