EAP Working Group Y. Ohba Internet-Draft Toshiba Expires: November 12, 2005 May 11, 2005 AAA-Key Derivation with Channel Binding draft-ohba-eap-aaakey-binding-00 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 November 12, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes an alternative method for deriving a AAA-Key. The method cryptographically binds EAP lower-layer parameters to the AAA-Key without need to carry those parameters in EAP methods. Ohba Expires November 12, 2005 [Page 1] Internet-Draft AAA-Key Binding May 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Solution Framework . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Key Binding Blob for Lower-Layer Parameters . . . . . . . 4 2.2 AAA-Key Derivation Algorithm . . . . . . . . . . . . . . . 4 2.3 AAA-Key Scope . . . . . . . . . . . . . . . . . . . . . . 4 2.4 AAA-Key Name . . . . . . . . . . . . . . . . . . . . . . . 4 2.5 Key Binding Procedure . . . . . . . . . . . . . . . . . . 5 3. AAA Protocol Consideration . . . . . . . . . . . . . . . . . . 6 4. Recommendations to EAP Lower-Layer . . . . . . . . . . . . . . 7 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1 Normative References . . . . . . . . . . . . . . . . . . . 11 8.2 Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 12 Ohba Expires November 12, 2005 [Page 2] Internet-Draft AAA-Key Binding May 2005 1. Introduction EAP (Extensible Authentication Protocol) is an authentication framework which supports multiple authentication algorithms known as "EAP methods" [RFC3748]. EAP lower- layers use a key generated and exported by an EAP method to bootstrap their ciphersuites. This key is referred to as AAA-Key. A framework for the generation, transport and usage of AAA-Key is described in [I-D.ietf-eap-keying]. Each EAP lower-layer has its own parameters that are carried at the lower-layer. EAP lower-layer end-point identifiers are one of such parameters. Those parameters would need to be cryptographically bound to the AAA-Key to avoid a possible man-in-the-middle attack which is also known as the lying NAS problem. A mechanism that is described in [RFC3748] to create such a binding is based on communicating lower-layer parameters over a protected channel of an EAP method to help the EAP peer and the EAP server detect a mismatch between the parameters exchanged over the protected channel and the ones advertised at an unprotected lower-layer. There have been several solutions [I-D.arkko-eap-service-identity-auth] [I-D.tschofenig-eap-ikev2] that are based on this mechanism. This document describes an alternate mechanism for creating a binding between a AAA-Key and EAP lower-layer parameters without need for an EAP method to carry the EAP lower-layer parameters. Ohba Expires November 12, 2005 [Page 3] Internet-Draft AAA-Key Binding May 2005 2. Solution Framework In this solution, it is the EAP lower-layer entities that makes the final decision as to whether the the lower-layer parameters are successfully bound to the AAA-Key, regardless of the location of the EAP server. Assuming that there is not always trust relationship between EAP peer and EAP authenticator, the EAP server with which both the EAP peer and EAP authenticator have trust relationship needs to involve in the process of binding the EAP lower-layer parameters to the AAA-Key. However, the EAP server should not need to have knowledge on specific EAP lower-layer parameters to be bound to the AAA-Key. Similarly, a AAA protocol should not need to have knowledge on the specific EAP lower-layer parameters to be bound to the AAA-Key. 2.1 Key Binding Blob for Lower-Layer Parameters Each EAP lower-layer must define a blob that is an octet string carrying lower-layer parameters that need to be bound to the AAA-Key. Such a blob is referred to as a key-binding-blob. It is the responsibility of each EAP lower-layer to define how the lower-layer parameters is encoded in the key-binding-blob. 2.2 AAA-Key Derivation Algorithm As a result of successful authentication, the EAP peer and EAP server derives a AAA-Key from the MSK [I-D.ietf-eap-keying] exported by the EAP method as follows. AAA-Key = PRF(MSK, AAA-Key-name|key-binding-blob) PRF is a pseudo random function. The definition of PRF is TBD. AAA- Key-name is the name of the AAA-Key. The format of the name of AAA- Key is described in Section 2.4 2.3 AAA-Key Scope The scope of a AAA-Key is between the pair of a particular EAP peer and a particular EAP authenticator. The AAA-Key MUST NOT be shared among multiple EAP authenticators or multiple EAP peers. 2.4 AAA-Key Name The name of a AAA-Key is concatenation of "AAA-Key", the EAP peer identifier, the EAP authenticator identifier and the EAP Session-Id. When a AAA protocol is used between the EAP authenticator and the EAP server, the EAP peer identifier and the EAP authenticator identifier Ohba Expires November 12, 2005 [Page 4] Internet-Draft AAA-Key Binding May 2005 are identical to the Called-Station-Id and the Calling-Station-Id attributes, respectively. The format of EAP peer identifier and EAP authenticator identifier must be defined by each EAP lower-layer. 2.5 Key Binding Procedure During an EAP authentication run, the EAP authenticator constructs a key-binding-blob from the EAP lower-layer parameters and sends the key-binding-blob to the EAP server. When the EAP authenticator is acting as a pass-through authenticator, a AAA protocol would be used for communicating the key-binding-blob to the EAP server. Upon successful EAP authentication, the EAP peer and the EAP server are expected to compute the AAA-Key using the above algorithm. The computed AAA-Key is delivered from the EAP server to the EAP authenticator. Finally, the EAP peer and the EAP authenticator verify the possession of the AAA-Key via a secure association protocol to establish a secure association. For the verification process to succeed, it is required for the EAP authenticator to have obtained the same AAA-Key from the EAP server as the EAP peer has. This actually requires the EAP authenticator to have sent the same key-binding-blob to the EAP server as the one the EAP peer constructs from the lower-layer parameters obtained via the lower-layer protocol. Ohba Expires November 12, 2005 [Page 5] Internet-Draft AAA-Key Binding May 2005 3. AAA Protocol Consideration When a AAA protocol such as RADIUS [RFC2865] and Diameter [RFC3588] is used for carrying EAP messages between an EAP authenticator and the EAP server, the key-binding-blob is carried in a AAA protocol as a AAA attribute. The Key-Binding-Blob attribute, which is a new RADIUS attribute, is defined for this purpose. Since Diameter has a backward compatibility with RADIUS, it is possible to automatically convert a RADIUS attribute to a corresponding Diameter AVP and vise versa. 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 | Opaque Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD Represents Key-Binding-Blob. Length: >=3 Opaque Data: Contains a key-binding-blob that carries EAP lower-layer parameters that need to be bound to the AAA-Key. Ohba Expires November 12, 2005 [Page 6] Internet-Draft AAA-Key Binding May 2005 4. Recommendations to EAP Lower-Layer Although the format of the content of a key-binding-blob is totally up to each EAP lower-layer, there is some recommendations on formatting. Since there are already several AAA attributes such as Calling- Station-Id and Called-Station-Id that carry EAP lower-layer attributes, it is recommended to reuse the already defined format for the attributes in a way that a key-binding-blob is formatted as an ordered sequence of AAA attributes where each AAA attribute contains an EAP lower-layer parameter. To increase randomness of AAA-Key, a key-binding-blob should contain an attribute that carries a random value. An EAP lower-layer should exchange such a random value between the end-points of the EAP lower- layer. Ohba Expires November 12, 2005 [Page 7] Internet-Draft AAA-Key Binding May 2005 5. Discussion The solution described in this document makes EAP methods totally agnostic to EAP lower-layers. EAP methods do not need to carry EAP lower-layer parameters even in the form of a blob. The solution does not require a AAA protocol entity to know the semantics of key-binding-blobs. It just needs to carry key-binding- blobs in a AAA protocol as opaque data. The solution works regardless of whether an EAP authenticator is acting as a pass-through authenticator or not. The solution requires a change in the existing AAA-Key derivation algorithm described in section 2.3 of [I-D.ietf-eap-keying]. This might lead to a deployment issue. Ohba Expires November 12, 2005 [Page 8] Internet-Draft AAA-Key Binding May 2005 6. Security Considerations The solution described in this document improves the security characteristics of the EAP key management framework in that a secure association is never established if there is a difference in EAP lower-layer parameters recognized by the EAP peer and the EAP authenticator. This is in contrast to existing channel binding methods described in [I-D.arkko-eap-service-identity-auth] [I-D.tschofenig-eap-ikev2] in which an EAP peer can still establish a secure association even when a mismatch in EAP lower-layer parameters is detected by the EAP peer, as the EAP peer can ignore the mismatch and continue the EAP conversation to succeed. Ohba Expires November 12, 2005 [Page 9] Internet-Draft AAA-Key Binding May 2005 7. Acknowledgments The author would like to thank Jari Arkko and Bernard Aboba for discussing this issue on the EAP mailing list and giving insights. Ohba Expires November 12, 2005 [Page 10] Internet-Draft AAA-Key Binding May 2005 8. References 8.1 Normative References [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [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. [I-D.ietf-eap-keying] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-06 (work in progress), April 2005. 8.2 Informative References [I-D.arkko-eap-service-identity-auth] Arkko, J. and P. Eronen, "Authenticated Service Information for the Extensible Authentication Protocol (EAP)", draft-arkko-eap-service-identity-auth-02 (work in progress), May 2005. [I-D.tschofenig-eap-ikev2] Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method (EAP- IKEv2)", draft-tschofenig-eap-ikev2-05 (work in progress), October 2004. Author's Address Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscateway, NJ 08854 USA Phone: +1 732 699 5365 Email: yohba@tari.toshiba.com Ohba Expires November 12, 2005 [Page 11] Internet-Draft AAA-Key Binding May 2005 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 (2005). 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. Ohba Expires November 12, 2005 [Page 12]