Network Working Group T. Clancy Internet-Draft N. Petroni Expires: August 8, 2004 W. Arbaugh University of Maryland February 8, 2004 Technique for Method-Specific Fast EAP Rekeying draft-clancy-eap-rekeying-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 8, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract A technique for fast rekeying with EAP is described here. The actual implementation is specific to each EAP method, but in general a master session key can be evolved with each client association such that the authentication requires as many packets exchanges as a "canned success". The concept is explained, with a specific implementation described for EAP-TLS with 802.11i. Clancy, et al. Expires August 8, 2004 [Page 1] Internet-Draft Fast EAP Rekeying February 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Language Requirements . . . . . . . . . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Example: EAP-TLS and 802.11i . . . . . . . . . . . . . . . . . 8 6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 9 Normative References . . . . . . . . . . . . . . . . . . . . . 9 Informative References . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 12 Clancy, et al. Expires August 8, 2004 [Page 2] Internet-Draft Fast EAP Rekeying February 2004 1. Introduction This document describes an EAP [I-D.ietf-eap-rfc2284bis] method-specific rekeying technique that is both fast and secure. The goal is to provide a technique by which a client and an authentication server can use a preexisting master key and master session key to establish a new session key in a minimal number of packet exchanges. Fast rekeying is desirable in many situations. For example, a mobile 802.11 client using 802.1X authentication would benefit from the ability to quickly derive new keys when associating with a new wireless access point. In this document, the protocol and cryptographic operations required to implement this fast rekeying technique are described, and a complete example using TLS is provided. 1.1 Language Requirements 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]. 1.2 Terminology Much of this terminology is defined in the EAP Key Management Framework [I-D.ietf-eap-keying]. peer The end client wishing to authenticate. authenticator The device initiating and enforcing authentication, often passing the authentication through to a backend EAP server through an AAA server. In 802.11, this is the Access Point (AP). AAA server Authentication, authorization, and accounting server responsible for passing EAP requests from the authenticator to the local EAP server methods. Clancy, et al. Expires August 8, 2004 [Page 3] Internet-Draft Fast EAP Rekeying February 2004 EAP server Backend of the EAP methods, responsible for performing authentication and key generation. EAP protocol The protocol between the peer and authenticator. AAA protocol The protocol between the authenticator and the AAA server. MK Master Key between the peer and EAP server from which all other EAP method session keys are derived. In TLS, this is the master secret. MSK Master Session Key generated from the MK and exported by the EAP method to the authenticator. EMSK Extended Master Session Key also generated from the MK and contains additional keying material for future use. These terms are illustrated in the following figure. Clancy, et al. Expires August 8, 2004 [Page 4] Internet-Draft Fast EAP Rekeying February 2004 +--------+ MK +--------+ | | <-------------------------------> | | | EAP | <---------------+---------------- | EAP | | method | | MSK | method | +--------+ V +--------+ | | +---------+ | | | EAP | EAP | | protocol | EAP | | peer | <===============================> | server | +--------+ | | +--------+ | | MAC/LLC | Authen- | AAA | | | client | <========> | ticator | <========> | AAA | | | protocol | | protocol | server | +--------+ +---------+ +--------+ Figure 1: Overview of EAP Terminology 2. Overview The fast rekeying protocol, which utilizes the EAP Identity message to notify the EAP server of a request for fast handoff, minimizes the number of messages between the authenticator and the AAA server and requires no changes to the existing EAP or AAA protocols. In fact, to the casual observer the exchange looks exactly like a "canned success", the term provided by [I-D.ietf-eap-rfc2284bis] for granting network access immediately without performing authentication. However, while in the case of "canned success" all clients are provided access, the fast authentication scheme described here actually encapsulates its proof of identity inside of the EAP Identity Response so that the EAP server can make an informed decision without performing a complete authentication. The principle behind the scheme is simple--reduce the conversation to the minimal number of messages required by the existing infrastructure and provide the necessary protections to insure the result is no less secure than a full authentication. One of the fundamental design goals of this reactive approach is to avoid changes to the authenticator. This goal is motivated by EAP's popularity in 802.11 and 802.1X environments. Here, an access point (AP) acts as the authenticator, and is likely the most difficult and costly equipment to replace and upgrade. The ability to upgrade to a fast-handoff scheme without buying new equipment or spending large amounts of time reflashing old equipment is a clear win. Second, the majority of 802.1X equipment on the market has been well tested for interoperability. Vendors would have far less overhead in rapidly deploying a fast-handoff scheme if fewer protocol changes needed to be made. Unlike access points, clients and AAA servers are more Clancy, et al. Expires August 8, 2004 [Page 5] Internet-Draft Fast EAP Rekeying February 2004 easily upgraded. AAA servers are fewer in number than access points and typically have general purpose processors and operating systems. Client updates are simple as well since the work load is divided among users who can trivially install software patches. +--------+ <------- EAP ID +---------+ +--------+ | | Request | | | | | | | | | | | | EAP ID -------> | | Access -------> | | | | Response | | Request | | | CLIENT | | AUTHEN- | | AAA | | | <---------- EAP | TICATOR | <------- Access | SERVER | | | Success | | Accept | | | | | | | | | | <-- Secure ---> | | | | +--------+ Association +---------+ +--------+ Figure 2: The Reactive Fast-Handoff Exchange The protocol detailed in the figure above starts with the standard EAP Identity Request and Response sequence. The fast rekeying only works after a normal, full authentication has begun the user's session. This full authentication uses a specific EAP method to produce a Master Key that is then used to bootstrap a set of keys for communication between the peer and the authenticator. Once this MK and a corresponding MSK are in place, future MSKs can be calculated by both the client and authentication server. In this scheme, a client that is using a valid MSK can request a fast handoff by including proof of knowledge of the MSK in the identity response, along with the user's identity. The authentication server then performs a trivial check for whether or not the Identity Response contains such proof, checks to make sure the proof is valid, and if so, immediately responds with an Access Accept containing an EAP Success packet and the new MSK (encrypted for the authenticator). For this protocol we define the MSKID, which serves as proof of knowledge of the MSK. 3. Protocol Specification One of the main benefits of this keying technique is that the AAA and EAP protocols do not need to be altered. The only difference is a change in the encoding of the identity in the EAP Identity Response message. The MSKID can be appended to the null-terminated string identifying the authenticating entity. This string is then passed unaltered by the authenticator to the AAA server. The AAA server can Clancy, et al. Expires August 8, 2004 [Page 6] Internet-Draft Fast EAP Rekeying February 2004 recognize additional data exists beyond the null character by noticing the field length is not equal to the string length. Provided the AAA server can validate the client-supplied MSKID, the remainder of the exchanges conform to the EAP canned-success method as described in [I-D.ietf-eap-rfc2284bis], where an EAP success message is followed with keying messages. Note that some EAP methods encode additional options after a null byte in the identity response. If this is the case, structure may be required following the null character to identify the options. After the MSKID has been verified by the EAP server, both the EAP server and the EAP peer need to generate the new MSK and EMSK. These values must be a function of both the MK and MSK or EMSK respectively. The exact manner this is done is method specific, but it should be computationally difficult to recover the MK, or determine the new MSK without knowledge of the MK and old MSK. The new MSK and EMSK can now be exported from the EAP method and used to generate other session-specific keys. 4. Security Considerations The goal of this scheme is provide a mechanism to further derive pairwise keys between the EAP server, authenticator, and EAP peer, and consequently new session keys between the client and authenticator. Since only the EAP peer and EAP server know the MK, a new MSK derived from them is only initially known by the EAP peer and EAP server. Therefore, we need not trust authenticators to which we are no longer associated. It is important that the keys derived from the new MSK are used for link-layer encryption. In this fast-rekeying scheme, a client is not authenticated until the new keys are used, and the client proves he or she indeed knows them. Knowledge of the MSKID is not sufficient. The MSKID is used primarily for efficiency reasons, as it offers little protocol security. Anyone could perform a man-in-the-middle attack to obtain the EAP Identity Response packet containing the MSKID, and use it to authenticate. However without both the MK and old MSK, the attacker cannot compute the new MSK, and therefore would not be able to decrypt the new keying material and communicate with the authenticator. The purpose of the MSKID is to make sure a client is capable of computing the new MSK by proving he or she knows the old one. If the EAP server receives an invalid MSKID, it can immediately request a full authentication without the initial reauthentication first failing. Clancy, et al. Expires August 8, 2004 [Page 7] Internet-Draft Fast EAP Rekeying February 2004 The worst an attacker could do is force a client to perform a full authentication during each reassociation, however significantly more detrimental denial of service attacks exist for most link-layer protocols. 5. Example: EAP-TLS and 802.11i Here we present a concrete example that uses the transaction layer security (TLS) EAP method, under the protocol recommendations of 802.11i. A version of our original diagram is presented below, with the EAP-TLS and 802.11i vocabulary substituted for the original terms. +--------+ Master Secret (MS) +--------+ | EAP- | <-------------------------------> | EAP- | | TLS | <---------------+---------------- | TLS | | method | Pairwise|Master Key (PMK) | method | +--------+ V +--------+ | | +---------+ | | | supp- | EAP | | protocol | EAP | | licant | <===============================> | server | +--------+ | | +--------+ | | 802.11 | Access | RADIUS | | | client | <========> | Point | <========> | RADIUS | | | protocol | | protocol | server | +--------+ +---------+ +--------+ Figure 3: Network Diagram for 802.11i using EAP-TLS With EAP-TLS, the MSKID used is the 802.11i-defined PMKID. This is computed by concatenating the string "PMK Name" with the 6-byte 802.11 MAC addresses of the access point and wireless client, and then putting that string through a SHA-1 hash keyed with the current PMK. The supplicant obviously knows its own MAC and the MAC of the AP to which it is associated. Additionally, the RADIUS protocol provides all the necessary MAC addresses to the EAP server methods. PMKID = HMAC-SHA1-128 (PMK, "PMK Name" || AP-MAC-address || Client-MAC-Address) Thus, the resulting EAP Identity Response packet is as follows: Clancy, et al. Expires August 8, 2004 [Page 8] Internet-Draft Fast EAP Rekeying February 2004 |<---- Standard EAP Identity Response ---->| +------+--------+--------+------+----------+------+---------+ | Code | 1-byte | 2-byte | Type | Identity | 0x00 | 16-byte | | 0x01 | ID | Length | 0x01 | | | PMKID | +------+--------+--------+------+----------+------+---------+ |<--- length field value -->| Figure 4 Next, the master secret and the TLS pseudorandom function (PRF) are used to generate new keys. The PMK is concatenated with the AP and Client MAC addresses and sent through the TLS pseudorandom function. PMK' = TLS-PRF (MS, PMK || AP-MAC-Address || Client-MAC-Address) 6. Acknowledgment The authors would like to thank Pasi Eronen of the Nokia Research Center, and Kyunghun Jang and Insun Lee of Samsung Electronics for contributions and feedback. This work was funded in part by a grant from Samsung Electronics, 0307158417, and the U.S. National Institute for Standards and Technology Critical Infrastructure Grant 60NANB1D0113. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [I-D.ietf-eap-rfc2284bis] Blunk, L., "Extensible Authentication Protocol (EAP)", draft-ietf-eap-rfc2284bis-07 (work in progress), December 2003. [I-D.ietf-eap-keying] Aboba, B., Simon, D., Arkko, J., Eronen, P. and H. Levkowetz, "EAP Key Management Framework", Clancy, et al. Expires August 8, 2004 [Page 9] Internet-Draft Fast EAP Rekeying February 2004 draft-ietf-eap-keying-02b (work in progress), November 2003. [IEEE.80211] Institute of Electrical and Electronics Engineers, "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11-1997, 1997. [IEEE.80211i] Institute of Electrical and Electronics Engineers, "Draft Supplement to STANDARD FOR Telecommunications and Information Exchange between Systems - LAN/MAN Specific Requirements - Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications: Specification for Enhanced Security", IEEE Draft 802.11I/ D6.1, August 2003. Informative References [MIS04] Mishra, A., Shin, M., Petroni, N., Clancy, T. and W. Arbaugh, "Proactive Key Distribution Using Neighbor Graphs", IEEE Wireless Communications, February 2004. Authors' Addresses T. Charles Clancy III University of Maryland, College Park A.V. Williams Building College Park, MD 20742 USA EMail: clancy@cs.umd.edu Nick L. Petroni, Jr. University of Maryland, College Park A.V. Williams Building College Park, MD 20742 USA EMail: npetroni@cs.umd.edu Clancy, et al. Expires August 8, 2004 [Page 10] Internet-Draft Fast EAP Rekeying February 2004 William A. Arbaugh University of Maryland, College Park A.V. Williams Building College Park, MD 20742 USA EMail: waa@cs.umd.edu Clancy, et al. Expires August 8, 2004 [Page 11] Internet-Draft Fast EAP Rekeying February 2004 Intellectual Property Statement 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 implementors 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 (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Clancy, et al. Expires August 8, 2004 [Page 12] Internet-Draft Fast EAP Rekeying February 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Clancy, et al. Expires August 8, 2004 [Page 13]