MIP6 Working Group F. Dupont Internet-Draft ISC Expires: May 17, 2008 J-M. Combes Orange Labs/France Telecom R&D November 14, 2007 Using IPsec between Mobile and Correspondent IPv6 Nodes draft-ietf-mip6-cn-ipsec-06.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 May 17, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Mobile IPv6 uses IPsec to protect signaling between the Mobile Node and the Home Agent. This document defines how IPsec can be used between the Mobile Node and Correspondent Nodes for Home Address Option validation and protection of mobility signaling for Route Optimization. The configuration details for IPsec and IKE are also provided. Dupont & Combes Expires May 17, 2008 [Page 1] Internet-Draft Using IPsec between MN and CN November 2007 1. Introduction Mobile IPv6 documents [RFC3775][RFC3776][RFC4877] specify IPsec [RFC4301] for the protection of the signaling between the Mobile Node (MN) and its Home Agent (HA), and the return routability procedure between the Mobile Node and its Correspondent Nodes (CN) for Route Optimization. This document defines an alternative mechanism for Mobile IPv6 route optimization based on strong authentication and IPsec. It specifies which IPsec configurations can be useful in a Mobile IPv6 context and how they can validate Home Address Options (enabling triangular routing) and protect mobility signaling (enabling Route Optimization). It gives detailed IKE [RFC2409][RFC4306] configuration guidelines for common cases. Note when the design goal of the return routability procedure was to be "not worse than the current Internet", the design goal of this document is "not worse than deployed IPsec". 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 [RFC2119]. IKE terminology is copied from IKEv2 [RFC4306]. 2. Applicability The purpose of this document is not to replace the return routability procedure, specified in [RFC3775], by the use of IPsec/IKE. It is unrealistic to expect credentials to be available today for strong authentication between any pair of Internet nodes. The idea is to enable the use of the superior security provided by IPsec when it is already in use (i.e., comes at no extra cost), when obstacles (i.e., authentication) to its use no more stand in the way, or simply when it can be considered as highly desirable. This mechanism should only be turned on by explicit configuration between specific peers. This explicit configuration involves turning on the mechanism specified in this document and turning off the Mobile IPv6 Return Routability mechanism. It does not support automatic capability negotiation at this time. It is expected that certificate enrollment supports the inclusion of the Home Address of a node in the node certificate when the Home Address is known in time. Dupont & Combes Expires May 17, 2008 [Page 2] Internet-Draft Using IPsec between MN and CN November 2007 It is REQUIRED that nodes conforming to this specification implement the base Mobile IPv6 as specified in RFC 3775 [RFC3775] (either in Mobile or Correspondent Node role or in both). 3. IPsec in a Mobile IPv6 context This document considers only suitable IPsec Security Associations, i.e., anything which does not fulfill the following requirements is out of scope: - IPsec Security Association pairs MUST be between the Mobile Node and one of its Correspondent Nodes. - origin authentication, payload integrity and anti-replay services MUST be enabled. - the Traffic Selectors MUST match exclusively the Home Address of the Mobile Node and an address of the Correspondent Node (the address used for communication between peers). - IPsec transport mode MUST be used. - for Route Optimization, the Mobility Header "upper protocol" with at least Binding Update (BU, from the MN) and Binding Acknowledgment (BA, from the CN) message types MUST be accepted by the Traffic Selectors. The purpose of the first three requirements is to allow IPsec to provide a proof of origin. The third one enforces the use of the proper Home Address. 4. Home Address Option validation This document amends the Mobile IPv6 [RFC3775] section 9.3.1 by adding a second way (other than Binding Cache Entry check) to provide Home Address Option validation. When a packet carrying a Home Address Option is protected by a suitable IPsec Security Association, the Home Address Option SHOULD be considered valid. A way to implement this is to mark the Home Address Option as "to be validated" when it is processed. When the upper protocol is reached, in order either: - an IPsec header was processed according to [RFC4301] section 5.2 with a suitable IPsec Security Association, or - a Binding Cache Entry check is successfully performed, or - the packet contains a Binding Update, or - the packet MUST be dropped. By just setting up an IPsec SA with the CN, the MN is able to send Dupont & Combes Expires May 17, 2008 [Page 3] Internet-Draft Using IPsec between MN and CN November 2007 packets directly to the CN, i.e., triangular routing is enabled. The CN does the Home Address Option validation by successful IPsec processing of the packet. The Care-of Address in the source address field of the IPv6 header is not used by IPsec at all as the IPsec policy checks happen against the Home Address. The CN continues to send the packets via the home network until a Binding Update is processed. 5. Route Optimization A suitable IPsec Security Association can protect Binding Updates and Acknowledgments. In Binding Updates the new requirements are: - Nonce Indices and Binding Authorization Data options SHOULD NOT be sent by the Mobile Node and MUST be ignored by the Correspondent Node. - when an Alternate Care-of Address option is present, the alternate Care-of Address MUST match the source address in the IP header or the Home Address itself. Any Binding Update which does not fulfill this requirement MUST be rejected. In Binding Acknowledgments the new requirement is: - Binding Authorization Data option SHOULD NOT be sent by the Correspondent Node and MUST be ignored by the Mobile Node. The use of the K (Key Management Mobility Capability) bit with Correspondent Nodes is not defined. This bit is always set to zero on sending a Binding Update or Binding Acknowledgment, and ignored on receipt. Note that a relatively long lifetime compatible with the IPsec policy (i.e., by default up to the IPsec Security Association lifetime) MAY be used with correspondent registrations, in contrast to the short lifetime required by standard RFC 3775 mechanisms. 6. IKE configurations With mobility the Mobile Node uses at least two addresses so if in general an address of the Mobile Node has to be the Home Address (this section is mostly about such requirements), it is not always the case: for instance when the Mobile Node uses its Home Address as the source of an IKE message, the source address in the IP header it- self can be a Care-of Address. There is place where the Correspondent Node always gets the Home Address, it is the Mobile Node address in the Traffic Selectors (note this is not a new requirement, just a direct consequence of Dupont & Combes Expires May 17, 2008 [Page 4] Internet-Draft Using IPsec between MN and CN November 2007 Section 3.) The Mobile Node MUST put its Home Address in its Traffic Selector payload and the Correspondent Node SHALL get the Home Address as the only address of its peer, the Mobile Node, in the peer Traffic Selector payload. Addresses IKE runs over (aka. the peer addresses) are the addresses seen at the transport or application layer. With this definition, IKE MUST be run over the Home Address for the Mobile Node side when the Home Address is usable. The case where the Home Address in unusable is the subject of Appendix A. The Home Address MAY be used in (phase 1) Mobile Node Identification payloads. But this does not work well with dynamic Home Addresses, so when it is acceptable by the Correspondent Node policy, name based Identification (i.e., of type ID_FQDN or ID_RFC822_ADDR, [RFC4306] section 3.5) payloads SHOULD be used by the Mobile Node. Note the PKI profile for IKE [RFC4945] applies so when the Mobile Node uses an Identification payload with the ID_IPV6_ADDR type, the Mobile Node MUST put the Home Address in it and the Correspondent Node MUST verify that the address in the Identification payload will be the Home Address. When an address appears in a Peer Authorization Database (the PAD, [RFC4301]) related object for the Mobile Node, the Correspondent Node MUST verify the address or one of these addresses is the same than the Home Address, so the third requirement of Section 3 applies only to authorized Home Addresses. For instance, this check is REQUIRED when the Home Address can be the address in an iPAddress field in the SubjectAltName extension [RFC3280] of the Mobile Node certificate; or when the Home Address can be the address used to lookup a pre-shared key. If the Home Address is not assigned dynamically by the Home Agent, the Home Address SHOULD appears in such a PAD related object for the Mobile Node. Note that the PAD was designed to provide such binding of addresses to peers ([RFC4301] at the end of the section 4.4.3.4) and this can be described directly in the PAD or indirectly by peer authentication/authorization data like an transmitted end system valid certificate. 7. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an Dupont & Combes Expires May 17, 2008 [Page 5] Internet-Draft Using IPsec between MN and CN November 2007 RFC. 8. Security Considerations The Mobile IPv6 Route Optimization security design background document [RFC4225] describes the unauthorized creation of Binding Cache entries as the main avenue of attack. The authentication and authorization of the Mobile Node provided by IPsec/IKE is a strong defense against this threat. Where the means to create suitable IPsec security associations exist, this mechanism provides origin authentication, integrity protection, replay protection and optional confidentiality services for the Mobile IPv6 signaling. This improves the security over RFC 3775 route optimization, as the signaling packets in the latter are vulnerable to man-in-the-middle attacks. The implications of this vulnerability are that an attacker performing the man-in-the-middle attack can have access to the security material needed to create MIPv6 signaling instead of the Mobile Node. On the other hand, an attacker in the same position is also capable of seeing all the payload packets and could launch other attacks with similar implications. For instance, such an attacker could see or modify the contents of payload packets not protected with end-to-end security and cause denial-of-service for others. However, the RFC 3775 mechanism allows such attacks in a short time window even after the attacker is no longer in a position to see the payload packets themselves. The mechanism defined in this specification removes this vulnerability. However, unlike RFC 3775 this mechanism should only be used when the correspondent node has good reason to trust the actions of the mobile node. In particular, the correspondent node needs to be certain that the mobile node will not launch flooding attacks against a third party as described in [RFC4225]. Without such trust the only protection comes from the application of ingress filtering in the network where the attacker resides. However, at the moment ingress filtering has not been universally deployed. This mechanism is vulnerable to flooding attacks as it does not verify the validity of a claimed new care-of address. Note, however, the following: - The attacker has to be the Mobile Node itself, i.e., the IPsec/IKE peer, which is supposed to be the subject of a minimal level of trust. - The attack can be easily traced back to the Mobile Node. In order to avoid granting extra privileges by a side effect, the application of this mechanism must not lead to allowing any new, previously unauthorized traffic to flow between the peers beyond Dupont & Combes Expires May 17, 2008 [Page 6] Internet-Draft Using IPsec between MN and CN November 2007 mobility signaling with the Mobility Header (MH) protocol. The IPsec peer policy MAY also restrict IPsec Security Associations to the protection of Mobile IPv6 signaling, i.e., restrict the Traffic Selectors to MH with at least Binding Update and Binding Acknowledgment message types. Although the protection of static addresses is not mandatory in IPsec or Home Addresses do not introduce a specific issue, this document requires authorized Home Addresses when the check is possible, and recommends to make the check possible for static Home Addresses. This protects a Mobile Node using a static so likely known Home Address against the theft of its Home Address, both when the security associations are established and without limitations when they are used. 9. Acknowledgments The authors would like to thank many people for believing in IPsec as a right way to secure Mobile IPv6. Special thanks to Wassim Haddad and Claude Castelluccia for keeping our attention to special cases where Home Addresses are derived from public keys. Thanks to Mohan Parthasarathy for the peer address clarification. 10. Possible enhancements A number of potential enhancements of this method are possible, including, for instance, various mechanisms for verification of Care-of Addresses or use of addresses bound to keys. [RFC4651] describes many proposals for the general Route Optimization problem. [I-D.dupont-mipv6-rrcookie] is an alternate approach to testing Care-of Addresses. When the Home Address is bound to a public key, for instance when the Home Address is a Cryptographically Generated Address [RFC3972], [I-D.laganier-ike-ipv6-cga] describes an alternative approach to the use of strong authentication. 11. Changes from the previous version To be removed prior to publication as an RFC. The support of the base Mobile IPv6 is required. The Home Address authorization must be performed when possible, and Dupont & Combes Expires May 17, 2008 [Page 7] Internet-Draft Using IPsec between MN and CN November 2007 the conditions of this "when possible" should be fulfilled by the configuration if the Home Address is not dynamically assigned by the Home Agent. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. [RFC4945] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007. 12.2. Informative References [I-D.dupont-mipv6-rrcookie] Dupont, F. and J-M. Combes, "Care-of Address Test for MIPv6 using a State Cookie", draft-dupont-mipv6-rrcookie-05.txt (work in progress), November 2007. Dupont & Combes Expires May 17, 2008 [Page 8] Internet-Draft Using IPsec between MN and CN November 2007 [I-D.laganier-ike-ipv6-cga] Laganier, J. and G. Montenegro, "Using IKE with IPv6 Cryptographically Generated Addresses", draft-laganier-ike-ipv6-cga-02.txt (work in progress), July 2007. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005. [RFC4651] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization", RFC 4651, February 2007. [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007. Appendix A. IKE running over a Care-of Address In special circumstances where the Home Address can be unusable, as when the Home Address is ORCHID [RFC4843] based and not routable, IKE must be run over a Care-of Address but this has many known drawbacks: - a Care-of Address can not be used for authentication nor authorization. - Security Associations do not survive handoffs. - the establishment of transport mode IPsec Security Association using the Home Address as the Mobile Node Traffic Selector raises a policy / authorization issue as IKE runs over another address. Authors' Addresses Francis Dupont ISC Email: Francis.Dupont@fdupont.fr Dupont & Combes Expires May 17, 2008 [Page 9] Internet-Draft Using IPsec between MN and CN November 2007 Jean-Michel Combes Orange Labs/France Telecom R&D 38 rue du General Leclerc 92794 Issy-les-Moulineaux Cedex 9 France Email: jeanmichel.combes@gmail.com Dupont & Combes Expires May 17, 2008 [Page 10] Internet-Draft Using IPsec between MN and CN November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Dupont & Combes Expires May 17, 2008 [Page 11]