Network Working Group M. Nakhjiri Internet-Draft Motorola Labs Expires: November 13, 2006 M. Parthasarathy Nokia J. Bournelle GET/INT H. Tschofenig Siemens R. Marin Lopez(Ed.) TARI May 12, 2006 AAA based Keying for Wireless Handovers: Problem Statement draft-nakhjiri-aaa-hokey-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 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 November 13, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Extensible Authentication Protocol (EAP) provides a framework for Nakhjiri, et al. Expires November 13, 2006 [Page 1] Internet-Draft EAP Keying Handovers: PS May 2006 performing authentication and key management using the AAA infrastructure. The framework deals with a model which includes a peer, a pass-through authenticator and a backend authentication server. Some of the emerging mobile networks use EAP in handover scenarios in ways that go beyond currently defined EAP keying framework. This document provides a problem statement for the usage of EAP in these emerging mobile networks. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Assumptions . . . . . . . . . . . . . . . . . 4 3. Problem Description . . . . . . . . . . . . . . . . . . . . . 6 4. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Key Context and scope, prevention of domino effect . . . . 11 4.2. Key Naming . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 12 4.5. Authentication of all the parties . . . . . . . . . . . . 13 4.6. Channel Binding . . . . . . . . . . . . . . . . . . . . . 13 4.7. EAP method independence . . . . . . . . . . . . . . . . . 13 4.8. Transport aspects . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.2. Informative references . . . . . . . . . . . . . . . . . . 15 Appendix A. Intra-ADC handover example . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Nakhjiri, et al. Expires November 13, 2006 [Page 2] Internet-Draft EAP Keying Handovers: PS May 2006 1. Introduction The Extensible Authentication Protocol (EAP) [RFC3748] and the keying framework [I-D.ietf-eap-keying] documents define an authentication and key management framework. These specifications define how an EAP method can be executed between a peer and an EAP server (typically located at the Home AAA server) through a pass-through authenticator and explain the key management. EAP Keying framework provide guidelines for generation of the keying material (MSK in EAP documents), at the EAP peer and the EAP/AAA servers. It also discusses transfer of this keying material to a pass-through authenticator for the purpose of further securing access links (i.e. deriving transient session keys (TSKs) through the Secure Association protocol (SAP) as described in [I-D.ietf-eap-keying]) to secure the link between the peer and the authenticator. Given that the TSK MAY be bound to particular access link, handover between different access links would require generation of new TSKs. Wireless networks deploy specific Access Nodes (ANs) providing link layer service to the peers, where the ANs are typically defined as separate elements from the element that controls them. On the other hand, mapping between those functional elements and the functional elements defined in EAP keying framework such as authenticator and authenticator ports has not been clear. This makes the applicability of EAP keying framework to each wireless technology difficult. As a result, existing wireless technologies had to create their own mappings as follows: o 802.11r [802.11r] has introduced the concept of the key holders and two levels of key hierarchy between the MSK sent from the AAA server and the TSKs (called Pairwise Transient Key, PTK in 802.11r) to avoid the need for generation of new MSKs in conjunction with each AN-handover. The two levels are PMK-R0 and PMK-R1 (PMK stands for Pairwise Master Key). The PMK-R0 is created based on MSK and is held at a so-called PMK-R0 key holder, while the PMK-R1 created from PMK-R0 and is kept at a PMK-R1 holder. This way the PMK-R0 key holder can create master keys (PMK-R1) for all the access points (AP) it is serving. o WiMAX (supporting organization for 802.16e) has introduced a two- part authenticator function, in which one part acts as a key holder, receiving the MSK from AAA server and calculating keys specific to ANs, while the other part residing at the AN acts as an authenticator relay and key receiver that receives the master keys for link security (authorization key, AK). In either case, it seems that these SDOs have recognized that the EAP keying model where the EAP server simply sends the MSK to the pass- Nakhjiri, et al. Expires November 13, 2006 [Page 3] Internet-Draft EAP Keying Handovers: PS May 2006 through authenticator to which the EAP peer is directly connected to is not sufficient to succinctly design a keying solution for a mobile wireless environment even in cases where the peer hands over between access nodes that are all served by the same authenticator. What is even more important to note is that neither of these SDOs have provided a method for inter-authenticator handovers. Given that various standard bodies are extending EAP keying framework in different ways to solve the wireless mobility keying for intra- authenticator handovers and given that most of these standards do not deal with inter-authenticator handovers, it seems appropriate to develop a comprehensive handover keying solutions that deals with various types of handovers within IETF. This document intends to provide a problem statement for handover keying. It also describing the security goals that the specification needs to meet. 2. Terminology and Assumptions 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]. Most of the terminology found in this document uses the EAP keying document [I-D.ietf-eap-keying]. However, this document defines new terms in place of several terms defined in EAP keying framework in order to clearly describe the handover keying problem. Since wireless technologies that support handover have the architecture of physically or logically separating network attachment points from the controller of the network attachment points, it is more reasonable, than re-using the existing terms, to define the network attachment points as separate elements from the authenticator and other new terms that are closely related to this separation of authenticator and authenticator ports defined in [I-D.ietf-eap-keying]. Access Node (AN): The access node is the entity (layer 2 or layer 3) residing at the edge of network and is responsible for providing access link to the peer. EAP server: The EAP server in handover keying has the same functionality of a backend EAP server in [RFC3748] and [I-D.ietf- eap-keying], i.e, the EAP server terminates the EAP authentication method with peer through a pass-through authenticator and can perform keying functions. Nakhjiri, et al. Expires November 13, 2006 [Page 4] Internet-Draft EAP Keying Handovers: PS May 2006 EAP pass-through authenticator: The pass-through authenticator is the entity between a peer and a backend EAP server that is passing through EAP Request and Response messages ([RFC3748]) without understanding their data content. It can understand EAP success and failure messages. The role of pass-through authenticator during EAP authentication is defined in [RFC3748]. Access Domain Controller: Entity responsible for keying needs within an Access Domain. ADC holds a per-ADC specific ADMSK for the authentication domain and uses this ADMSK to derive new LSAP-MK for different ANs under its control. Access Domain (AD): A domain whose authentication (with the backend EAP/AAA server) and key management goes through the same ADC. Mobile Node (MN) (peer): The entity that receives network access through an Access Node--> and acts as an EAP peer functionality as described by [RFC3748] and EAP keying framework [I-D.ietf-eap- keying], with the exception that mobile node may not have a direct link to the EAP pass-through authenticator. In this document we use the terms MN and EAP peer interchangeably. SA: Security Association. X-Master Session Key (XMSK): A key that will be used as the root key to solve the handover keying problem. We assume that the XMSK is generated as a result of a successful EAP authentication and keying process and will be available at both the peer and the Home AAA server. Whether the EAP generated MSK or an AMSK (generated from EMSK) is used as XMSK as the root key is to be determined later on. In the rest of this document, we will only refer to XMSK. Access Domain Master Session Key (ADMSK): A key that is sent to each Access Domain Controller (or the key holder function within the ADC) that is unique for that ADC and can be used for a root key for generation further lower level keys within the domain served by the ADC. Link Secure Association Protocol (LSAP): In a general case, the authenticator function is not located at the AN. The term Link Secure Association Protocol refers to the process used between the peer and the AN to generate and manage the security associations used to protect the peer-AN link (layer 2 or layer 3). We introduce this term to avoid confusion with term Secure Association Protocol (SAP) defined in [I-D.ietf-eap-keying] that runs between the peer and the authenticator. The LSAP protocol Nakhjiri, et al. Expires November 13, 2006 [Page 5] Internet-Draft EAP Keying Handovers: PS May 2006 uses LSAP-MK (below) as a root key and arrives at LSKs. LSAP Master key (LSAP-MK): The master key used by the peer and the AN during LSAP run to arrive at LSKs between the peer and the AN. LSAP-MK is derived from XMSK through one or more steps in ways to be explored. Link Session Keys (LSK): The keys derived upon completion of LSAP and used to secure the access link between the peer and the AN. In a special case, where the AN and the authenticator are co-located and use the same identifiers, the LSKs in this document and the transient session keys (TSK) in [I-D.ietf-eap-keying] may become the same. Key Holder: The functional entity that holds a root key/s and can perform further key derivation using that root key. There may be multiple Key Holders in the network (e.g. at the AAA server or ADC). 3. Problem Description As mentioned earlier, in wireless access networks, where the peer hands off between various ANs, using the keying model described in EAP authentication and key management framework causes some difficulties in achieving optimized handovers. As shown in Figure 1, it is more appropriate to consider a functional model, where a functional entity (we have used the term Authentication Domain Controller) other than the AN holds the master key sent from the AAA server and generates per AN master keys for each AN. +-+-+-+-+-+ +-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | MN/ |-----| AN |---| ADC |----|EAP/AAA server | |EAP Peer | +-+-+-+ | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+-+ Figure 1: Wireless access network with separate AN and Access Domain Controller(ADC) Using EAP keying framework on this new architecture model poses some design issues in two main cases analyzed following: Nakhjiri, et al. Expires November 13, 2006 [Page 6] Internet-Draft EAP Keying Handovers: PS May 2006 o Inter-ADC handovers: Most of the modern EAP methods create both an Master Session Key (MSK) and an Extended Master Session Key (EMSK) upon a success authentication. Most of existing access technologies that use EAP keying transport MSK to the authenticator (as suggested by the current EAP keying framework). This means they cannot support inter-authenticator handover without depending on either an authenticator-anchoring or a key context transfer from one authenticator to the next. The anchoring would cause practical limitations in high speed mobility environments, while the context transfer will potentially suffer from the domino effect (see [I-D.housley-aaa-key-mgmt]), where the compromise of a single authenticator may lead to the compromise of series. Writing off those two options, handing over to another authenticator would require generation of another MSK for the new authenticator (and thus a new EAP authentication). A new key hierarchy should be developed in a way that handover to a new authenticator does not require a new full EAP authentication. This for instance could be achieved by generating lower level keys (called ADMSK) for each access domain from the XMSK. The AAA server will then transport the ADMSKs to the entity responsible for keying within the access domain. Since this functionality is different from the behavior described for the "pass-through authenticator" within EAP document, we have called this entity the Access Domain Controller (ADC), even though an ADC will with high likelihood include pass-through authenticator functionality that assists the peer with its EAP authentications. o Intra-ADC handovers: The current EAP keying framework does not specify keying details for topologies where multiple ANs are grouped under one pass-through authenticator. The need for separation of master keys at the pass-through authenticator/ADC (ADMSK delivered from AAA server) and master keys used for LSAP exchange (called LSAP_MK in this draft) has been recognized in several SDOs, such as IEEE 802.11r, 802.16e and WiMAX. The notion of authenticator ports are now being discussed to deal with this issue. Each AN can correspond to an authenticator port that may or may not physically be separated from the authenticator function. However, introducing the notion of authenticator-port alone does not deal with issues related to derivation of AN- specific master keys (LSAP_MK) from ADMSK, including key scoping and channel binding issues. Furthermore, it does not solve the delicate problem of the delivery of LSAP_MK from pass-through authenticator/ADC to the AN. Given both types of handover, some additional issues needs to be considered: Nakhjiri, et al. Expires November 13, 2006 [Page 7] Internet-Draft EAP Keying Handovers: PS May 2006 o Choice of XMSK: As mentioned, the inter-authenticator handover scenario would require that per-authenticator (per-ADC) keys (ADMSK) would be different from the top level key (XMSK) generated as part of/or as a result of an EAP authentication MSK. Since EAP methods only generate an MSK and an EMSK, and EMSK is not transportable and possibly not exportable from the EAP server, either a MSK or an AMSK generated from the EMSK are two choices for XMSK. It should also be noted that at EAP keying framework has required the transported keys to be deleted after transport. Choosing MSK as the root for handover keying key hierarchy (XMSK) would mean the MSK can no longer be sent to any authenticator and this would mean MSK usage would be different in EAP and handover keying solutions. Choosing AMSK would not cause any backward compatibility (by redefining previous usage of MSK) but would require generation of a specification on how AMSK needs to be generated from EMSK. o Fast Re-authentication: The EAP keying framework does not provide guidance on fast re-authentication process, that will help to improve handover process. This would lead us to the following minimum architecture to realize the handover keying solution (note that, in the Figure 2 we name the authenticator as Authentication Domain Controller or ADC): Nakhjiri, et al. Expires November 13, 2006 [Page 8] Internet-Draft EAP Keying Handovers: PS May 2006 SA1 <-----------------------------------------------------> SA12 <-----------------------------------------------------> SA4 SA3 SA2 <----------> <---------------> <----------------------> SA5 <----------------------------> (LSAP-MK) +-+-+-+-+-+ +-+-+-+ | MN/ |-----| AN1 |---+ (ADMSK1) |EAP Peer | +-+-+-+ | +--------------+ +-+-+-+-+-+ ^ +-----|ADC1(AUTH_KH) |---+ | SA6 | +--------------+ | | | | (XMSK) V | | +-+-+-+-+-+ +-+-+-+ | | |AAA/EAP | | AN2 |---+ +-+---| Server | +-+-+-+ | +---------+ (ADMSK2) | +-+-+-+ +--------------+ | | AN 3|---------|ADC2(AUTH_KH) |-----+ +-+-+-+ +--------------+ Figure 2: A wireless handover keying architecture deploying EAP Note that, it is assumed that the Home AAA server (AAAH) and the EAP server are co-located within the same physical device and possibly interact through internal mechanism, and therefore can be considered as one trusted party. As it can also be noted, this document introduces certain Key Holder (AUTH_KH) and key distribution functionality into the Authentication Domain Controller (ADC). As mentioned earlier, EAP keying specification has required of a AAA entity (either a AAA server or a AAA client) to delete a key (such as ADMSK) after transport. To accommodate such requirements a few things are required: 1. A per-ADC ADMSK must be generated from XMSK and transported to the ADC instead of the XMSK (to comply with the delete after transport requirement). 2. A stateless AAA server (such as RADIUS server) may also have a Key Holder (AAA_KH) function that caches the XMSK. Finally and for completion, various security associations (SA) Nakhjiri, et al. Expires November 13, 2006 [Page 9] Internet-Draft EAP Keying Handovers: PS May 2006 between the architecture entities shown in Figure 2 are described below: 1. SA1 is a long term credential established between the MN and the Home AAA server and used for EAP authentication. Provisioning of SA1 is outside scope. 2. SA12 is generated as a result of the EAP authentication between EAP peer and EAP server. For the purpose of handover keying, SA12 consists of XMSK and other information resulting from EAP authentication, such as authentication lifetime, XMSK lifetime and so on. 3. SA2 pre-exists between the ADC and the EAP/AAA server based on the AAA infrastructure before the EAP authentication starts. In roaming environments (multiple administrative domains) this SA may have to be established through a chain of trust. 4. SA3 is between the Access Node and the ADC to protect signalling and key transfers. Provisioning of SA3 is important for distribution of LSAP_MKs from authenticator to the AN. SA3 may pre-exist or may be created as part of initial keying. The requirements for SA3 and its creations are to be developed later on. 5. SA4 is between the peer (MN) and the Access Node and is established through LSAP exchange. SA4 information includes LSKs. Providing key derivation guidelines for SA4 is part of the problem being considered. 6. SA5 is between the MN and the ADC derived from the EAP authentication and key framework procedures. Providing key derivation guidelines and specifications for SA5 is part of the problem being considered. 7. SA6 represents a possible trust relationship between the ANs. The need for this trust for keying solution is to be investigated. As mentioned earlier, the potential physical separation (or separation of identifiers) of the ADC and AN will present challenges such as the need for an additional key transport protocol between the ADC and the AN, channel binding at multiple levels and carrying EAP signalling between the peer and the ADC through the AN. The most important goal for this effort is to provide a handover keying solution that best fit the architecture shown in Figure 2, whilst meeting the initially defined security goals. 4. Security Goals The baseline assumption in this document (see Section 3) is to use AAA based key management possibly using a key hierarchy stemming from Nakhjiri, et al. Expires November 13, 2006 [Page 10] Internet-Draft EAP Keying Handovers: PS May 2006 an XMSK which is generated through the EAP authentication and keying process. However, as we described, there are a number of alternatives for deployment of EAP framework to a wireless mobile network providing handover keying solutions. The definition of key material and associated parameters to derive the keys and security associations from an initial EAP authentication to support an optimized wireless network handover is the goal of this work. An important goal is to assess what keys and security associations (e.g. SA4 and/or SA5 in Figure 2) are to be re-used or re-generated as part of handover or a re-authentication process. The assessment is done considering the handover performance as well as the security goals defined in this document. Definition of relationship between the key material, such as definition of the hierarchy and child-parent/sister relationship before and after handover is part of scope. Although the exact definition of the actual cryptographic functions (Pseudo Random Functions) may not be part of the scope, definition of the inputs into the PRFs, e.g. root keys and associated parameters (e.g. ADC's IDs and nonces) are part of solution scope. The section will draw from the guidance provided in [I-D.housley-aaa- key-mgmt] to further define the security goals to be achieved by a complete handover keying solution. 4.1. Key Context and scope, prevention of domino effect Any key, including XMSK and the keys derived for the lower levels of key hierarchy (e.g., ADMSK, LSKs) 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 the 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 (e.g., lifetime, ADC's ID, authorization information) have to be exchanged. Furthermore, the semantics (not syntax) of these parameters MUST be defined to provide proper channel binding specifications. The definition of exact parameter syntax definition is however part of the design of the transport protocol used for the parameter exchange and that may be outside scope of this document. If a key hierarchy is deployed, compromising lower level keys MUST NOT result in a compromise of higher level keys which they were used to derive the lower level keys. The compromise of keys at each level MUST NOT result in compromise of other keys at the same level. The same principle applies to entities that hold and manage a particular Nakhjiri, et al. Expires November 13, 2006 [Page 11] Internet-Draft EAP Keying Handovers: PS May 2006 key defined in the key hierarchy. For example, an AN cannot have access to keying material for another AN. That is, compromising keys on one AN MUST NOT reveal the keys of another AN. 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 will be defined in a solution document. 4.2. Key Naming All the keying material starting from XMSK and the derivatives MUST be uniquely named so that it can be managed effectively. For example, when the peer is engaging in the LSAP, it should be able to identify the name of the key that is being used. 4.3. 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. For instance, the LSAP-MK for the LSAP between the MN and two different ANs must be generated freshly and independently, even when both ANs are under the same ADC. Furthermore, the keying solution needs to provide mechanisms for authorized refreshing each of the keys within the key hierarchy. 4.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 choosing a particular decision are not communicated to the AAA clients. In fact, the AAA client only knows the final authorization result. If AAA exchange is bypassed, this creates additional challenges to ensure that authorization is properly handled. Possibly differing capabilities of the ANs before and after handovers could result in correctness issues with these authorization as the AN or AAA client may lack information of proper granularity to make access or authorization decisions after a handover. The logical descriptions of each of the parties in the architecture in this document assumes that all the parties with the same role (ANs, ADCs, etc) have the Nakhjiri, et al. Expires November 13, 2006 [Page 12] Internet-Draft EAP Keying Handovers: PS May 2006 same capabilities when dealing with the AAA and keying matters. 4.5. Authentication of all the parties Each party in the handover keying architecture MUST be authenticated to any other party with whom it communicates and provides 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. 4.6. Channel Binding Channel Binding procedures are needed to avoid a compromised intermediate authenticator/ADC providing unverified and conflicting service information to each of the peer and the EAP server. However, typically only a 3-party model has been considered (see [I-D.arkko- eap-service-identity-auth]). In the architecture introduced in this document, there are multiple intermediate entities between the peer and the backend EAP/AAA 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 lying intermediate entities at each level and make sure that an entity with higher level of trust can examine the truthfulness of the claims made by intermediate parties (a discussion about hierarchical channel binding can be found in [I-D.ohba-eap-channel-binding]) 4.7. EAP method independence The handover keying framework needs to be independent of the chosen EAP method, as long as the method supports the needs of [RFC4017] and [I-D.ietf-eap-keying]. 4.8. 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. For instance when keys are transported between AAA server and AAA client, the key transport may be performed through a AAA protocol. On the other hand, when the ANs and ADCs are physically disparate, and the ADCs perform key management functions for the ANs, there will be a need for a key transport protocol between the AN and the ADCs. Thus, a set of requirements for each of these protocols (and the parameters they will carry) will be developed. Following the requirement specifications, recommendations will be provided as to whether new protocols or extensions to existing protocols are needed. Nakhjiri, et al. Expires November 13, 2006 [Page 13] Internet-Draft EAP Keying Handovers: PS May 2006 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. 5. Security Considerations This document discusses an enhancement of EAP key management for in the emerging mobile networks. Security aspects of this enhancement are discussed throughout the document. When the solution for the problem statement presented in this document is being specified, the solution will be checked against the security goals presented previously. 6. IANA consideration This document does not require any actions by IANA. 7. Acknowledgements The authors would like to thank Joe Salowey, Yoshihiro Ohba and Kuntal Chowdhury for their useful suggestions on forming this problem statement. 8. References 8.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. [I-D.ietf-eap-keying] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-13 (work in progress), May 2006. Nakhjiri, et al. Expires November 13, 2006 [Page 14] Internet-Draft EAP Keying Handovers: PS May 2006 8.2. Informative references [802.11r] Institute of Electrical and Electronics Engineer, "Draft Amendment to STANDARD FOR Information Technology - Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements. Part 11:Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Amendment 8: Fast BSS Transition", IEEE std. 802.11r/D2.0. [I-D.housley-aaa-key-mgmt] Housley, R. and B. Aboba, "Guidance for AAA Key Management", draft-housley-aaa-key-mgmt-02 (work in progress), March 2006. [I-D.arkko-eap-service-identity-auth] Arkko, J. and P. Eronen, "Authenticated Service Information for the Extensible Authentication Protocol (EAP)", draft-arkko-eap-service-identity-auth-04 (work in progress), October 2005. [I-D.ohba-eap-channel-binding] Ohba, Y., "Channel Binding Mechanism based on Parameter Binding in Key Derivation", draft-ohba-eap-channel-binding-00 (work in progress), January 2006. [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005. Nakhjiri, et al. Expires November 13, 2006 [Page 15] Internet-Draft EAP Keying Handovers: PS May 2006 Appendix A. Intra-ADC handover example Following and for the sake of clarity, we explain an intra-ADC handover example. (the example is based on the Figure 2 explained in Section 3) Initially, the MN (EAP peer) is connected to AN1 which in turn is connected to the ADC1. When MN connects to the access network for the first time (through AN1), it can use EAP [RFC3748] to authenticate to the access network (AAA server). This EAP authentication generates cryptographic material needed to generate the XMSK. The AAA server can upon generating the XMSK and then ADMSK1 forwards the ADMSK1 to ADC1, which in turn creates the LSAP master key (LSAP-MK) for the LSAP process between AN1 and the peer. The LSAP exchange leads to creation of a set of link security keys (LSKs) between the peer and AN1. When the peer (MN) needs to handoff to another AN (AN2 in Figure 2), the MN needs to the SA4 and potentially SA5 (e.g. AN2 to AN3 handover) needs to be updated. Thus, a new LSAP-MK is needed to perform a LSAP with new AN (i.e. AN2) and arrive with new LSKs with it. Not only the MN needs to know the mechanisms to arrive at a new LSAP-MK (LSAP-MK2) from the XMSK (or its derivatives), but also there must be an infrastructure to deliver the LSAP-MK2 to AN2 in a secure and timely manner. An optimal handover keying solution will achieve both of the above should happen without a new EAP authentication and possibly without contacting the Home AAA server. Nakhjiri, et al. Expires November 13, 2006 [Page 16] Internet-Draft EAP Keying Handovers: PS May 2006 Authors' Addresses Madjid Nakhjiri Motorola Labs Email: Madjid.nakhjiri@motorola.com Mohan Parthasarathy Nokia 313 Fairchild Drive Mountain View CA-94043 US Email: mohan.parthasarathy@nokia.com Julien Bournelle GET/INT 9 rue Charles Fourier Evry 91011 France Email: julien.bournelle@int-evry.fr Hannes Tschofenig Siemens Corporate Technology Otto-Hahn-Ring 6 81739 Munich Germany Email: Hannes.Tschofenig@siemens.com Rafael Marin Lopez Toshiba America Research,Inc 1 Telcordia Dr. Piscataway, NJ 08854 USA Email: rmlopez@tari.toshiba.com Nakhjiri, et al. Expires November 13, 2006 [Page 17] Internet-Draft EAP Keying Handovers: PS May 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. Nakhjiri, et al. Expires November 13, 2006 [Page 18]