Mipshop V. Narayanan Internet-Draft Qualcomm, Inc. Expires: October 28, 2006 N. Venkitaraman Motorola Labs H. Tschofenig Siemens G. Giaretta TILab J. Bournelle GET/INT April 26, 2006 Handover Keys Using AAA draft-vidya-mipshop-handover-keys-aaa-02.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 October 28, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes a AAA-assisted key management protocol to Narayanan, et al. Expires October 28, 2006 [Page 1] Internet-Draft Handover Keys Using AAA April 2006 generate a handover key between a mobile node (MN) and an access router (AR) for the purpose of securing 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 idea is that the key derived between a mobile node and an access router through this protocol can be used in fast handovers. Narayanan, et al. Expires October 28, 2006 [Page 2] Internet-Draft Handover Keys Using AAA April 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Goals, Assumptions and Requirements . . . . . . . . . . . . . 5 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Mobility Header Types . . . . . . . . . . . . . . . . . . 8 5.1.1. Handover Key Request (HKReq) . . . . . . . . . . . . . 8 5.1.2. Handover Key Response (HKResp) . . . . . . . . . . . . 10 5.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 13 5.2.1. Handover Nonce Mobility Option . . . . . . . . . . . . 13 5.2.2. Message Authentication Code (MAC) Mobility Option . . 14 5.2.3. Timestamp Mobility Option . . . . . . . . . . . . . . 15 6. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 16 6.1.1. Handover Integrity Key Derivation . . . . . . . . . . 17 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. AAA Server Considerations . . . . . . . . . . . . . . . . 24 6.5. Indirect MN-AR Handover Key Exchange . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7.1. Strength of the HMK . . . . . . . . . . . . . . . . . . . 26 7.2. Strength of the HIK and HK . . . . . . . . . . . . . . . . 26 7.3. Replay Protection . . . . . . . . . . . . . . . . . . . . 27 7.4. IP Address Authorization . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 Appendix A. RADIUS Handover Key Attributes . . . . . . . . . . . 29 Appendix B. Diameter Handover Key Application . . . . . . . . . . 31 B.1. New Messages . . . . . . . . . . . . . . . . . . . . . . . 31 B.2. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 B.3. Diameter Flow of Messages . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Intellectual Property and Copyright Statements . . . . . . . . . . 34 Narayanan, et al. Expires October 28, 2006 [Page 3] Internet-Draft Handover Keys Using AAA April 2006 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 AAA-assisted key management protocol to generate session keys between a mobile node and an access router for usage in the context of FMIPv6. As such, it specifies: o A message exchange between the MN and the AR o Payloads to carry keying material and parameters in the AAA infrastructure 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 PAR as specified in FMIPv6 [1]. Other protocols may also use this mechanism as noted below. For instance, CxTP [9] can also use this protocol to derive keys between the AR and MN to secure the CTAR message. Additionally, keys between an MN and a MAP can be derived using this protocol for 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 October 28, 2006 [Page 4] Internet-Draft Handover Keys Using AAA April 2006 MN-AAA Handover Master Key (HMK): A key that is shared between the Mobile Node and the AAA server, hereby referred to simply as the Handover Master Key. The HMK is never used directly to protect any messages. MN-AAA Handover Integrity Key (HIK): A key that is shared between the Mobile Node and the AAA server, hereby referred to simply as the Handover Integrity Key. The HIK is derived from the HMK and is used for authenticating the HKReq/ HKResp messages between the MN and the AAA server. Handover Key (HK): Session key used to secure messages between the Mobile Node and Access Router. A given HK between an MN and ARn is termed as HKn. 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 leverage the existence of AAA infrastructure to establish session keys for securing FMIPv6 signaling messages. AAA protocols are widely deployed today due to the usage of AAA-based network access authentication. The AAA server is used to authenticate and authorize the MN for fast handovers prior to generation of the handover key. The solution presented in this document relies on the AAA infrastructure to derive and distribute keying material for handover support. o The protocol must be able to provide separation of the keys used for integrity protection and the derivation of the handover keys. For this purpose, two keys are derived from the HMK for a given node - the Handover Integrity Key (HIK) and the actual Handover Key (HK). The former is used to create the MAC (Message Authentication Code) in the signaling messages for the key management protocol described in this document and the latter is used for FMIPv6 signaling protection. 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. In order to provide identity protection, it may be undesirable to reuse the same NAI as used for network access authentication. For sake of identity protection, it may be Narayanan, et al. Expires October 28, 2006 [Page 5] Internet-Draft Handover Keys Using AAA April 2006 desirable to have the AAA 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. 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. o It is imperative that the handover key derivation does not impact handoff latency. The protocol does not introduce any new required steps at the time of handover. Any new messages introduced for deriving handover keys can be exchanged prior to the handover process, thereby not impacting 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 AAA server directly to the AR requesting it. o A Handover Master Key (HMK) between the MN and the AAA 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 AAA 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 AAA server. For the purpose of the protocol itself, the HMK may simply be a handover specific master key pre-shared between the MN and the AAA server. A Handover Integrity Key (HIK) is derived from the HMK at the MN and AAA server. The HIK is used to provide integrity protection to messages exchanged by the MN and the AAA 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. Narayanan, et al. Expires October 28, 2006 [Page 6] Internet-Draft Handover Keys Using AAA April 2006 MN AR AAAH 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, a sequence number 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-AAA 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 AAA Server. The MAC in the HKReq allows the AAA 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, AAA Nonce | MN Nonce | AR1 ID | MN ID | "Handover Key"), where | indicates concatenation The AR1 ID is the 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 AAA and MN Nonces are nonces generated by the AAA 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 AAA Server then sends two different parameters to AR1 - one of the parameters includes the key HK1 and the lifetime associated with it. The other parameter, to be sent to the MN, includes the AAA Nonce. The message Narayanan, et al. Expires October 28, 2006 [Page 7] Internet-Draft Handover Keys Using AAA April 2006 is protected with the AR1-AAA SA when forwarded to AR1. AR1 sends a Handover Key Response (HKResp) to the MN, including the material (nonce) sent by the AAA server and also the key lifetime it received from the AAA 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. 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. The description of AAA attributes that are needed for this protocol are described in the Appendices. Appendix A provides the attributes for RADIUS and Appendix B describes a Diameter handover application. 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 October 28, 2006 [Page 8] Internet-Draft Handover Keys Using AAA April 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |v|PRF|Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Key Care of Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Suboptions (variable) . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Handover Key Request HKReq Fields Message Type A one octet field indicating the handover key exchange mechanism encoded in the mobility options, the value of which is taken from the IANA Handover Key Exchange Mechanism Type registry. A value of '1' (to be assigned by IANA) indicates AAA-assisted handover key exchange. Other key exchange protocols defined in future may define additional values. v Verify flag. This is set by the MN to indicate that it may already share a key with the AR. 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 October 28, 2006 [Page 9] Internet-Draft Handover Keys Using AAA April 2006 Message ID A two octet random value used to uniquely match requests and responses and identify retransmissions. Sequence # A two octet unsigned integer used by the AR in combination with the message ID to detect retransmissions and replays. 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 October 28, 2006 [Page 10] Internet-Draft Handover Keys Using AAA April 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |v|PRF|Reserved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Handover Key Response HKResp Fields Message Type A one octet field indicating the key exchange mechanism encoded in the mobility options, the value of which is taken from the IANA Handover Key Agreement Mechanism Type registry. A value of '1' (to be assigned by IANA) indicates AAA-assisted handover key exchange. Other key exchange protocols defined in future may define additional values. 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 AAA server used for key generation. This is the algorithm used in the derivation of HIK and HK from the HMK. If the AAA 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. Narayanan, et al. Expires October 28, 2006 [Page 11] Internet-Draft Handover Keys Using AAA April 2006 Reserved Set to 0; ignored on reception. Message ID A two octet random value used to uniquely match requests and responses and identify retransmissions. This value is copied from the corresponding HKReq. Sequence # A two octet unsigned integer from the matching HKReq that triggered this message. Status Code One octet status code indicating the status of the request. 0 - Success. 129 - HKE_NOT_SUPPORTED. 130 - CoA_AUTH_FAILED 131 - ADMINISTRATIVELY_PROHIBITED. 132 - HK_VERIFY_FAILED 133 - MN_AR_MAC_REQD 134 - INVALID_AUTH_VALUE 135 - TIMESTAMP_REQD 136 - INVALID_PRF_ALG 137 - INVALID_MAC_ALG 138 - INVALID_TIMESTAMP Lifetime Lifetime of the handover key, in seconds. Narayanan, et al. Expires October 28, 2006 [Page 12] Internet-Draft Handover Keys Using AAA April 2006 SPI Four octet Security Parameter Index for the handover key at the AR. The SPI is used by the MN and the AR to identify the key when the key is used. 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 5.2.1. Handover Nonce Mobility Option This new mobility option is defined to carry the nonce generated by the MN or the AAA 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 4: Handover Nonce Mobility Option Option Fields Option Type Handover Nonce (to be assigned by IANA) Narayanan, et al. Expires October 28, 2006 [Page 13] Internet-Draft Handover Keys Using AAA April 2006 Option Length 8-bit unsigned integer, representing the length in octets of the Sub-type, and the handover nonce fields. Sub-type '1' - AAA-Nonce (nonce generated by the AAA 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 AAA server. 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 5: Authentication Mobility Option Option Fields Option Type MAC Option (to be assigned by IANA) Narayanan, et al. Expires October 28, 2006 [Page 14] Internet-Draft Handover Keys Using AAA April 2006 Option Length 8-bit unsigned integer, representing the length in octets Sub-type '1' - MN-AAA MAC Option (authentication between MN and AAA 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. Reserved Set to 0 and ignored on reception. AUTH Value This field is calculated using the HIK for the MN-AAA option and using the HK for the MN-AR 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 6: Timestamp Mobility Option Narayanan, et al. Expires October 28, 2006 [Page 15] Internet-Draft Handover Keys Using AAA April 2006 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. 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 AAA 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 AAA server. If the timestamp is invalid, the AAA 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 AAA server. 6.1. Key Derivation As mentioned earlier, the MN and the AAA server share a key for the purpose of handover key derivation, called the Handover Master Key Narayanan, et al. Expires October 28, 2006 [Page 16] Internet-Draft Handover Keys Using AAA April 2006 (HMK). The HMK may be a pre-shared key or may be derived between the MN and AAA 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 or derive handover keys. The HMK is only used to derive the Handover Integrity Key (HIK) and the Handover Key (HK). The HMK must be updated periodically to allow the derivation of cryptographically strong handover keys. The MN and the AAA 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 AAA server in the HKReq message. The AAA 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). 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. These lengths are dependent on the MAC algorithm and the PRF chosen. For instance, if the HIK required is a 256-bit key and the PRF used yields 160-bit keys, the HIK will come from T1 and the beginning of T2. Y is a two-byte hexadecimal value that may differ in different uses of gprf+. Each key derivation procedure below explains the appropriate values of K, S and Y. 6.1.1. Handover Integrity Key Derivation The gprf+ is used as follows to derive the HIK. Narayanan, et al. Expires October 28, 2006 [Page 17] Internet-Draft Handover Keys Using AAA April 2006 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. The actual length of the HIK required is determined by the PRF used in the derivation. Note that the length of the HIK must be sufficient for the MAC algorithm used. Hence, the choice of PRF must be done such that it results in a sufficiently long key that can be used by the MAC algorithm. 6.1.2. Handover Key Derivation The gprf+ is used as follows to derive the HK (where | indicates concatenation). HK = gprf+ (HMK, "MN Nonce | AAA 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 AAA server in the HKReq message. The AAA nonce is generated by the AAA server and communicated to 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 PRF used in the derivation. Note that the length of the HK must be sufficient for the MAC algorithm used in the protection of FMIPv6 signaling. Hence, the choice of PRF must be done such that it results in a sufficiently long key that can be used by the MAC algorithm. More details on the process leading to HK derivation and its usage can be found in sections below. Narayanan, et al. Expires October 28, 2006 [Page 18] Internet-Draft Handover Keys Using AAA April 2006 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, random Message ID and a sequence number also starting at a random value. The MN MUST also derive a fresh MN nonce that will be used in HK derivation and include it in the HKReq. For subsequent retransmissions, the sequence number MUST be incremented by 1 and the Message ID MUST remain the same. In order to obtain absolute 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. A value of 1 indicates HMAC-SHA1. That is the only value presently defined in this document. The HKReq sent by the MN MUST include the MN-AAA MAC Mobility Sub- Option. The AUTH Value in the MN-AAA MAC option shall be calculated as follows: AUTH = prf(HIK, MH Data) The prf used is indicated in the Algorithm Type included in the MAC Mobility Option. At the time of writing of this document, the only value defined is 1 for HMAC-SHA1. 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. 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. Narayanan, et al. Expires October 28, 2006 [Page 19] Internet-Draft Handover Keys Using AAA April 2006 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. It is repeated here for completion. HK = gprf+ (HMK, AAA Nonce| MN Nonce | AR ID | MN ID | "Handover Key"), where | indicates concatenation The AR ID is the IP address of the AR. The MN ID is the NAI of the MN that is sent by the MN in the HKReq message. The AAA Nonce is a nonce generated by the AAA server and included in the HKResp received by the MN. The MN Nonce is the nonce generated by the MN and included in the HKReq message. The PRF used is indicated by the PRF field of the HKResp message. 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 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. If the MN receives a HKResp with the Code set to HKE_NOT_SUPPORTED, it SHOULD use a different key exchange protocol to derive the handover key. 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. If the code is set to MN_AAA_AUTH_REQD, the MN MUST send a new HKReq with the MN AAA Authentication Option included. If the code is set to INVALID_AUTH_VALUE, the MN MUST NOT send any more HKReq messages via that AR. If the code is set to TIMESTAMP_REQD, the MN SHOULD send another HKReq using the Timestamp mobility option. If the code is set to INVALID_TIMESTAMP, the MN SHOULD send another HKReq with the adjusted timestamp value. If the Narayanan, et al. Expires October 28, 2006 [Page 20] Internet-Draft Handover Keys Using AAA April 2006 code is set to INVALID_PRF_ALG, the MN MAY send another HKReq with the PRF Algorithm specified in the HKResp message. If the code is set to INVALID_MAC_ALG in the MN-AAA 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 is a freshly generated random number. However the sequence number value in this HKReq MUST be greater than the sequence number in previous HKReq sent to the AR corresponding to the key. 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 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 verify request is not successful the MN SHOULD create a new MN-AR handover key by sending a HKReq with the MN-AAA Auth option . If the MN receives a HKResp with the code set to HK_VERIFY_FAILED, it SHOULD send another HKReq with the MN-AAA MAC Mobility sub-option to obtain a new handover key via the AAA 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-AAA 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 AAA response corresponding to the HKReq, the AR SHOULD retransmit the HKResp to the MN. If the received message has the same message ID and the sequence number as before, the AR MUST drop the packet. 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 home AAA Server but has not yet received a response from AAA server, the AR MUST silently Narayanan, et al. Expires October 28, 2006 [Page 21] Internet-Draft Handover Keys Using AAA April 2006 discard the retransmitted request from the MN. Note that the AAA protocol should independently perform its own retransmission. If this is a new HKReq, the AR MUST check to determine if the MN-AAA 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 home AAA 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 AAA server only after successful validation of the CoA. 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 AAA message is constructed using the appropriately defined attributes (illustrated in Appendix A for RADIUS and Appendix B for Diameter). While creating the AAA request message, the AR MUST include the NAS-IP-Address AVP in the AAA message (e.g. RADIUS Access Request) sent to the AAA server. The AR MUST use its IP address as seen by the MN in this AVP. This will be used as the AR ID in deriving the handover key. The domain name in the NAI is used to determine the AAA server to be contacted. If the AR receives a successful AAA response (e.g., RADIUS Access Accept) message from the AAA server, it MUST store the handover key received from the AAA server along with the CoA and MN ID and index it additionally with an SPI. The AR MUST send the SPI, AAA Nonce and lifetime in the RADIUS message 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 = prf (HK, MH Data) The prf used is indicated in the Algorithm Type included in the MAC Mobility Option. At the time of writing of this document, the only value defined is 1 for HMAC-SHA1. 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-AAA MAC sub-option from the AAA server, it Narayanan, et al. Expires October 28, 2006 [Page 22] Internet-Draft Handover Keys Using AAA April 2006 MUST include that in the HKResp to the MN. If the AR receives an unsuccessful AAA response (e.g., RADIUS Access Reject) message from the AAA server, the AR MUST send an appropriate error code to the MN in the HKResp message. 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 and incremented sequence number. If an AR receives a AAA 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 AAA 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. 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 MN ID to lookup the MN and obtain the key. If a key is present the AR MUST verify the AUTH value in the MAC option. If it is valid, it MUST verify that the sequence number in the HKReq is greater than the value in the sequence number field in the previously received HKReq from the MN for the same key. This ensures that the message is not a replay of a previous message with a verify bit set. If the sequence number check fails the AR MUST silently discard the message. If the sequence number check is successful and 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 in this case, the AR MUST drop the message and return a HKResp with the error code set to "MN_AR_MAC_REQD". Also, if the option was included but the AR was unable to verify the MAC, it MUST drop the message and return a HKResp with the error code set to "INVALID_AUTH_Value". The Narayanan, et al. Expires October 28, 2006 [Page 23] Internet-Draft Handover Keys Using AAA April 2006 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-AAA 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-AAA MAC Mobility Sub-Option, the AR MAY process the HKReq as though the 'V' bit was not set. 6.4. AAA Server Considerations A description of the actual AAA attributes is included in Appendix A and Appendix B. The text in the Appendices are provided for illustration only and these are expected to be specified in separate documents. This section provides a brief description of the operation of the AAA server for this protocol. The discussion is explained with RADIUS as the example AAA protocol, but applies equally to Diameter as well. If the MN cannot be authenticated by the AAA server, it MUST silently discard the HKReq message. If authorization failed for the MN to use FMIPv6 at the AR it is visiting, the AAA server MUST return a response with the code set to ADMINISTRATIVELY_PROHIBITED. If the AAA 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 AAA server, in this case, MUST include an MN-AAA MAC option with the AUTH Value computed using the HIK. The AAA 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 AAA 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 AAA server MUST send an error with the code INVALID_TIMESTAMP and include its timestamp in accordance with Section 5.2.3. The AAA server, in this case, MUST include an MN-AAA MAC option with the AUTH Value computed using the HIK. Upon receiving a handover key request, the AAA server MUST verify that the MN-AAA MAC Mobility Sub-Option is present in the message. If it is absent, the AAA server MUST silently discard the message. Otherwise, the AAA server MUST verify the AUTH Value in the option. If it is invalid, the AAA server MUST silently discard the message. Narayanan, et al. Expires October 28, 2006 [Page 24] Internet-Draft Handover Keys Using AAA April 2006 If it is valid, the AAA server must proceed with the handover key generation described in Section 6.1. If the MAC Algorithm used by the MN is unacceptable, the AAA server SHOULD return an error of type INVALID_MAC_ALG, including an MN-AAA MAC option with the algorithm set to the desired value and the AUTH Value computed using the HIK. If the NAS-IP-Address AVP was not included in the request, the AAA server MUST return an error to the AR, indicating that the NAS-IP- Address is required. The AAA server MUST send a response back to the AR, including the AAA Nonce as well as the derived HK. Note that the AAA protocol is expected to provide its own security between the AR and the AAA server for purposes of encrypting the HK. The AAA server SHOULD include a lifetime for the HK in the RADIUS Access Accept message. The AAA 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 AAA 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 protocol is loosely based on the Mobile IP-AAA model [12] where the MN-HA security association is derived using a AAA server. The handover key protocol described in this document transports the nonce from the AAA server to the MN and the MN derives its own Narayanan, et al. Expires October 28, 2006 [Page 25] Internet-Draft Handover Keys Using AAA April 2006 handover key using the nonce and other parameters. The proposed protocol uses an NAI-like identity of the MN as the identity to derive the handover keys between the MN and AR. This protocol does not provide active or passive user identity confidentiality. If such confidentiality is desired, a service specific identity must be derived as part of the HMK bootstrapping procedure. 7.1. Strength of the HMK The protocol relies on the HMK shared between the mobile node and the AAA server for handover key derivation. It also relies on the security of the AAA protocol (RADIUS or Diameter) used between the AR and the AAA server for HK distribution to the AR. 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 AAA Security Association between the mobile node and the AAA 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 and AAA 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 AAA 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 AAA 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 AAA 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 Narayanan, et al. Expires October 28, 2006 [Page 26] Internet-Draft Handover Keys Using AAA April 2006 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 a sequence number in combination with a message ID to detect retransmissions and replays at the AR. It also allows the use of timestamp based absolute replay protection between the MN and the AAA server. Using the sequence number alone provides limited replay protection. Replay protection is provided as long as there is state corresponding to an MN at the AR. An attacker may, however, cache a HKReq message sent on the link between an MN and AR and replay it at a sufficiently later time when the AR has no state for that MN. In this case, the AR will end up sending a AAA request to the AAA server. The HKReq will be successfully processed by the AAA server in this case, since the authentication data will be valid (as the attacker has not modified anything in the message). The AAA server will create a HK corresponding to this message and will provide it to the AR. However, it must be noted that the MN cannot obtain the HK, because, without the HMK, it cannot derive the key from the nonce. Hence, this scenario does not lead to an adversary using FMIP services on the AR. But, it does result in some minimal resource consumption at the AAA server (for computing the handover key). The assumption from an accounting perspective here is that accounting at the AAA server will not be triggered until the MN actually starts using the FMIP service (in other words, until the MN sends an FBU to the AR). If accounting for FMIPv6 is started based on when the handover key is derived, this issue could result in an MN getting charged for FMIP service due to an adversary. To provide absolute replay protection, the use of a timestamp-based approach using the Timestamp mobility option is recommended. 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. 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. Narayanan, et al. Expires October 28, 2006 [Page 27] Internet-Draft Handover Keys Using AAA April 2006 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. . 8. IANA Considerations TBD: Details will be provided in a future draft version. 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 document. 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. Narayanan, et al. Expires October 28, 2006 [Page 28] Internet-Draft Handover Keys Using AAA April 2006 [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-02 (work in progress), March 2006. [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. Appendix A. RADIUS Handover Key Attributes This section provides an overview of the protocol interaction between the access router and the RADIUS server to request a key for FMIPv6. The proposal assumes that the AAA exchange is authenticated, replay protected, integrity protected and encrypted. For RADIUS, the usage of IPsec between the AR and the AAA server is recommended. The AR acts as a AAA client in order to get a Handover Key in order to secure FMIPv6 signaling messages. This section will eventually be incorporated in a handover key RADIUS extensions document for standardization of the required attributes. Narayanan, et al. Expires October 28, 2006 [Page 29] Internet-Draft Handover Keys Using AAA April 2006 MN AR AAAH Server | HKReq. | | | ---------> | | | | Access Request | | | ----------------------> | | | Access Accept (key mtrl)| | | <----------------------- | | HKResp. | | | <--------- | | Figure 7: RADIUS Messages As shown in Figure 7 the MN sends a HKReq to the AR. This message contains an NAI of the Mobile node and the MN-AAA MAC Option. The AUTH Value in the MAC option is computed with the HIK. The access router forwards the HKReq in a RADIUS Access Request message to the AAA server. This message is sent to the AAA infrastructure. The AR includes at least the IP address used with the MN in the NAS-IP attributes. The message is the following: RADIUS-Access-Request { HK-MN-HKReq NAS-IP (IP Address of the AR) Message Authenticator(80)} The home RADIUS server receives the message and checks the validity of the AUTH Value in the HKReq message. The RADIUS server generates a Nonce of at least 128 bits (AAA Nonce) and computes the Handover Key (HK) as specified in Section 6.1. The RADIUS server answers to the AR by sending a RADIUS-Access- Accept message. RADIUS-Access-Accept{ HK-MN-AR-Key (HK) HK-MN-AR-Key-Lifetime (HK's lifetime) HK-AAA-Nonce (Nonce generated by AAA) Narayanan, et al. Expires October 28, 2006 [Page 30] Internet-Draft Handover Keys Using AAA April 2006 Message Authenticator(80)} If the verification of the AUTH value in the HKReq failed (wrong MN- AAA MAC), the AAA generates a RADIUS Access-Reject message. The AR receives the message, extracts the HK1 and its associated lifetime and creates the HKResp containing the Nonce AAA-MN, the HK1's lifetime and the signed hash. Thus, this proposal needs the following attributes to be defined: o HK-MN-HKReq o HK-MN-AR-Key (HK1) o HK-MN-AR-Key-Lifetime (HK1's lifetime) o HK-AAA-MN-Nonce (Nonce generated by AAAH) It may be possible to reuse some attributes defined for Mobile IPv4 here - such as the MIP-MN-NAI or the MIP-MN-AAA-Authenticator attribute - this possibility will be explored at the time of writing of the handover key RADIUS extensions document. Appendix B. Diameter Handover Key Application To support this proposal a new Diameter application may need to be defined. It needs to be determined if a re-use of the Diameter NASREQ application is feasible with new attributes defined. The intent of this section is to provide an overview of what is needed to support the proposal. Note that the proposal assumes that AAA exchanges between AR and the AAA server is protected. Use of IPsec or TLS is recommended for this purpose. In this section, we describe needed Diameter messages and AVPs. This section will eventually be incorporated in a handover key Diameter extensions document for standardization of the required attributes. B.1. New Messages As for RADIUS, the AR will act as a AAA client and thus as a Diameter client. However, new Diameter command could be defined for this proposal: Narayanan, et al. Expires October 28, 2006 [Page 31] Internet-Draft Handover Keys Using AAA April 2006 o HK-Mobile-Node-Request (HMR) - Command Code (TBD) and 'R' bit set in Command Flags field. This message is sent by AR acting as a Diameter client to a AAA in order to request the handover key for the mobile node. The AR uses the information provided in the HKreq to construct the needed AVPs. o HK-Mobile-Node-Answer (HMA) - The HK-Mobile-Node-Answer (HMA) indicated by the Command-Code field set to TBD and 'R' bit cleared in Command Flags field is sent by the AAAH in response to a HMR message. B.2. AVPs For backward compatibility, attributes defined for RADIUS can be reused within this new Diameter Application. B.3. Diameter Flow of Messages The AAA exchanges between AR and its home AAA server is basically the same as for RADIUS. However, the Diameter application will benefit from all of the advantages that Diameter provides. MN AR AAAH Server | HKReq. | | | ---------> | | | | HMR | | | ----------------------> | | | HMA | | | <----------------------- | | HKResp. | | | <--------- | | Figure 8: Diameter Handover Key Messaging Narayanan, et al. Expires October 28, 2006 [Page 32] Internet-Draft Handover Keys Using AAA April 2006 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 Gerardo Giaretta TILab via G. Reiss Romoli, 274 TORINO 10148 Italy Email: gerardo.giaretta@telecomitalia.it Julien Bournelle GET/INT 9 rue Charles Fourier Evry 91011 France Email: julien.bournelle@int-evry.fr Narayanan, et al. Expires October 28, 2006 [Page 33] Internet-Draft Handover Keys Using AAA April 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Narayanan, et al. Expires October 28, 2006 [Page 34]