--- 1/draft-ietf-hokey-reauth-ps-01.txt 2007-11-06 23:52:45.000000000 +0100 +++ 2/draft-ietf-hokey-reauth-ps-02.txt 2007-11-06 23:52:45.000000000 +0100 @@ -1,18 +1,18 @@ -HOKEY Working Group T. Clancy, Editor +HOKEY Working Group T. Clancy, Ed. Internet-Draft LTS -Intended status: Informational January 24, 2007 -Expires: July 28, 2007 +Intended status: Informational July 24, 2007 +Expires: January 25, 2008 Handover Key Management and Re-authentication Problem Statement - draft-ietf-hokey-reauth-ps-01 + draft-ietf-hokey-reauth-ps-02 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,85 +23,85 @@ 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 28, 2007. + This Internet-Draft will expire on January 25, 2008. Copyright Notice - Copyright (C) The Internet Society (2007). + Copyright (C) The IETF Trust (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. + for handover. Table of Contents 1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 6. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 6 + 6. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Key Context and Domino Effect . . . . . . . . . . . . . . 7 6.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7 - 6.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 7 + 6.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 8 6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 8 6.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 8 6.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 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 + 7.2. IEEE 802.21 Applicability . . . . . . . . . . . . . . . . 10 + 7.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10 + 7.4. Inter-Technology Handover . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 - Intellectual Property and Copyright Statements . . . . . . . . . . 12 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 + Intellectual Property and Copyright Statements . . . . . . . . . . 13 1. Authors The following authors contributed to the HOKEY problem statement draft: o Julien Bournelle, France Telecom R&D, julien.bournelle@orange-ftgroup.com o Lakshminath Dondeti, QUALCOMM, ldondeti@qualcomm.com o Rafael Marin Lopez, Universidad de Murcia, rafa@dif.um.es o Madjid Nakhjiri, Huawei, mnakhjiri@huawei.com o Vidya Narayanan, QUALCOMM, vidyan@qualcomm.com o Mohan Parthasarathy, Nokia, mohan.parthasarathy@nokia.com o Hannes Tschofenig, Siemens, Hannes.Tschofenig@siemens.com 2. Introduction - The extensible authentication protocol (EAP), specified in RFC3748 - [RFC3748] is a generic framework supporting multiple authentication - methods. The primary purpose of EAP is network access control. It - also supports exporting session keys derived during the - authentication. The EAP keying hierarchy defines two keys that are - derived at the top level, the master session key (MSK) and the - extended MSK (EMSK). + The extensible authentication protocol (EAP), specified in [RFC3748] + is a generic framework supporting multiple authentication methods. + The primary purpose of EAP is network access control. It also + supports exporting session keys derived during the authentication. + 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 many common deployment scenario, an EAP peer and EAP server authenticate each other through a third party known as the pass- through authenticator (hereafter referred to as simply "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 @@ -118,21 +118,21 @@ \-------------------------->| Authen- |<--------/ L2/L3 | ticator | AAA +---------+ Initial Authentication: <----------------- EAP Authentication -------------> <------ MSK Transport ------------- <- TSK Generation -> - Re-Authentication / Hand-off: + Re-Authentication / Handover: <----------------- 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 @@ -150,47 +150,46 @@ will require the peer to run an EAP method irrespective of whether it has been authenticated to the network recently and has unexpired keying material. A full EAP method execution involves several round trips between the EAP peer and the server. There have been attempts to solve the problem of efficient re- authentication in various ways. However, those solutions are either EAP-method specific, EAP lower-layer specific, or are otherwise limited in scope. Furthermore, these solutions do not deal with scenarios involving handovers to new authenticators, or do not - conform to the AAA keying requirements specified in - [I-D.housley-aaa-key-mgmt]. + conform to the AAA keying requirements specified in [RFC4962]. This document provides a detailed description of EAP efficient re- authentication protocol requirements. 3. 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]. This document follows the terminology that has been defined in - RFC3748 [RFC3748] and the EAP Keying Framework [I-D.ietf-eap-keying]. + [RFC3748] and the EAP Keying Framework [I-D.ietf-eap-keying]. 4. Problem Statement When a peer needs to re-affirm access to an authenticator or moves from one authenticator and reattaches to another authenticator, the current EAP keying model requires the peer to engage in a full EAP exchange with the authentication server in its home domain [RFC3748]. An EAP conversation with a full EAP method run takes several round trips and significant time to complete, causing delays in re- - authentication and hand-off times. Some methods [RFC4187] specify + authentication and handover times. Some methods [RFC4187] specify the use of keys and state from the initial authentication to finish subsequent authentications in fewer round trips. However, even in those cases, several round trips to the EAP server are still involved. Furthermore, many commonly-used EAP methods do not offer such a fast re-authentication feature. In summary, it is undesirable to have to run a full EAP method each time a peer associates with a new authenticator or needs to extend its current association with the same authenticator. Furthermore, it is desirable to specify a method-independent, efficient, re-authentication protocol. Keying material from the full authentication can be used to enable efficient @@ -213,48 +212,52 @@ 5. Design Goals The following are the goals and constraints in designing the EAP re- authentication and key management protocol: Lower latency operation: The protocol MUST be responsive to handover and re-authentication latency performance objectives within a mobile access network. A solution that reduces latency as compared to a full EAP authentication will be most favorable. + EAP lower-layer independence: Any keying hierarchy and protocol defined MUST be lower layer independent in order to provide the capability over heterogeneous technologies. The defined protocols MAY require some additional support from the lower layers that use it. Any keying hierarchy and protocol defined MUST accommodate inter-technology heterogeneous handover. + EAP method independence: Changes to existing EAP methods MUST NOT be required as a result of the re-authentication protocol. There 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]. + [RFC4962]. + 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. + The section draws from the guidance provided in [RFC4962] to further + define the security goals to be achieved by a complete re- + authentication keying solution. 6.1. Key Context and Domino Effect Any key MUST have a well-defined scope and MUST be used in a specific context and for the intended use. This specifically means the lifetime and scope of each key MUST be defined clearly so that all entities that are authorized to have access to the key have the same context during the validity period. In a hierarchical key structure, the lifetime of lower level keys MUST NOT exceed the lifetime of higher level keys. This requirement MAY imply that the context and @@ -277,26 +280,26 @@ Guidance on parameters required, caching, storage and deletion procedures to ensure adequate security and authorization provisioning for keying procedures MUST be defined in a solution document. 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 refreshing each of the keys - within the key hierarchy. + As [RFC4962] 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 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 @@ -347,160 +350,181 @@ 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, 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. + One of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D7.0], 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. The proposed work on EAP efficient re-authentication protocol aims at 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 +7.2. IEEE 802.21 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 IEEE 802.21 working group [IEEE.802-21] is standardizing + mechanisms for media-independent handover. More specifically, they + are looking at transitions from one link-layer protocol to another, + which is currently beyond the scope of the HOKEY charter. - The CAPWAP model supports both split and integrated MAC - architectures, with the authenticator always being implemented at the - AC. + The techniques developed within HOKEY could be applicable to IEEE + 802.21 if the necessary issues with handover between different lower + layers can be resolved. In particular, pre-authentication may be + more appropriate than re-authentication. + +7.3. CAPWAP Applicability + + The IETF CAPWAP WG [RFC3990] 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 + addresses an inter-authenticator handover problem from an EAP + perspective, which applies during handover between ACs. Inter- + controller handover is a topic yet to be addressed in great detail and the re-authentication work can potentially address it in an effective manner. -7.3. Inter-Technology Hand-Off +7.4. Inter-Technology Handover EAP is used for access authentication by several technologies and is under consideration for use over several other technologies going - forward. Given that, it should be feasible to support smoother hand- - offs across technologies. That is one of the big advantages of using - a common authentication protocol. Authentication procedures - typically add substantial hand-off delays. + forward. Given that, it should be feasible to support smoother + handover across technologies. That is one of the big advantages of + using a common authentication protocol. Authentication procedures + typically add substantial handover delays. An EAP peer that has multiple radio technologies (802.11 and GSM, for instance) must perform the full EAP exchange on each interface upon - every horizontal or vertical hand-off. With a method independent EAP - efficient re-authentication, it is feasible to support faster hand- - offs even in the vertical hand-off cases, when the peer may be + every horizontal or vertical handover. With a method independent EAP + efficient re-authentication, it is feasible to support faster + handover even in the vertical handover cases, when the peer may be roaming from one technology to another. 8. Security Considerations This document details the HOKEY problem statement. Since HOKEY is an authentication protocol, there are a myriad of security-related issues surrounding its development and deployment. In this document, we have detailed a variety of security properties - inferred from [I-D.housley-aaa-key-mgmt] to which HOKEY must conform, - including the management of key context, scope, freshness, and - transport; resistance to attacks based on the domino effect; and - authentication and authorization. See section Section 6 for further - details. + inferred from [RFC4962] to which HOKEY must conform, including the + management of key context, scope, freshness, and transport; + resistance to attacks based on the domino effect; and authentication + and authorization. See section Section 6 for further details. 9. IANA Considerations This document does not introduce any new IANA considerations. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. + [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, + Authorization, and Accounting (AAA) Key Management,", + BCP 132, RFC 4962, July 2007. + [I-D.ietf-eap-keying] Aboba, B., "Extensible Authentication Protocol (EAP) Key - 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. + Management Framework", draft-ietf-eap-keying-18 (work in + progress), February 2007. 10.2. Informative References [RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement", RFC 3990, February 2005. [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006. + [IEEE.802-11R-D7.0] + "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 - Amendment 2: Fast BSS + Transition", IEEE Standard 802.11r, June 2007. + + [IEEE.802-21] + "Media Independent Handover Working Group", IEEE Working + Group 802.21. + Author's Address T. Charles Clancy, Editor DoD Laboratory for Telecommunications Sciences 8080 Greenmead Drive College Park, MD 20740 USA Email: clancy@LTSnet.net Full Copyright Statement - Copyright (C) The Internet Society (2007). + Copyright (C) The IETF Trust (2007). 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 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 + 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