Network Working Group T. Clancy Internet-Draft LTS Intended status: Standards Track July 31, 2008 Expires: February 1, 2009 EAP Method Support for Transporting AAA Payloads draft-clancy-emu-aaapay-01 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 February 1, 2009. Abstract This document defines bindings for existing EAP methods to transport Diameter AVPs, called "AAA payloads". The primary application is to support EAP channel bindings, but this could be used for other applications as well. Clancy Expires February 1, 2009 [Page 1] Internet-Draft EAP-AAAPAY July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview and Requirements . . . . . . . . . . . . . . . . . . . 3 4. AAA Payload Format . . . . . . . . . . . . . . . . . . . . . . 4 5. Bindings for Existing EAP Methods . . . . . . . . . . . . . . . 5 5.1. Generalized Pre-Shared Key (GPSK) . . . . . . . . . . . . . 5 5.2. Pre-Shared Key (PSK) . . . . . . . . . . . . . . . . . . . 5 5.3. Passord Authenticated Exchange (PAX) . . . . . . . . . . . 6 5.4. Tunneled Transport Layer Security (TTLS) . . . . . . . . . 6 5.5. Flexible Authentication via Secure Tunneling (FAST) . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Clancy Expires February 1, 2009 [Page 2] Internet-Draft EAP-AAAPAY July 2008 1. Introduction This document defines a payload which can be securely transported by an Extensible Authentication Method (EAP) method [RFC3748] that carries arbitrary Diameter Attribute-Value Pairs (AVPs) [RFC3588]. While it may seem strange for EAP to encapsulate Authorization, Authentication, and Accounting (AAA) messages, since AAA typically encapsulates EAP, the security properties are different. In particular, AAA data transported by EAP between the client and server will be protected by an end-to-end security relationship. This provides a secure channel for doing things like channel bindings [RFC5056]. 2. Terminology In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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]. 3. Overview and Requirements Many EAP [RFC3748] methods have extensible properties that allow you to embed arbitrary data within a secure channel. This channel is secured using keys derived during the EAP authentication. These channels vary in the properties that they provide, typically either providing integrity protection or both confidentiality and integrity protection. In this document we define a payload format for encapsulating Diameter AVPs [RFC3588], and via backwards compatability [RFC4005], RADIUS TLVs [RFC2865]. We provide bindings for a variety of existing EAP methods that would allow them to transport this data. One specific application of this is to support EAP channel bindings [RFC5056][I-D.clancy-emu-chbind]. The main goal is to provide the peer and server to exchange AAA messages protected by an end-to-end security association. As such, any EAP method transporting the AAA payloads defined in this document MUST support integrity protection. To accomplish this, a method supporting AAA payloads MUST perform mutual authentication and derive session keys (i.e. MSK, etc), and during this derivation process MUST derive a unique, cryptographically independent, fresh key for protecting AAA payloads. Protocols SHOULD also support confidentiality in addition to integrity protection. Confidentiality Clancy Expires February 1, 2009 [Page 3] Internet-Draft EAP-AAAPAY July 2008 is important for identity protection, as a variety of identities can be passed over this channel. 4. AAA Payload Format This section describes the formatting for the AAA Payloads. Each payload consists of the following fields: o Version, 1 octet o Flags, 1 octet o length(Session-ID), 2 octets o Session-ID [I-D.ietf-eap-keying], arbitrary length o One or more Diameter AVPs [RFC3588], arbitrary length The version field is 1 octet. This documents defines version 0x01. The flags field is 1 octet, and is the logical AND of the following applicable values: o 0x01: Validation Failed o 0x02: Validation Inconclusive o 0x04: Validation Successful The validation flag fields are used by the EAP server to convey the success of the consistency check to the EAP peer. These flags SHOULD NOT be used in messages from the peer to server. The Session-ID field is arbitrary length and is proceeded by its 2-octet length specified in network-byte order. Following the Session-ID is an arbitrary number of Diameter AVPs. AVPs already contain a length field internally, so they can be parsed without additional information. The payload can be graphically depicted as: Clancy Expires February 1, 2009 [Page 4] Internet-Draft EAP-AAAPAY July 2008 --- bit offset ---> 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version=0x01 | Flags | length(Session-ID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... Session-ID ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... Diameter AVP 1 ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... Diameter AVP N ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 5. Bindings for Existing EAP Methods This section describes how binding tokens can be included in all current EAP methods that support secure transport of arbitrary data. Future EAP methods SHOULD describe how they can implement binding tokens. 5.1. Generalized Pre-Shared Key (GPSK) EAP-GPSK [I-D.ietf-emu-eap-gpsk] defines protected data payloads. Use by GPSK simply requires instantiation of a new protected data specifier (PData/Specifier): o 0x0000002 (IANA-TBD): AAA Payload 5.2. Pre-Shared Key (PSK) EAP-PSK [RFC4764] defines a protected channel. Use by PSK simply requires instantiation of a new EXT_Type value: o 0x01 (IANA-TBD): AAA Payload Clancy Expires February 1, 2009 [Page 5] Internet-Draft EAP-AAAPAY July 2008 5.3. Passord Authenticated Exchange (PAX) EAP-PAX [RFC4746] defines an authenticated data exchange (ADE). Use by PAX simply requires instantiation of a new ADE type: o 0x04 (IANA-TBD): AAA Payload 5.4. Tunneled Transport Layer Security (TTLS) EAP-TTLS [I-D.funk-eap-ttls-v0] uses Diameter Attribute-Value-Pairs (AVPs) for its messaging. As such it natively supports transporting AAA payloads. No protocol changes are necessary. 5.5. Flexible Authentication via Secure Tunneling (FAST) EAP-FAST [RFC4851] uses Type-Length-Values (TLVs) for its messaging. To embed binding tokens, a new TLV must be defined: o 0x15 (IANA-TBD): AAA Payload 6. Security Considerations Section 3 documented a variety of requirements for EAP methods to transport these AAA payloads. They MUST support identity protection of arbitrary payloads, and SHOULD support confidentiality. Each method's security considerations section would detail how they achieve those requirements. The payload includes the EAP Session-ID field. This is to prevent replay attacks. In particular, depending on how an EAP method implements their secured channel, it may or may not be cryptographically bound to the rest of the session. By explicitly including the EAP Session-ID, we prevent replay attacks. Implementations MUST verify the consistency of the Session-ID received in the AAA payloads. Certainly there are a whole host of issues surrounding the security of what may be contained within the AAA payload format. If the information being transported requires confidentiality, then the method SHOULD support that. Otherwise sensitive data could be disclosed. 7. IANA Considerations We require registry from a variety of IANA repositories. Clancy Expires February 1, 2009 [Page 6] Internet-Draft EAP-AAAPAY July 2008 From "EAP-GPSK PData/Specifier": o 0x0000002 (IANA-TBD): AAA Payload From "EAP EXT_Type Numbers": o 0x01 (IANA-TBD): AAA Payload From "EAP-PAX ADE Type Namespace": o 0x04 (IANA-TBD): AAA Payload From "EAP-FAST TLV Types": o 0x15 (IANA-TBD): AAA Payload 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. 8.2. Informative References [I-D.ietf-eap-keying] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-22 (work in progress), November 2007. [I-D.ietf-emu-eap-gpsk] Clancy, C. and H. Tschofenig, "EAP Generalized Pre-Shared Key (EAP-GPSK) Method", draft-ietf-emu-eap-gpsk-11 (work in progress), July 2008. [I-D.funk-eap-ttls-v0] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication Protocol Version 0 (EAP-TTLSv0)", draft-funk-eap-ttls-v0-05 (work in progress), April 2008. Clancy Expires February 1, 2009 [Page 7] Internet-Draft EAP-AAAPAY July 2008 [I-D.clancy-emu-chbind] Clancy, T. and K. Hoeper, "Channel Binding Support for EAP Methods", Internet Draft draft-clancy-emu-chbind-02, July 2008. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005. [RFC4746] Clancy, T. and W. Arbaugh, "Extensible Authentication Protocol (EAP) Password Authenticated Exchange", RFC 4746, November 2006. [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method", RFC 4764, January 2007. [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)", RFC 4851, May 2007. [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007. Author's Address T. Charles Clancy Laboratory for Telecommunications Sciences US Department of Defense College Park, MD USA Email: clancy@LTSnet.net Clancy Expires February 1, 2009 [Page 8] Internet-Draft EAP-AAAPAY July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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, THE IETF TRUST 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. Intellectual Property 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. Clancy Expires February 1, 2009 [Page 9]