--- 1/draft-ietf-hokey-reauth-ps-05.txt 2007-11-06 21:12:06.000000000 +0100 +++ 2/draft-ietf-hokey-reauth-ps-06.txt 2007-11-06 21:12:06.000000000 +0100 @@ -1,18 +1,18 @@ HOKEY Working Group T. Clancy, Editor Internet-Draft LTS -Intended status: Informational November 2, 2007 -Expires: May 5, 2008 +Intended status: Informational November 6, 2007 +Expires: May 9, 2008 Handover Key Management and Re-authentication Problem Statement - draft-ietf-hokey-reauth-ps-05 + draft-ietf-hokey-reauth-ps-06 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,139 +23,128 @@ 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 May 5, 2008. + This Internet-Draft will expire on May 9, 2008. Copyright Notice 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 handover. + statement. The current Extensible Authentication Protocol (EAP) + keying framework is not designed to support re-authentication and + handovers. This often causes unacceptable latency in various mobile + wireless environments. The HOKEY Working Group plans to address + these problems by designing a generic mechanism to reuse derived EAP + keying material for handover. Table of Contents - 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 - 5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 6. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 6 - 6.1. Key Context and Domino Effect . . . . . . . . . . . . . . 6 - 6.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7 - 6.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 7 - 6.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 7 - 6.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 7 - 6.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 7 - 7. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 8 - 7.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 8 - 7.2. IEEE 802.21 Applicability . . . . . . . . . . . . . . . . 9 - 7.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 9 - 7.4. Inter-Technology Handover . . . . . . . . . . . . . . . . 9 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 5. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 + 5.1. Key Context and Domino Effect . . . . . . . . . . . . . . 6 + 5.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 6 + 5.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 6 + 5.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 7 + 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 7 + 5.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 7 + 6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 8 + 6.1. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 8 + 6.2. IEEE 802.21 Applicability . . . . . . . . . . . . . . . . 8 + 6.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 9 + 6.4. Inter-Technology Handover . . . . . . . . . . . . . . . . 9 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 - Intellectual Property and Copyright Statements . . . . . . . . . . 12 - -1. Contributors - - The following authors contributed to the HOKEY problem statement - document: - - 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, Motorola, madjid.nakhjiri@motorola.com - o Vidya Narayanan, QUALCOMM, vidyan@qualcomm.com - o Mohan Parthasarathy, Nokia, mohan.parthasarathy@nokia.com - o Hannes Tschofenig, Siemens, Hannes.Tschofenig@siemens.com + Intellectual Property and Copyright Statements . . . . . . . . . . 13 -2. Introduction +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 MSK (EMSK). + 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 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. + technology to 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. 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. + to transports the MSK to the authenticator. Note that this is + performed using AAA protocols, not EAP itself. The underlying L2 or + L3 protocol uses the MSK to derive additional keys, including the + transient session keys (TSKs) 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 unfortunately - not efficient in case of mobile and wireless networks. When a peer - arrives at the new authenticator, or is expected to re-affirm its - access through the current authenticator, the security restraints - 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 may involves several - round trips between the EAP peer and the server. + not efficient in cases where the peer is a mobile device. When a + peer arrives at the new authenticator, the security restraints 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 may involve 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 [RFC4962]. - This document provides a detailed description of EAP efficient re- - authentication protocol requirements. + This document provides a detailed description of efficient EAP-based + re-authentication protocol requirements. -3. Terminology +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 respect to EAP, this document follows the terminology that has been defined in [RFC3748] and [I-D.ietf-eap-keying]. -4. Problem Statement +3. Problem Statement Under the existing model, any re-authentication requires a full EAP exchange with the EAP server in its home domain [RFC3748]. An EAP conversation with a full EAP method run can take several round trips and significant time to complete, causing delays in re-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, multiple round trips to the EAP server are still involved. Furthermore, many commonly-used EAP methods do not offer such a fast @@ -166,32 +155,30 @@ method-independent, efficient, re-authentication protocol. Keying material from the full authentication can be used to enable efficient re-authentication. Significant network latency between the peer and EAP server is another source of delay during re-authentication. It is desirable to have a local server with low-latency connectivity to the peer that can facilitate re-authentication. Lastly, a re-authentication protocol should also be capable of - supporting handover keying. Handover keying allows re-authentication - keys to be passed to a different re-authentication domain (not - necessarily a different AAA domain or administrative domain). - Execution of the re-authentication protocol in that re-authentication - domain will then allow handover from one re-authentication domain to - another. + supporting handover keying. Handover keying allows an EAP server to + pass authentication information to a remote re-authentication server, + allowing a peer to re-authenticate to that re-authentication server + without having to communicate with its home re-authentication server. These problems are the primary issues to be resolved. In solving them, there are a number of constraints to conform to and those result in some additional work to be done in the area of EAP keying. -5. Design Goals +4. 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 @@ -213,27 +200,27 @@ 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 RFC 4962 [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 +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. -6.1. Key Context and Domino Effect +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 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 the scope parameters have to be exchanged. Furthermore, the semantics of these parameters MUST be defined to provide proper @@ -252,91 +239,91 @@ Note that the compromise of higher-level keys has security implications on lower levels. 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 +5.2. Key Freshness 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 +5.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 +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 also influence in the authorization decision. 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. -6.5. Channel Binding +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. In the architecture introduced in this document, there are multiple 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 this architecture will need to consider layering intermediate entities at each level to make sure that an entity with higher level of trust can examine the truthfulness of the claims made by intermediate parties. -6.6. Transport Aspects +5.6. Transport Aspects Depending on the physical architecture and the functionality of the 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. Following the requirement specifications, recommendations will be provided as to whether new protocols or extensions to existing protocols are needed. As mentioned, 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 identities used by the transport protocol and the identities used for keying also needs to be explored. -7. Use Cases and Related Work +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. -7.1. IEEE 802.11r Applicability +6.1. IEEE 802.11r Applicability 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 @@ -355,80 +342,119 @@ 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. IEEE 802.21 Applicability +6.2. IEEE 802.21 Applicability 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 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 +6.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 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.4. Inter-Technology Handover +6.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 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 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 +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 6 for further details. + and authorization. See section Section 5 for further details. -9. IANA Considerations +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. + + Authors of "AAA based Keying for Wireless Handovers: Problem + Statement" are: + + Madjid Nakhjiri + Motorola Labs + Email: madjid.nakhjiri@motorola.com + + Mohan Parthasarathy + Nokia + Email: mohan.parthasarathy@nokia.com + + Julien Bournelle + France Telecom R&D + Email: julien.bournelle@orange-ftgroup.com + + Hannes Tschofenig + Siemens + Email: Hannes.Tschofenig@siemens.com + + Rafael Marin Lopez, Editor + Universidad de Murcia + Email: rafa@dif.um.es + + Authors of "Problem Statement on EAP Efficient Re-authentication and + Key Management" are: + + Vidya Narayanan + QUALCOMM, Inc. + Email: vidyan@qualcomm.com + + Lakshminath Dondeti + QUALCOMM, Inc. + Email: ldondeti@qualcomm.com + 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.