James Kempf Internet Draft DoCoMo Labs USA Document: draft-kempf-mobopts-handover-key-01.txt Rajeev Koodli Nokia Research Center Expires: January, 2006 July, 2005 Bootstrapping a Symmetric IPv6 Handover Key from SEND Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. 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 November 16, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract Multiple IPv6 handover optimization protocols (for example, Fast Mobile IPv6 and Context Transfer Protocol) require an Access Router to verify that signaling received to perform an IP handover operation originated from a Mobile Node having authorization to claim a particular address on the Access Router's wireless subnet. In this document, a method for securing such signaling is defined. The method utilizes a secret key sent from the Access Router to the Mobile Node prior to handover, encrypted with an RSA public key that the Mobile Node used to generate its Cryptographically Generated Address. The ability of the Mobile Node to decrypt the secret key verifies its possession of the private key corresponding to the public key used to generate the address. This allows the Mobile Node to use the secret key to sign and authorize signaling causing changes affecting traffic to and from that address. The use of symmetric cryptography avoids the time consuming public key operation associated with using the RSA key directly during performance-sensitive IP subnet handover. Table of Contents Kempf Expires January, 2006 [Page 1] Internet Draft FMIP Security July, 2005 1.0 Introduction.....................................................2 2.0 IP Handover Signaling Protocols Requiring Authorization..........2 3.0 Brief Review of SEND.............................................3 4.0 Handover Key Generation and Use..................................4 5.0 Handover Key Option..............................................6 6.0 Security Considerations..........................................6 7.0 IANA Considerations..............................................6 8.0 Normative References.............................................6 9.0 Informative References...........................................7 10.0 Author Information...............................................7 11.0 Full Copyright Statement.........................................7 12.0 Intellectual Property............................................8 13.0 Acknowledgement..................................................8 1.0 Introduction In IPv6 handover optimization, certain operations to a Mobile Node's (MN's) previous Access Router (AR) during IPv6 subnet handover require signaling from the MN undergoing handover. The signaling requests that the AR perform operations affecting traffic to and from the MN's previous address on the AR's wireless subnet. These operations are done to ensure that the MN's traffic continues to be delivered while the MN is changing its Mobile IP home address. In order to avoid masquerading attacks, such signaling needs to be secured so that the AR can verify the authorization of the sender to perform operations affecting the address. In this document, a lightweight mechanism is defined by which such operations can be secured. The mechanism utilizes a shared handover key sent from the AR to the MN prior to handover, encrypted with the public key utilized by the MN to generate a Cryptographically Generated Address (CGA) (called here the CGA public key) in the SEND protocol [SEND]. In SEND, the CGA key is used to authorize possession of an address, and, thereby, to perform operations associated with the address. The connection between the address and the CGA public/private key pair is called the key pair's CGA property. The shared handover key derives its authorization potential from the ability of the MN to decrypt the handover key using the CGA private key. Handover keys are an instantiation of the purpose built key architectural principle [PBK]. 2.0 IP Handover Signaling Protocols Requiring Authorization 2.1 FMIPv6 The FMIPv6 protocol [FMIP] defines a message, called Fast Binding Update (FBU), by which a MN can quickly signal its new care-of address to its previous AR before or after a handover between IPv6 subnets. The previous AR then constructs a tunnel to the new care-of address, so that traffic packets for the MN delivered to the old care-of address Kempf Expires January 2006 [Page 2] Internet Draft FMIP Security July, 2005 flow to the new care-of address while the MN changes its home address to care-of address binding at the Home Agent, and while the MN performs route optimization with Correspondent Nodes, both time consuming operations. Use of FMIPv6 reduces the number of packets dropped during IP subnet handover. In Section 8 of [FMIP], security threats to FMIPv6 signaling are identified. Unless the previous AR can authenticate that the FBU comes from a MN authorized to change the routing for the old care-of address, it is possible for an attacker to redirect a victim MN's traffic, for purposes of denial of service or to steal the victim's traffic. Section 8 of [FMIP] specifies no mechanism by which the threat can be countered, leaving the mechanism open for further study. 2.2 CTP The Seamoby Context Transfer Protocol (CTP) [CTP] defines a message, called Context Transfer Activate Request (CTAR) which a MN sends to its new AR (and can send to its previous AR) to start context transfer from the previous AR to the new AR. Context transfers are used to speed establishing routing treatments (such as QoS) that were originally established on the previous AR, and therefore involve routing properties associated with a particular address. The CTAR message contains an authorization token field that is calculated using a shared key between the MN and AR. Section 2.5.1 of [CTP] describes how to calculate the authorization token, but the CTP document does not specify how to establish the shared key. 3.0 Brief Review of SEND While the extent of its ultimate deployment is as yet unclear, it seems likely that the SEND protocol [SEND] may ultimately be widely deployed on mobile, wireless IPv6 networks. SEND protects against a variety of threats to local link address resolution (also known as Neighbor Discovery) and last hop router (AR) discovery in IPv6 [RFC3756]. These threats are not exclusive to wireless networks, but they generally are easier to mount on wireless networks because the link between the access point and MN can't be physically secured. SEND utilizes CGAs in order to secure Neighbor Discovery signaling [CGA]. Briefly, a CGA is formed by taking the IPv6 subnet prefix for a node's subnet and combining it with an interface identifier suffix formed as the hash of the node's public key. The public key is used to sign a Neighbor Advertisement message sent to resolve the link layer address to the IPv6 address. The combination of the CGA and the signature on the Neighbor Advertisement proves to a receiving node the sender's authorization to claim the address. The node may opportunistically generate one or several keys specifically for SEND, or it may use a certified key that it distributes more widely. In any case, this document refers to the public key/private key pair used for CGA generation as the CGA key pair, and the authorization to claim a CGA as the key's CGA property. Kempf Expires January 2006 [Page 3] Internet Draft FMIP Security July, 2005 4.0 Handover Key Generation and Use 4.1 Mobile Node Considerations At some time prior to handover, the MN sends an IPv6 Router Solicitation (RS) [RFC2461] exactly as specified for IPv6 Router Discovery. The CGA for the MN is the source address on the packet, and the MN includes the SEND CGA Option and SEND Signature Option with the packet, as specified in [SEND]. Receiving routers reply directly to the CGA with a Router Advertisement (RA) and include a Handover Key Option (defined here in Section 5.0) containing the encrypted, shared handover key. The MN chooses an AR, decrypts the handover key with its CGA private key, and stores the associated handover key for later use. The lifetime and size of the handover key depend on the lifetime of the address and the application. The handover key lifetime depends on the lifetime of the CGA key [CGA], which, in turn, is determined by the lifetime of the address. The CGA key and handover key should be renewed when the preferred lifetime of the address expires and must be renewed if the valid lifetime of the address expires [RFC2462]. The lifetime also depends on the strength of the key. For MIPv6 (and thus FMIPv6), the usual length of Kbm for return routability purposes is 20 octets [MIP6]. For CTP, the key length is variable [CTP], but should also be on the order of 16 to 20 octets, to prevent guessing attacks. When a handover occurs or is about to occur and the MN needs to signal the previous AR, the MN generates a message authentication code using the handover key. Exactly how the message authentication code is generated depends on the protocol. For the specific examples given in Section 2.0: o For FMIPv6, the message authentication code is generated as a Binding Authorization Data Mobility Option for the FBU, as described in Section 6.2.7 of [MIP6], with the handover key used as Kbm. The MN includes an IP Address Mobility Option with the previous care-of CGA, to identify the key. o For CTP, the authorization token is generated using the handover key as Key in the token calculation algorithm described in Section 2.5.1 of [CTP]. 4.2 Access Router Considerations When an AR capable of handover optimization receives a RS from a MN including a CGA Option and a Signature Option, and the source address is an IPv6 global unicast address, the AR verifies the signature and CGA as described in [SEND]. If the signature and CGA verify, the AR then constructs a shared handover key and encrypts the handover key with the MN's CGA public key. The AR inserts the encrypted handover key into a Handover Key Option and attaches the Handover Key Option to the Router Advertisement (RA), which is then unicast back to the CGA. The handover key is stored by the AR, indexed by the CGA, for future use. Unless the MN renews the key with another RS, the AR discards the handover key when the CGA's valid lifetime expires. Kempf Expires January 2006 [Page 4] Internet Draft FMIP Security July, 2005 When the AR receives an IPv6 handover optimization signaling message associated with a particular address on the wireless link and containing a message authentication code, the AR looks up the handover key using the address. If a match is found, the AR utilizes the handover key to verify the message authentication code. For the specific examples given in Section 2.0: o For FMIPv6, the Binding Authorization Data Mobility Option for the FBU contains the message authentication code, as described in Section 6.2.7 of [MIP6]. The AR obtains the CGA for the MN's previous care-of address from the IP Address Mobility Option in the FBU, and uses that address to look up the handover key. The AR utilizes the handover key as Kbm to verify the message authentication code. o For CTP, the previous AR includes the handover key associated with the MN's previous IP address when it sends a Predictive Context Transfer Data message (PCTD), described in Section 2.5.3 of [CTP]. Both the previous AR and new AR additionally use the handover key to verify the authorization token included in a CTAR from the MN or CT-Req message from the new AR. 4.3 Possible Alternatives and Their Drawbacks One alternative mechanism is to use the CGA key directly, by signing the optimization protocol messages with an RSA-generated signature using the CGA key. This mechanism has a technical drawback when applied to the handover optimization protocols. Because RSA is a public key algorithm, verification of the signature is more time consuming than for a shared key signature. Since the handover optimization protocols are primarily for performance optimization, it seems appropriate to design the security mechanism in a way that minimizes the amount of time required for processing during handover. Additionally, the handover optimization protocols typically define their verification signatures as message authentication codes using shared keys. Use of a public key signature would require addition of new verification algorithms to the handover optimization protocols, rather than simply using the existing algorithms, so a shared key has a higher degree of backwards compatibility. An alternative mechanism that uses shared keys but a different key provisioning mechanism is Diffie-Hellman key agreement [RFC2631]. The drawback of Diffie-Hellman key agreement is that it is subject to man- in-the-middle attacks in the absence of certified keys. Provisioning end hosts with certificates is a difficult deployment challenge that has yet to become widespread. In contrast, the CGA key, on which the handover key is based, requires no certificate. The handover key mechanism described in this document establishes the key's authorization potential via the CGA property of the CGA key pair used to encrypt and decrypt the handover key, thereby tying it definitively to the address. Kempf Expires January 2006 [Page 5] Internet Draft FMIP Security July, 2005 5.0 Handover Key Option The Handover Key Option is a standard IPv6 Neighbor Discovery option in TLV format. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Key Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encrypted Handover Key . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type: To be assigned by IANA. Length: The length of the option in units of 8 octets, including the type and length fields. Key Length: Length of the encrypted handover key, in units of octets. Encrypted Key: The encrypted handover key. The option is padded to an 8 octet boundary, as required for IPv6 Neighbor Discovery Protocol options. 6.0 Security Considerations This document describes a security protocol for the IPv6 handover optimization protocols. The protocol utilizes the CGA key of SEND to bootstrap a shared key for authorizing changes due to handover associated with the MN's former address on the wireless interface of the AR. General security considerations involving CGAs apply to the protocol described in this document, see [CGA] for a discussion of security considerations around CGAs. 7.0 IANA Considerations A new IPv6 Neighbor Discovery option, the Handover Key Option, is defined, and requires a type code from IANA. 8.0 Normative References [SEND] Arkko, J., et. al., "SEcure Neighbor Discovery (SEND)", Internet Draft, work in progress. [RFC3756] Nikander, P., editor, Kempf, J., and Nordmark, E., " IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. Kempf Expires January 2006 [Page 6] Internet Draft FMIP Security July, 2005 [CGA] Aura, T., "Cryptographically Generated Addresses", Internet Draft, work in progress. [RFC2461] Narten, T., and Nordmark, E., "Neighbor Discovery for IP version 6 (IPv6)", RFC 2461, December 1998. [RFC2462] Thomas, S., and Narten, T., "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. 9.0 Informative References [PBK] Bradner, S., Mankin, A., and Schiller, J., "A Framework for Purpose-Built Keys (PBK)", Internet Draft, work in progress. [FMIP] Koodli, R., editor, "Fast Handovers for Mobile IPv6", Internet Draft, work in progress. [CTP] Loughney, J., editor, et. al. "Context Transfer Protocol", Internet Draft, work in progress. [MIP6] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in IPv6", Internet Draft, work in progress. [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement", RFC 2631, June 1999. 10.0 Author Information James Kempf Phone: +1 408 451 4711 DoCoMo Labs USA Email: kempf@docomolabs-usa.com 181 Metro Drive Suite 300 San Jose, CA 95110 USA Rajeev Koodli Phone: +1 650 625 2359 Nokia Research Center Fax: +1 650 625 2502 313 Fairchild Drive Email: Rajeev.Koodli@nokia.com Mountain View, CA 94043 USA Kempf Expires January 2006 [Page 7] Internet Draft FMIP Security July, 2005 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. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 (2004). 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. Kempf Expires January 2006 [Page 8]