MIP6 Working Group V. Devarapalli Internet-Draft M. Parthasarathy Expires: April 19, 2006 Nokia October 16, 2005 Mobile IPv6 Bootstrapping with IKEv1 draft-devarapalli-mip6-ikev1-bootstrap-00.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 April 19, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The current Mobile IPv6 bootstrapping mechanisms require the use of IKEv2 between the mobile node and the home agent. If the Mobile IPv6 signaling messages are protected by IKEv1 and IPsec as described in RFC 3776, then the bootstrapping mechanism based on IKEv2 cannot be used. This document describes a bootstrapping mechanism for Mobile IPv6 when RFC 3776 is used. Devarapalli & Parthasarathy Expires April 19, 2006 [Page 1] Internet-Draft MIP6 Bootstrapping with IKEv1 October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Home Address Configuration . . . . . . . . . . . . . . . . . . 3 3.1. Using ISAKMP MODECFG . . . . . . . . . . . . . . . . . . . 3 3.2. Using DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Association Setup . . . . . . . . . . . . . . . . . . 4 5. Mobile Node's DNS Entry Update . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Devarapalli & Parthasarathy Expires April 19, 2006 [Page 2] Internet-Draft MIP6 Bootstrapping with IKEv1 October 2005 1. Introduction RFC 3775 [2] does not address dynamically configuring a mobile node with the home agent and home address information. Mobile IPv6 bootstrap mechanisms enable a mobile node to dynamically configure a home agent, acquire a home address and setup security associations with the home agent. Such a mechanism is defined in [8]. However, the bootstrap mechanism defined in [8] uses IKEv2 to configure a home address and cannot be used if IKEv1 and IPsec as defined in RFC 3776 [3] is used for protecting the Mobile IPv6 signaling messages. In this document we define a bootstrap mechanism that will work when RFC 3776 is used. With this mechanism a mobile node will be able to configure a home address and dynamically setup security associations with the home agent through IKEv1 [4]. This document does not define a new home agent discovery mechanism. Home agent discovery based in DNS lookup, as described in [8] should be used by the mobile node to discover a home agent. 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 [1]. 3. Home Address Configuration 3.1. Using ISAKMP MODECFG The Home Address can be configured by using the ISAKMP [10] configuration method described in [6]. When the mobile node initiates an IKEv1 exchange with the home agent and wants to configure a home address, it initiates an ISAKMP Transaction exchange as specified in [6]. The transaction exchange MUST occur after an ISAKMP phase 1 security association is already established and before an ISAKMP phase 2 negotiation has started. In the exchange, the mobile node includes an configuration message of the type ISAMKP_CFG_REQUEST with the attribute INTERNAL_IP6_ADDRESS. The address field in the INTERNAL_IP6_ADDRESS attribute should be set to 0::0. When the home agent sees the request for a home address, it allocates a home address and returns in the INTERNAL_IP6_ADDRESS attribute in a ISAKMP_CFG_REPLY message. The home agent can specify the time for Devarapalli & Parthasarathy Expires April 19, 2006 [Page 3] Internet-Draft MIP6 Bootstrapping with IKEv1 October 2005 which the home address is valid through the INTERNAL_ADDRESS_EXPIRY attribute. The mobile node may also configure additional information from the home link like a DNS server and a DHCPv6 server by including the INTERNAL_IP6_DNS and INTERNAL_IP6_DHCP attributes in the ISAKMP_CFG_REQUEST message. 3.2. Using DHCPv6 The mobile node can run DHCPv6 [9] over the initial IPsec tunnel with the home agent and configure a home address. RFC 3456 [11] describes how DHCPv4 can be run over a tunnel between the mobile node and a security gateway. However, RFC 3456 is only applicable for DHCPv4 and cannot be for Mobile IPv6 home address configuration. If the home agent supports DHCPv6 relay agent functionality, then the mobile node can request for a home address over the initial IPsec tunnel with the home agent. The home agent relays the request from the mobile node to a DHCPv6 server on the home link. Once the mobile node acquires a new home address, it should run IKEv1 again to configure the necessary security associations as required by RFC 3776. 4. Security Association Setup RFC 3776 describes dynamically setting up security associations between the mobile node and the home agent using pre-shared secrets and certificate based mechanisms. If pre-shared secrets or certificate based mechanisms are the only mechanisms used to authenticate the mobile node to the home agent, then nothing new needs to be specified. If in a particular deployment, the mobile node is authenticated using mechanisms such as RADIUS, SecureID, mobile node - AAA shared secret or smart card based authentication mechanism, then RFC 3776 is not sufficient. The hybrid authentication mechanism as described in [7] is required. The home agent SHOULD be authenticated using HybridInitRSA method in the Phase 1 exchange of IKE. This MUST be immediately followed by the XAUTH exchange described in [5]. The home agent SHOULD use the Radius CHAP method to authenticate the mobile node. 5. Mobile Node's DNS Entry Update If the mobile node has a DNS entry that maps its FQDN to its home Devarapalli & Parthasarathy Expires April 19, 2006 [Page 4] Internet-Draft MIP6 Bootstrapping with IKEv1 October 2005 address, the DNS entry becomes invalid if the mobile node bootstraps a new home address. In order to be reachable at its new home address, the DNS entry of the mobile node needs to be updated. This document proposes to use the DNS update mechanism described in section 6 of [8] to update the mobile node's FQDN with the newly configured home address. 6. Security Considerations The transaction exchange for configuring a home address MUST occur after the ISAKMP phase 1 security association has been setup. This would enable protecting the entire exchange using the phase 1 security association. For security considerations regarding the use of IKEv1 for negotiating security associations between the mobile node and the home agent using shared keys or certificates, please refer to [3]. For security considerations regarding the use of DNS to discover a home agent and the use of dynamic DNS updates to update the mobile node's DNS entry, please refer to [8]. 7. IANA Considerations This document requires no action from IANA. 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [4] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [5] Pereira, R., "Extended Authentication within ISAKMP/Oakley", draft-ietf-ipsec-isakamp-xauth-06 (work in progress), May 1999. Devarapalli & Parthasarathy Expires April 19, 2006 [Page 5] Internet-Draft MIP6 Bootstrapping with IKEv1 October 2005 [6] Pereira, R., "The ISAKMP Configuration Method", draft-ietf-ipsec-isakamp-mode-cfg-05 (work in progress), August 1999. [7] Litvin, M., "A Hybrid Authentication mode for IKE", draft-ietf-ipsec-isakamp-hybrid-auth-05 (work in progress), August 2000. [8] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", draft-ietf-mip6-bootstrapping-split-00 (work in progress), June 2005. [9] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. 8.2. Informative References [10] Maughan, D., Schneider, M., and M. Schertler, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [11] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003. Devarapalli & Parthasarathy Expires April 19, 2006 [Page 6] Internet-Draft MIP6 Bootstrapping with IKEv1 October 2005 Authors' Addresses Vijay Devarapalli Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA Email: vijay.devarapalli@nokia.com Mohan Parthasarathy Nokia 313 Fairchild Drive Mountain View, CA 94043 USA Email: mohan.parthasarathy@nokia.com Devarapalli & Parthasarathy Expires April 19, 2006 [Page 7] Internet-Draft MIP6 Bootstrapping with IKEv1 October 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. 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 (2005). 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. Devarapalli & Parthasarathy Expires April 19, 2006 [Page 8]