AAA Working Group D. Mitton Internet-Draft RSA Security, Inc. Category: Standards Track February 2006 Diameter/RADIUS Vendor Specific AVP Translation draft-mitton-diameter-radius-vsas-01.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 document is an individual submission to the Authentication, Authorization and Accounting (AAA) Working Group of the Internet Engineering Task Force (IETF). Comments are welcome should be submitted to the mailing list aaa-wg@merit.edu. Copyright (C) The Internet Society 2006. D. Mitton Expires Aug 2006 [Page 1] INTERNET-DRAFT Diameter/RADIUS VSA Translation Feb 2006 Abstract This document describes how a Diameter protocol application would interact with a RADIUS protocol application with respect to translation of Vendor Specific Attributes and AVPs in both networks. This interactions between Diameter applications and RADIUS specified in this document are in addition to that specified in the Diameter Base, the Diameter NAS Application and RADIUS. In this sense, this document extends the Base Diameter protocol and requests an addition to the RADIUS attribute space. D. Mitton Expires Aug 2006 [Page 2] INTERNET-DRAFT Diameter/RADIUS VSA Translation Feb 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. RADIUS Vendor Specific Attributes (VSA) . . . . . . . . 4 2.2. Diameter Vendor Specific Attribute Value Pairs . . . . . 5 3. Translation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Issues . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Technical Differences . . . . . . . . . . . . . . . . . 6 4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. RADIUS VSA data in Diameter . . . . . . . . . . . . . . 7 4.2. Diameter VSA data in RADIUS . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property Considerations . . . . . . . . . . . . . . . . 13 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . . 13 D. Mitton Expires Aug 2006 [Page 3] INTERNET-DRAFT Diameter/RADIUS VSA Translation Feb 2006 1. Introduction This document describes how a Diameter protocol application would interact with a RADIUS protocol application with respect to translation of Vendor Specific Attributes and AVPs in both networks. RFC 4005 [DiameterNAS] describes how RADIUS functionality should represented within the Diameter AAA protocol. However there are issues when translating between the two different formats because of the differences in capabilities. This draft specifies methods where RADIUS VSAs and Diameter Vendor Specific AVPs could be exchanged with minimum transformational knowledge and no loss of information. 2. Background 2.1. RADIUS Vendor Specific Attributes RFC 2865 [RADIUS] Section 5.26 Attribute 26 describes the VSA format which includes an SMI identifier and a value string. Section 5.26 continues to describe that the string SHOULD encode a sequence of vendor type / vendor length / values fields. It gives an example format that has a one octet Vendor Type field and one byte Vendor Length. RADIUS VSA Generic: 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 = 26 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute-Specific... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- D. Mitton Expires Aug 2006 [Page 4] INTERNET-DRAFT Diameter/RADIUS VSA Translation Feb 2006 RADIUS VSA Suggested format: 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 = 26 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Type | Vendor Length | Attribute-Specific... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2.2. Diameter Vendor Specific Attribute Value Pairs RFC 3588 [DiameterBase] Section 4.1 defines the Vendor-Specific AVP bit flag. When the V-bit is set, it indicates that the AVP has a Vendor- Specific Type code. The Vendor Type code is not IANA assigned, though the RFC suggests that the first 255 values be reserved for RADIUS compatibility. The Vendor-ID code is the SMA Enterprise code [ASSIGNNO]. Diameter AVP values have a 24 bit length. Diameter Vendor-Specific AVP 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V M P r r r r r| AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute-Specific... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- where V=1, M=x, P=x 3. Translation D. Mitton Expires Aug 2006 [Page 5] INTERNET-DRAFT Diameter/RADIUS VSA Translation Feb 2006 3.1. Goals One goal of Diameter was to allow Diameter systems to operate as a superset of the RADIUS functionality. Diameter should be able to accomodate RADIUS attributes with minimal per attribute knowledge (per RFC 4005 Section 9). Conversely, whenever possible, Diameter capabilities should translate into RADIUS cleanly. In a mixed network, RADIUS and Diameter systems will not generally know which peer they will be communicating with, and while such information can be configured, it should not be necessary. Vendors are to be discouraged from creating VSAs that are substantially different in each protocol. And should consider their encodings formats carefully in coexistence situations. The translation between RADIUS and Diameter should involve as few as possible exception cases on a per attribute basis. A Diameter/RADIUS gateway should not have to have a VSA dictionary for each vendors equipment. 3.2. Issues At this writing RADIUS devices are the majority of AAA applications in the field. Many RADIUS devices operate well and do not justify an effort to retrofit Diameter on them. There is a installed legacy base of RADIUS equipment that has an established base of practice that must be accomodated. Diameter practices are still in their formative stages, and attention should be paid to forward compatible operations. RFC 4005, Diameter NAS Application, Section 9.6, describes a transformation that works only for RADIUS VSAs that meet the SHOULD format. The described transform maps one byte into the Diameter Vendor space. It cannot transparently deal with codes greater than 255. And other RADIUS formats would require special knowledge and formats. 3.3. Technical Differences Many RADIUS vendors found the suggested one byte type code indequate and expanded their format to a two or four byte type code. Given there is no expansion technique defined, it is not possible, without Vendor Specific knowledge to recognize a such a differently formated VSA. RADIUS systems that use these attributes must be specially coded to recognize them. D. Mitton Expires Aug 2006 [Page 6] INTERNET-DRAFT Diameter/RADIUS VSA Translation Feb 2006 Diameter Vendor Attributes use the setting of the V-flag in the header to indicate that the Base Diameter Type code is Vendor Specific and is 32 bits wide. When the V-Flag is set, a Vendor SMI code is included in the Diameter message header. Diameter AVPs data field can be >16K bytes long (length 24 bits). RADIUS attributes can only be upto 253 bytes long, which doesn't include the SMI value. To handle longer values, there must be a chaining and concatenation process. 4. Proposed Solution This document proposes two solutions. In order to accomodate RADIUS VSAs of unknown formats, an attribute format is defined that allows these formats to flow un-interpretted into a Diameter network. Devices that wish to understand them, can apply the same decoding code that they would use in a RADIUS network. The complexity of the issue has not been increased or forced on the gateway systems. In order for RADIUS devices to receive Diameter attributes, Vendor Specific or otherwise, this documet proposes a generic encapsulation that allows RADIUS systems to examine Diameter attributes (if they want too) without a loss of content. Note that both of these transformations do not lose information, so a transformation via multiple environments would be possible. 4.1. RADIUS VSA data in Diameter Because they come in various non-standard formats RADIUS VSA data should treated transparently and directly presented in a Diameter Base AVP of type 26. Format-wise this is not a Diameter VSA, but it doesn't differ by much. It SHOULD be treated as another logical form of VSA. This requires a Diameter change, as this AVP value is currently not allowed by RFC 4005, section 9.4. Diameter speaking applications could parse the RADIUS information with the same processing that a similar RADIUS application would use. Diameter applications that wish to communicate directly with RADIUS applications can use this format to send responses. When forwarding from a Diameter network to a RADIUS network. Lengths greater than 249 are NOT allowed and MUST be discarded. D. Mitton Expires Aug 2006 [Page 7] INTERNET-DRAFT Diameter/RADIUS VSA Translation Feb 2006 Diameter AVP #26 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V M P r r r r r| AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute-Specific... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- where V=0, M=0, P=0 Diameter AVP Type = 26 RADIUS VSA type Diameter Length = length of VSA data Diameter Flags: V=0, M=0, P=0 Data: Vendor Code (begining of RADIUS 26 data) Remaining data Diameter AVP #26, RFC 2865 Suggested Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V M P r r r r r| AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Type | Vendor Length | Attribute-Specific... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- where V=0, M=0, P=0 4.2. Diameter VSA data in RADIUS Diameter gateways that wish to forward Diameter format VSAs to RADIUS applications should transform the data in to a RADIUS attribute format as shown below. This format is subject to review in the RADIUS Extentions Working Group (RADEX). D. Mitton Expires Aug 2006 [Page 8] INTERNET-DRAFT Diameter/RADIUS VSA Translation Feb 2006 RADIUS Diameter Vendor AVP: 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 = TBA | Length |V M P r r r r r| Segment | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Id (first segment only) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Type (first segment only) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute-Specific... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where V=1 for first, 0=continuation, Flags M & P retrain their Diameter values. RADIUS Type = TBA RADIUS Length (3~255) Flags = from Diameter message Segment = 0-63, Segment number for data lengths greater than 242, Vendor Code = 4 bytes from the Diameter Vendor Code Vendor Type = 4 bytes from the Diameter VSA Type code Vendor data = upto 242 bytes For Diameter values with lengths greater than 242, the additional data would be put in consecutive attributes, in the same manner as EAP [RADIUS-EAP], [DiameterEAP]. The Segment field will be zero for the first attribute, and each sucessive attribute data segment will increment the Segment field. The Vendor-Id and Vendor-Type SHALL not be repeated. Note that RADIUS applications that do not understand the Vendor's attributes will not honor the Diameter M and P flags. These flags have no meaning in RADIUS, but are preserved for vendor specific meaning and potential transport back to Diameter. 5. IANA Considerations This document defines the use of a RADIUS type 26 attribute code in the Diameter Protocol space as defined in [DiameterBase] and [DiameterNAS]. It also calls for the assignment of a RADIUS attribute type to encapsulate Diameter Vendor Specific AVPs. The IANA references are [DiameterTypes] and [RADIUSTypes]. D. Mitton Expires Aug 2006 [Page 9] INTERNET-DRAFT Diameter/RADIUS VSA Translation Feb 2006 6. Security Considerations This document does not contain a security protocol, it describes an addition to the existing Diameter and RADIUS protocols. All security issues of those protocols must be considered in implementing this specification. This extention does not add any unique concerns. D. Mitton Expires Aug 2006 [Page 10] INTERNET-DRAFT Diameter/RADIUS VSA Translation Feb 2006 7. References 7.1. Normative References [DiameterBase] P. Calhoun, et.al, "Diameter Base Protocol", RFC 3588, Sept 2003. [DiameterNAS] P. Calhoun, et.al, "Diameter NAS Application", RFC 4005, Mar 2005. [DiameterTypes] IANA, "AAA Parameters", URL: [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [ASSIGNNO] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. [RADIUSTypes] IANA, "RADIUS Types", URL: [IANAConsid] Narten, Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998 [IANA] IANA Assigned Numbers Database, URL: [Keywords] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [RADIUS-IANA] B. Aboba, "IANA Considerations for RADIUS", RFC 3575, August 2003. [NASCriteria] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access Server Protocols", RFC 3169, September 2001. [AAACriteria] Aboba, et al., "Criteria for Evaluating AAA Protocols for Network Access", RFC 2989, Nov 2000. D. Mitton Expires Aug 2006 [Page 11] INTERNET-DRAFT Diameter/RADIUS VSA Translation Feb 2006 [RADIUS-EAP] B. Aboba, P. Calhoon, "RADIUS Support for EAP", RFC 3579, Jun 2003. [DiameterEAP] P. Eronen, T. Hiller, G. Zorn, "Diameter EAP Application", draft-ietf-aaa-eap-10.txt, Work-in-progress, Nov 2004 8. Acknowledgements The author would like to thank Glen Zorn for looking after this issue in spite of Section 9 of RFC 4005, which I wrote. And my co-chairs Bernard Aboba and John Loughney for suggesting this document. 9. Authors' Addresses Questions about this memo can be directed to: David Mitton RSA Security, Inc. 174 Middlesex Turnpike Bedford, MA 01730 Email: dmitton@circularnetworks.com D. Mitton Expires Aug 2006 [Page 12] INTERNET-DRAFT Diameter/RADIUS VSA Translation Feb 2006 Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full 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. 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. D. Mitton Expires Aug 2006 [Page 13]