Network Working Group M. Nakhjiri Internet-Draft Motorola Labs Expires: August 14, 2006 February 10, 2006 A Keying hierarchy for managing Wireless Handover security draft-nakhjiri-hokey-hierarchy-00 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 August 14, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Problem of AAA-based key management for faciliating secure handovers in a wireless mobile environment has been described in [I-D.nakhjiri-aaa-hokey-ps]. The intention with this document is to provide a starting point for developing a solution for that problem by introducing a key hierarchy using EAP generated keys. Nakhjiri Expires August 14, 2006 [Page 1] Internet-Draft Handover Keying Hierarchy Description February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Assumptions . . . . . . . . . . . . . . . . . 5 3. Key Hierarchy and Generation . . . . . . . . . . . . . . . . . 6 4. Security report Card . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative references . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Nakhjiri Expires August 14, 2006 [Page 2] Internet-Draft Handover Keying Hierarchy Description February 2006 1. Introduction Wireless networks deploy specific access nodes (AN) providing link layer service to the peers. While the primary function of the AN is provide network connectivity and operator policy enforcement on the services rendered, it can do so only after the required authentication and security procedures are successfully performed. This typically involves exchange of authentication signaling between the peer and a backend AAA server through the AN and provisioning of keys for securing the link between the peer and the AN. The Extensible Authentication Protocol (EAP) framework, including [RFC3748] and the keying framework [I-D.ietf-eap-keying] have been used to perform authentication and to generate the EAP master keys (MSK and EMSK) at both backend server and the peer. The EAP framework also allows transport of MSK to a pass-through authenticator and recommends this transport be done through a AAA protocol. When the AN implements the authenticator and AAA client function, it can then after receiving the MSK engage in a key management schema with the peer to establish a secure link with the peer. The process described above may be sufficient in an environment where the authentication, AAA client and AN are co-located and the peer does not have move between different ANs. However, it will cause difficulties when those conditions do not apply. If the MSK is transported to an AN, when the peer moves to another AN, using the same MSK at the new AN will violate the principle of least privilage [I-D.housley-aaa-key-mgmt] and can result in a so-called domino effect. Creating a new MSK at the new AN, on the other hand could require performance of another round of lengthy EAP method authentication exchange, which is detrimental to handover performance, especially when real time services are in active session. As described in [I-D.nakhjiri-aaa-hokey-ps] an architecture deploying a key holder, KH, (shown in Figure 1) that can act as a AAA client and receive the master keys transmitted by the AAA server seems to gain more acceptance in the industry due to its strength in addressing this issue more effectively. EAP working group is currently working on specification of methodology [I-D.ietf-eap-keying] that allows the use of EAP method generated master keys (MSK and EMSK) in assisting AAA-based key management procedures. The notion of application master session key (AMSK) has been recognized as a useful concept. While some basic tenets about AMSK use has been discussed in IETF EAP WG, the process of AMSK generation, caching and distribution is not yet standardized Nakhjiri Expires August 14, 2006 [Page 3] Internet-Draft Handover Keying Hierarchy Description February 2006 in IETF. In the handover problem description document [I-D.nakhjiri-aaa-hokey-ps] we tried to reduce the dependency of a handover keying solution to the AMSK for that reason by introducing the notion of XMSK as the master key that is pushed/pulled into each key holder. Distinguishing between AMSK and XMSK serves two notions: 1) from one AMSK generated for handover, multiple XMSKs (one for each key holder, KH) can be generated. This way the architecture is capable of supporting Inter-KH handovers if need be. At the same time it can comply with the concern that only the AMSK and not the EMSK can be available at the AAA server, while the EMSK needs to stay (or possibly deleted) at the EAP server. 2) The XMSK, created at the AAA server for key holder and transported to the each KH, can be deleted from AAA server cache, if required. The AMSK can on the other stay at the AAA server for future use (such as XMSK generation for other, not currently identified KHs). Nakhjiri Expires August 14, 2006 [Page 4] Internet-Draft Handover Keying Hierarchy Description February 2006 (HO-AMSK,HO-AAA-REAUTH-KEY) <--------------------------------------------> (XMSK,HO-KH-REAUTH-KEY) <----------------------------> LSK,LSAP-MK <------------> +-+-+-+-+-+LSK +-+-+-+ LSAP-MK1 | MN/ |-----| AN11|---+ |EAP Peer | +-+-+-+ | +-+-+-+ +-+-+-+-+-+ +-----|KH 1 |-+XMSK1 +-----+ | +-----+ | | AN12|---|LSAP-MK2 ^ +-----+ | | . | | . | | +-+-+-+-+-+ +-+-+-+ | | |AAA/EAP | | AN1n|---+ +--+--| Server | +-+-+-+ | +---------+ | +-+-+-+ +-----+ | | AN21|---------|kH 2 |----+XMSK2 +-+-+-+ +-+-+-+ | . . | . . | +-+-+-+ +-----+ | | ANm1|---------|kH m |----+ XMSK3 +-+-+-+ +-+-+-+ . | . | +-+-+-+ | | ANmk|-----------+ +-+-+-+ Figure 1: A keying architecture deploying key holders This document intends to provide an example of how the various keys in handover keying architecture shown in figure Figure 1 can be generated. The document leaves the transport aspects of the key distribution for future discussion. Some of our key binding ideas may be self-evident through inclusion of various identifiers in the expressions provided for generation of various keys, however, these expression will need to examined more closely through further discussions. 2. Terminology and Assumptions Nakhjiri Expires August 14, 2006 [Page 5] Internet-Draft Handover Keying Hierarchy Description February 2006 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]. For a complete description of the terminology, the reader is referred to [I-D.nakhjiri-aaa-hokey-ps] X-Master Session Key (XMSK): A key that will be used as the root key to solve the handover keying problem. Link Secure Association Protocol (LSAP): 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). 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. 3. Key Hierarchy and Generation Upon successful completion of the EAP authentiation method, the EAP server generates the EAP MSK and EMSK as defined by the method that was executed. From this EMSK, an AMSK designated for handover keying application can be generated. We call this AMSK, the HO-AMSK HO-AMSK=AMSK-PRF (EMSK, "AMSK for Handover" | EAP session ID | Key_ID | AAA server ID) EAP session ID is supposed to be unique between peer and the server, identified by the peer-ID and EAP server ID, respectively. The current assumption is that the EMSK cannot be exported from the EAP layer down to the AAA layer, but the HO-AMSK can. Hence from this point, we assume that the AAA server can maintain a cache of HO- AMSK if it needs to. The HO-AMSK is then used to create further keys: HO-AAA-REAUTH-KEY= HO-PRF (HO-AMSK, "Key for re-authentication to AAA server" | EAP session ID | Key_ID ) Nakhjiri Expires August 14, 2006 [Page 6] Internet-Draft Handover Keying Hierarchy Description February 2006 KH-MK= HO-PRF (AMSK, "master Key for all key holders" | EAP session ID | Key_ID ) HO-AAA-REAUTH-KEY is a key that can be used by the peer, if it needs to indicate to the AAA server that it has moved to an area served by a new key holder. The key allows for a quick re-authorization process in the course of inter-KH handover, without requiring a new EAP. Proof of possession of this key, authorizes the peer to receive key generation services through a new key holder. Note that the peer may not necessarily need to know that it has moved to a new key holder; the AAA server can request proof of possession of this key through a request. HO-AAA-REAUTH-KEY does not leave the AAA server and is not exposed to any other entity in the network. The peer is able to generate this key through knowledge of AMSK. KH-MK is a key that does not leave the AAA server and is used by the AAA server as a root key when generating XMSK for a key holder number i: XMSK for KH i= XMSKi= KH-i-MK= HO-PRF (KH-MK, "XMSK generation" | EAP session ID | Key ID | Key holder i ID) Note that the peer may not have knowledge of the key holder identifier, hence some sort of domain identifier corresponding to the key holder needs to be used. Such domain identifiers can be broadcast through the advertisements provided by the AN to the peer. The AAA server now can send the XMSKi to the key holder i through a secure transport (possibly a secured AAA message). The AAA server can now delete the XMSKi, if required for compliance with principle of least privilage. The key holder i (KHi) receives the XMSKi. From this point on, we refer to this key as XMSK or XMSK-current to comply with the description provided in the handover keying problem description [I-D.nakhjiri-aaa-hokey-ps] The XMSK is meant to be cached at the key holder and not distributed to any other entities. The key holder uses the XMSK as for all the key generation activities within its domain (i.e. for all the ANs it serves). In the following we assume key holder i is the key holder 1 shown Figure 1) and the first AN the peer is connecting to is AN1. So the KH1 creates the LSAP-MK1 for the (peer-AN1) interaction as follows: LSAP-MK1 = LSAPMK-PRF (XMSK-i, "LSAP master key generation" | EAP Nakhjiri Expires August 14, 2006 [Page 7] Internet-Draft Handover Keying Hierarchy Description February 2006 Session ID | Key-ID | AN1-Device-Id) The LSAP-MK1 is transported to the AN1 through a secure transport at some point in conjunction to the handover To maintain a level of integrity in the design, we provision another authorization key (we call this HO-KH-REAUTH-KEY) so that the peer can use this key to gain authorization from the key holder to handover to another key. The need for proof of possession of this key as part of handover is to be tested later on, but its provisioning eliminates the need for interaction with the backend AAA server (e.g. fast re-authentication procedures with the AAA server). The KO-KH-REAUTH-KEY can be calculated as follows: HO-KH-REAUTH-KEY= HO-PRF (XMSK, "Key for re-authentication to key holder" | EAP session ID | Key_ID ) Once the LSAP-MK1 is obtained by the AN1, the peer and AN1 can engage in an LSAP exchange to arrive at the LSKs. The exact process of LSAP is dictated by the SDO governing the specification of the communications link between the peer and ANs. So the following is simply an example: LSK-encryption=LSK-PRF (LSAP-MK1, "Link encryption key", EAP session ID | Key ID | peer-link-ID | AN-link-ID | peer-nonce | AN1-nonce), LSK-Authentication=LSK-PRF (LSAP-MK1, "Link authentication key", EAP session ID | Key ID | peer-link-ID | AN1-link-ID | peer-nonce | AN- nonce), Where the nonces are exchanged as part of an exchange between the peer and AN1. The link IDs are the identifiers through which the peer and the AN recognize each other over the wireless link. As the mobile node hands off from AN1 to another AN, through some method that we do not discuss at this point, the key holder is notified about the move and about the device ID of AN2. The Key holder may require proof of possession of the HO-KH-REAUTH-KEY from the peer. The key holder calculates the LSAP-MK2 for the AN2: LSAP-MK2 = LSAPMK-PRF (XMSK-i, "LSAP master key generation" | EAP Session ID | Key-ID | AN2-Device-Id) and transports the LSAP-MK2 to AN2, which engages in LSAP with the peer as described earlier. The details of the signaling are to be explored later. For instance the timing and triggers for various authorization messaging or keying Nakhjiri Expires August 14, 2006 [Page 8] Internet-Draft Handover Keying Hierarchy Description February 2006 material transport needs to be fine tuned based on the physical conditions of the (peer-AN1), (peer-AN2) and (AN1, AN2) links. For instance, authorization request for handover to AN2 and even LSAP-MK2 transport may happen prior to or following a handover to AN2. The former is for instance possible through the KH encrypting and signing the keying material for the AN2 through a (KH-AN2) shared key and sending it to the AN1, which then can through a simple context transfer move to the AN2, without much security requirements. transfer. Another example is if the AN or the peer could request LSAP-MKs for a list of candidate ANs as part of the request to the key holder. The key holder could then send signed (peer ID, AN-ID, encrypted(LSAP-MK)) triplets for each of the ANs. Finally, As discussed in the problem statement draft, a key holder seems to be a necessary part of the architecture. However, the realization of this architecture can take various shapes. the recommendation here is to use the following architecture to use EAP keying framework. +-+-+-+-+-+ | Key Hldr| | AAAC |-----+ +-+-+-+-+-+ \ | \ | \ V \ +-+-+-+-+ +-+-+-+-+-+ \ +-+-+-+-+-+ | | | Athr | +-| | | EAP |--------| AAAC |------------| EAP/AAA | | Peer | | AN | | Server | +-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ Figure 2: off-EAP-path key holder function 4. Security report Card This section of the document provides a test of the provided key hierarchy agains the security goals stated in the kandover keying problem statement draft [I-D.nakhjiri-aaa-hokey-ps] Nakhjiri Expires August 14, 2006 [Page 9] Internet-Draft Handover Keying Hierarchy Description February 2006 Key Context and scope, prevention of domino effect: The context and scope for each key is defined. The entire purpose of the hierarchy is to abide with the principle of least privilage to prevent the domino effect. Master keys are deleted after transport. Keys generated at each level of the hierarchy are unique to entities. for instance, XMSK for each key holder is only specific to that key holder, the same as LSAP-MK for each AN. Key Naming: All keying material starting from XMSK and the derivatives are uniquely named, using the identity of the parties sharing the key. Key Freshness: Use of EAP session ID should provide adequate level of freshness, in cases where the identity of an entity within the architecture is not known to the peer and in case of LSAP-MK generation. Generation of link level keys (LSKs) is outside control of IETF. The examples provided in this document, use peer and AN nonces for that purpose. Handover Vulnerabilities: The key hierarchy introduced here, provides a hierarchy in authorization as well, e.g. HO-AAA- REAUTH-KEY versus HO-KH-REAUTH-KEY. This way, the entity that generates the keys is making the authorization decisions. Authentication of all the parties: The hierarchy allows for peer- AAA server, peer-key holder and peer-AN authentication through introduction of specific keys. AAA server-key holder, key holder-AN authentication mechanisms are outside control of this document. Channel binding: The keys introduced in this document are named in a way that allows for proper binding. Exact signaling procedures for channel binding are to be investigated. EAP method independence: The key hierarchy in this document stems from the EAP method generated keys (MSK and EMSK). As long as the method is capable of creating EMSKs, this hierarchy is method independent. 5. Security Considerations This document discusses branching a key hierarchy from root keys provided by the EAP key management in order for providing keying solutions for wireless mobile networks. Key caching and non- transport requirements (i.e. storing a key at the origin without transporting it) are discussed throughout the document. However, the solution relies on the secure (encrypted and authenticated) transport of keys. Such secure transport of keying material between pairs such as (AAA server, key holder) and (key holder, AN) may be subject to security issues that are outside control of this docuemnt. Future revisions of this document is to provide recommendations for the transport mechanisms. Nakhjiri Expires August 14, 2006 [Page 10] Internet-Draft Handover Keying Hierarchy Description February 2006 6. IANA consideration This document does not require any actions by IANA. 7. Acknowledgements The authors would like to thank Jari Arrko for useful suggestions on use of AMSK for handover key hierarchy and Mohan Parthasarathy for providing feedback. 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. [I-D.nakhjiri-aaa-hokey-ps] Nakhjiri, M., "AAA based Keying for Wireless Handovers: Problem Statement", draft-nakhjiri-aaa-hokey-ps-01 (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. [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. Nakhjiri Expires August 14, 2006 [Page 11] Internet-Draft Handover Keying Hierarchy Description February 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. [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005. Nakhjiri Expires August 14, 2006 [Page 12] Internet-Draft Handover Keying Hierarchy Description February 2006 Author's Address Madjid Nakhjiri Motorola Labs Email: Madjid.nakhjiri@motorola.com Nakhjiri Expires August 14, 2006 [Page 13] Internet-Draft Handover Keying Hierarchy Description February 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 Expires August 14, 2006 [Page 14]