Network Working Group M. Nakhjiri Internet-Draft Motorola Labs Expires: July 30, 2006 M. Parthasarathy Nokia J. Bournelle GET/INT H. Tschofenig Siemens January 26, 2006 AAA based Keying for Wireless Handovers: Problem Statement draft-nakhjiri-aaa-hokey-ps-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that 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 July 30, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Extensible Authentication Protocol (EAP) provides a framework for performing authentication and key management using the AAA infrastructure. The framework deals with a model which includes a Nakhjiri, et al. Expires July 30, 2006 [Page 1] Internet-Draft EAP Keying Handovers: PS January 2006 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 . . . . . . . . . . . . . . . . . 5 3. Problem Description . . . . . . . . . . . . . . . . . . . . . 8 4. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Key Context and scope, prevention of domino effect . . . . 12 4.2. Key Naming . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 13 4.4. Handover Vulnerabilities . . . . . . . . . . . . . . . . . 14 4.5. Authentication of all the parties . . . . . . . . . . . . 14 4.6. Channel binding . . . . . . . . . . . . . . . . . . . . . 14 4.7. EAP method independence . . . . . . . . . . . . . . . . . 14 4.8. Non goals . . . . . . . . . . . . . . . . . . . . . . . . 15 4.8.1. Transport aspects . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5.1. open issues . . . . . . . . . . . . . . . . . . . . . . . 15 6. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.2. Informative references . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Nakhjiri, et al. Expires July 30, 2006 [Page 2] Internet-Draft EAP Keying Handovers: PS January 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 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 (TSK) through the Secure Association protocol (SAP) as described in [I-D.ietf-eap-keying]) to secure the link between the peer and the authenticator. Wireless networks deploy specific access nodes (AN) providing link layer service to the peers. The EAP keying framework has been used for these environments to arrive at TSKs to secure the peer-AN link. This however means, the authenticator would have to either be co- located at the AN or deploy specific ports at the AN to be able to perform SAP exchanges with the peer based on the MSK received from the EAP/AAA server (hence required AAA client functionality at the authenticator) to generate TSKs with the peer. Use of this model (authenticator colocated with AN) for mobile networks poses some difficulties. When the peer hands off to another AN, it needs to renegotiate new TSKs with that AN. Since the MSK is typically the only secret used in derivation of TSK (the other information exchanged in SAP is visible to outsiders), protecting the TSK at new AN from the old AN would require derivation of new MSK at the new AN. Deriving a new MSK would require performing a new EAP authentication with the EAP server through the new authenticator (new AN) and this could result in significant handover performance degradation. In an effort to improve mobility performance, the latest access technologies have made architectural changes to avoid the need for authenticator-relocation and new MSK derivation. However, the approach has not been uniform: 802.11r has introduced the concept of key holder that maintains MSKs, so that the authenticator does not have access to the MSK. The authenticator instead uses lower level keys (pairwise master key 1, PMK-R1) in exchanges leading to TSKs (called pairwise transient keys, PTKs in 802.11r). WiMAX (supporting organization for 802.16e) has introduced a two-part Nakhjiri, et al. Expires July 30, 2006 [Page 3] Internet-Draft EAP Keying Handovers: PS January 2006 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 the picture shown in Figure 1, where the peer connects to an AN rather than an authenticator, is more representative of the actual deployment of the EAP keying and the pass-through authenticator function as a single logical and physical entity as defined in EAP framwork documents is not sufficient to succintly design a keying solution for a mobile wireless environment. Using EAP keying framework on this new architecture model poses some design issues that are being exarcerbated by the ambiguities in the current collection of EAP documentation. +-+-+-+-+-+ +-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | MN/ |-----| AN |---|Authenticator|----|EAP/AAA server | |EAP Peer | +-+-+-+ | /key holder | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+-+ Figure 1: Wireless access network with separate AN and pass-through authenticators First, EAP framework describes the delivery of master keys only to pass-through authenticators, and not to the ANs or to key holders, that are not collocated with the authenticator. Since, EAP framework needs to be mode independent (2 party or 3 party authentication), it does not clarify the role of pass-through authenticator in the AAA infrastructure (AAA client) transporting the MSK. In the design of a mobile network handover keying architecture we can safely assume the existence of both edge devices and backend AAA servers. Therefore we can and need to clarify the AAA roles in master key transport. Furthermore, the current EAP keying documentation requires AAA layer entities to delete the transported keys and this may imply a logical authenticator or AAA client will not be able to act as a key holder. Second, the EAP framework is currently ambiguious in whether the AAA key, MSK or AMSK is to be used in generation of keys for applications such as handover keying. It is also not clear what the role of each of EAP server and AAA server in authorizing, generating, caching and transferring AMSKs from EMSK is. It is the goal of this work to investigate the feasibility of concepts such as AMSK generation and usage in providing an appropriate AAA-based keying mechanism. Third, some deployments of EAP framework have introduced the notion of authenticator ports to address the scenarios where the AN is separate from the authenticator and the keys at the AN and the Nakhjiri, et al. Expires July 30, 2006 [Page 4] Internet-Draft EAP Keying Handovers: PS January 2006 authenticator are at different levels of key hierarchy. The issue is that the current EAP documentation does not specify the channel binding solution for each hierarchy level. Specific identities for authenticator and authenticator ports (ANs) would be needed at both peer (through advertising) and the network entities (see 802.11r R0KH-ID, R0 key holder identifier, and R1KH-ID, R1 keyholder IDs in document [IEEE P802.11r/D1.0]. Finally, the EAP framework does not provide guidance on processes such as pre-authentication, fast re-authentication that will help to improve handover process. Given that various standard bodies are extending EAP keying framework in a different way to solve the wireless mobility keying, it may be appropriate to use the IETF as a forum for development of such extensions. For exampel, it would be very useful to provide specifications that describe how the EAP derived keys, such as AMSK can be used to provide keying solutions for the handover problem without requiring new excution of full EAP exchanges with the EAP server. Topics to be addressed can range from possible inclusion of additional entities required for holding the keys, generating keys according some hierarchy and distributing the keys to proper entities to key hierarchy itself (relation to the EAP keys such as AMSK),channel binding and so on. This docuemnt 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]. Some additional terms and clarifications are included below. EAP server: The EAP server in handover keying has the 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 July 30, 2006 [Page 5] Internet-Draft EAP Keying Handovers: PS January 2006 AAA server: The entity that is the main point of trust and authorization (AAA) in the administrative domain, and maintains peer information and possibly keying information. The AAA server relies on EAP server for execution of EAP-method authentications. Party: A party is a processing entity that has a logically separate role in the architecture. In order to provide appropriate security for the key management design, in this document, we treat each party as if it were physically separate from the other parties, although in practice one or more parties may be inserted in the same physical box. Mobile Node (MN) (peer): The entity that receives network access through a point to point link to an Access Node and acts as an EAP peer functionality as described by [RFC3748] and keying frameworks [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. Access Node: 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. The physical implementation of AN may or may not include EAP pass-through authenticator or AAA client functions (described separately). Therefore, we consider AN and pass-through authenticator as separate parties. However, the AN is responsible for de-encapsulation of EAP messages over access- technology-specific link protocols (e.g. encapsulating EAP over EAPOL for 802.11 or over PKMv2 for 802.16e). 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 understand EAP success and failure messages. The authenticator may not necessarily be the terminating point for the physical access link to the peer. AAA client: We use AAA client in two senses in this document. 1) the first AAA entity (from mobile node side), that engages in AAA protocol conversation with the AAA infrastructure leading to the home AAA server. This entity is also responsible for encapsulating EAP messaging inside AAA protocol messages (RADIUS [RFC3579] or Diameter [RFC4072]). 2) An entity such the key holder that acts as a client dealing with the AAA server. Nakhjiri, et al. Expires July 30, 2006 [Page 6] Internet-Draft EAP Keying Handovers: PS January 2006 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. Exact correlation of XMSK with the EAP keys (e.g. MSK, EMSK, AMSK) is to be determined. In the rest of this document, we will only refer to XMSK. 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 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: This entity is the one that holds the root key/s for a key derivation process. There may be multiple key holders in the network and depending on their interaction with the AAA infrastructure, they may need to have AAA client functionality, especially if the key holder receives a key such as XMSK from a AAA server. Pseudo Random Function (PRF): The function used in generation of a keying material. There may be multiple PRFs (PRF1/PRF2/..PRFn) involved dealing with generation various keys between each pair in the architecture. Cryptographic specification of the PRFs is outside scope of this document, as it may be governed by outside SDO. For instance a PRF used between the peer and AN to generate LSKs is specified by the SDO standardizing the access link. Nakhjiri, et al. Expires July 30, 2006 [Page 7] Internet-Draft EAP Keying Handovers: PS January 2006 AAA protocol: AAA based keying relies on tranferring the XMSK from AAA server to a AAA client using a AAA protocol. The AAA protocol needs to support secure key wrapping and transfer as well as transfer of authorization and usage material if needed. 3. Problem Description As mentioned earlier, in wireless access networks using EAP authentication and key management framework, it is not appropriate to store the XMSK from the EAP process at the AN. Otherwise, as the peer hands off from one AN to another, it would have to perform a complete EAP authentication to receive a new XMSK unique for the new AN. Since, the EAP keying framework assumes the XMSK is tranported to the pass-through authenticator, the need to keep XMSK unchanged would mean the XMSK needs to be stored at a key holder other than the AN. This would lead us to the following minimum archiecture to realize the handover keying solution: SA1 <-----------------------------------------> SA12 <-----------------------------------------> SA4 SA3 SA2 <--------> <--------------> <-------------> SA5 <---------------------> +-+-+-+-+-+ +-+-+-+ | MN/ |-----| AN1 |---+ |EAP Peer | +-+-+-+ | +-+-+-+ +-+-+-+-+-+ ^ +-----|KH 1 |-+ | SA6 | +-----+ | | | | V | | +-+-+-+-+-+ +-+-+-+ | | |AAA/EAP | | AN2 |---+ +--+--| Server | +-+-+-+ | +---------+ | +-+-+-+ +-----+ | | AN 3|---------+kH 2 +----+ +-+-+-+ +-+-+-+ Nakhjiri, et al. Expires July 30, 2006 [Page 8] Internet-Draft EAP Keying Handovers: PS January 2006 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 mechanisms, and therefore can be considered as one trusted party. As can also be noted, this document introduces a key holder into the architecture. Another reason for introducing a key holder is, EAP keying specification currently requires a AAA entity (either a AAA server or a AAA client) to delete a key (such as XMSK) after transport. To accomodate the key management functions (storage, further key derivation and distribution) required, we assume the AAA infrastructure passes the keys to the key holders (KH). A local key holder that receives keys from the AAA server may need to be a AAA client. As shown in Figure 2, the MN (EAP peer) is connected to AN1 which in turn is connected to the Authenticator 1 (Athr1). We will discuss alternatives on authenticator placement shortly, but let us assume for now the Athr1 is at key holder 1 (KH1). 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) through authenticator 1. The AAA server forwards the XMSK to KH1, 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. The ultimate solution may include levels of hierarchies and key holders betwen XMSK and LSAP-MK, but that is not important for this discussion at the moment. When the peer (MN) needs to handoff to another AN (AN2 in figure Figure 2), the MN needs to have a new LSAP-MK to perform a LSAP with AN2 and arrive with new LSKs with AN2. 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 achive both of the above should happen without a new EAP authentication and possibly without contacting the home AAA server. For completion, various security associations (SA) between the archiecture entities in figure 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 life time, XMSK life time Nakhjiri, et al. Expires July 30, 2006 [Page 9] Internet-Draft EAP Keying Handovers: PS January 2006 and so on. 3. SA2 pre-exists between the key holder 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 pre-exists between the Access Node and the key holder to protect signaling and key transfers. Provisioning of SA3 is outside scope of this document, unless it is required by IETF to provide guidance for the SDOs using the handover keying architecture. 5. SA4 is between the peer (MN) and the Access Node and is established through LSAP exchange. SA4 information includes LSKs. 6. SA5 is between the EAP peer and the key holder derived from the EAP authentication and key framework procedures. 7. SA6 represent a possible trust relationship between the ANs. The need for this trust for keying solution is to be investigated. As the mobile node hands off from AN1 to another AN, the SA4 and potentially SA5 (e.g. AN2 to AN3 handover) needs to be updated. Depending on the solution and the coverage domain of the key holder, a change of SA5 may also require a change of SA12 and thereby require a full EAP authentication. However, handover performance requirements may dictate that handover keying should not involve full EAP authentication exchange. Currently, there are no clear guidelines on how the EAP keying framework and its master keys (MSK, EMSK) can be used further in the access network to derive keys for SA1, SA4 and SA5. As mentioned earlier, the EAP keying specifications only discuss transport of XMSK to an authenticator and therefore, we recommended separating the AN and authenticator functions and introduction of a key holder into the architecture to receive and hold the XMSK. This makes the physical placement of pass-through authenticator and AAA client in our architecture uncertain. There are several alternatives for placing the pass-through authenticator and AAA client functionalities on the table: Alternative 1: Authenticator, AAA client and key holder are co- located. AN has only access technology functionality, encapsulates EAP over link technology on the peer side and over a TBD protocol to the EAP pass-through authenticator. The AAA client/authenticator/key holder encapsulates EAP inside AAA protocol and receives XMSK from the AAA server. The issue with this alternative is that, authenticator handovers are equivalent to key holder handovers. In other word, when an AN handovers leads to a key holder handover (AN2 Nakhjiri, et al. Expires July 30, 2006 [Page 10] Internet-Draft EAP Keying Handovers: PS January 2006 to AN3 handover in Figure 2), require derivation of new XMSKs. In wireless networks, the link between AN and the authenticator may be the link carrying backhaul traffic and hence may be bandwidth- limited. This will constrain the AN to key holder ratio in the handover keying architecture and therefore may have an adverse effect on over all system handover performance as the likelihood of a handover leading to a key holder handover (and hence interaction with backend server) will increase. +-+-+-+-+ +-+-+-+-+-+ +-+-+-+ +-+-+-+-+-+ | | | | |KH | | | | EAP |--------| Access |-------|Athr |------| EAP/AAA | | Peer | | Node | |AAAC | | Server | +-+-+-+-+ +-+-+-+-+-+ +-+-+-+ +-+-+-+-+-+ Figure 3: Alternative 1: AN with almost no AAA or EAP functionality Alternative 2: Authenticator and AAA client are located in the AN: as previous case, however the key holder is not on the AAA signaling path and acts as separate AAA client receiving the XMSK from the server. In this alternative a key holder can serve many authenticators and hence the Number of ANs (AN_No)per key holder is not directly limited by the backhaul issues. The AN_No/key holder ratio can be higher than AN_No/ authenticator ratio. However, issues related to key transfer from AAA server to key holder (instead of authenticator) need to be resolved. +-+-+-+-+-+ | Key Hldr| | AAAC |-----+ +-+-+-+-+-+ \ | \ | \ V \ +-+-+-+-+ +-+-+-+-+-+ \ +-+-+-+-+-+ | | | Athr | +-| | | EAP |--------| AAAC |------------| EAP/AAA | | Peer | | AN | | Server | +-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ Figure 4: Alternative 2: off-AAA-path key holder function As it can be clearly seen, there are many architecture, protocol design, security and authorization issues to be resolved as part of definition of the problem and solution for handover keying. This document is merely serving as a statement for a problem to be Nakhjiri, et al. Expires July 30, 2006 [Page 11] Internet-Draft EAP Keying Handovers: PS January 2006 solved without going into the specifics of the solution. The actual specifications will be part of the later solution documents. The most important goal for this effort is to provide a keying solution that best fit the architecture shown in Figure 2, whilst meeting the initially defined security goals.. This will most likely involve choosing one of the realization alternatives described in Figure 3 to Figure 4 which is agreed by the involved experts as the most deployable and the one with the highest probability of providing best handover performance, For an initial discussion on the pros and cons of each of these alternatives, the reader is referred to [I-D.nakhjiri-eap-ho]. 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 an XMSK delivered 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 association to support initial entry to wireless network and handover is the goal of this work. An important goal is to assess what keys and security associations (e.g. SA4 and/or SA5) are to be re-used or re-generated as part of handover or re-authentication. 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 (PRFs) may not be part of the scope, definition of the inputs into the PRF, e.g. root keys and the parameters e.g. holder 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 layers of key hierarchy (e.g., LSKs) MUST have a well-defined scope and MUST be used a specific context. This specifically means the lifetime and scope of each key MUST be defined clearly so that all the entities Nakhjiri, et al. Expires July 30, 2006 [Page 12] Internet-Draft EAP Keying Handovers: PS January 2006 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, key holder 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, the lower layer key holder MUST NOT have access to keying material for the higher layer key holder or another key holder at the same layer, e.g., an AN cannot have access to keying material for another AN. The compromise of keys on one Access Node SHOULD NOT reveal the keys of another Access Node. Note that, the compromise of higher level key holders (such as AAA server data base) does have have security implications on lower levels. Depending on the outcome of [I-D.ietf-eap-keying] in EAP WG if the AAA layer (as an EAP lower layer) is not authorized to keep any transported keys, the role of AAA entities (AAA client and server) and their interaction with the key holders within the keying architecture must be defined. 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 Session keys produced at each level of key hierarchy, e.g. LSAP-MK for LSAP or between each two parties SHOULD be fresh. The strength of these keys are abstracted by the choice of Pseudo Random Function (PRF) used to derive the keys at that level. The same key at a higher level can be used to derive multiple keys at lower layers. The keying material at the key holder may be used to derive keying material for multiple ANs under that key holder, as long as the keying material for the Access Nodes are not derived from each other in whole or partially. Nakhjiri, et al. Expires July 30, 2006 [Page 13] Internet-Draft EAP Keying Handovers: PS January 2006 4.4. Handover Vulnerabilities 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. If AAA proxies are involved, they may also influence the decision. The reasons for choosing a particular decision is not communicated to the AAA clients. The AAA client (and thereby AN in this architecture) knows only the final result. When the 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, key holders, etc) have the same capabilities when dealing with the AAA and keying matters. 4.5. Authentication of all the parties Each party in the keying framework 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 (channel binding). 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 pass- through entity providing unverified and conflicting service information to each of the peer and the EAP server. The current solutions [I-D.arkko-eap-service-identity-auth] [I-D.ohba-eap-aaakey- binding] only address 3-party models. In the architecture introduced in this document, there are multiple intermediate parties 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. 4.7. EAP method independence The keying framework needs to be independent of the chosen EAP method, as long as the method supports the needs of [RFC4017] and Nakhjiri, et al. Expires July 30, 2006 [Page 14] Internet-Draft EAP Keying Handovers: PS January 2006 [I-D.ietf-eap-keying]. 4.8. Non goals This section deals with items that are considered out of scope for the handover keying problem space defined in this paper. 4.8.1. Transport aspects Except between the AAA server and the AAA client, specification of the transport (including message formats) of EAP messages between the different parties, e.g., between the peer and the AN (such as use of PKMv2/802.16e for 802.16 ANs) and the backhaul between the AN and the key holder may be a responsibility of other standards organizations and therefore possibly outside scope of this work. This document may however pose restrictions on the protocol and the mechanism used between the AN and key holder for key transport between the AN and the key holder and may provide recommendations for protocols between the peer and AN (e.g., parameters for channel binding, etc). 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. As the solution for the problem statement presented in this document is specified, the solution will be checked against the security goals presented previously. 5.1. open issues It is yet to be determined whether the solution will depend on a key hierarchy and whether the key holder at each hierarchy level need to maintain a cache of each key as it is transported to lower layer entities. It is also yet to be understood what are the role of a central AAA server and of the local entities in the authorization and generation Nakhjiri, et al. Expires July 30, 2006 [Page 15] Internet-Draft EAP Keying Handovers: PS January 2006 of keys. generation. For that reason, until the "role" of which each entity is to play in a successfully implemented mobile environment, and specifically its access to particular keys according to this principle is to be defined and the risks of compromise of any entities resulted from the compromise of this entity is also to be determined. It is intuitively predicted that the higher the key holder is in the key hierarchy, the more impact on the lower layer key holders. 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-09 (work in progress), January 2006. 8.2. Informative references [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. Nakhjiri, et al. Expires July 30, 2006 [Page 16] Internet-Draft EAP Keying Handovers: PS January 2006 [I-D.nakhjiri-eap-ho] Nakhjiri, M., "EAP keying and handover support", draft-nakhjiri-eap-ho-00 (work in progress), June 2005. [I-D.housley-aaa-key-mgmt] Housley, R. and B. Aboba, "Guidance for AAA Key Management", draft-housley-aaa-key-mgmt-01 (work in progress), November 2005. [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-aaakey-binding] Yanagiya, M. and Y. Ohba, "AAA-Key Derivation with Lower- Layer Parameter Binding", draft-ohba-eap-aaakey-binding-01 (work in progress), July 2005. [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 July 30, 2006 [Page 17] Internet-Draft EAP Keying Handovers: PS January 2006 Authors' Addresses Madjid Nakhjiri Motorola Labs Email: Madjid.nakhjiri@motorola.com Mohan Parthasarathy Nokia 313 Fairchild Drive Moutain 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 Nakhjiri, et al. Expires July 30, 2006 [Page 18] Internet-Draft EAP Keying Handovers: PS January 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 July 30, 2006 [Page 19]