Network Working Group L. Dondeti Internet-Draft V. Narayanan Expires: December 21, 2006 QUALCOMM, Inc. June 19, 2006 EAP Extensions Problem Statement draft-dondeti-eapext-ps-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 December 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The extensible authentication protocol (EAP), specified in RFC3748 [1] is a generic framework supporting multiple authentication methods. The EAP keying hierarchy specified in [2] has two top level keys: a master session key (MSK) and an extended MSK (EMSK). The MSK is used for access control enforcement, whereas the purpose of EMSK is to be defined. Several proposals for the use of the EMSK have been made, among them are support for efficient re-authentication of the EAP peer as it moves from one authenticator to another, Dondeti & Narayanan Expires December 21, 2006 [Page 1] Internet-Draft EAPext PS June 2006 bootstrapping preshared keys, visited domain key management. In this document, we explore the various proposed uses of the EMSK key hierarchy and the design considerations in specifying the EMSK key hierarchy. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Candidate use cases . . . . . . . . . . . . . . . . . . . 3 1.2. Key material selection for additional uses of EAP authentication . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Proposed and potential use cases for EMSK . . . . . . . . 5 3.2. Summary of Gaps in EAP . . . . . . . . . . . . . . . . . . 6 3.3. Scope of Proposed Work . . . . . . . . . . . . . . . . . . 7 4. Applicability and Related Work . . . . . . . . . . . . . . . . 7 4.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . 7 4.2. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 8 4.3. Kerberos Applicability . . . . . . . . . . . . . . . . . . 8 5. Design goals and constraints . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. References . . . . . . . . . . . . . . . . . . . . . . . . 10 9.2. References . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Dondeti & Narayanan Expires December 21, 2006 [Page 2] Internet-Draft EAPext PS June 2006 1. Introduction The extensible authentication protocol (EAP), specified in RFC3748 [1] is a generic framework supporting multiple authentication methods. The primary purpose of EAP is network access control and a key generating method is recommended for that purpose. The EAP keying hierarchy defines two keys that are derived at the top level - the master session key (MSK) and the extended MSK (EMSK). In the most common deployment scenario, an EAP peer and server authenticate each other through a third party known as the authenticator. The authenticator or an entity controlled by the authenticator enforces access control. After successful authentication, the server transports the MSK to the authenticator; the authenticator and the peer derive transient session keys (TSK) using the MSK as the authentication key or a key derivation key and use the TSK and use the TSK for per-packet access enforcement. 1.1. Candidate use cases When a peer moves from one authenticator to another, it is desirable to avoid full EAP authentication. The full EAP exchange with another run of the EAP method takes several round trips and significant time to complete, causing delays in handoff times. Some methods specify the use of state from the initial authentication to finish subsequent authentications to finish in fewer roundtrips. However, most methods do not offer this feature. Thus, it is beneficial to have efficient re-authentication support in EAP rather than in individual methods. For this purpose we need key material derived via a full EAP authentication. Related to an efficient re-authentication is faster roaming in a visited domain. While basic EAP handles visited domain authentication via the home EAP/AAA server, any authentication must pass through the home server every time. It is desirable to optimize handoffs while in the visited domain. The home EAP/AAA server may enable brokering a trust relationship between the peer and a local EAP/AAA server, so that subsequent authentications can be done between the peer and the visited domain server, without having to traverse the home domain server. It is important that such a solution attempt to preserve the stateless nature of AAA proxies. Another candidate use case is pre-configuration of shared secrets between the peer and other entity that provides network services. Setting up such PSKs is an administrative burden. The most common solution is to configure a password or a symmetric key and use it for several purposes: entity authentication and key generation in various uncoordinated ways. In most cases, PSKs are generally not changed often enough in practice and are not as strong as they need to be. Dondeti & Narayanan Expires December 21, 2006 [Page 3] Internet-Draft EAPext PS June 2006 If a bootstrapping key for such upper layer services can, in fact, be derived from the EAP keying hierarchy in place of such PSKs, it can yield stronger and periodically changing keys, allowing for better security practices without the administrative burden. 1.2. Key material selection for additional uses of EAP authentication Given that the proposal is to reuse key material from an earlier EAP authentication, there are two choices as the root key for these various use cases: the MSK and the EMSK. The MSK is delivered to the authenticator and used differently by different lower layers. For instance, IKEv2 uses the MSK for entity authentication alone, while lower layers like 802.11 and 802.16 use it in the secure association protocol to derive TSKs. Also, different lower layers use different parts of the MSK to derive other keys from it. For example, IEEE 802.11 uses the first 256 bits of the MSK for TSK derivation and 802.11's Task Group r (TGr) uses the second 256 bits to derive PMKs-R1. IEEE 802.16 uses the first 320 bits of the MSK to derive TSKs. Such disparate uses of the MSK at the lower layers makes it infeasible to use the MSK for general purpose key material derivation. The EMSK key hierarchy on the other hand is in initial stages of specification. From the discussion so far, it is clear that the EMSK is the appropriate root key for extensions to EAP keying hierarchy. Next, we note that some use cases requiring extensions to the EAP keying hierarchy need more urgent work than the others: the fast re- authentication application being one such use case. However, given that the key material may need to come from the EMSK hierarchy for this and various other purposes, it is imperative that the key hierarchy development be done in parallel with the usage specific protocol and hierarchy development. 2. Terminology 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 [3]. This document follows the terminology that has been defined in RFC3748 [1] and the EAP Keying I-D. In addition, this document uses the following terms: Dondeti & Narayanan Expires December 21, 2006 [Page 4] Internet-Draft EAPext PS June 2006 Usage Specific Root Key (USRK) is keying material derived from the EMSK for a particular usage definition as specified in this document. It is used to derive child keys in a way defined by its usage definition. USRKs are defined and specified in [4]. 3. Problem Statement The overarching problem we propose to tackle is to take stock of the various proposed and potential use cases of the EAP key material. MSK handling by various EAP lower layers in disparate ways is acceptable since the stated handling of that key is to deliver it to the authenticator, an entity within the realm of the lower layer, and allow the authenticator to use it as required by the lower layer. The proposed use cases for the EMSK are expected to be lower layer agnostic, which is logical, as it allows us to get around the limitations of lower layers. For instance the IEEE 802.11r solution for re-association and re-authentication is limited to a single extended service set (ESS). Presumably 802.11 would require an IETF defined protocol and key hierarchy for efficient roaming between ESSs. To avoid uncoordinated and potentially unsafe uses of the EMSK, or key material derived from that key, we propose that one of the first steps to take is to evaluate the use cases for the EAP key material and define the EMSK key derivation, caching and delivery semantics. 3.1. Proposed and potential use cases for EMSK We discuss three proposed use cases for keys from the key hierarchy in the following: EAP fast re-authentication There have been significant discussions around the area of faster handoffs within and across technologies that employ EAP-based authentication. Inter-authenticator handoffs typically result in a full EAP exchange, leading to unacceptable handoff latency. A more efficient EAP re- authentication mechanism will allow for faster authentication procedures. This has also been termed as "handover keying" in the HOAKEY discussions and documents. There is a need to develop such a re-authentication mechanism at the IETF in a link layer agnostic manner to allow easy adoption across the different link layers using EAP. EMSK KH for visited domains: Related to an efficient re- authentication is faster roaming in a visited domain. While basic EAP handles visited domain authentication via the home EAP/AAA server, any authentication must pass through the home server every Dondeti & Narayanan Expires December 21, 2006 [Page 5] Internet-Draft EAPext PS June 2006 time. It is desirable to optimize handoffs while in the visited domain. The home EAP/AAA server may enable brokering a trust relationship between the peer and a local EAP/AAA server, so that subsequent authentications can be done between the peer and the visited domain server, without having to traverse the home domain server. It is important that such a solution attempt to preserve the stateless nature of AAA proxies. PSK bootstrapping: Many upper layer protocols require the pre- configuration of shared secrets between the peer and the AAA server for setting up a security association between the peer and a third entity. Setting up such PSKs is an administrative burden. In order to circumvent this issue, a single root key for a client is often configured and shared for several purposes. Further, such PSKs are generally not changed often enough in practice and are not as strong as they need to be. If a bootstrapping key for such upper layer services can, in fact, be derived from the EAP keying hierarchy in place of such PSKs, it can yield stronger and periodically changing keys, allowing for better security practices without the administrative burden. Largely, all of the work discussed above is likely to require the use of the EAP EMSK. With the definition of EMSK usage leading to Usage Specific Root Keys (USRKs), additional work is required to actually define a USRK and its usage. 3.2. Summary of Gaps in EAP The EAP specification and the EAP keying framework have some gaps in the specification that are brought to fore by the proposed and potential usage cases specified above. A gap analysis on EAP keying is provided in [5]. A brief summary of the gaps in EAP are as listed below. EMSK usage specification: The EMSK usage is currently undefined in EAP keying. The usage of EMSKs for Usage Specific Root Key (USRK) derivation is separately described in [4]. EAP re-authentication protocol and key hierarchy specification EAP currently does not have a re-authentication mechanism. Some EAP methods do have fast re-authentication or session resumption - however, those still require a minimum of two roundtrips to the server. Visited domain key hierarchy specification EAP keying currently provides no optimization for authentication in the visited domain. Dondeti & Narayanan Expires December 21, 2006 [Page 6] Internet-Draft EAPext PS June 2006 Specification of PSK provisioning using EAP keying EAP is currently only specified for network access and provides keying material that is used by the authenticator for providing lower layer security. Definition of channel binding The term channel binding is somewhat loosely defined in [2]. The term is used by different people to mean different things in terms of what it provides and how it can be achieved. A good analysis of what can be achieved via channel binding and a study of practical implications of the same are yet to be done. 3.3. Scope of Proposed Work Given the background, the use cases, and the gap analysis, there is a long list of EAP related work items to be done at the IETF. However, a prioritization is necessary to get the most important and urgent work done in a timely manner. We propose the following subset of the work items: EMSK usage specification EAP re-authentication protocol and key hierarchy specification Visited domain key hierarchy specification Specification of PSK provisioning using EAP keying 4. Applicability and Related Work In order to further clarify the items listed in scope of the proposed work, this section provides some background on related work and how the proposed work differs from it. 4.1. IEEE 802.11r Applicability One of the EAP lower layers, IEEE 802.11, provides a mechanism to avoid the problem of repeated full EAP exchanges in a limited setting, by introducing a two-level key hierarchy. The EAP authenticator is collocated with what is known as an R0 Key Holder (R0-KH), which of course receives the MSK from the EAP server. A pairwise master key (PMK-R0) is derived from the second half (last 32 octets) of the MSK. Subsequently, the R0-KH derives an PMK-R1 to be handed out to the attachment point of the peer. When the peer moves from one R1-KH to another, a new PMK-R1 is generated by the R0-KH and handed out to the new R1-KH. The transport protocol used between the R0-KH and the R1-KH is not specified at the moment. Dondeti & Narayanan Expires December 21, 2006 [Page 7] Internet-Draft EAPext PS June 2006 In some cases, a mobile may seldom move beyond the domain of the R0-KH and this model works well. A full EAP authentication will generally be repeated when the PMK-R0 expires. However, in general cases mobiles may roam beyond the domain of R0-KHs (or EAP authenticators), and the latency of full EAP authentication remains an issue. Another consideration is that there needs to be a key transfer protocol between the R0-KH and the R1-KH; in other words, there is either a star configuration of security associations between the key holder and a centralized entity that serves as the R0-KH, or if the first authenticator is the default R0-KH, there will be a full-mesh of security associations between all authenticators. This is undesirable. Furthermore, in the 802.11r architecture, the R0-KH may actually be located close to the edge, thereby creating a vulnerability: If the R0-KH is compromised, all PMK-R1s derived from the corresponding PMK- R0s will also be compromised. The proposed work on EAP efficient re-authentication protocol aims at addressing the problem in a lower layer agnostic manner that also can operate without some of the restrictions or shortcomings of 802.11r mentioned above. 4.2. CAPWAP Applicability The IETF CAPWAP WG is developing a protocol between what is termed an Access Controller (AC) and Wireless Termination Points (WTP). The AC and WTP can be mapped to a WLAN switch and Access Point respectively. The CAPWAP model supports both split and integrated MAC architectures. The proposed work on EAP efficient protocol addresses an inter- authenticator roaming problem from an EAP perspective. Depending on the architecture of WLAN deployment, this may apply during handoff across ACs or across WTPs. Hence, this is complementary and does not conflict with the CAPWAP work. 4.3. Kerberos Applicability Upper layer PSK bootstrapping and visited domain roaming are part of the proposed work items. The motivation for this work has already been discussed. At a concept level, however, Kerberos provides some of the functionality needed to solve these problems. Kerberos provides a means of authenticating to the home authentication infrastructure. This establishes keying material that Dondeti & Narayanan Expires December 21, 2006 [Page 8] Internet-Draft EAPext PS June 2006 can be used to derive new keying material for applications and services. One of the applications and services clients can get keying material for is visited domain authentication infrastructure. There is a relatively fast exchange to prove knowledge of keying material and to use that to derive keying material for a new service that the client needs to access. Kerberos has been a candidate for fast handoffs as shown by proposals for inter-provider roaming in RADIUS, the early IEEE 802.11i design (which mandated Kerberos support), and the IEEE 802.11r MDC protocol design (which looked at writing a Kerberized application for inter- authenticator handoff). For example, it is possible for the peer to obtain a ticket as a result of the original EAP exchange. The AAA server could return the ticket in the Access-Accept, and the authenticator could give it to the peer via a link-layer exchange. There are, however, a number of questions that would need to be answered as to how this would work, and whether this can use Kerberos as is, or whether it requires extensions or a new "Kerberos-like" protocol. For instance, the authenticators cannot be assumed to support Kerberos. Also, IP address use for link layer access is typically not a good model. Further, while shared key bootstrapping for applications using Kerberos is well defined, similar concerns exist. For instance, support for Kerberos in all the parties involved cannot be assumed, while the support for AAA-based models do exist in systems that employ EAP. Also, the goal of PSK bootstrapping via EAP is to be able to leverage the keying material produced during network access to provide stronger PSKs for services in cases where the support for Kerberos cannot be assumed. 5. Design goals and constraints The following are the design goals for protocols extending the EAP keying hierarchy. o EAP lower layer independence - Any keying hierarchy and protocol defined should be lower layer independent in order to provide the capability over heterogeneous technologies. The defined protocols may, however, require some additional support from the lower layers that use it. o EAP method independence - No changes to EAP methods should be required as a result of the extensions to EAP itself. Dondeti & Narayanan Expires December 21, 2006 [Page 9] Internet-Draft EAPext PS June 2006 o AAA protocol compatibility - any extensions to EAP and EAP keying must still be compatible with RADIUS and Diameter. o The designs and protocols must satisfy the AAA key management requirements specified in [6]. o Compatibility with the currently defined fast transition mechanisms in IEEE 802.11r is strongly desired. o The keying hierarchy or protocol extensions must not preclude the use of the CAPWAP protocol. 6. Security Considerations In this version of the draft, we just note that the "Guidance for AAA Key Management" [6] applies to the protocols and key hierarchies developed to solve the problems listed within. 7. IANA Considerations This document does not request any IANA assignments. 8. Acknowledgments In writing this draft, we benefited from discussing the problem space with a number of folks including, Bernard Aboba, Jari Arkko, Sam Hartman, Russ Housley, Joe Salowey, and Jesse Walker. Note that this does not necessarily mean that they endorse this work or support it. 9. References 9.1. References [1] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [2] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-13 (work in progress), May 2006. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Dondeti & Narayanan Expires December 21, 2006 [Page 10] Internet-Draft EAPext PS June 2006 9.2. References [4] Salowey, J., "Specification for the Derivation of Usage Specific Root Keys (USRK) from an Extended Master Session Key (EMSK)", draft-salowey-eap-emsk-deriv-00 (work in progress), May 2006. [5] Narayanan, V. and L. Dondeti, "Gap analysis on the EAP keying hierarchy", draft-vidya-eap-keying-gap-analysis-00 (work in progress), April 2006. [6] Housley, R. and B. Aboba, "Guidance for AAA Key Management", draft-housley-aaa-key-mgmt-02 (work in progress), March 2006. Dondeti & Narayanan Expires December 21, 2006 [Page 11] Internet-Draft EAPext PS June 2006 Authors' Addresses Lakshminath Dondeti QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-1267 Email: ldondeti@qualcomm.com Vidya Narayanan QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-2483 Email: vidyan@qualcomm.com Dondeti & Narayanan Expires December 21, 2006 [Page 12] Internet-Draft EAPext PS June 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. Dondeti & Narayanan Expires December 21, 2006 [Page 13]