| TOC |
|
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 16, 2007.
EAP [1] (Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP),” June 2004.) 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] (Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP),” June 2004.). 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] (Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, “Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK),” June 2008.). The EMSK hierarchy is meant to be extensible to derive keys for various usages. This document defines the key hierarchy and key derivations for using the EMSK hierarchy for keying in IP mobility protocols.
1.
Introduction
1.1.
EAP Keying Overview
1.2.
Motivation for EAP-Based Keying in IP Mobility Protocols
1.3.
Scope
2.
Terminology
3.
Overview of EAP-Based Keying for IP Mobility Protocols
3.1.
Requirements
4.
Key Hierarchy and Derivation Framework
4.1.
Mobility Root Key (MRK) Derivation and Properties
4.1.1.
MRK Derivation
4.1.2.
MRK Properties
4.2.
Mobility Integrity Key (MIK) Derivation and Properties
4.2.1.
MIK Derivation
4.2.2.
MIK Properties
4.3.
Mobility Usage Session Key (MUSK) Derivation and Properties
4.3.1.
MUSK Derviation
4.3.2.
MUSK Properties
5.
Security Considerations
5.1.
Key Distribution
5.2.
Revocation of Keys
6.
Acknowledgements
7.
References
§
Author's Address
§
Intellectual Property and Copyright Statements
| TOC |
| TOC |
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] (Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP),” June 2004.), 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] (Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, “Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK),” June 2008.). 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.
| TOC |
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 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] (Perkins, C., “IP Mobility Support for IPv4,” August 2002.) 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] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) 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] (Soliman, H., Castelluccia, C., Malki, K., and L. Bellier, “Hierarchical Mobile IPv6 Mobility Management,” July 2008.) also recommends the use of IPsec keyed using IKEv2 with EAP for client authentication. Further, FMIPv6 [6] (Koodli, R., “Mobile IPv6 Fast Handovers,” April 2008.) 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.
| TOC |
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.
| TOC |
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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
This document uses terminology defined in [4] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.), [5] (Soliman, H., Castelluccia, C., Malki, K., and L. Bellier, “Hierarchical Mobile IPv6 Mobility Management,” July 2008.), [6] (Koodli, R., “Mobile IPv6 Fast Handovers,” April 2008.), [1] (Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP),” June 2004.) and [2] (Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, “Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK),” June 2008.).
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.
| TOC |
As described in Section 1.2 (Motivation for EAP-Based Keying in IP Mobility Protocols), 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] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” March 2008.) 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.
| TOC |
The following requirements need to be met in order to use the mechanism described here for EAP-based keying of IP mobility protocols.
-----------------------------------------
| 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 (EAP-Based IP Mobility Keying Architecture) 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] (Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, “Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK),” June 2008.).
When a valid EMSK or DSRK is available, usage specific root keys may be derived from those for different uses, in accordance with [2] (Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, “Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK),” June 2008.). This document proposes the derivation of USRKs that are needed for host-based IP mobility protocols. For each protocol, a separate label for root key generation is registered in this document. Further, the framework for derivation of integrity and mobility session keys is also provided.
| TOC |
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 (EAP Based IP Mobility Key Hierarchy) 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.
| TOC |
| TOC |
The Mobility Root Key (MRK) is calculated in accordance with the USRK derivation described in [2] (Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, “Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK),” June 2008.) 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
The KDF is as defined in [2] (Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, “Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK),” June 2008.) 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] (Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, “Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK),” June 2008.).
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.
Based on the above labels, the following are the specific root keys defined for the various IP mobility protocols:
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.
| TOC |
The MRK has the following properties. These properties apply to the MRK regardless of the parent key used to derive it.
| TOC |
| TOC |
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] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) 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.
| TOC |
The MIK has the following properties.
| TOC |
| TOC |
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] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.), 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 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.
| TOC |
A MUSK has the following properties.
| TOC |
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.
In general, all the security considerations described in [2] (Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, “Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK),” June 2008.) apply to this document as well. In addition, the following considerations apply.
| TOC |
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.
| TOC |
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.
| TOC |
Thanks to Lakshminath Dondeti for his review and comments on this document.
| TOC |
| [1] | Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP),” RFC 3748, June 2004 (TXT). |
| [2] | Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, “Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK),” draft-ietf-hokey-emsk-hierarchy-07 (work in progress), June 2008 (TXT). |
| [3] | Perkins, C., “IP Mobility Support for IPv4,” RFC 3344, August 2002 (TXT). |
| [4] | Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” RFC 3775, June 2004 (TXT). |
| [5] | Soliman, H., Castelluccia, C., Malki, K., and L. Bellier, “Hierarchical Mobile IPv6 Mobility Management,” draft-ietf-mipshop-4140bis-05 (work in progress), July 2008 (TXT). |
| [6] | Koodli, R., “Mobile IPv6 Fast Handovers,” draft-ietf-mipshop-fmipv6-rfc4068bis-07 (work in progress), April 2008 (TXT). |
| [7] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [8] | Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” draft-ietf-hokey-erx-14 (work in progress), March 2008 (TXT). |
| [9] | Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” RFC 4306, December 2005 (TXT). |
| TOC |
| Vidya Narayanan | |
| Qualcomm, Inc. | |
| 5775 Morehouse Dr | |
| San Diego, CA | |
| USA | |
| Email: | vidyan@qualcomm.com |
| TOC |
Copyright © 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.
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.