--- 1/draft-ietf-hokey-reauth-ps-08.txt 2008-02-24 01:12:12.000000000 +0100 +++ 2/draft-ietf-hokey-reauth-ps-09.txt 2008-02-24 01:12:12.000000000 +0100 @@ -1,22 +1,22 @@ HOKEY Working Group T. Clancy Internet-Draft LTS Intended status: Informational M. Nakhjiri -Expires: August 13, 2008 Motorola +Expires: August 26, 2008 Motorola V. Narayanan L. Dondeti Qualcomm - February 10, 2008 + February 23, 2008 Handover Key Management and Re-authentication Problem Statement - draft-ietf-hokey-reauth-ps-08 + draft-ietf-hokey-reauth-ps-09 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 @@ -27,21 +27,21 @@ 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 13, 2008. + This Internet-Draft will expire on August 26, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document describes the Handover Keying (HOKEY) re-authentication problem statement. The current Extensible Authentication Protocol (EAP) keying framework is not designed to support re-authentication @@ -50,51 +50,51 @@ document details the problem and defines design goals for a generic mechanism to reuse derived EAP keying material for handover. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 6 - 5.1. Key Context and Domino Effect . . . . . . . . . . . . . . 6 + 5.1. Key Context and Domino Effect . . . . . . . . . . . . . . 7 5.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 7 - 5.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 7 - 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 7 + 5.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 8 + 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 8 5.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8 - 6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 8 - 6.1. Method-Specific EAP Re-authentication . . . . . . . . . . 8 + 6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 9 + 6.1. Method-Specific EAP Re-authentication . . . . . . . . . . 9 6.2. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 9 6.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 1. Introduction The Extensible Authentication Protocol (EAP), specified in RFC 3748 [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 Master Session Key (EMSK). - In many common deployment scenario, an EAP peer and EAP server + In many common deployment scenarios, 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 encapsulating EAP packets from a network access technology lower layer within the Authentication, Authorization, and Accounting (AAA) protocol. The authenticator does not directly participate in the EAP exchange, and simply acts as a gateway during the EAP method execution. After successful authentication, the EAP server transports the MSK to the authenticator. Note that this is performed using AAA protocols, @@ -103,45 +103,57 @@ used for per-packet encryption and authentication. Note that while the authenticator is one logical device, there can be multiple physical devices involved. For example, the CAPWAP model [RFC3990] splits authenticators into two logical devices: Wireless Termination Points (WTPs) and Access Controllers (ACs). Depending on the configuration, authenticator features can be split in a variety of ways between physical devices, however from the EAP perspective there is only one logical authenticator. - The current models of EAP authentication and keying are frequently - not efficient in cases where the peer is a mobile device - [MSA03][KP01]. In existing implementations, when a peer arrives at - the new authenticator, it runs 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 an EAP- - Response/Identity message from the peer to server, followed by one or - more round trips between the EAP server and peer to perform the - authentication, followed by the EAP-Success or EAP-Failure message - from the EAP server to peer. At a minimum, the peer has 2 round - trips with the EAP server. + Wireless handover between access points or base stations is typically + a complex process that involves several layers of protocol execution. + Often times executing these protocols results in unacceptable delays + for many real-time applications such as voice [MSA03]. One part of + the handover process is EAP re-authentication, which can contribute + significantly to the overall handover time [MSPCA04]. Thus in many + environments we can lower overall handover time by lowering EAP re- + authentication time. + + In EAP existing implementations, when a peer arrives at the new + authenticator, it runs an EAP method irrespective of whether it has + been authenticated to the network recently and has unexpired keying + material. This typically involves an EAP-Response/Identity message + from the peer to server, followed by one or more round trips between + the EAP server and peer to perform the authentication, followed by + the EAP-Success or EAP-Failure message from the EAP server to the + peer. At a minimum, the EAP exchange consists of 1.5 round trips. + However, given the way EAP interacts with AAA, and given that an EAP + identity exchange is typically employed, at least 2 round trips are + required to the EAP server. An even higher number of round trips is + required by the most commonly used EAP methods. For instance, EAP- + TLS requires at least 3 but typically 4 or more round trips. There have been attempts to solve the problem of efficient re- authentication in various ways. However, those solutions are either EAP-method specific or EAP lower-layer specific. Furthermore, these solutions do not deal with scenarios involving handovers to new authenticators, or do not conform to the AAA keying requirements specified in [RFC4962]. This document provides a detailed description of efficient EAP-based re-authentication protocol design goals. The scope of this protocol is specifically re-authentication and handover between authenticators - within a single administrative domain. Inter-technology handover and - inter-administrative-domain handover are outside the scope of this - protocol. + within a single administrative domain. While the design goals + presented in this document may facilitate inter-technology handover + and inter-administrative-domain handover, they are outside the scope + of this protocol. 2. 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], with the qualification that unless otherwise stated they apply to the design of the re-authentication protocol, not its implementation or @@ -152,25 +164,26 @@ 3. Problem Statement Under the existing model, any re-authentication requires a full EAP exchange with the EAP server to which the peer initially authenticated [RFC3748]. This introduces handover latency from both network transit time and processing delay. In service provider networks, the home EAP server for a peer could be on the other side of the world, and typical intercontinental latencies across the Internet are 100 to 300 milliseconds per round trip [LGS07]. + Processing delays average a couple of milliseconds for symmetric-key operations and hundreds of milliseconds for public-key operations. An EAP conversation with a full EAP method run can take two or more - round trips and to complete, causing delays in re-authentication and + round trips to complete, causing delays in re-authentication and handover times. Some methods specify the use of keys and state from the initial authentication to finish subsequent authentications in fewer round trips and without using public-key operations (detailed Section 6.1). However, even in those cases, multiple round trips to the EAP server are required, resulting in unacceptable handover times. In summary, it is undesirable to run an EAP Identity and complete EAP method exchange each time a peer authenticates to a new authenticator or needs to extend its current authentication with the same @@ -220,31 +233,40 @@ AAA protocol compatibility and keying: Any modifications to EAP and EAP keying MUST be compatible with RADIUS [I-D.ietf-radext-design] and Diameter [I-D.ietf-dime-app-design-guide]. Extensions to both RADIUS and Diameter to support these EAP modifications are acceptable. The designs and protocols must be configurable to satisfy the AAA key management requirements specified in RFC 4962 [RFC4962]. Compatibility: Compatibility and co-existence with compliant - ([RFC3748] [I-D.ietf-eap-keying]) EAP deployments SHOULD be + ([RFC3748] [I-D.ietf-eap-keying]) EAP deployments MUST be provided. Specifically, the protocol should be designed such that - fall back to EAP authentication occurs if not all devices in the - network support fast re-authentication. + a peer not supporting fast re-reauthentication should still + function in a network supporting fast re-authentication, and also + a peer supporting fast re-authentication should still function in + a network not supporting fast re-authentication. + Cryptographic Agility: Any re-authentication protocol MUST support cryptographic algorithm agility, to avoid hard-coded primitives whose security may eventually prove to be compromised. The protocol MAY support cryptographic algorithm negotiation, provided it does not adversely affect overall performance (i.e. by requiring additional round trips). + Impact to Existing Deployments: Any re-authentication protocol MAY + make changes to the peer, authenticator, and EAP server, as + necessary to meet the aforementioned design goals. In order to + facilitate protocol deployment, protocols should seek to minimize + the necessary changes, without sacrificing performance. + 5. Security Goals 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. 5.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 @@ -293,26 +315,25 @@ ensure proper key scoping, and securely provide its identity to any other entity that may require the identity for defining the key scope. 5.4. Authorization The EAP Key management document [I-D.ietf-eap-keying] discusses several vulnerabilities that are common to handover mechanisms. One important issue arises from the way the authorization decisions might be handled at the AAA server during network access authentication. - For example, if AAA proxies are involved, they may influence - authorization decisions. Furthermore, the reasons for making a - particular authorization decision are not communicated to the - authenticator. In fact, the authenticator only knows the final - authorization result. The proposed solution must make efforts to - document and mitigate authorization attacks. + Furthermore, the reasons for making a particular authorization + decision are not communicated to the authenticator. In fact, the + authenticator only knows the final authorization result. The + proposed solution must make efforts to document and mitigate + authorization attacks. 5.5. Channel Binding Channel Binding procedures are needed to avoid a compromised intermediate authenticator providing unverified and conflicting service information to each of the peer and the EAP server. To support fast re-authentication, there will be intermediate entities between the peer and the back-end EAP server. Various keys need to be established and scoped between these parties and some of these keys may be parents to other keys. Hence the channel binding for @@ -327,36 +348,36 @@ elements involved, there may be a need for multiple protocols to perform the key transport between entities involved in the handover keying architecture. Thus, a set of requirements for each of these protocols, and the parameters they will carry, must be developed. The use of existing AAA protocols for carrying EAP messages and keying material between the AAA server and AAA clients that have a role within the architecture considered for the keying problem will be carefully examined. Definition of specific parameters, required for keying procedures and to be transferred over any of the links in - the architecture, are part of the scope. The relation of the + the architecture, are part of the scope. The relation between the identities used by the transport protocol and the identities used for keying also needs to be explored. 6. 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. 6.1. Method-Specific EAP Re-authentication A number of EAP methods support fast re-authentication. In this section we examine their properties in further detail. - EAP-SIM [RFC4186] and EAP-AKA [RFC4187] supports fast re- + EAP-SIM [RFC4186] and EAP-AKA [RFC4187] support fast re- authentication, bootstrapped by the keys generated during an initial full authentication. In response to the typical EAP-Request/ Identity, the peer sends a specially formatted identity indicating a desire to perform a fast re-authentication. A single round-trip occurs to verify knowledge of the existing keys and provide fresh nonces for generating new keys. This is followed by an EAP success. In the end, it requires a single local round trip between the peer and authenticator, followed by another round trip between the peer and EAP server. AKA is based on symmetric-key cryptography, so processing latency is minimal. @@ -441,21 +463,21 @@ 7. 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 [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 5 for further details. + and authorization. See Section 5 for further details. 8. IANA Considerations This document does not introduce any new IANA considerations. 9. Contributors This document represents the synthesis of two problem statement documents. In this section, we acknowledge their contributions, and involvement in the early documents. @@ -475,21 +497,21 @@ Rafael Marin Lopez Universidad de Murcia Email: rafa@dif.um.es 10. Acknowledgements The authors would like to thank the participants of the HOKEY working group for their review and comments, including Glen Zorn, Dan Harkins, Joe Salowey, and Yoshi Ohba. The authors would also like to thank those that provided last call reviews, including Bernard Aboba, - Alan DeKok, and Hannes Tschofenig. + Alan DeKok, Jari Arkko, and Hannes Tschofenig. 11. References 11.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)", @@ -506,22 +528,22 @@ 11.2. Informative References [I-D.funk-eap-ttls-v0] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication Protocol Version 0 (EAP-TTLSv0)", draft-funk-eap-ttls-v0-02 (work in progress), November 2007. [I-D.ietf-capwap-protocol-specification] Calhoun, P., "CAPWAP Protocol Specification", - draft-ietf-capwap-protocol-specification-08 (work in - progress), November 2007. + draft-ietf-capwap-protocol-specification-09 (work in + progress), February 2008. [I-D.ietf-dime-app-design-guide] Fajardo, V., Asveren, T., Tschofenig, H., McGregor, G., and J. Loughney, "Diameter Applications Design Guidelines", draft-ietf-dime-app-design-guide-06 (work in progress), January 2008. [I-D.ietf-eap-keying] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", @@ -562,42 +584,43 @@ May 2007. [IEEE.802-11R-D9.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, January 2008. - [KP01] Koodli, R. and C. Perkins, "Fast Handover and Context - Relocation in Mobile Networks", ACM SIGCOMM Computer and - Communications Review, October 2001. - [LGS07] Ledlie, J., Gardner, P., and M. Selter, "Network Coordinates in the Wild", USENIX Symposium on Networked System Design and Implementation, April 2007. [MSA03] Mishra, A., Shin, M., and W. Arbaugh, "An Empirical Analysis of the IEEE 802.11 MAC-Layer Handoff Process", ACM SIGCOMM Computer and Communications Review, April 2003. + [MSPCA04] 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, Editor Laboratory for Telecommunications Sciences US Department of Defense College Park, MD USA Email: clancy@LTSnet.net + Madjid Nakhjiri Motorola Email: madjid.nakhjiri@motorola.com Vidya Narayanan Qualcomm, Inc. San Diego, CA USA