Network Working Group Internet Draft Madjid Nakhjiri (editor) draft-nakhjiri-aaa-hokey-ps-00.txt Motorola Labs Category: Internet draft M. Parthasarathy Expires: June 2006 Nokia J. Bournelle GET/INT December 2005 AAA based Keying for Wireless Handovers: Problem Statement 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 in June 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Extensible Authentication Protocol (EAP) provides a framework for performing authentication and key management using the AAA infrastructure. The framework specified in these documents deals with a model which includes a peer, a pass-through authenticator and a Nakhjiri et. al. AAA based Keying for Wireless HO: PS [Page 1] backend authentication server. However, some of the emerging mobile networks are deploying EAP framework in scenarios that go beyond what is defined in the current specifications, e.g. cases where a peer hands over between two wireless network points of attachment. This document intends to describe the problems posed with such usage. Table of Contents 1. Introduction...................................................2 2. Terminology and Assumptions....................................3 3. Problem description............................................7 3.1 Intended scope and non-scope..............................11 3.1.1 Architecture realization alternatives 11 3.1.2 Transport issues 11 3.1.3 Keying 12 3.1.4 Key maintenance issues 12 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..................................13 4.5 Authenticate all the parties..............................14 4.6 Channel binding...........................................14 4.7 EAP method independence...................................14 5. Security considerations.......................................14 6. References....................................................15 7. Acknowledgements..............................................15 8. Authors Address...............................................15 1. Introduction The Extensible Authentication Protocol (EAP) [EAP3748] and the keying framework [EAP-KEY] documents define the authentication framework and key management. The entities involved in the existing specifications are the EAP peer, pass-through authenticator and the EAP server that is typically collocated with the AAA server. EAP key management framework provides mechanisms for distribution of the keying material (so-called master keys), generated at the EAP peer and the EAP/AAA server, to the pass-through authenticator, following a successful EAP method authentication between the peer and the EAP server. Such master keys are intended to aid the secure association protocol phase during which the EAP peer and the authenticator prove the possession of the master keys and derive new transient session keys (TSK) for securing their communication. Nakhjiri et. al. AAA based Keying for Wireless HO: PS [Page 2] Use of this model for mobile networks poses performance issues. If the authenticator is collocated with the node where the link from the peer is terminated, then when the handoff occurs from one link to another, it leads to relocating the authenticator also. This results in the potential need for a new authentication run and a subsequently new secure association protocol exchange. The end result will be a sub-optimal handover performance. In an effort to improve mobility performance, the latest access technologies are starting to introduce additional entities to the traditional 3-party authentication model As shown in Figure 1, the peer does not connect to the authenticator directly; instead it connects to a base station (BS) or Access Point (AP) which in turn is connected to the authenticator. We call this new entity Access Node (AN) in this document. The Access Node helps handling the mobility without changing the authenticator for every handover. But there are several issues with the introduction of the new entity in the EAP signaling. Firstly, EAP framework only describes the delivery of master keys to authenticators, not to the ANs that are not collocated with the authenticator. Secondly, as a result of its mobility, the peer may need to handover between the ANs. This handover should not result in performing the EAP authentication again as this would defeat the purpose of the new architecture. The goal of this document is to examine this problem in detail and identify the new requirements and security issues in this new architecture. This document is organized as follows. First it discusses the problem that needs to be solved in detail. Next it discusses the security goals that need to be met while a solution is sought for the problem. 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 RFC 2119 [1]. Most of the terminology followed in this document follows the EAP keying document [EAP-KEY]. Some additional terms and clarifications are included below. EAP server EAP server is the entity that engages in EAP method exchange and terminates the EAP authentication method with peer as defined in [EAP3748]. EAP server is capable of generating and exporting relevant EAP keys as defined in [EAP-KEY]. The handover keying architecture assumes the EAP server is a backend entity that Nakhjiri et. al. AAA based Keying for Wireless HO: PS [Page 3] provides an authentication service to a pass-through authenticator as defined in [EAP3748]. AAA server The entity that is in charge of overall access control which provides authentication, authorization and accounting services to network edge devices. This document considers the AAA server (not the EAP server) to be the main point of trust and authorization in any administrative domain, but the AAA server relies on EAP server for EAP-method authentications. Also, this document does not distinguish between the AAA server function and the storage databases that may hold information related to keying and AAA functions and refer to the server implementing AAA protocols and functions as well as storage as “AAA server”. The implication is that, any compromise of the database at the AAA server is understood to possibly have security implications on the administrative domain. 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. Party A party is a processing entity which logically can be identified as a single role in the architecture. In order to provide appropriate security for the key management design, in this document, each party is considered a physical entity separate from other parties, although in practice one or more parties may be inserted in the same physical box. To preserve the scope of our work, we apply an exception to this rule and consider the EAP server and the AAA server to be implemented as two layers of the stack within the same party and therefore consider the security association between EAP server and AAA server outside the scope of this work. Mobile Node (MN) (peer) The entity that receives network access through a direct link to an Access Node. This document considers EAP as default authentication and key management framework. In an architecture using EAP for authentication and key management, the mobile node includes EAP peer functionality as described by [EAP3748] and keying frameworks [EAP-KEY], with the exception that mobile node may not have a direct link to the EAP pass-through authenticator. For that reason in this document we use the terms MN and EAP peer interchangeably. MN is the entity whose records are kept at the AAA server and is authorized for various network services. Access Node Nakhjiri et. al. AAA based Keying for Wireless HO: PS [Page 4] 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 AN is a logically separate entity from the EAP pass- through authenticator. Therefore, the AN is only responsible for relaying the EAP signaling between the peer and the authenticator without understanding the EAP signaling. The relay may involve de- /encapsulating the EAP signaling over the shim layers that run over access-technology-specific link protocols (e.g. EAPOL for LANs, PKMv2 for 802.16e). Since the separation of Access node and the EAP pass-through authenticator is not recognized in EAP documentation ([EAP3748] and [EAP-KEY], the Access Node may not be considered as the logical termination point for an EAP lower layer currently recognized by EAP layer documentation even though it does terminate the link from the peer to the access network (runs the link secure association protocol) and possibly encapsulate and decapsulates EAP signaling from an access link protocol to a protocol internal to the network in a way that is transparent to the EAP layer. EAP pass-through Authenticator According to [EAP3748], authenticator is the end of the link initiating EAP authentication. In this document, to add specificity, we define the term authenticator to refer to the entity acting as a "pass-through" during EAP authentication between a peer and a backend EAP server. The pass-through authenticator does not understand the content of the data field within EAP Request and Response messages, but can match requests with responses and can understand EAP success and failure messages. The authenticator may not necessarily be the entity that terminates the link between the peer and the access network. AAA client 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). The logical AAA client is not responsible for understanding EAP messaging, however, it is the physical entity that receives any transported master keys produced as part EAP keying process, if the transport is performed through AAA protocols. It is assumed that the EAP pass-through authenticator and the AAA client are collocated. According to current EAP keying documentation AAA layer entities are to delete the transported keys and this may mean a logical AAA client will not have an authority to act as a key holder. Nakhjiri et. al. AAA based Keying for Wireless HO: PS [Page 5] Link Secure Association Protocol (LSAP) To maintain consistency with existing documents for EAP keying we assume that the Link Secure Association Protocol is the process used for generating and managing the security associations used on the link between the peer and the network edge device (AN). Hence, to avoid confusion we assume the term Secure Association Protocol (SAP) defined in [EAP-KEY] to mean as a protocol that is run between the peer and the authenticator. The LSAP protocol draws from the result of EAP and/or AAA exchanges. Successful completion of LSAP will result in generation of a set of link session keys. Note that by term link, we do not necessarily mean a layer 2 protocol, but a protocol that runs between the peer and the first point of attachment, which may be a layer 3 entity. Link Session Keys (LSK) The keys derived upon completion of LSAP and used to secure the access link between the peer and the AN. The definition of LSK in this document is consistent with that of transient session keys (TSK) in [EAP-KEY]. LSAP Master key (LSAP-MK) A master key used by the peer and the AN during LSAP run to arrive at LSKs between the peer and the AN. The relationship between LSAP- MK and XMSK is to be explored. X-Master Session Key (XMSK) A key that will be used as the root key to solve the keying problem described in this document. For the purpose of this document we assume that the XMSK will be available at both the peer and the home AAA server if and only if a prior successfully completed authentication is still valid. Exact correlation of XMSK with the keys described in current EAP documents (e.g. MSK, EMSK, AMSK) and the exact location it is generated (EAP server or AAA server) is to be a manner that is compliant with the yet to be completed outcome of the EAP WG documentation. In the rest of this document, we will only refer to XMSK. Key holder This entity is the one that holds the XMSK received from AAA server and possibly performs further key derivations and distribution functions for access nodes. It is yet to be determined from the EAP keying requirement specification in EAP WG whether either a AAA server or a AAA client can cache the keys after key transport. This may mean both central (next to AAA server) and local (next to AAA client) key holders may exist in the architecture. How the key holder receives the key (from which entity) is to be determined. In Nakhjiri et. al. AAA based Keying for Wireless HO: PS [Page 6] the EAP keying architecture, it is the pass-through authenticator that acts as a key holder (receiving the key through AAA protocol). Pseudo Random Function (PRF) The function used in generation of a keying material. To stand the test of time and Moore's law, the keying framework will work will only refer to a generic PRF without further cryptographic specifications. Furthermore, a complete keying solution for the architecture described in this document will require generation of keys between several parties, which may be governed by different design requirements, sometimes described by different SDOs. This will mean there may be multiple PRFs (PRF1/PRF2/..PRFn) involved dealing with generation various keys. For instance an SDO standardizing the access link between peer and AN may be use PRF3 for the generation of keys related to that link. Another PRF (PRF2) may be used for generation keys in a different part of the architecture. AN-Authenticator protocol (ANAP) In an architecture where the AN and the EAP pass-through authenticator are physically separated, ANAP is the protocol that runs between the authenticator and the Access node and most likely dependent on the other standards development organization (SDO). Hence, the details of this ANAP and security algorithms and associations to protect ANAP messaging are outside the scope of this document. The solution for the problem statement in this draft may however place requirements or extensions for keying-related information to be carried ANAP. AAA protocol The authenticator is assumed to have AAA client protocol. Therefore, the authenticator and AAA server/ EAP server will use a standard protocol (RADIUS or Diameter) for communications. 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 Many emerging wireless technologies (e.g. 802.11) are using EAP authentication and keying framework as a basis for key management, e.g. for delivering master keys used in establishing secure access links. However, when mobility and handover comes into picture, use of EAP poses specific problems. Networks, providing wireless connectivity to a mobile node through its access nodes, require the mobile node to establish a security association and a set of link security keys (LSKs) with the access node it is willing to connect Nakhjiri et. al. AAA based Keying for Wireless HO: PS [Page 7] to. As shown in Figure 1, When a mobile entity that is initially connected to an access node, AN1, needs to handoff to another Access Node (AN2), the MN needs to establish a new set of LSKs with the new AN through performing an LSAP exchange with the new AN. The LSAP typically involve several exchanges through which the MN and AN both authenticate and arrive at LSKs using an LSAP master key (LSAP-MK). Various security requirements for this key generation dictate that each AN is supplied with a fresh LSAP-MK that is independent of the LSAP-MKs used by either MN or any of the ANs. Supplying new LSAP-MK to an access node, if done through EAP, may require full EAP authentication with the backend EAP server, which severely impacts handover performance. To avoid such affects, the emerging mobile networks (such as 802.11r and WiMAX) are introducing two logically and possibly physically separate entity between the mobile entity and the backend server. For generality we have called these two entities the Access Node and the key holder. By separating the LSAP-MK from XMSK and holding the XMSK at the key holder while only supplying the LSAP-MK to the AN, the need for generating new XMSKs for each handover and thereby the need for new full EAP authentications during each handover is significantly reduced and thereby significant handover performance gain can be achieved in majority of AN-handover cases. As shown in Figure 1, the MN (EAP peer) is connected to AN1 which in turn is connected to the Authenticator (Athr1). When MN connects to the access network for the first time, it can use EAP [EAP3748] to authenticate to the access network. There are several security associations between the various nodes in the network. SA1 <-----------------------------------------> SA12 <-----------------------------------------> SA4 SA3 SA2 <--------> <--------------> <-------------> +-+-+-+-+-+ +-+-+-+ | MN/ |-----| AN1 |---+ |EAP Peer | +-+-+-+ | +-+-+-+ +-+-+-+-+-+ SA5 +-----|khr1 |-+ <-------------|----> +-+-+-+ | | | +-+-+-+-+-+ +-+-+-+ | | |AAA/EAP | | AN2 |---+ +-----| Server | +-+-+-+ | +-+-+-+-+-+ | +-+-+-+ +-+-+-+ | | AN3 |---------+khr2 +--+ +-+-+-+ +-+-+-+ Nakhjiri et. al. AAA based Keying for Wireless HO: PS [Page 8] Figure 1: A wireless mobile architecture deploying EAP framework for keying 1. The security association SA1 is a long term credential established between the MN and the home AAA server. During the EAP authentication, the MN acting as an EAP peer uses SA1 to perform an authentication with the EAP server (co-located with AAA server). Provisioning of this SA is outside scope of this document. 2. The security association SA12 is generated as a result of the EAP authentication between EAP peer and EAP server and maybe transferred from EAP server to the AAA server through export of XMSK. The provisioning and life time of this temporary SA is determined based on guidance provided by [EAP-KEY] and the used EAP method. 3. The security association SA2 pre-exists between the key holder and the AAA server (including a co-located EAP server) based on the AAA infrastructure before the EAP authentication starts. Without loss of generality, for simplicity we assume a single administrative domain, meaning the AAA server is the home AAA server. 4. The security association SA3 pre-exists between the Access Node and the key holder. This SA is used to protect signaling and transferred key material between key holder and the AN. Provisioning of this SA is through specification of ANAP and is outside scope of this document. 5. The security association SA4 is created between the mobile node and the Access Node. SA4 establishment involves establishment of LSKs. 6. The security association SA5 is created between the EAP peer and the key holder derived from the EAP authentication and key framework procedures. 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. 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. Nakhjiri et. al. AAA based Keying for Wireless HO: PS [Page 9] 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. There are also multiple proposal for placing the pass-through authenticator and AAA client functionalities on the table: 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. Authenticator encapsulates EAP inside AAA protocol and receives XMSK from the AAA server. +-+-+-+-+ +-+-+-+-+-+ +-+-+-+ +-+-+-+-+-+ | | | | |khlr | | | | EAP |--------| Access |-----|Athr |------| EAP/AAA | | Peer | | Node | |AAAC | | Server | +-+-+-+-+ +-+-+-+-+-+ +-+-+-+ +-+-+-+-+-+ 2) Authenticator and AAA client are located in AN, i.e. the AN performs EAP encapsulations, however it does not receive the XMSK from the AAA server. The key holder function will receive the XMSK from the AAA server and hence must act as a separate AAAC w.r.t. AAA server. The key holder is on the path of the AAA signaling (AAA proxy). +-+-+-+-+ +-+-+-+-+-+ +-+-+-+ +-+-+-+-+-+ | | | Athr | |khr | | | | EAP |--------| AAAC |-----| |------| EAP/AAA | | Peer | | AN | |AAAP | | Server | +-+-+-+-+ +-+-+-+-+-+ +-+-+-+ +-+-+-+-+-+ 3) Authenticator and AAA 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. +-+-+-+-+-+ | Key Hldr | | AAAC |-----\ +-+-+-+-+-+ \ | \ | \ V \ +-+-+-+-+ +-+-+-+-+-+ \ +-+-+-+-+-+ | | | Athr | \-| | | EAP |--------| AAAC |------------| EAP/AAA | | Peer | | AN | | Server | +-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ Nakhjiri et. al. AAA based Keying for Wireless HO: PS [Page 10] 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. 3.1 Intended scope and non-scope Note that this document is merely serving as a problem statement and does not discuss the specifics of what herein is considered as in scope. The actual specifications will be part of the later solution documents. Rest of the document discusses the security goals that need to be considered while solving the keying issues in the new architecture. 3.1.1 Architecture realization alternatives The most important goal for this effort to provide a keying solution that best fit the architecture shown in Figure 1, possibly using one of the realization alternatives described in the initial part of this section. The goal may not be to provide a solution based on all the alternative architectures suggested but hopefully to focus on one architecture where the involved experts agree is the most deployable and the one with the highest probability of providing best handover performance, whilst meeting the initially defined security goals. For an initial discussion on the pros and cons of each of these alternatives, the reader is referred to [EAPHOPS]. 3.1.2 Transport issues The transport (including message formats) for carrying EAP messages and distributing key material between different parties, e.g. the AN and the key holder and the specification of access link messaging (between EAP peer and AN e.g. PKMv2/802.16) and backhaul (between AN and key holder, e.g. PANA) are beyond the scope of this document or the solution document as it may be specific to the standards organization developing the access/mobile network and not within control of IETF. On the other hand 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. Nakhjiri et. al. AAA based Keying for Wireless HO: PS [Page 11] 3.1.3 Keying 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. 3.1.4 Key maintenance issues 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. Example of specific issues that require consideration are parameters for channel binding, key life time and scope (who can be a key holder, holder/s ID, etc.). 4. Security goals As shown in the problem description section, the outgoing assumption here 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, we also saw that there are a number of alternatives for deployment of EAP framework to a wireless mobile network providing handover keying solutions. The section will draw from the guidance provided in [AAA-KEY] 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 of keys, including XMSK and the keys derived for the lower layers of key hierarchy (e.g. LSKs) MUST have a well-defined context. 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 mean that context and scope parameters (e.g. lifetime, key holder ID, authorization information) may have to be exchanged as part of each key derivation process over the transport mechanism between the parties sharing the key and hence the semantics (not syntax) of these Nakhjiri et. al. AAA based Keying for Wireless HO: PS [Page 12] parameters MUST be defined to provide proper channel binding specifications. The exact parameter syntax definition is however part of the design of the transport protocol that is outside scope of this work. 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. Depending on the outcome of [EAP-KEY] 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. 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, e.g. for LSAP (between peer and AN), and through ANAP (master keys used for each AN), 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. 4.4 Handover Vulnerabilities The EAP Key management document [EAP-KEY] discusses several vulnerabilities that are common to handover mechanisms. They can be classified into two categories. . Correctness issue relating to possibly differing capabilities of the AN that could result in bypassing the restrictions that would otherwise be imposed by the AAA server when a full EAP authentication is run. The logical descriptions of each of the parties in the architecture in this document assumes that all the parties with the same name (ANs, key holders, etc) have the same capabilities when dealing with the AAA authorization matters. Nakhjiri et. al. AAA based Keying for Wireless HO: PS [Page 13] . Authorization issue relating to the granularity or lack of information available at the authenticator to be able to make decisions on whether a user should be able to access the service across handoffs. 4.5 Authenticate all the parties Each party in the keying framework MUST be authenticated to the other parties 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 Using the traditional 3-party authentication with a pass-through entity, channel binding methods 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 [CB- METH] [CB-AAA] 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 [EAP-KEY]. 5. Security considerations This document discusses the security issues of EAP key management in the emerging mobile networks. It does not discuss any new protocol that would introduce additional security concerns. 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 the role of a central AAA server and of the local entities in the authorization and generation of keys are. For that reason, until the "role" of which each entity is to Nakhjiri et. al. AAA based Keying for Wireless HO: PS [Page 14] play in a successfully implemented mobile environment, and specifically its access to particular keys according to this principle is to be defined and he risks of compromise of any entities resulted from the compromise of this entity is 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. References [1] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997 [EAP-KEY] B. Aboba et. al., Extensible Authentication Protocol (EAP) Key Management Framework, draft-ietf-eap-keying-08.txt, work in progress, October 2005 [EAP3748] B. Aboba et. al., Extensible Authentication Protocol, RFC 3748, IETF, June 2004 [RFC2865] C. Rigney et. al., Remote Authentication Dial In User Service (RADIUS), RFC 2865, June 2000 [RFC3588] P. Calhoun et. al., Diameter Base Protocol, RFC 3588, September 2003 [CB-METH] J. Arkko et. al., Authenticated Service Information for the Extensible Authentication protocol, draft-arkko-eap-service-identity- auth-04.txt, work in progress, October 2005 [CB-AAA] Y. Ohba et. al., AAA-key derivation with lower layer parameter binding, draft-ohba-eap-aaakey-binding-01.txt, work in progress, June 2005 [RFC4017] D. Stanley et. al., Extensible Authentication Protocol (EAP) Method requirements for Wireless LANs, RFC 4017, March 2005 [AAA-KEY] R. Housely, B. Aboba, AAA Key Management, draft-housley- aaa-key-mgmt-00.txt, IETF, June 2005. [EAPHOPS], M. Nakhjiri, EAP Keying and Handover Support, draft- nakhjiri-eap-ho-00.txt, IETF, June 2005. 7. Acknowledgements 8. Authors Address Madjid Nakhjiri Motorola Labs Nakhjiri et. al. AAA based Keying for Wireless HO: PS [Page 15] Email: Madjid.nakhjiri@motorola.com Mohan Parthasarathy NOKIA 313 Fairchild Drive Mountain View CA-94043 Email: mohan.parthasarathy@nokia.com 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 (2005). Nakhjiri et. al. AAA based Keying for Wireless HO: PS [Page 16] 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. AAA based Keying for Wireless HO: PS [Page 17]