--- 1/draft-ietf-hokey-reauth-ps-00.txt 2007-11-06 23:50:26.000000000 +0100 +++ 2/draft-ietf-hokey-reauth-ps-01.txt 2007-11-06 23:50:26.000000000 +0100 @@ -1,18 +1,18 @@ HOKEY Working Group T. Clancy, Editor Internet-Draft LTS -Intended status: Informational January 16, 2007 -Expires: July 20, 2007 +Intended status: Informational January 24, 2007 +Expires: July 28, 2007 Handover Key Management and Re-authentication Problem Statement - draft-ietf-hokey-reauth-ps-00 + draft-ietf-hokey-reauth-ps-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 @@ -23,51 +23,51 @@ 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 July 20, 2007. + This Internet-Draft will expire on July 28, 2007. Copyright Notice Copyright (C) The Internet Society (2007). Abstract This document describes the Handover Keying (HOKEY) problem statement. The current EAP keying framework is not designed to support re-authentication and handovers. This often cause unacceptable latency in various mobile wireless environments. HOKEY plans to address these HOKEY plans to address these problems by implementing a generic mechanism to reuse derived EAP keying material for hand-off. Table of Contents 1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 6 - 6.1. Key Context and Domino Effect . . . . . . . . . . . . . . 6 + 6.1. Key Context and Domino Effect . . . . . . . . . . . . . . 7 6.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7 6.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 7 - 6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 7 + 6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 8 6.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 8 6.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8 - 7. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 8 + 7. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 9 7.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 9 7.2. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 9 7.3. Inter-Technology Hand-Off . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 @@ -102,30 +102,41 @@ "authenticator"). The authenticator is responsible for translating EAP packets from the layer 2 (L2) or layer 3 (L3) network access technology to the AAA protocol. According to [RFC3748], after successful authentication, the server transports the MSK to the authenticator. The underlying L2 or L3 protocol uses the MSK to derive additional keys, including the transient session keys (TSK) used per-packet access encryption and enforcement. Figure Figure 1 depicts this process. - +--------+ +---------------+ +----------+ - | EAP |<----->| Passthrough |<--->| EAP | - | Client | L2/L3 | Authenticator | AAA | Server | - +--------+ +---------------+ +----------+ + +--------+ +---------+ +--------+ + | EAP |<----->| Authen- |<------------------->| EAP | + | Client | L2/L3 | ticator | AAA | Server | + +--------+ +---------+ +--------+ + ^ ^ + | +---------+ | + \-------------------------->| Authen- |<--------/ + L2/L3 | ticator | AAA + +---------+ - <------------- EAP Authentication ----------> + Initial Authentication: - <---- MSK Transport ---- + <----------------- EAP Authentication -------------> + <------ MSK Transport ------------- + <- TSK Generation -> - <-- TSK Generation --> + Re-Authentication / Hand-off: + + <----------------- EAP Authentication -------------> + <- MSK Transport - + <---------- TSK Generation ---------> Figure 1: Logical diagram of EAP authentication and key derivation using passthrough authenticator Note that while the authenticator is one logical device, there can be many physical devices involved. For example, in the CAPWAP model [RFC3990] WTPs communicate using L2 protocols with the EAP client and ACs communicate using AAA to the EAP server, while using CAPWAP protocols to communicate with each other. Depending on the configuration, authenticator features can be split in a variety of @@ -220,23 +231,22 @@ MUST be no requirements imposed on future EAP methods. Note that the only EAP methods for which independence is required are those that conform to the specifications of [I-D.ietf-eap-keying] and [RFC4017]. AAA protocol compatibility and keying: Any modifications to EAP and EAP keying MUST be compatible with RADIUS and Diameter. Extensions to both RADIUS and Diameter to support these EAP modifications are acceptable. The designs and protocols must satisfy the AAA key management requirements specified in [I-D.housley-aaa-key-mgmt]. - Compatability: Compatibility and especially co-existence with - current EAP implementations and deployment SHOULD be provided. - Compatibility with other fast transition mechanisms SHOULD also be + Compatability: Compatibility and co-existence with compliant + ([RFC3748] [I-D.ietf-eap-keying]) EAP deployments SHOULD be provided. The keying hierarchy or protocol extensions MUST NOT preclude the use of CAPWAP or IEEE 802.11r. 6. Security Goals The section draws from the guidance provided in [I-D.housley-aaa-key-mgmt] to further define the security goals to be achieved by a complete re-authentication keying solution. 6.1. Key Context and Domino Effect @@ -271,22 +281,22 @@ All the keying material MUST be uniquely named so that it can be managed effectively. 6.2. Key Freshness As [I-D.housley-aaa-key-mgmt] defines, a fresh key is one that is generated for the intended use. This would mean the key hierarchy MUST provide for creation of multiple cryptographically separate child keys from a root key at higher level. Furthermore, the keying - solution needs to provide mechanisms for authorized refreshing each - of the keys within the key hierarchy. + solution needs to provide mechanisms for refreshing each of the keys + within the key hierarchy. 6.3. Authentication Each party in the handover keying architecture MUST be authenticated to any other party with whom it communicates, and securely provide its identity to any other entity that may require the identity for defining the key scope. The identity provided MUST be meaningful according to the protocol over which the two parties communicate. 6.4. Authorization @@ -338,62 +347,57 @@ identities used for keying also needs to be explored. 7. Use Cases 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 the use cases envisioned for the proposed work. 7.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 receives the MSK from the EAP server. A pairwise - master key (PMK-R0) is derived from the 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. + One of the EAP lower layers, IEEE 802.11, is in the process of + specifying 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 receives the MSK from the EAP server. + A pairwise master key (PMK-R0) is derived from the 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. 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. + addressing re-authentication in a lower layer agnostic manner that + also can fill some of the gaps in IEEE 802.11r. 7.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, with the authenticator always being implemented at the AC. The proposed work on EAP efficient re-authentication protocol addresses an inter-authenticator hand-off problem from an EAP perspective, which applies during hand-off between ACs. Inter- controller hand-offs is a topic yet to be addressed in great detail and the re-authentication work can potentially address it in an effective manner. @@ -441,21 +445,21 @@ [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005. [I-D.ietf-eap-keying] Aboba, B., "Extensible Authentication Protocol (EAP) Key - Management Framework", draft-ietf-eap-keying-16 (work in + Management Framework", draft-ietf-eap-keying-17 (work in progress), January 2007. [I-D.housley-aaa-key-mgmt] Housley, R. and B. Aboba, "Guidance for AAA Key Management", draft-housley-aaa-key-mgmt-06 (work in progress), November 2006. 10.2. Informative References [RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and