Mipshop V. Narayanan Internet-Draft Qualcomm, Inc. Expires: September 7, 2007 N. Venkitaraman Motorola Labs H. Tschofenig Siemens G. Giaretta TILab J. Bournelle France Telecom R&D March 6, 2007 Establishing Handover Keys using Shared Keys draft-vidya-mipshop-handover-keys-aaa-04.txt 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 September 7, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes a key management protocol to generate a Narayanan, et al. Expires September 7, 2007 [Page 1] Internet-Draft Handover Keys Using Shared Keys March 2007 handover key between a mobile node (MN) and an access router (AR) for the purpose of securing Fast Mobile IPv6 (FMIPv6) signaling messages. As such, it specifies a message exchange between the MN and the AR and assumptions that must hold in order for this protocol to work. The protocol itself is described here for FMIPv6 use, but is applicable to other protocols that need to establish shared keys between the MN and a network entity. Narayanan, et al. Expires September 7, 2007 [Page 2] Internet-Draft Handover Keys Using Shared Keys March 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Goals, Assumptions and Requirements . . . . . . . . . . . . . 5 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Message Exchange Summary . . . . . . . . . . . . . . . . . 8 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Mobility Header Types . . . . . . . . . . . . . . . . . . 9 5.1.1. Handover Key Request (HKReq) . . . . . . . . . . . . . 9 5.1.2. Handover Key Response (HKResp) . . . . . . . . . . . . 11 5.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 13 5.2.1. Handover Nonce Mobility Option . . . . . . . . . . . . 14 5.2.2. Message Authentication Code (MAC) Mobility Option . . 15 5.2.3. Timestamp Mobility Option . . . . . . . . . . . . . . 16 6. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 17 6.1.1. Handover Integrity Key Derivation . . . . . . . . . . 18 6.1.2. Handover Key Derivation . . . . . . . . . . . . . . . 18 6.2. Mobile Node Considerations . . . . . . . . . . . . . . . . 19 6.2.1. Sending Handover Key Request Messages . . . . . . . . 19 6.2.2. Receiving and Processing Handover Key Response Messages . . . . . . . . . . . . . . . . . . . . . . . 20 6.2.3. Returning to an Access Router . . . . . . . . . . . . 21 6.3. Access Router Considerations . . . . . . . . . . . . . . . 21 6.3.1. Returning Mobile Node . . . . . . . . . . . . . . . . 23 6.4. Handover Key Server Considerations . . . . . . . . . . . . 24 6.5. Indirect MN-AR Handover Key Exchange . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7.1. Strength of the HMK . . . . . . . . . . . . . . . . . . . 25 7.2. Strength of the HIK and HK . . . . . . . . . . . . . . . . 26 7.3. Replay Protection . . . . . . . . . . . . . . . . . . . . 26 7.4. IP Address Authorization . . . . . . . . . . . . . . . . . 26 7.5. Identity Protection . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 10.2. Informative References . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . . . 31 Narayanan, et al. Expires September 7, 2007 [Page 3] Internet-Draft Handover Keys Using Shared Keys March 2007 1. Introduction Fast Mobile IPv6 [1] specifies a fast handoff protocol for IPv6 mobile nodes. It requires tunneling of packets from an old access router to the mobile node. For this purpose, the FMIPv6 signaling messages between the mobile node and the access router must be secured to ensure FMIPv6 support for a legitimate mobile node that has been authorized to obtain such services. The FMIPv6 protocol itself does not provide a method to establish a session key and the corresponding parameters between the mobile node and the access router required for this purpose. This document describes a key management protocol to generate session keys between a mobile node and an access router for usage in the context of FMIPv6. In practice, this messaging may be carried in AAA between the AR and a Handover Key Server, although that is not required when the AR and the Handover Key Server are collocated. As such, it specifies: o A message exchange between the MN and the AR o Derivation of a new session key for handoff purposes based on a shared secret 1.1. Applicability Although this document is focused on FMIPv6, it is applicable to other protocols as well. In the context of FMIPv6, the key derived using this protocol can be used to secure the Fast Binding Update (FBU) sent from the MN to the Previous Access Router (PAR) as specified in FMIPv6 [1]. Other protocols may also use this mechanism as noted below. For instance, Context Transfer Protocol (CxTP) [9] can also use this protocol to derive keys between the AR and MN to secure the messages between the two entities. Additionally, keys between an MN and a MAP can be derived using this protocol for Hiearchical Mobile IPv6 (HMIPv6) [10] operation. This draft, however, does not address any details on how the protocol described in this draft may be used for CxTP or HMIPv6. 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 RFC2119 [2]. In addition, this document uses the following terms: Narayanan, et al. Expires September 7, 2007 [Page 4] Internet-Draft Handover Keys Using Shared Keys March 2007 Handover Key Server (HKS) This is the entity with which the Mobile Node shares a key in order to generate a handover key required for FMIPv6 operation. In practice, this server may be collocated with the Access Router or with a AAA server in the infrastructure. Handover Master Key (HMK): A key that is shared between the Mobile Node and the Handover Key Server. The HMK is never used directly to protect any messages. Handover Integrity Key (HIK): A key that is shared between the Mobile Node and the Handover Key Server. The HIK is derived from the HMK and is used for authenticating the HKReq/HKResp messages between the MN and the Handover Key Server. Handover Key (HK): Session key used to secure fast handover signaling messages between the Mobile Node and Access Router. A given HK between an MN and ARn is termed as HKn. Pseudo Random Function (PRF): A pseudo-random function (PRF) takes a key and some input data and produces a pseudo-random output; the key must be random and secret, but the input data can be public. 3. Goals, Assumptions and Requirements The document generally follows the key management guidelines documented in [11]. This section describes the goals and assumptions that the protocol design is based on. o A major goal of the protocol is to shared keys to establish session keys for securing FMIPv6 signaling messages. In using shared keys, one of the goals is to allow the use of AAA infrastructure to help establishing the handover keys. AAA protocols are widely deployed today due to the usage of AAA-based network access authentication. The handover keying protocol (HKP) uses a Handover Key Server to authenticate and authorize the MN for fast handovers. When the Handover Key Server is an entity that is separate from the AR, AAA may be used for message transport between the AR and the server. The handover key in this Narayanan, et al. Expires September 7, 2007 [Page 5] Internet-Draft Handover Keys Using Shared Keys March 2007 case will be delivered using AAA to the AR. o There must be cryptographic separation between the keys used for integrity protection and the derivation of the handover keys. To avoid reusing the HMK for two distinct purposes, namely in a PRF for key derivation and in a MAC for integrity proctetion, two keys are derived from the HMK -- an HIK, that protects HKP messages and an HK that protects the FMIPv6 signaling messages. o Unique key naming of the keys must be provided. Key naming of the HMK and HIK is provided using the Network Access Identifier (NAI) of the MN. The HK is also named using the NAI - however, at some point, a valid MN Care-of-address and an SPI are associated with the HK. Note that the use of temporary NAIs is allowed by the protocol to protect the privacy of the Mobile Node. o It is imperative that the handover key derivation does not impact handoff latency. The HKP does not introduce any new messages or steps that impact handover latency. o It is necessary that the compromise of one AR or a particular handover key does not lead to the compromise of keys shared between the MN and any other AR. The protocol is designed such that no AR is able to view the key of another AR - keys are transferred securely from the Handover Key Server directly to the AR requesting it. o A Handover Master Key (HMK) between the MN and the Handover Key Server is required for this protocol to be able to derive handover keys between the MN and the AR. The exact method of establishing or deriving this HMK is outside the scope of this document. No particular method is mandated for this protocol to work. o It is further assumed that a security association exists between each AR and the Handover Key Server. These security associations protect the signaling message exchange including the transport of keying material and other security sensitive parameters. 4. Protocol Overview This section provides a description of the procedure to obtain the Handover Key (HK). We assume that the MN shares a key, called Handover Master Key (HMK), with the Handover Key Server. This may be a pre-shared key or a shared key derived in some means outside the scope of this document. A Handover Integrity Key (HIK) is derived from the HMK at the MN and Narayanan, et al. Expires September 7, 2007 [Page 6] Internet-Draft Handover Keys Using Shared Keys March 2007 the server. The HIK is used to provide integrity protection to messages exchanged by the MN and the server. Also, the actual Handover Key (HK) shared between the MN and the AR is derived from the HMK. The derivation of these keys is described in Section 6.1. Figure 1 depicts the high-level protocol interaction. MN AR HK Server | HKReq. | | | ---------> | | | | AAA Request | | | ----------------------> | | | AAA Response | | | <----------------------- | | HKResp. | (Keying material) | | <--------- | | Figure 1: Protocol Operation The MN, upon attaching to an AR (say AR1) in a given administrative domain, sends a Handover Key Request (HKReq) message to the AR. The MN creates a HKReq message including an NAI-like identifier (that was derived possibly during the time of HMK derivation), a message ID, and the care-of-address (CoA). The MN also generates a nonce and includes it in the HKReq message. Further, the MN indicates the PRF algorithm that it chooses to use for key generation in the HKReq message. The MN includes a MAC of the message fields in an MN-HKS MAC Mobility sub-option. Upon receiving the HKReq from the MN, AR1 must first ensure that it has a valid neighbor cache entry for the CoA claimed by the MN. AR1 further verifies the validity and uniqueness of the CoA claimed by the MN. After verifying the validity of the CoA of the MN, AR1 forwards the HKReq message to the Handover Key Server. The MAC in the HKReq allows the Handover Key Server to authenticate the MN and to perform authorization for fast handoffs before deriving a unique and fresh session key, the Handover Key (HK1). HK1 will subsequently be used between the MN and the AR1 after a successful protocol execution. The key derivation procedure for the Handover Key is defined as follows: HK1 = gprf+ (HMK, HKS-Nonce | MN-Nonce | AR1 ID | MN ID | "Handover Key"), where | indicates concatenation The AR1 ID is the global IP address of AR1 as seen by the MN. The MN ID is the NAI of the MN that is sent by the MN in the HKReq message. The HKS-Nonce and MN-Nonce are nonces generated by the Handover Key Narayanan, et al. Expires September 7, 2007 [Page 7] Internet-Draft Handover Keys Using Shared Keys March 2007 Server and the MN respectively for the purpose of HK1 derivation. The function gprf+ is defined in Section 6.1. After successful authentication and authorization, the Handover Key Server sends two sets of parameters to AR1 - HK1 and associated lifetime destined to AR1 and the HKS-Nonce to be sent to the MN. The message is protected with an SA that AR1 shares with the Handover Key Server. AR1 sends a Handover Key Response (HKResp) to the MN, including the material (nonce) sent by the server and also the key lifetime it received from the server. AR1 further includes an SPI it uses to index the key, so that the MN can use that SPI while sending the FBU in accordance with [1]. AR1 includes a MAC computed using HK1 as part of the HKResp. Using the keying material obtained, the MN derives HK1 and validates the HKResp using that. When the MN is ready to send an FBU to AR1 (in accordance with [1], it uses HK1 to secure the FBU message. 4.1. Message Exchange Summary MN AR HKS ---- ---- ----- MSGID, PRF, CoA, N1, ID, [T], MN-HKS MAC --> AAA (MSGID, PRF, CoA, N1, ID, [T], MN-HKS MAC) --> <-- AAA (N2, [MN-HKS MAC]) <-- MSGID, PRF, Code, SPI, N2, [MN-HKS MAC], [T], MN-AR MAC Figure 2: Message Exchange The figure summarizes the message exchange in the protocol. The fields shown in [ ] are optional fields. ( ) indicates encapsulation - for instance, the encapsulation of the payloads in a AAA protocol is shown as AAA ( ... ). MSGID denotes the message ID chosen by the MN in the HKReq - the message ID in the HKResp is set to the same value. The PRF indicates the algorithm chosen by the MN or the Handover Key Server in the respective messages. CoA indicates the care-of-address of the MN that is carried in the HKReq. N1 and N2 Narayanan, et al. Expires September 7, 2007 [Page 8] Internet-Draft Handover Keys Using Shared Keys March 2007 are the nonces sent by the MN and the Handover Key Server respectively. The MN-HKS or MN-AR MAC options carry the authentication data in the HKReq and HKResp messages. T denotes the timestamp. The SPI in the HKResp is chosen by the AR and sent to the MN. 5. Message Formats This protocol defines new Mobility Header types for carrying the Handover Key Request (HKReq) and Handover Key Response (HKResp) messages. This protocol also defines three new Mobility Options - the Handover Nonce Mobility Option, the Timestamp Mobility Option and the MAC Mobility Option. This section presents the description of the HKReq and HKResp messages and the Mobility options that this protocol uses. 5.1. Mobility Header Types 5.1.1. Handover Key Request (HKReq) A Handover Key Request (HKReq) message MUST be sent from the MN to the AR to request the derivation of a handover key. The MN sends this message some time after selecting the AR as its default router but prior to the need to handover to a different AR. It is recommended that this protocol be executed significantly ahead of impending handoff in order to not impact the handover latency. The detailed processing rules for this message are described in Section 6. The HKReq message uses the MH Type value TBA1. The length in the mobility header is set to include the mobility suboptions. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: Narayanan, et al. Expires September 7, 2007 [Page 9] Internet-Draft Handover Keys Using Shared Keys March 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID |v|PRF|Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Key Care of Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Suboptions (variable) . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Handover Key Request HKReq Fields Message ID A one octet value used to uniquely match requests and responses and identify retransmissions. The message ID may be a sequence number starting at any value. V Verify flag. This is set by the MN to indicate that it may already share a key with the AR. If the V flag is set, the MN-AR MAC option MUST be included in the message. PRF A 3 bit field indicating the PRF algorithm that the MN wishes to use for key generation. This is the algorithm the MN proposes to use in the derivation of HIK and HK from the HMK. Currently, the value of 1 is assigned to indicate HMAC-SHA1. Reserved Set to 0; ignored on reception. Narayanan, et al. Expires September 7, 2007 [Page 10] Internet-Draft Handover Keys Using Shared Keys March 2007 Key Care of Address Sixteen octet field containing the IPv6 CoA for which the key is requested. Mobility Suboptions Variable length field of such length that the complete Mobility Header is an integer multiple of 8 octets. This field contains one or more TLV-encoded mobility suboptions. Valid mobility sub-options for this message include the following: Handover Nonce Mobility Option (new option defined in section Section 5.2.1 below) Mobile Node Identifier Mobility Sub-option, as defined in [3] MAC Mobility Option as defined in Section 5.2.2 Timestamp Mobility Option as defined in Section 5.2.3 5.1.2. Handover Key Response (HKResp) A handover key response (HKResp) message MUST be sent from the AR to the MN in response to a HKReq message. HKResp must carry suboptions appropriate to the key agreement mechanism requested in the HKReq, which the MN can use to derive a handover key. The HKResp message uses the MH Type value TBA2. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: Narayanan, et al. Expires September 7, 2007 [Page 11] Internet-Draft Handover Keys Using Shared Keys March 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID |v|PRF|Reserved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Handover Key Response HKResp Fields Message ID A one octet value used to uniquely match requests and responses and identify retransmissions. This value is copied from the corresponding HKReq. V Verified flag. Set by the AR in response to a HKReq with the V bit set, if it verified the request. PRF Type A 3 bit field indicating the PRF algorithm that the server used for key generation. This is the algorithm used in the derivation of HIK and HK from the HMK. If the server accepts the algorithm proposed by the MN, it sets the value to the same as in the HKReq. If not, the value in this field indicates the algorithm the MN MUST use to derive the keys. Currently, the value of 1 is assigned to indicate HMAC-SHA1. Reserved Set to 0; ignored on reception. Narayanan, et al. Expires September 7, 2007 [Page 12] Internet-Draft Handover Keys Using Shared Keys March 2007 Status Code One octet status code indicating the status of the request. 0 - Success. 130 - CoA_AUTH_FAILED 131 - ADMINISTRATIVELY_PROHIBITED. 135 - TIMESTAMP_REQD 136 - INVALID_PRF_ALG 137 - INVALID_MAC_ALG 138 - INVALID_TIMESTAMP Lifetime Lifetime of the handover key, in seconds. SPI Four octet Security Parameter Index for the handover key at the AR. The SPI is used by the AR to identify the key when the key is used. The SPI, along with the IP address of the AR, uniquely identifies the key at the MN. Mobility Suboptions Variable length field of such length that the complete Mobility Header is an integer multiple of 8 octets. This field contains one or more TLV-encoded mobility suboptions. Valid mobility sub-options for this message include the following: Handover Nonce Mobility Option (new option defined in section Section 5.2.1 below) MAC Mobility Option as defined in Section 5.2.2 Timestamp Mobility Option as defined in Section 5.2.3 5.2. New Mobility Options Narayanan, et al. Expires September 7, 2007 [Page 13] Internet-Draft Handover Keys Using Shared Keys March 2007 5.2.1. Handover Nonce Mobility Option This new mobility option is defined to carry the nonce generated by the MN or the Handover Key Server in the HKReq and HKResp messages. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opt Type | Opt Lgth | Subtype | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Handover Nonce ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Handover Nonce Mobility Option Option Fields Option Type Handover Nonce (to be assigned by IANA) Option Length 8-bit unsigned integer, representing the length in octets of the Sub-type, and the handover nonce fields. Sub-type '1' - HKS-Nonce (nonce generated by the Handover Key Server) '2' - MN-Nonce (nonce generated by the MN) Reserved Set to 0 and ignored on reception. Handover Nonce A variable length nonce generated by the MN or Handover Key Server. Narayanan, et al. Expires September 7, 2007 [Page 14] Internet-Draft Handover Keys Using Shared Keys March 2007 5.2.2. Message Authentication Code (MAC) Mobility Option This new mobility option is defined to carry the message authentication code in the HKReq and HKResp messages. The HKReq and HKResp messages MUST carry atleast one Authentication Mobility Option. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opt Type | Opt Lgth | Subtype |Reserved| AT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AUTH Value .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Authentication Mobility Option Option Fields Option Type MAC Option (to be assigned by IANA) Option Length 8-bit unsigned integer, representing the length in octets Sub-type '1' - MN-HKS MAC Option (authentication between MN and Handover Key Server) '2' - MN-AR MAC Option (authentication between MN and AR) Algorithm Type This field indicates the algorithm used for integrity protection of messages. Set to 1 to indicate HMAC-SHA-1. Narayanan, et al. Expires September 7, 2007 [Page 15] Internet-Draft Handover Keys Using Shared Keys March 2007 Reserved Set to 0 and ignored on reception. AUTH Value This field is calculated using the HIK for the MN-HKS MAC option and using the HK for the MN-AR MAC option. The details of computing the AUTH value are provided in Section 6. 5.2.3. Timestamp Mobility Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opt Type | Opt Lgth | Timestamp ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp (contd) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp (contd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Timestamp Mobility Option Option Fields Option Type Timestamp Option (to be assigned by IANA) Option Length 8-bit unsigned integer, representing the length in octets Timestamp 64-bit Timestamp The Mobile Node MUST set the Timestamp field to a 64-bit value formatted as specified by the Network Time Protocol (NTP) [4]. The low-order 32 bits of the NTP format represent fractional seconds, and those bits that are not available from a time source SHOULD be generated from a good source of randomness. Narayanan, et al. Expires September 7, 2007 [Page 16] Internet-Draft Handover Keys Using Shared Keys March 2007 Note, however, that when using timestamps, the 64-bit timestamp used in a HKReq from the Mobile Node MUST be greater than that used in any previous successful HKReq. The Handover Key Server checks the timestamp value to ensure its validity. If valid, it copies the entire value into the HKResp, after successful processing of the HKReq message. By default, a difference of 7 seconds is an acceptable deviation of timestamps between the MN and the server. If the timestamp is invalid, the server copies only the low-order 32 bits into the HKResp, and supplies the high-order 32 bits from its own time of day. In this case, the HKResp MUST indicate a failure "INVALID_TIMESTAMP". In the event of such a failure, the MN MUST adjust its timestamp and send another HKReq with the corrected timestamp. 6. Protocol Details The proposed protocol enables a MN to derive session keys (HKs) with an access router. This section describes the key derivation process and the processing rules for the mobile node, the access router and the Handover Key Server. 6.1. Key Derivation As mentioned earlier, the MN and the Handover Key Server share a key for the purpose of handover key derivation, called the Handover Master Key (HMK). The HMK may be a pre-shared key or may be derived between the MN and the server by means outside the scope of this document. The HMK MUST be at least 64 bytes in length and SHOULD NOT be generated from a password. The HMK MUST NOT be directly used to protect any data. The HMK is only used to derive the Handover Integrity Key (HIK) and Handover Keys (HK). The MN and the Handover Key Server MUST derive a Handover Integrity Key (HIK) and a Handover Key (HK) from the Handover Master Key. The PRF used in the derivation must be communicated by the MN to the server in the HKReq message. The Handover Key Server may choose to mandate a different PRF type by indicating so in the HKResp message. The key derivation follows the procedure explained in this section. For the purpose of deriving keys of variable length that depend on the PRF type and MAC algorithm used, this document uses an adaptation of prf+ defined in RFC4306 [5]. This function is termed "Generalized prf+ (gprf+)" and is defined as follows (where | indicates concatenation). Narayanan, et al. Expires September 7, 2007 [Page 17] Internet-Draft Handover Keys Using Shared Keys March 2007 gprf+ (K, S) = T1 | T2 | T3 | T4 ... where: T1 = PRF (K, S | Y) T2 = PRF (K, T1 | S | Y+1) T3 = PRF (K, T2 | S | Y+2) T4 = PRF (K, T3 | S | Y+3) continuing as needed to compute all required keys. The keys are taken from the output string without regard to boundaries, depending on the length of the key required. 6.1.1. Handover Integrity Key Derivation The gprf+ is used as follows to derive the HIK. HIK = gprf+ (HMK, "Handover Integrity Key") where, the string Handover Integrity Key is a 22-character ascii string with no null termination. The value of Y is the Message ID (in hex) from the HKReq sent by the MN. The Message ID is used in the derivation to allow the values of HIK to change upon every instantiation of the gprf+ for this purpose. Since the HIK derivation does not involve nonces or other changing parameters, the Message ID is included to avoid the use of the same HIK for a long time. This really is provided to allow implementations that don't refresh the HMK appropriately to still be able to have changing HIKs. If the HMK is refreshed periodically, there is not a need to derive a new HIK at every HKReq/HKResp exchange. However, at the time of this writing, it is felt that it will not be uncommon to configure a HMK and not change it for a long period of time. 6.1.2. Handover Key Derivation The gprf+ is used as follows to derive the HK (where | indicates concatenation). HK = gprf+ (HMK, MN-Nonce | HKS-Nonce | MN ID | AR ID | "Handover Key") where, the string Handover Key is a 12-character ascii string with no null termination. The MN Nonce is generated by the MN and communicated to the Handover Key Server in the HKReq message. The HKS-Nonce is generated by the Handover Key Server and communicated to Narayanan, et al. Expires September 7, 2007 [Page 18] Internet-Draft Handover Keys Using Shared Keys March 2007 the MN in the HKResp message. The MN ID is the NAI of the MN and the AR ID is the IP address of the AR as seen by the MN. The value of Y for the HK derivation is set to 0x0000. The actual length of the HK required is determined by the MAC algorithm used in the protection of FMIPv6 signaling. More details on the process leading to HK derivation and its usage can be found in sections below. 6.2. Mobile Node Considerations After attaching to an AR, an FMIPv6 capable mobile node SHOULD immediately proceed to obtain a session key between itself and its current AR. 6.2.1. Sending Handover Key Request Messages In order to derive a shared key with the AR, the MN MUST create a HKReq with a unique Message ID. The Message ID may be random or it may be a sequence number. The MN MUST also derive a nonce that will be used in HK derivation and include it in the HKReq. For subsequent retransmissions, the Message ID MUST remain the same. In order to obtain replay protection, the MN SHOULD use the Timestamp mobility option defined in Section 5.2.3. The MN MUST indicate the PRF algorithm it used for HIK derivation and intends to use for HK derivation in the PRF field of the HKReq header. The HKReq sent by the MN MUST include the MN-HKS MAC Mobility Sub- Option. The AUTH Value in the MN-HKS MAC option shall be calculated as follows: AUTH = MAC(HIK, MH Data) The MAC algorithm used is indicated in the Algorithm Type included in the MAC Mobility Option. MH Data is the content of the Mobility Header up to and including the Algorithm Type field of this option. The MN should send a new HKReq before the expiry of the lifetime of the key obtained via the pervious HKReq. Once a MN obtains a new key, it MUST discard the old key and use the new key for authenticating the FBU. Narayanan, et al. Expires September 7, 2007 [Page 19] Internet-Draft Handover Keys Using Shared Keys March 2007 If the MN does not receive a response after a configured timeout (HKEY_REQ_TOUT), it SHOULD retransmit the request for a maximum of N HO_KEYTRIES. In each of the retry attempts, the MN MUST use the same message ID. The default value of N_HO_KEYTRIES is 3. 6.2.2. Receiving and Processing Handover Key Response Messages Upon receiving a successful HKResp message from the AR, the MN MUST ensure that the message contains the MN-AR MAC mobility option. If not, it MUST silently discard the message. The MN MUST ensure that the Message ID matches with that of the corresponding HKReq. If there is a mismatch, it MUST drop the packet. The MN MUST compute the handover key using the keying material contained in the HKResp message. The key is computed as described in Section 6.1. The MN MUST verify the AUTH Value in the MN-AR MAC mobility option using the HK derived. The MAC algorithm used is the one specified in the Algorithm Type field of the MN-AR MAC mobility sub-option. If the MAC algorithm is not supported by the MN, it MUST discard the message. If the AUTH Value verification fails, the MN MUST silently discard the message. Upon successful processing of the HKResp and derivation of the valid HK, the MN MUST store the SPI and lifetime associated with the key, as sent in the HKResp. 6.2.2.1. Error Processing The MN handles the following error conditions upon receiving the HKResp message with a code set to a value other than 0. o If the MN receives a HKResp with the Code set to ADMINISTRATIVELY_PROHIBITED, the MN MUST NOT send any more HKReq messages via that AR. o If the code is set to COA_AUTH_FAILED, it MAY retransmit the HKReq after a random time greater than HK_RETRY_INTERVAL. However, the MN MUST NOT retransmit the HKReq more than N HO_KEYTRIES. o If the code is set to TIMESTAMP_REQD, the MN SHOULD send another HKReq using the Timestamp mobility option. o If the code is set to INVALID_TIMESTAMP, the MN SHOULD send another HKReq with the adjusted timestamp value. o If the code is set to INVALID_PRF_ALG, the MN MAY send another HKReq with the PRF Algorithm specified in the HKResp message. Narayanan, et al. Expires September 7, 2007 [Page 20] Internet-Draft Handover Keys Using Shared Keys March 2007 o If the code is set to INVALID_MAC_ALG in the MN-HKS MAC sub- option, the MN MAY send another HKReq with the Algorithm Type value set to that found in the corresponding field of the HKResp message. 6.2.3. Returning to an Access Router When a MN attaches to an AR with which the MN believes it has a shared Key (for example the MN has an unexpired key it obtained when it was previously associated with the access router), the MN MAY request that the AR utilize the key as long as the key has not expired. If the MN wishes to re-use the key, it MUST do so only after verifying that by sending a HKReq with the verify flag set. The message ID field in the HKReq may be a freshly generated random number or a sequence number starting at any value. The MN MUST include an MN-AR MAC mobility option in HKReq with verify flag set. The MN-AR MAC Option MUST be the last option included in the HKReq. The MAC option allows the AR to verify proof of possession of the handover key by the MN. The verify procedure serves two purposes: (1) It is used to verify that the AR still has the key and allows use of the key until the lifetime of the key and (2)It enables the MN CoA to be bound to the key. If the HKReq message is successfully processed by the AR, the CoA contained in the message is bound to the existing HK for that MN. If the verify request is not successful the MN SHOULD create a new MN-AR handover key by sending a HKReq with the MN-HKS MAC mobility option . If the MN receives a HKResp with the code set to HK_VERIFY_FAILED, it SHOULD send another HKReq with the MN-HKS MAC Mobility sub-option to obtain a new handover key via the Handover Key server. 6.3. Access Router Considerations If the HKReq message does not contain the MN ID Mobility Option, the AR MUST silently discard the message. If the HKReq does not have the verify bit set, the AR does the following. If the HKReq message does not contain the MN-HKS MAC Mobility sub- option, it MUST silently discard the message. The AR MUST first determine if it has a pending request from the MN with the same message id. If so and if the AR has already received a response corresponding to the HKReq, the AR SHOULD retransmit the HKResp to the MN. For further protection from replays, the rate of retransmissions of responses to MN MUST not be more than a preconfigured RETRANS_RATE. If the AR already forwarded this message to the Handover Key Server but has not yet received a response from the server, the AR MUST silently discard the retransmitted request Narayanan, et al. Expires September 7, 2007 [Page 21] Internet-Draft Handover Keys Using Shared Keys March 2007 from the MN. Note that the AAA protocol transporting the message between the AR and the Handover Key Server should independently perform its own retransmission. If this is a new HKReq, the AR MUST check to determine if the MN-HKS MAC Mobility sub-option has been included in this message by the MN. If it has been included, then the AR MUST forward the request to the Handover Key Server. If the AR expects timestamp-based replay protection, it MUST return a HKResp with the error code set to "TIMESTAMP_REQD". If it is a new HKReq, the AR SHOULD send a request to the Handover Key Server only after successful validation of the CoA to ensure that the MN is claiming the correct IP address. Section 7.4 provides additional discussion on the issues associated with address validation and some possible options for address validation. If the AR fails to verify the CoA, it MUST send a HKResp with the code set to CoA_AUTH_FAILED. The AR MUST communicate its IP address as seen by the MN to the Handover Key Server. This will be used as the AR ID in deriving the handover key. The domain name in the NAI is used to determine the Handover Key Server to be contacted. If the AR receives a successful response message from the Handover Key Server, it MUST store the handover key received from the server along with the CoA and MN ID and index it additionally with an SPI. The AR MUST send the SPI, HKS-Nonce and lifetime obtained from the server in the HKResp message to the MN. The AR MUST include a MAC of the message created using the HK in the MN-AR MAC Mobility Sub-Option carried in the HKResp message. The AUTH Value in the MN-AR MAC option is created as follows. AUTH = MAC (HK, MH Data) The MAC algorithm used is indicated in the Algorithm Type included in the MAC Mobility Option. MH Data is the content of the Mobility Header up to and including the Algorithm Type field of this option. If the AR received an MN-HKS MAC sub-option from the server, it MUST include that in the HKResp to the MN. If the AR receives an unsuccessful response from the server, the AR MUST send an appropriate error code to the MN in the HKResp message. Narayanan, et al. Expires September 7, 2007 [Page 22] Internet-Draft Handover Keys Using Shared Keys March 2007 The AR SHOULD buffer the information to be sent to the MN for a maximum value of HKEY_REQ_TOUT, so that it can be retransmitted upon receiving a HKReq with the same Message ID. If an AR receives a response message corresponding to a MN that is no longer connected to it, the AR SHOULD silently discard it. After retransmission timeout, if the AR does not receive a response from the server, it MUST remove all state associated with the MN and MUST NOT send a response to the MN. When the neighbor cache entry for the CoA expires, the AR MUST disassociate the key and the corresponding CoA. When the lifetime of the key expires, the AR should remove the SPI. However, the AR SHOULD keep the handover key and SPI until the lifetime of the key expires. 6.3.1. Returning Mobile Node If a mobile node believes that it shares a handover key with a valid lifetime with the AR, it may send a HKReq with the 'V' bit set. If so, the AR MUST use the SPI to lookup the key. If a key is present the AR MUST verify the AUTH value in the MAC option. If the AUTH value is invalid, the AR MUST silently discard the message. If the computed MAC matches the AUTH value included in the HKReq message, the AR SHOULD verify that the IP address is valid and is not claimed by any other node. If that procedure succeeds, the AR MUST send a response with the verified bit set including a MAC of the response. Also, the AR MUST record the CoA of the MN as the IP address associated with the handover key for that MN, in addition to the MN ID (NAI). If the MN-AR MAC Mobility Sub-Option is not present in the HKReq or if the AR is unable to verify the MAC in this case, the AR MUST silently drop the message, The rate of transmissions of responses to MN MUST not be more than a preconfigured TRANS_RATE. If the AR does not have the key and if the HKReq does not have the MN- HKS MAC Option, it MUST drop the message and return a HKResp with the error code set to "HK_VERIFY_FAILED". If the AR does not have the key and the HKReq included the MN-HKS MAC Mobility Sub-Option, the AR MAY process the HKReq as though the 'V' bit was not set. Narayanan, et al. Expires September 7, 2007 [Page 23] Internet-Draft Handover Keys Using Shared Keys March 2007 6.4. Handover Key Server Considerations This section provides a description of the operation of the Handover Key Server for this protocol. If the MN cannot be authenticated by the server, it MUST silently discard the HKReq message. If authorization failed for the MN to use FMIPv6 at the AR it is visiting, the server MUST return a response with the code set to ADMINISTRATIVELY_PROHIBITED. If the server expects to use a PRF other than the one indicated in the HKReq message, it MUST return an error set to INVALID_PRF_ALG and set the PRF field in the HKResp to indicate the algorithm that must be used. The server, in this case, MUST include an MN-HKS MAC option with the AUTH Value computed using the HIK. The server MUST derive a Handover Integrity Key (HIK) from the Handover Master Key (HMK) for the MN as specified in Section 6.1. If the server is expecting timestamp-based replay protection in the HKReq, it MUST send an error set to TIMESTAMP_REQD in response to an HKReq that does not contain the Timestamp mobility option. If the HKReq contains the Timestamp mobility option, it MUST be processed in accordance with Section 5.2.3. If the timestamp sent by the MN does not match its own timestamp, the server MUST send an error with the code INVALID_TIMESTAMP and include its timestamp in accordance with Section 5.2.3. The server, in this case, MUST include an MN-HKS MAC option with the AUTH Value computed using the HIK. Upon receiving a handover key request, the server MUST verify that the MN-HKS MAC Mobility Sub-Option is present in the message. If it is absent, the server MUST silently discard the message. Otherwise, the server MUST verify the AUTH Value in the option. If it is invalid, the server MUST silently discard the message. If it is valid, the server must proceed with the handover key generation described in Section 6.1. If the MAC Algorithm used by the MN is unacceptable, the server SHOULD return an error of type INVALID_MAC_ALG, including an MN-HKS MAC option with the algorithm set to the desired value and the AUTH Value computed using the HIK. If the IP address of the AR was not available, the server MUST return an error to the AR, indicating that the IP-Address is required. The server MUST send a response back to the AR, including the HKS- Nonce as well as the derived HK. Note that the AAA protocol used for transport of messages and key distribution between the AR and the Handover Key Server is expected to provide its own security for purposes of encrypting the HK. The server SHOULD include a lifetime Narayanan, et al. Expires September 7, 2007 [Page 24] Internet-Draft Handover Keys Using Shared Keys March 2007 for the HK in the response message. The server is, however, not required to store the key or the lifetime. 6.5. Indirect MN-AR Handover Key Exchange The MN may wish to derive a handover key with an AR when it is not directly attached to that AR. This may happen in case the MN is using FMIPv6 service with pAR as its anchor (while moving rapidly across ARs, for instance) and its handover key with the pAR is about to expire. In this case, the MN may need to refresh the key via the nAR it is attached to. To establish a new handover key with an AR, the MN simply sends HKReq message destined to that AR. The CoA for such indirect refreshes SHOULD be set to NULL. If the CoA is non-NULL, the pAR MUST check if the CoA provided in the HKReq is the same address that is tied to the NAI provided by the MN. If that is not the case the pAR MUST reject the HKReq. If the checks are valid, the pAR contacts the Handover Key Server to establish a handover key as described before. 7. Security Considerations This section describes the security considerations for the protocol for establishing handover keys specified in this document. The messages described in this document are intended to allow the establishment of a security association between the mobile node and access router for fast handoff purposes. The handover key protocol described in this document transports the nonce from the Handover Key Server to the MN and the MN derives its own handover key using the nonce and other parameters. 7.1. Strength of the HMK The protocol relies on the HMK shared between the mobile node and the Handover Key Server for handover key derivation. When the server is a separate backend entity, it also relies on the security of the AAA protocol used for transport between the AR and the server for HK distribution to the AR. The AAA channel MUST be capable of providing confidentiality and integrity protection of messages. The Security Associations resulting from use of this protocol do not offer any higher level of security than what is already implicit in use of the Security Association between the mobile node and the Handover Key Server. In order to deny any adversary the luxury of unbounded time to analyze and break the HMK, it must be refreshed periodically. The provisioning and refreshing of the HMK in the MN Narayanan, et al. Expires September 7, 2007 [Page 25] Internet-Draft Handover Keys Using Shared Keys March 2007 and server is outside the scope of this document. 7.2. Strength of the HIK and HK The protocol allows the derivation of the Handover Integrity Key (HIK) and the Handover Key (HK) from the HMK. The HIK is shared between the MN and the Handover Key Server and used in integrity protection of the HKReq message and in implicit authentication of the MN. The AUTH value in the MAC option of the message is calculated using the HIK, allowing integrity protection. By verifying proof of possession of the valid HIK, the MN is authenticated by the server. The Handover Key (HK) is shared between the MN and the AR and is used in integrity protection of messages between the MN and the AR. The AR uses the HK to compute the AUTH value in the HKResp message to the MN. Also, when the MN sends a HKReq to the AR with the MN-AR MAC Mobility Sub-Option, it uses the HK to derive the AUTH value in it. Subsequently, when the MN and AR exchange FMIPv6 signaling messages (FBU/FBAck), the HK is used to protect the signaling. This protocol allows the PRF used for key derivation to be indicated by the MN in the HKReq message. Also, the server may choose to deny the usage of the chosen PRF by specifying a different PRF in the HKResp messages. Currently, HMAC-SHA1 is the only PRF for which a value has been defined in this document. Future documents may define more PRF types and values. The choice of the PRF must be done in keeping with the security properties of the desired key and the desired level of security. Also, the MAC algorithm used in the creation of the AUTH value must be taken into consideration to determine the length of the HK and the HIK required. 7.3. Replay Protection The proposed protocol uses timestamp based replay protection between the MN and the Handover Key server. The timestamp is verified at the server to be within a certain value of the server's time. Timestamp based replay protection allows the server to be stateless and yet allow a single-roundtrip protocol. When the clocks are not synchronized, this may result in two roundtrips - however, with synchronized clocks, the protocol operates in one roundtrip. 7.4. IP Address Authorization For FMIPv6 operation, the access router must ensure that a mobile node cannot redirect traffic belonging to any other node. For this purpose, the access router must bind the handover key of a mobile node to its care-of-address. The AR must ensure that the CoA claimed by the MN does not belong to any other node. Narayanan, et al. Expires September 7, 2007 [Page 26] Internet-Draft Handover Keys Using Shared Keys March 2007 IP address authorization may be done in different ways in different networks. For example, where stateful address assignment is used, it is possible for a DHCP server to securely notify the AR (DHCP Relay Agent potentially) of the IP address assigned to the MN. The AR may note the IP address to MN ID mapping at that time. Also, when IPv6CP is used, it is possible for the AR to know the same mapping. When stateless autoconfiguration is used by the MN to obtain a CoA, SeND may be used to protect against the threats of ND in general. It must be noted that this protocol is not attempting to solve the general threats of ND itself. Some other mechanisms may also be available for IP address authorization. For instance, in cellular networks that do not have a broadcast link between the MN and a base station, the packets coming on the link between the MN and BS can be considered valid, since it is an authenticated point-to-point link to the MN. In such a case, SeND is not required to achieve IP address authorization, even for of stateless IP address autoconfiguration. . 7.5. Identity Protection In order to provide identity protection, it may be undesirable to reuse the same NAI as used for network access authentication. For identity protection, it may be desirable to have the server to derive an ephemeral identity at the time of HMK creation that can be used in subsequent creation of handover keys. Such privacy protection mechanisms are outside the scope of this document. 8. IANA Considerations This document requests the assignment of two Mobility header types - one each for the HKReq and HKResp. Further, this document requests IANA to assign the following mobility option types - Handover Nonce Mobility Option, Timestamp Mobility Option and MAC Mobility Option. 9. Acknowledgments The authors would like to thank Lakshminath Dondeti for helping with discussions leading to key derivation in this document. The authors would like to thank Rajeev Koodli and Mohan Parthasarathy for their reviews and comments on earlier versions of this document. The authors would like to thank James Kempf for helping with the design of the Mobility Header messages and for his help in several discussions that helped the design of the protocol itself. The authors would like to thank, in alphabetical order of last names, Mike Korus, Madjid Nakhjiri and George Popovich for their discussions, reviews and comments on the early versions of this Narayanan, et al. Expires September 7, 2007 [Page 27] Internet-Draft Handover Keys Using Shared Keys March 2007 document. In addition, Julien Bournelle would like to thank GET/INT since he began to work on this document while he was employed there. 10. References 10.1. Normative References [1] Koodli, R., "Fast Handovers for Mobile IPv6", draft-ietf-mipshop-fmipv6-rev-00 (work in progress), April 2006. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005. [4] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992. [5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [7] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [8] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 10.2. Informative References [9] Loughney, J., "Context Transfer Protocol", draft-ietf-seamoby-ctp-11 (work in progress), August 2004. [10] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005. [11] Housley, R. and B. Aboba, "Guidance for AAA Key Management", draft-housley-aaa-key-mgmt-09 (work in progress), February 2007. Narayanan, et al. Expires September 7, 2007 [Page 28] Internet-Draft Handover Keys Using Shared Keys March 2007 [12] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, March 2005. [13] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [14] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. Authors' Addresses Vidya Narayanan Qualcomm, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-2483 Email: vidyan@qualcomm.com Narayanan Venkitaraman Motorola Labs 1301 E. Algonquin Road Schaumburg, IL 60196 US Email: narayanan.venkitaraman@motorola.com Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@siemens.com Narayanan, et al. Expires September 7, 2007 [Page 29] Internet-Draft Handover Keys Using Shared Keys March 2007 Gerardo Giaretta TILab via G. Reiss Romoli, 274 TORINO 10148 Italy Email: gerardo.giaretta@telecomitalia.it Julien Bournelle France Telecom R&D 38-4O rue du general Leclerc Issy-Les-Moulineaux 92794 France Email: julien.bournelle@orange-ftgroup.com Narayanan, et al. Expires September 7, 2007 [Page 30] Internet-Draft Handover Keys Using Shared Keys March 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, et al. Expires September 7, 2007 [Page 31]