Network Working Group V. Narayanan Internet-Draft G. Giaretta Expires: May 19, 2008 Qualcomm, Inc. November 16, 2007 EAP-Based Keying for IP Mobility Protocols draft-vidya-eap-usrk-ip-mobility-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 19, 2008. 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 Narayanan & Giaretta Expires May 19, 2008 [Page 1] Internet-Draft draft-vidya-eap-usrk-ip-mobility November 2007 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. 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 . . . . . . . . . . . . . . . . . . . . 9 4.2. Mobility Integrity Key (MIK) Derivation and Properties . . 9 4.2.1. MIK Derivation . . . . . . . . . . . . . . . . . . . . 9 4.2.2. MIK Properties . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . 12 5.1. Key Distribution . . . . . . . . . . . . . . . . . . . . . 12 5.2. Revocation of Keys . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 7. Annex A - Example of applicability to MIPv4 . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Narayanan & Giaretta Expires May 19, 2008 [Page 2] Internet-Draft draft-vidya-eap-usrk-ip-mobility November 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 or running a separate security association protocol to establish the necessary keying material (e.g. running again an EAP exchange over IKEv2). The assumption in this document is that the mobility service authorizer and the access service authorizer as defined in RFC 4640 are the same entity (i.e. integrated scenario). 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 Narayanan & Giaretta Expires May 19, 2008 [Page 3] Internet-Draft draft-vidya-eap-usrk-ip-mobility November 2007 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. Based on these motivations, dynamic bootstrapping solutions architecture have been defined. The solution are usually based on the AAA infrastructure for ease of credential management. 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. However this approach increases the signaling overhead and this is not needed as EAP is run twice between the same mobile node and the same EAP server, the first time for network access authentication and the second time for IKEv2 authentication. 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 or the need of running separate security association protocols. Note that this approach was discussed also within the MIP6 bootstrapping design team some time ago; while there was a good agreement to specify some optimization in the integrated scenario based on key derivation from network access authentication, this was not possible due to the lack of a clear EMSK hierarchy definition. We think that now such a clear definition exists within the IETF and therefore it is the right time to define those bootstrapping optimizations. 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 Narayanan & Giaretta Expires May 19, 2008 [Page 4] Internet-Draft draft-vidya-eap-usrk-ip-mobility November 2007 key delivery to mobility agents. Annex A provides an informative example on how the derived keys can be used in the context of MIPv4. The scope of this document is limited to the protocols listed above. Also, the scope is limited to the case where a key generating EAP method is used and 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. 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 Mobility Anchor Point (MAP), the FMIP Previous Access Router (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 (i.e. integrated scenario as defined in RFC4640). 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. Narayanan & Giaretta Expires May 19, 2008 [Page 5] Internet-Draft draft-vidya-eap-usrk-ip-mobility November 2007 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. ----------------------------------------- | 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 Narayanan & Giaretta Expires May 19, 2008 [Page 6] Internet-Draft draft-vidya-eap-usrk-ip-mobility November 2007 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 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, Narayanan & Giaretta Expires May 19, 2008 [Page 7] Internet-Draft draft-vidya-eap-usrk-ip-mobility November 2007 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] 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. Narayanan & Giaretta Expires May 19, 2008 [Page 8] Internet-Draft draft-vidya-eap-usrk-ip-mobility November 2007 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. 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. Narayanan & Giaretta Expires May 19, 2008 [Page 9] Internet-Draft draft-vidya-eap-usrk-ip-mobility November 2007 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. 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 or to perform IKEv2 authentication to establish an IPsec security association. 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 as shown in Annex A. 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. Narayanan & Giaretta Expires May 19, 2008 [Page 10] Internet-Draft draft-vidya-eap-usrk-ip-mobility November 2007 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. 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. Narayanan & Giaretta Expires May 19, 2008 [Page 11] Internet-Draft draft-vidya-eap-usrk-ip-mobility November 2007 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. 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 acte\d 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, Narayanan & Giaretta Expires May 19, 2008 [Page 12] Internet-Draft draft-vidya-eap-usrk-ip-mobility November 2007 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 document. 7. Annex A - Example of applicability to MIPv4 The following is an example on how the key derivation procedure described in this document can be applied to MIPv4 in order to dynamically bootstrap the mobility security association based on the key material derived from the network access authentication. The flow is based on current 3GPP2 specifications. Narayanan & Giaretta Expires May 19, 2008 [Page 13] Internet-Draft draft-vidya-eap-usrk-ip-mobility November 2007 Flow for MIPv4 bootstrapping +----+ +----+ +----+ +-----+ | MN | | AR | | HA | | AAA | +----+ +----+ +----+ +-----+ | | | | | <---------EAP authentication for network access -------------> | | | | | |---Agent Solicitation--->| | | | | | | |<--Agent Advertisement---| | | | | | | |--RRQ (MN-AAA Auth Ext)->| | | | | | | | | ---AAA request (RRQ, HA Request)----->| | | | | | | | +-----------+ | | | | Generate | | | | | MN-HA key | | | | +-----------+ | | | | | | |<--AAA (RRQ,MN-HA key)---| | | | | | | |----- AAA (RRP)--------->| | | | | | |<-------- AAA reply (RRP)--------------| | | | | |<-------RRP--------------| | | | | | | +----------+ | | | | Generate | | | | | MN-HA key| | | | +----------+ | | | | | | | | | | | The description of the steps required follows: 1. The MN performs the EAP authentication for network access. It is supposed that the EAP method used in this transaction supports the generation of keys. A MRK for MIPv4 is derived as described in Section 4.1. 2. The MN may send an Agent Solicitation. 3. The FA sends an Agent Advertisement to the MN. 4. The MN sends a RRQ message as specified in [3]. Narayanan & Giaretta Expires May 19, 2008 [Page 14] Internet-Draft draft-vidya-eap-usrk-ip-mobility November 2007 5. The FA sends the RRQ message via AAA to the AAA server 6. The AAA server selects the HA and generates the MUSK as defined in Section 4.3. The MUSK is used as the MN-HA key. 7. The MN-HA key is sent to the HA together with the RRQ message. 8. The HA replies with a RRP message. 9. The AAA server sends the RRP to the FA. 10. The FA forwards the RRP to the MN. 11. Based on the identity of the HA, the MN generates the MN-HA key as defined in Section 4.3 and checks the validity of the RRP. 8. 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 Root Keys from an Extended Master Session Key (EMSK)", draft-ietf-hokey-emsk-hierarchy-01 (work in progress), June 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., "Mobile IPv6 Fast Handovers", draft-ietf-mipshop-fmipv6-rfc4068bis-03 (work in progress), October 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 Extensions for EAP Re- authentication Protocol (ERP)", draft-ietf-hokey-erx-07 (work in progress), November 2007. Narayanan & Giaretta Expires May 19, 2008 [Page 15] Internet-Draft draft-vidya-eap-usrk-ip-mobility November 2007 [9] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. Authors' Addresses Vidya Narayanan Qualcomm, Inc. 5775 Morehouse Dr San Diego, CA USA Email: vidyan@qualcomm.com Gerardo Giaretta Qualcomm, Inc. 5775 Morehouse Dr San Diego, CA USA Email: gerardog@qualcomm.com Narayanan & Giaretta Expires May 19, 2008 [Page 16] Internet-Draft draft-vidya-eap-usrk-ip-mobility November 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 & Giaretta Expires May 19, 2008 [Page 17]