Network Working Group V. Narayanan Internet-Draft Qualcomm, Inc. Expires: December 15, 2007 June 13, 2007 EAP-Based Keying for IP Mobility Protocols draft-vidya-eap-usrk-ip-mobility-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 December 15, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract EAP [1] is increasingly used for network access authentication in various networks. Also, key generating EAP methods are being adopted in various systems for the purposes of cryptographic protection between an EAP peer and an enforcement point in the network. Key generating EAP methods produce an MSK and an EMSK in accordance with [1]. The MSK is meant for use by the EAP lower layer at the peer and the authenticator and is used differently by various lower layers. The EMSK hierarchy is defined in [2]. The EMSK hierarchy is meant to be extensible to derive keys for various usages. This document Narayanan Expires December 15, 2007 [Page 1] Internet-Draft draft-vidya-eap-usrk-ip-mobility June 2007 defines the key hierarchy and key derivations for using the EMSK hierarchy for keying in IP mobility protocols. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. EAP Keying Overview . . . . . . . . . . . . . . . . . . . 3 1.2. Motivation for EAP-Based Keying in IP Mobility Protocols . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview of EAP-Based Keying for IP Mobility Protocols . . . . 5 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 4. Key Hierarchy and Derivation Framework . . . . . . . . . . . . 7 4.1. Mobility Root Key (MRK) Derivation and Properties . . . . 7 4.1.1. MRK Derivation . . . . . . . . . . . . . . . . . . . . 7 4.1.2. MRK Properties . . . . . . . . . . . . . . . . . . . . 8 4.2. Mobility Integrity Key (MIK) Derivation and Properties . . 9 4.2.1. MIK Derivation . . . . . . . . . . . . . . . . . . . . 9 4.2.2. MIK Properties . . . . . . . . . . . . . . . . . . . . 9 4.3. Mobility Usage Session Key (MUSK) Derivation and Properties . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3.1. MUSK Derviation . . . . . . . . . . . . . . . . . . . 10 4.3.2. MUSK Properties . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5.1. Key Distribution . . . . . . . . . . . . . . . . . . . . . 12 5.2. Revocation of Keys . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Narayanan Expires December 15, 2007 [Page 2] Internet-Draft draft-vidya-eap-usrk-ip-mobility June 2007 1. Introduction 1.1. EAP Keying Overview EAP-based authentication is being adopted in several networks for access control purposes. Key generating EAP methods are often used to allow some key material to be available for cryptographic access enforcement in various lower layers. As defined in [1], key generating EAP methods produce a Master Session Key (MSK) and an Extended Master Session Key (EMSK) and the MSK is provided to the lower layer. Several lower layers use the MSK in various different ways. The EMSK hierarchy for EAP is defined in [2]. The EMSK hierarchy is meant to be extensible to derive keys for various usages. In accordance with the defined EMSK hierarchy, Usage Specific Root Keys (USRK) and Domain Specific Root Keys (DSRK) may be derived from the EMSK. USRKs are meant to be defined for specific usages and the scope of the key will be determined by the EAP Server (or the home AAA server) of the peer. On the other hand, the DSRKs are limited in scope to a specific domain and are meant to be distributed to local AAA servers in different domains. The DSRK may then be used to derive various Domain Specific USRKs (DS-USRK), which are defined for specific usages within the domain for which the DSRK is valid. 1.2. Motivation for EAP-Based Keying in IP Mobility Protocols Several IP mobility protocols require cryptographic key material for authentication of signaling messages. When one or more of these protocols is used in a system by end devices that perform network access authentication using EAP, it is plausible to derive keys for use in such mobility protocols using the EMSK key hierarchy. This prevents the need for having any pre-configured key material being available for each of these protocols used. The need for pre-configured keying material leads to some malpractices in practical usage. For instance, greater the number of pre-configured keys required, the more re-use of a single key across various usages tend to occur. This potentially leads to lack of appropriate cryptographic independence across various keys derived from a given PSK. Also, PSKs tend to be configured and kept around for long periods of time, due to management issues with frequent refreshes. Consequently, it proves to be a disadvantage in several systems to have to require a PSK to be available between an end node and network entities for every application that may be used by the end node. Traditionally, most of the IP mobility protocols have used symmetric Narayanan Expires December 15, 2007 [Page 3] Internet-Draft draft-vidya-eap-usrk-ip-mobility June 2007 keys for message authentication between the end nodes and the mobility agent (the entity in the network terminating the mobility signaling and enabling IP mobility management for the end node). These symmetric keys may either be pre-configured at the end node and the mobility agent or may be dynamically derived from a different pre-configured key between the end node and a AAA server. For ease of credential management, a AAA-based credential is often used in various systems. For example, Mobile IPv4 [3] allows derivation of an MN-HA key based on an available shared MN-AAA key between the MN and the AAA server. Mobile IPv6 [4] recommends the use of IPsec for securing the messaging. In that case, IKEv2 with EAP for client authentication is often used as a means for keying IPsec, since EAP allows re-use of AAA-based credentials. It is also plausible that manually keyed IPsec is used between the MN and the HA, in which case, there needs to be a PSK between the MN and HA. Similarly, HMIP [5] also recommends the use of IPsec keyed using IKEv2 with EAP for client authentication. Further, FMIPv6 [6] also requires protection of signaling messages using symmetric keys between a mobile node and an access router. These symmetric keys may be derived using AAA- based mechanisms, in which case, the MN and AAA server are expected to share a PSK. Since the AAA server responsible for distributing key material for mobility agents is the same as the EAP or ERP server that already shares key material with the MN, a mechanism of using the EAP-derived keys to provide key material for other uses provides a meaningful means of avoiding the need for additional PSKs between the MN and AAA server. 1.3. Scope This document describes EAP-based key derivations for the following protocols - Mobile IPv4, Mobile IPv6, Hierarchical Mobile IPv6, Fast Mobile IPv4, Fast Mobile IPv6. The USRK labels required for these protocols as well as derivation of keys needed between the MN and the corresponding mobility agents are described. Further, the properties of the various keys and usage guidelines are also specified. It is, however, left to other individual documents to describe the exact signaling mechanisms that will trigger this keying process and enable key delivery to mobility agents. The scope of this document is limited to the protocols listed above. Also, the scope is limited to the case where the EMSK or DSRK holder is deriving the appropriate USRKs for the end node and distributing any keys derived from the USRKs to appropriate mobility agents. Narayanan Expires December 15, 2007 [Page 4] Internet-Draft draft-vidya-eap-usrk-ip-mobility June 2007 2. Terminology 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 [7]. This document uses terminology defined in [4], [5], [6], [1] and [2]. In addition, this document uses the following terms: Mobility Agent A mobility agent is an entity maintaining state about the location of the mobile nodes. Examples of mobility agents include the Mobile IP Home Agent (HA), the HMIP MAP, the FMIP PAR, etc. 3. Overview of EAP-Based Keying for IP Mobility Protocols As described in Section 1.2, there is good reason for bootstrapping the keys needed for IP mobility protocols using EAP generated key material. The basic assumption here is that EAP is used for access authentication between the mobile node and a AAA server that is also responsible for providing or managing keys for the IP mobility services provided in the network. Alternately, EAP Re-authentication Protocol (ERP) [8] may be used between the MN and the ERP Server that is responsible for providing key material for IP mobility services. For the purpose of this document , the terms "Mobile Node (MN)", "Peer" and "End Node" are interchangeably used. 3.1. Requirements The following requirements need to be met in order to use the mechanism described here for EAP-based keying of IP mobility protocols. o The EMSK or DSRK holder is also the entity responsible for deriving any keys required for use between the mobile node and a mobility agent. o There must be a secure channel for key transport between the mobility agent requesting a Mobility Usage Session Key (MUSK) and the AAA server that is deriving and distributing the key. Narayanan Expires December 15, 2007 [Page 5] Internet-Draft draft-vidya-eap-usrk-ip-mobility June 2007 ----------------------------------------- | Home System | | | | ---------------- ------------- | | | Mobility Agent | | AAA Server | | | ---------------- ------------- | | | ----------------------------------------- | | | | -------------------- ( ) ( IP Network ) ( ) -------------------- | | | | ----------------------------------------- | Local System | | | | ---------------- ------------- | | | Mobility Agent | | ERP Server | | | ---------------- ------------- | | | ----------------------------------------- | | ------------- | Mobile Node | ------------- Figure 1: EAP-Based IP Mobility Keying Architecture Figure 1 shows the various components that enable EAP-based IP mobility keying. It is assumed that the MN uses EAP for authentication upon attachment to the network at any point prior to starting any IP mobility sessions with one or more mobility agents. It is further assumed that a key generating EAP method is used in the EAP exchange, resulting in an EMSK being available at the MN as well as at the home AAA server. A Domain Specific Root Key (DSRK) may also be available at a local AAA server in accordance with [2]. When a valid EMSK or DSRK is available, usage specific root keys may be derived from those for different uses, in accordance with [2]. This document proposes the derivation of USRKs that are needed for host-based IP mobility protocols. For each protocol, a separate Narayanan Expires December 15, 2007 [Page 6] Internet-Draft draft-vidya-eap-usrk-ip-mobility June 2007 label for root key generation is registered in this document. Further, the framework for derivation of integrity and mobility session keys is also provided. 4. Key Hierarchy and Derivation Framework EMSK/DSRK | | Mobility Root Key (MRK) | | +----------------------------+ | | Mobility Integrity Key (MIK) Mobility Usage Session Key (MUSK) Figure 2: EAP Based IP Mobility Key Hierarchy Figure 2 shows the key hierarchy for deriving IP mobility related keys from EAP-based keys. The keys may be derived from the EMSK or the DSRK, depending on whether the keys are being derived at the home domain or the local domain. 4.1. Mobility Root Key (MRK) Derivation and Properties 4.1.1. MRK Derivation The Mobility Root Key (MRK) is calculated in accordance with the USRK derivation described in [2] as shown below: MRK = KDF(Key, Mobility Key Label, Optional Data, Length) where, Key = EMSK or DSRK Mobility Key Label = the specific label defined for the particular IP mobility protocol Optional Data = NULL Length = 2 byte unsigned integer in network byte order of the output key length in octets Narayanan Expires December 15, 2007 [Page 7] Internet-Draft draft-vidya-eap-usrk-ip-mobility June 2007 The KDF is as defined in [2] and the default PRF used is HMAC-SHA- 256. Alternatively, the PRF used MAY be the same as that used by the EAP method - using the PRF from the EAP method provides algorithm agility. The MRK-Name is calculated as follows, in accordance with [2]. MRK_Name = prf-64( EAP Session-ID, Mobility Key Label ), where prf-64 is the first 64 bits from the output The following mobility key labels are specified in this document. o MIP4: "Mobile IPv4 Root Key" o MIP6: "Mobile IPv6 Root Key" o HMIPv6: "Hierarchical Mobile IPv6 Root Key" o FMIPv6: "Fast Mobile IPv6 Root Key" Based on the above labels, the following are the specific root keys defined for the various IP mobility protocols: o MIP4-RK = KDF (Key, "Mobile IPv4 Root Key", Optional Data, Length) o MIP6-RK = KDF (Key, "Mobile IPv6 Root Key", Optional Data, Length) o HMIP6-RK = KDF (Key, "Hierarchical Mobile IPv6 Root Key", Optional Data, Length) o FMIP6-RK = KDF (Key, "Fast Mobile IPv6 Root Key", Optional Data, Length) where, Optional Data is NULL and length is a 2 byte unsigned integer in network byte order of the output key length in octets, as described above. 4.1.2. MRK Properties The MRK has the following properties. These properties apply to the MRK regardless of the parent key used to derive it. o The length of the MRK MUST be at least 64 bytes. o The MRK is to be used only as a root key for the corresponding IP mobility protocol and MUST never be used to directly protect any data. Narayanan Expires December 15, 2007 [Page 8] Internet-Draft draft-vidya-eap-usrk-ip-mobility June 2007 o The MRK is only used for derivation of MIK and MUSK as specified in this document. o The MRK must remain on the MN and the server that derived it and MUST NOT be transported to any other entity. o The MRK is cryptographically separate from any other key derived from its parent key. o The lifetime of the MRK is never greater than that of its parent key. The MRK is expired when the parent key expires and removed from use at that time. 4.2. Mobility Integrity Key (MIK) Derivation and Properties 4.2.1. MIK Derivation The Mobility Integrity Key (MIK) is the key used to protect any exchange between the MN and the server deriving the MRK, to prove possession of the MRK and authorize distribution of key material to a mobility agent. The MIK is derived from the MRK using the prf+ operation defined in RFC4306 [9] as follows. MIK = prf+ (MRK, "Mobility Integrity Key") The PRF used MAY be the same as that used by the EAP method - using the PRF from the EAP method provides algorithm agility. Otherwise, the default PRF used is HMAC-SHA-256. The MIK name is derived as follows. MIK_name = prf-64 (MRK, "MIK Name") where prf-64 is the first 64 bits from the output of the PRF. The PRF is the same as that used in the derivation of the MIK. 4.2.2. MIK Properties The MIK has the following properties. o The length of the MIK depends on the MAC algorithm used in protecting the exchange between the MN and the AAA server used to prove possession of the MRK. The MAC algorithm used MAY be specified in the corresponding mobility protocol message sent by the peer. The default MAC algorithm is HMAC-SHA-256. Narayanan Expires December 15, 2007 [Page 9] Internet-Draft draft-vidya-eap-usrk-ip-mobility June 2007 o The MIK MUST only be used for authentication of message exchange between the MN and the server that derived the MRK. This exchange may occur through the mobility agent. o The MIK MUST NOT be used to derive any other keys. o The MIK must remain on the MN and the server that derived it and MUST NOT be transported to any other entity. o The MIK is cryptographically separate from any other keys derived from the MRK. o The lifetime of the MIK is never greater than that of its parent key. The MIK is expired when the MRK expires and removed from use at that time. 4.3. Mobility Usage Session Key (MUSK) Derivation and Properties 4.3.1. MUSK Derviation The Mobility Usage Session Key (MUSK) is the key that is delivered to a mobility agent for a particular mobility session between the MN and the agent. This key may be used to protect the mobility signaling messages between the MN and the mobility agent. The derivation of this key may be triggered by signaling exchange specific to the mobility protocol that requires the key and is not defined in this document An example of MUSK may be the MN-HA Key as used in Mobile IPv4. This document only specifies the framework for the MUSK derivation. The actual inputs for the derivations are expected to be specified in documents that define the actual protocol exchange that leads to the derivation. The MUSK is derived from the MRK, using the prf+ operation defined in RFC4306 [9], as follows. MUSK = prf+ (MRK, "Mobility Usage Session Key", Mobility Agent Identity, Optional Data) The PRF used MAY be the same as that used by the EAP method - using the PRF from the EAP method provides algorithm agility. Otherwise, the default PRF used is HMAC-SHA-256. The inclusion of the mobility agent identity ensures the distribution of different keys to different mobility agents that the MN may be using. This identity may be in any form as specified by the documents that specify the inputs for MUSK derivation in any specific Narayanan Expires December 15, 2007 [Page 10] Internet-Draft draft-vidya-eap-usrk-ip-mobility June 2007 IP mobility protocol. Examples of Mobility Agent Identity are IP address, FQDN, etc. It is RECOMMENDED that the optional data contain some freshness parameter such as a nonce or a sequence number. The MUSK name is derived as follows. MUSK_name = prf-64 (MRK, "MUSK Name") where prf-64 is the first 64 bits from the output of the PRF. The PRF is the same as that used in the derivation of the MUSK. 4.3.2. MUSK Properties A MUSK has the following properties. o The length of the MUSK depends on the MAC algorithm used in protecting the intended mobility protocol exchanges between the MN and the mobility agent. The MAC algorithm used MAY be specified in the corresponding mobility protocol message sent by the peer or may be pre-specified by the specific protocol. The default MAC algorithm is HMAC-SHA-256. o The MUSK is cryptographically separate from any other keys derived from the MRK. o The lifetime of the MUSK is less than or equal to that of the MRK. It MUST NOT be greater than the lifetime of the MRK. o If a new MRK is derived, subsequent MUSKs must be derived from the new MRK. Previously delivered MUSKs may still be used until the expiry of the lifetime. o A given MUSK MUST NOT be shared by multiple mobility agents. 5. Security Considerations This document describes the use of EAP-based keys for IP mobility protocol keying. This provides a means of avoiding the need for multiple pre-shared keys being present between the MN and the AAA server. It may provide an optimization in some cases by making the key management of the IP mobility protocol simpler, but, that is rather a side effect. The following security considerations must be evaluated carefully before choosing EAP-based IP mobility keying mechanisms. Narayanan Expires December 15, 2007 [Page 11] Internet-Draft draft-vidya-eap-usrk-ip-mobility June 2007 In general, all the security considerations described in [2] apply to this document as well. In addition, the following considerations apply. 5.1. Key Distribution The mobility agent is often a different entity from the one that acted as the NAS or EAP authenticator during the EAP exchange that produced the EMSK. In order to avoid mobility agents obtaining keys for mobile nodes that are not requesting any mobility service from them, it is recommended that the MUSK be distributed after some exchange between the MN and AAA server corresponding to the mobility agent in question. For instance, this may be a mobility protocol exchange between the MN and the mobility agent that contains some information protected with the MIK, that can be verified by the AAA server. This basically allows peer consent to be verified prior to distribution of a given key. Without peer consent, it is possible that a MUSK given out is never used. It may be that it does not pose any particular problem in some systems, but, that may depend on other factors. One example is whether the distribution of MUSK is in any way related to any accounting or billing for the MN. Verifying peer consent prior to MUSK distribution provides better security in such cases. 5.2. Revocation of Keys Once an MUSK is handed out to a mobility agent, it may continue to be used until its lifetime expires. This may be true even if a new EMSK is available before that. However, if the EMSK is revoked for some reason and the peer (MN) is no longer given access, continuing to use the MUSK may pose a security risk. In many systems, once the EAP credentials or keys are revoked and the peer is no longer allowed to access the system, the peer will be denied access to any other service in the system as well and hence, the availability of MUSKs at a mobility agent may not pose a risk. But, if the MN is able to use the IP mobility service after its EAP key material has been revoked, the corresponding MUSKs SHOULD also be revoked. This places a burden on AAA servers in such systems to be stateful about the entities to which MUSKs have been handed out and is often undesirable. However, this is assumed to be a rare requirement, since it is expected that the peer will automatically be denied any service once its EAP key material is revoked. 6. Acknowledgements Thanks to Lakshminath Dondeti for his review and comments on this Narayanan Expires December 15, 2007 [Page 12] Internet-Draft draft-vidya-eap-usrk-ip-mobility June 2007 document. 7. References [1] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [2] Salowey, J., "Specification for the Derivation of Usage Specific Root Keys (USRK) from an Extended Master Session Key (EMSK)", draft-ietf-hokey-emsk-hierarchy-00 (work in progress), January 2007. [3] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [5] Castelluccia, C., "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", draft-ietf-mipshop-4140bis-00 (work in progress), March 2007. [6] Koodli, R., "Fast Handovers for Mobile IPv6", draft-ietf-mipshop-fmipv6-rfc4068bis-01 (work in progress), March 2007. [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [8] Narayanan, V. and L. Dondeti, "EAP Re-authentication Extensions", draft-ietf-hokey-erx-01 (work in progress), May 2007. [9] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. Narayanan Expires December 15, 2007 [Page 13] Internet-Draft draft-vidya-eap-usrk-ip-mobility June 2007 Author's Address Vidya Narayanan Qualcomm, Inc. 5775 Morehouse Dr San Diego, CA USA Email: vidyan@qualcomm.com Narayanan Expires December 15, 2007 [Page 14] Internet-Draft draft-vidya-eap-usrk-ip-mobility June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Narayanan Expires December 15, 2007 [Page 15]