MIP6 Working Group V. Devarapalli Internet-Draft Nokia Expires: January 18, 2006 July 17, 2005 Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture draft-ietf-mip6-ikev2-ipsec-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 January 18, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. Devarapalli Expires January 18, 2006 [Page 1]
Internet-Draft Mobile IPv6 with IKEv2 and IPsec July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1 General Requirements . . . . . . . . . . . . . . . . . . . 4 4.2 Policy Requirements . . . . . . . . . . . . . . . . . . . 5 4.3 IPsec Protocol Processing Requirements . . . . . . . . . . 6 4.4 Dynamic Keying Requirements . . . . . . . . . . . . . . . 8 5. Manual Configuration . . . . . . . . . . . . . . . . . . . . . 8 5.1 Binding Update and Acknowledgements . . . . . . . . . . . 8 5.2 Return Routabililty Messages . . . . . . . . . . . . . . . 9 5.3 Mobile Prefix Discovery Messages . . . . . . . . . . . . . 10 5.4 Payload Packets . . . . . . . . . . . . . . . . . . . . . 11 6. Dynamic Configuration . . . . . . . . . . . . . . . . . . . . 11 6.1 Security Policy Database Entries . . . . . . . . . . . . . 12 6.1.1 Binding Updates and Acknowledgements . . . . . . . . . 12 6.1.2 Return Routability Messages . . . . . . . . . . . . . 13 6.1.3 Mobile Prefix Discovery Messages . . . . . . . . . . . 14 6.1.4 Payload Packets . . . . . . . . . . . . . . . . . . . 15 6.2 Security Association negotiation using IKEv2 . . . . . . . 16 6.3 Movements and Dynamic Keying . . . . . . . . . . . . . . . 18 7. The use of EAP authentication . . . . . . . . . . . . . . . . 19 8. Dynamic Home Address Configuration . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 12.1 Normative References . . . . . . . . . . . . . . . . . . . 22 12.2 Informative References . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . 24 Devarapalli Expires January 18, 2006 [Page 2]
Internet-Draft Mobile IPv6 with IKEv2 and IPsec July 2005 1. Introduction RFC 3776 describes how IPsec [12] is used with Mobile IPv6 [2] to protect the signaling messages. It also illustrates examples of Security Policy Database and Security Association Database entries that can be used to protect Mobile IPv6 signaling messages. The IPsec architecture has been revised [5]. Among the many changes, the list of selectors has been expanded to included the Mobility Header message type. This has an impact on how security policies and security associations are configured for protecting mobility header messages. It becomes easier to differentiate between the various Mobility Header messages based on the type value instead of checking if a particular mobility header message is being sent on a tunnel interface between the mobile node and the home agent, as it was in RFC 3776. The revised IPsec architecture specification also includes ICMP message type and code as selectors. This makes it possible to protect Mobile Prefix Discovery messages without applying the same security associations to all ICMPv6 messages. This document discusses new requirements for the Home Agent and the mobile node to use the revised IPsec architecture and IKEv2. Section 4 lists the requirements. Section 5 and Section 6 describe the required Security Policy Database (SPD) and Security Association Database (SAD) entries. The Internet Key Exchange (IKE) has also been substantially revised and simplified [4]. Section 6.2 of this document describes how IKEv2 can be used to setup security associations for Mobile IPv6. The use of EAP within IKEv2 is allowed to authenticate the mobile node to the Home Agent. This is described in Section 7. A method for dynamically configuring a home address from the Home Agent using the Configuration Payload in IKEv2 is described in Section 8. 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. Packet Formats The mobile node and the Home Agent must support the packet formats as defined in Section 3 of RFC 3776. This document does not update the packet formats described in RFC 3776. Devarapalli Expires January 18, 2006 [Page 3]
Internet-Draft Mobile IPv6 with IKEv2 and IPsec July 2005 4. Requirements This section describes mandatory rules and requirements for all Mobile IPv6 mobile nodes and Home Agents so that IPsec, with IKEv2 as the key negotiation protocol, can be used to protect traffic between the mobile node and the Home Agent. Many of the requirements are repeated from RFC 3776 to make this document self-contained and complete. 4.1 General Requirements o RFC 3775 states that manual configuration of IPsec security associations MUST be supported and automated key management MAY be supported. This document does not make any recommendations regarding the support of manual IPsec configuration and dynamic IPsec configuration. This document just describes the use of manually created IPsec security associations and the use of IKEv2 as the automated IPsec key management protocol for protecting Mobile IPv6 signaling messages. o ESP encapsulation for Binding Updates and Binding Acknowledgements MUST be supported and used. o ESP encapsulation in tunnel mode for the Home Test Init and Home Test messages tunneled between the mobile node and the Home Agent MUST be supported and SHOULD be used. o ESP encapsulation of the ICMPv6 messages related to mobile prefix discovery MUST be supported and SHOULD be used. o ESP encapsulation of the payload packets tunneled between the mobile node and the home agent MAY be supported and used. o If multicast group membership control protocols or stateful address autoconfiguration protocols are supported, payload data protection MUST be supported for those protocols. o The Home Agent and the mobile node MAY support authentication using EAP in IKEv2 as described in Section 7. o The Home Agent and the mobile node MAY support remote configuration of home address as described in Section 8. When the Home Agent receives a configuration payload with a CFG_REQUEST for INTERNAL_IP6_ADDR, it must reply with a valid home address for the mobile node. The Home Agent could pick a home address from a local database or from a DHCPv6 server on the home link. Devarapalli Expires January 18, 2006 [Page 4]
Internet-Draft Mobile IPv6 with IKEv2 and IPsec July 2005 4.2 Policy Requirements The following requirements are related to the configuration of security policy database on the Home Agent and the mobile node. o RFC 3776 required configuration of the security policies per interface in order to be able to differentiate between mobility header messages sent to the Home Agent and tunneled through the Home Agent to the correspondent node. Since the Mobility Header message type is a selector, it is now easy to differentiate between HoTi and HoT messages from other mobility header messages. Therefore per-interface configuration of security policies is not required. o The Home Agent MUST be able to prevent a mobile node from using its security association to send a Binding Update on behalf of another mobile node. With manual IPsec configuration, the Home Agent MUST be able to verify that a security association was created for a particular home address. With dynamic keying, it should be possible for the Home Agent to verify that the identity presented in the IKE_AUTH exchange is allowed to create security associations for a particular home address. o The Home Agent MAY use the Peer Authorization Database (PAD) [5] to store per-mobile node state. The PAD entry for a mobile node can contain a shared key, public key or a trust anchor to verify the mobile node's certificate for authenticating the mobile node. o As required in the base specification [7], when a packet destined to the receiving node is matched against IPsec security policy or selectors of a security association, an address appearing in a Home Address destination option is considered as the source address of the packet. Note that the home address option appears before IPsec headers. Section 11.3.2 of the base specification describes one possible implementation approach for this: The IPsec policy operations can be performed at the time when the packet has not yet been modified per Mobile IPv6 rules, or has been brought back to its normal form after Mobile IPv6 processing. That is, the processing of the Home Address option is seen as a fixed transformation of the packets that does not affect IPsec processing. o Similarly, a home address within a Type 2 Routing header destined to the receiving node is considered as the destination address of the packet, when a packet is matched against IPsec security policy or selectors of a security association. Devarapalli Expires January 18, 2006 [Page 5]
Internet-Draft Mobile IPv6 with IKEv2 and IPsec July 2005 Similar implementation considerations apply to the Routing header processing as was described above for the Home Address destination option. o When the mobile node returns home and de-registers with the Home Agent, the tunnel between the home agent and the mobile node's care-of address is torn down. The security policy entries, which were used for protecting tunneled traffic between the mobile node and the home agent MUST be made inactive (for instance, by removing them and installing them back later through an API). The corresponding security associations could be kept as they are or deleted depending on how they were created. If the security associations were created dynamically using IKE, they are automatically deleted when they expire. If the security associations were created through manual configuration, they MUST be retained and used later when the mobile node moves away from home again. The security associations protecting Binding Updates and Acknowledgements, and prefix discovery SHOULD NOT be deleted as they do not depend on care-of addresses and can be used again. o The mobile node MUST use the Home Address destination option in Binding Updates and Mobile Prefix Solicitations, sent to the home agent from a care-of address. o The home agent MUST use the Type 2 Routing header in Binding Acknowledgements and Mobile Prefix Advertisements sent to the mobile node, again due to the need to have the home address visible when the policy checks are made. 4.3 IPsec Protocol Processing Requirements The following lists requirements for IPsec processing at the Home Agent and the mobile node. o The Home Agent and mobile node MUST support Mobility Header message type as an IPsec selector. o The Home Agent and mobile node MUST support ICMPv6 message type as an IPsec selector. o The Home Agent MUST be able to distinguish between HoTi messages sent to itself, when it is acting as a Correspondent Node, from those sent to Correspondent Nodes when it is acting as a Home Agent, based on the destination address of the packet. o When securing Binding Updates, Binding Acknowledgements, and prefix discovery, both the mobile nodes and the home agents MUST support and SHOULD use the Encapsulating Security Payload (ESP) Devarapalli Expires January 18, 2006 [Page 6]
Internet-Draft Mobile IPv6 with IKEv2 and IPsec July 2005 [6] header in transport mode and MUST use a non-null payload authentication algorithm to provide data origin authentication, connectionless integrity and optional anti-replay protection. o Tunnel mode IPsec ESP MUST be supported and SHOULD be used for the protection of packets belonging to the return routability procedure. A non-null encryption transform and a non-null authentication algorithm MUST be applied. o When ESP is used to protect Binding Updates, there is no protection for the care-of address that appears in the IPv6 header outside the area protected by ESP. It is important for the home agent to verify that the care-of address has not been tampered with. As a result, the attacker would have redirected the mobile node's traffic to another address. In order to prevent this, Mobile IPv6 implementations MUST use the Alternate Care-of Address mobility option in Binding Updates sent by mobile nodes while away from home. The exception to this is when the mobile node returns home and sends a Binding Update to the home agent in order to de- register. When IPsec is used to protect return routability signaling or payload packets, the mobile node MUST set the source address it uses for the outgoing tunnel packets to the current primary care- of address. o When IPsec is used to protect return routability signaling or payload packets, IPsec security associations are needed to provide this protection. When the care-of address for the mobile node changes as a result of an accepted Binding Update, special treatment is needed for the next packets sent using these security associations. The home agent MUST set the new care-of address as the destination address of these packets, as if the outer header destination address in the security association had changed. Similarly, the home agent starts to expect the new source address in the tunnel packets received from the mobile node. Such address changes can be implemented, for instance, through an API from the Mobile IPv6 implementation to the IPsec implementation. It should be noted that the use of such an API and the address changes MUST only be done based on the Binding Updates received by the home agent and protected by the use of IPsec. Address modifications based on other sources, such as Binding Updates to the correspondent nodes protected by return routability, or open access to an API from any application may result in security vulnerabilities. Devarapalli Expires January 18, 2006 [Page 7]
Internet-Draft Mobile IPv6 with IKEv2 and IPsec July 2005 4.4 Dynamic Keying Requirements The following requirements are related to the use of a dynamic key management protocol by the mobile node and the Home Agent. Section 6.2 describes the use of IKEv2 as the dynamic key management protocol. o The mobile node MUST use its Care-of Address as source address in protocol exchanges, when using dynamic keying. o The mobile node and the Home Agent MUST create security associations based on the home address, so that the security associations survive change in Care-of Address. When using IKEv2 as the key exchange protocol, the home address should be carried as the initiator IP address in the TSi payload during the CREATE_CHILD_SA exchange [4]. o If the mobile node has used IKEv2 to establish security associations with its home agent, it should follow the procedures discussed in Section 11.7.1 and 11.7.3 of the base specification [2] to determine whether the IKE endpoints can be moved or if IKE SA has to be re-established. o If the home agent has used IKEv2 to establish security associations with the mobile node, it should follow the procedures discussed in Section 10.3.1 and 10.3.2 of the base specification [2] to determine whether the IKE endpoints can be moved or if IKE SA has to be re-established. 5. Manual Configuration This section describes the SPD and SAD entries that can be used to protect Mobile IPv6 signaling messages. The SPD and SAD entries are only example configurations. A particular mobile node implementation and a Home Agent implementation could configure different SPD and SAD entries as long as they provide the required security of the Mobile IPv6 signaling messages. For the examples described in this document, a mobile node with home address, "home_address_1", a Home Agent with address, "home_agent_1" and a user of the mobile node with identity "user_1" are assumed. If the home address of the mobile node changes, the SPD and SAD entries need to re-created or updated for the new home address. 5.1 Binding Update and Acknowledgements The following are the SPD and SAD entries on the mobile node and the Home Agent to protect Binding Updates and Acknowledgements. Devarapalli Expires January 18, 2006 [Page 8]
Internet-Draft Mobile IPv6 with IKEv2 and IPsec July 2005 mobile node SPD-S: - IF source = home_address_1 & destination = home_agent_1 & proto = MH & mh_type = BU Then use SA SA1 mobile node SPD-I: - IF source = home_agent_1 & destination = home_address_1 & proto = MH & mh_type = BAck Then use SA SA2 mobile node SAD: - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT): source = home_address_1 & destination = home_agent_1 & proto = MH & mh_type = BU - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT): source = home_agent_1 & destination = home_address_1 & proto = MH & mh_type = BAck home agent SPD-S: - IF source = home_agent_1 & destination = home_address_1 & proto = MH & mh_type = BAck Then use SA SA2 home agent SPD-I: - IF source = home_address_1 & destination = home_agent_1 & proto = MH & mh_type = BU Then use SA SA1 home agent SAD: - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT): source = home_agent_1 & destination = home_address_1 & proto = MH & mh_type = BAck - SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT): source = home_address_1 & destination = home_agent_1 & proto = MH & mh_type = BU 5.2 Return Routabililty Messages The following are the SPD and SAD entries on the mobile node and the Home Agent to protect Return Routability messages. Devarapalli Expires January 18, 2006 [Page 9]
Internet-Draft Mobile IPv6 with IKEv2 and IPsec July 2005 mobile node SPD-S: - IF source = home_address_1 & destination = any & proto = MH & mh_type = HoTi Then use SA SA3 mobile node SPD-I: - IF destination = home_address_1 & source = any & proto = MH & mh_type = HoT Then use SA SA4 mobile node SAD: - SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL): source = home_address_1 & destination = any & proto = MH & mh_type = HoTi - SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL): source = any & destination = home_address_1 & proto = MH & mh_type = HoT home agent SPD-S: - IF destination = home_address_1 & source = any & proto = MH & mh_type = HoT Then use SA SA4 home agent SPD-I: - IF source = home_address_1 & destination = any & proto = MH & mh_type = HoTi Then use SA SA3 home agent SAD: - SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL): source = any & destination = home_address_1 & proto = MH & mh_type = HoT - SA3(IN, spi_c, home_agent_1, ESP, TUNNEL): source = home_address_1 & destination = any & proto = MH & mh_type = HoTi 5.3 Mobile Prefix Discovery Messages The following are the SPD and SAD entries used to protect Mobile Prefix Discovery messages. Devarapalli Expires January 18, 2006 [Page 10]
Internet-Draft Mobile IPv6 with IKEv2 and IPsec July 2005 mobile node SPD-S: - IF source = home_address_1 & destination = home_agent_1 & proto = ICMPv6 & icmp6_type = MPS Then use SA SA5. mobile node SPD-I: - IF source = home_agent_1 & destination = home_address_1 & proto = ICMPv6 & icmp6_type = MPA Then use SA SA6 mobile node SAD: - SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT): source = home_address_1 & destination = home_agent_1 & proto = ICMPv6 & icmp6_type = MPS - SA6(IN, spi_f, home_address_1, ESP, TRANSPORT): source = home_agent_1 & destination = home_address_1 & proto = ICMPv6 & icmp6_type = MPA home agent SPD-S: - IF source = home_agent_1 & destination = home_address_1 & proto = ICMPv6 & icmp6_type = MPA Then use SA SA6 home agent SPD-I: - IF source = home_address_1 & destination = home_agent_1 & proto = ICMPv6 & icmp6_type = MPS Then use SA SA5 home agent SAD: - SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT): source = home_agent_1 & destination = home_address_1 & proto = ICMPv6 & icmp6_type = MPA - SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT): source = home_address_1 & destination = home_agent_1 & proto = ICMPv6 & icmp6_type = MPS 5.4 Payload Packets Payload traffic tunneled through the Home Agent can be protected by IPsec, if required. The mobile node and the Home Agent use ESP in tunnel mode to protect the tunneled traffic. The SPD and SAD entries shown in Section 5.2.4 of [3] are applicable here. 6. Dynamic Configuration This section describes the use of IKEv2 to setup the required security associations. Devarapalli Expires January 18, 2006 [Page 11]
Internet-Draft Mobile IPv6 with IKEv2 and IPsec July 2005 6.1 Security Policy Database Entries The following sections describe the security policy entries on the mobile node and the Home Agent. The SPD entries are only example configurations. A particular mobile node implementation and a Home Agent implementation could configure different SPD entries as long as they provide the required security of the Mobile IPv6 signaling messages. In the examples shown below, the identity of the user of the mobile node is assumed to be user_1, the home address of the mobile node is assumed to be home_address_1 and the IPv6 address of the Home Agent is assumed to be home_agent_1. 6.1.1 Binding Updates and Acknowledgements The following are the SPD entries on the mobile node and the Home Agent for protecting Binding Updates and Acknowledgements. mobile node SPD-S: - IF destination = home_agent_1 & proto = MH & mh_type = BU Then use SA ESP transport mode IDi = user_1, IDr = home_agent_1, TSi = home_address_1 mobile node SPD-I: - IF source = home_agent_1 & proto = MH & mh_type = BAck Then use SA ESP transport mode IDi = user_1, IDr = home_agent_1, TSi = home_address_1 home agent SPD-S: - IF source = home_agent_1 & proto = MH & mh_type = BAck Then use SA ESP transport mode IDr = user_1, IDi = home_agent_1, TSr = home_address_1 home agent SPD-I: - IF destination = home_agent_1 & proto = MH & mh_type = BU Then use SA ESP transport mode IDr = user_1, IDi = home_agent_1, TSr = home_address_1 In the examples shown above, the home address of the mobile node might not be available all the time. For instance, the mobile node might have not configured a home address yet. When the mobile node acquires a new home address, it must either add the address to the corresponding SPD entries or create the SPD entries for the home address. Devarapalli Expires January 18, 2006 [Page 12]
Internet-Draft Mobile IPv6 with IKEv2 and IPsec July 2005 The Home Agent should have named SPD entries per mobile node, based on the identity of the mobile node. The identity of the mobile node is stored in the "Name" selector in the SPD [5]. The Home Address presented by the mobile node during the IKE negotiation is stored as the Remote IP address in the resultant IPsec security associations. The home agent MAY also have generic SPD entries to prevent mobility header traffic that requires IPsec protection from bypassing the IPsec filters. The Mobility Header message type is negotiated by placing it in the most significant eight bits of the 16 bit local "port" selector during IKEv2 exchange. For more details, refer to [5]. The TSi and TSr payloads in the above examples will contain many other selectors apart from home_address_1. For the sake of brevity, they are not shown here. 6.1.2 Return Routability Messages The following are the SPD entries on the mobile node and the Home Agent for protecting the Return Routability messages. Devarapalli Expires January 18, 2006 [Page 13]
Internet-Draft Mobile IPv6 with IKEv2 and IPsec July 2005 mobile node SPD-S: - IF proto = MH & mh_type = HoTi Then use SA ESP tunnel mode IDi = user_1, outer src addr = coa outer dst addr = home_agent_1, inner src addr = home_address_1 mobile node SPD-I: - IF destination = home_address_1 & proto = MH & mh_type = HoT Then use SA ESP tunnel mode IDi = user_1, outer src addr = home_agent_1, outer dst addr = coa, home agent SPD-S: - IF proto = MH & mh_type = HoT Then use SA ESP tunnel mode IDr = user_1, outer src addr = home_agent_1, outer dst addr = coa, inner dst addr = home_address_1 home agent SPD-I: - IF proto = MH & mh_type = HoTi Then use SA ESP tunnel mode IDr = user_1, outer src addr = coa, outer dst addr = home_agent_1, inner src addr = home_address_1 When the mobile node's Care-of Address changes the SPD entries on both the mobile node and the Home Agent must be updated. The Home Agent knows about the change in Care-of Address of the mobile node when it receives a Binding Update from the mobile node. 6.1.3 Mobile Prefix Discovery Messages The following are the SPD entries on the mobile node and the Home Agent for protecting Mobile Prefix Discovery messages. Devarapalli Expires January 18, 2006 [Page 14]
Internet-Draft Mobile IPv6 with IKEv2 and IPsec July 2005 mobile node SPD-S: - IF destination = home_agent_1 & proto = ICMPv6 & icmp6_type = MPS Then use SA ESP transport mode IDi = user_1, IDr = home_agent_1, TSi = home_address_1 mobile node SPD-I: - IF source = home_agent_1 & proto = ICMPv6 & icmp6_type = MPA Then use SA ESP transport mode IDi = user_1, IDr = home_agent_1, TSi = home_address_1 home agent SPD-S: - IF source = home_agent_1 & proto = ICMPv6 & icmp6_type = MPA Then use SA ESP transport mode IDr = user_1, IDi = home_agent_1, TSr = home_address_1 home agent SPD-I: - IF destination = home_agent_1 & proto = ICMPv6 & icmp6_type = MPS Then use SA ESP transport mode IDr = user_1, IDi = home_agent_1, TSr = home_address_1 In the examples shown above, the home address of the mobile node might not be available all the time. When the mobile node acquires a new home address, it must add the address to the corresponding SPD entries. The TSi and TSr payloads in the above examples will contain many other selectors apart from home_address_1. For brevity, they are not show here. 6.1.4 Payload Packets The following are the SPD entries on the mobile node and the Home Agent if payload traffic exchanged between the mobile node and its Correspondent Node needs to be protected. The SPD entries are similar to the entries for protecting Return Routability messages and have lower priority than the above SPD entries. Devarapalli Expires January 18, 2006 [Page 15]
Internet-Draft Mobile IPv6 with IKEv2 and IPsec July 2005 mobile node SPD-S: - IF interface = IPv6 tunnel to home_agent_1 & proto = X Then use SA ESP tunnel mode IDi = user_1, outer src addr = coa outer dst addr = home_agent_1, inner src addr = home_address_1 mobile node SPD-I: - IF destination = home_address_1 & proto = X & source = any_cn Then use SA ESP tunnel mode IDi = user_1, outer src addr = home_agent_1, outer dst addr = coa, home agent SPD-S: - IF interface = IPv6 tunnel to home_address_1 & proto = X Then use SA ESP tunnel mode IDr = user_1, outer src addr = home_agent_1, outer dst addr = coa, inner dst addr = home_address_1 home agent SPD-I: - IF interface = IPv6 tunnel to home_address_1 & proto = X Then use SA ESP tunnel mode IDr = user_1, outer src addr = coa, outer dst addr = home_agent_1, inner src addr = home_address_1 6.2 Security Association negotiation using IKEv2 Mobile IPv6 signaling messages are typically initiated by the mobile node. The mobile node sends a Binding Update to the Home Agent whenever it moves and acquires a new Care-of Address. The mobile node initiates an IKEv2 protocol exchange if the required security associations are not present. The default mechanism used for mutual authentication is a shared secret between the mobile node and the Home Agent. The Home Agent uses the identity of the mobile node to identify the corresponding shared secret. If public key based mechanism is available, it should be the preferred mechanism Devarapalli Expires January 18, 2006 [Page 16]
Internet-Draft Mobile IPv6 with IKEv2 and IPsec July 2005 for mutual authentication. The Home Agent and the mobile node should use their private keys to generate the AUTH payload, when a public key based mechanism is used. The mobile node and the Home Agent should use CERTREQ and CERT payloads if the identities need to be verified. If the mobile node is configured with the Home Agent information including the public key that corresponds to the Home Agent, then the mobile node MAY exclude the CERTREQ payload in message 3. Similarly, the Home Agent MAY exclude the CERTREQ payload in message 2, if it is configured with the mobile node information. If a shared secret is being used, the mobile node uses the shared secret to generate the AUTH payload in the IKE_AUTH exchange. If the mobile node is using a public key based mechanism, then it uses its private key to generate the AUTH payload in the IKE_AUTH exchange. Mobile Node Home Agent ----------- ---------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} The mobile node MUST always includes its identity in the IDi payload in the IKE_AUTH exchange. The mobile node could use the following different types of identities to identity itself to the Home Agent. o Home Address - The mobile node could use its statically configured home address as its identity. In this case the ID Type field is set to ID_IPV6_ADDR. o FQDN - The mobile node can use a Fully Qualified Domain Name as the identifier and set the ID Type field to ID_FQDN. o RFC 822 identifier - If the mobile node uses a RFC 822 identifier [10], it sets the ID Type field to ID_RFC822_ADDR. In the IKE_AUTH exchange, the mobile node includes the home address and the appropriate selectors in the TSi (Traffic Selector-initiator) payload to negotiate IPsec security associations for protecting the Binding Update and Binding Acknowledgement messages. The mobile node MAY use a range of selectors that includes the mobility message types for Binding Update and Binding Acknowledgement to use the same pair of IPsec security association for both messages. Devarapalli Expires January 18, 2006 [Page 17]
Internet-Draft Mobile IPv6 with IKEv2 and IPsec July 2005 After the IKE_AUTH exchange completes, the mobile node and the Home Agent initiate CREATE_CHILD_SA exchanges to negotiate additional security associations for protecting Return Routability signaling, Mobile Prefix Discovery messages and optionally payload traffic. The CREATE_CHILD_SA exchanges are protected by the security association created during the IKE_AUTH exchange. It is important that the security associations are created based on the home address of the mobile node, so that the security associations survive Care-of Address change. The mobile node MUST use its home address as the initiator IP address in the TSi payload in the CREATE_CHILD_SA exchange in order to create the security associations for the home address. Mobile Node Home Agent ----------- ---------- HDR, SK {[N], SA, Ni, [KEi], [TSi, TSr]} --> <-- HDR, SK {SA, Nr, [KEr], [TSi, TSr]} When PKI based authentication is used between the mobile and the Home Agent, the identity presented by the mobile node in the IDi payload must correspond to the identity in the certificate obtained by the Home Agent. The Home Agent uses the identity presented in the IDi payload to lookup the policy and the certificate that corresponds to the mobile node. If the mobile node presents its home address in the IDi payload, then the Home Agent MUST verify that the home address matches the address in the iPAddress field in the SubjectAltName extension [9]. 6.3 Movements and Dynamic Keying If the mobile node moves and its care-of address changes, the IKEv2 SA might not be valid, unless the mobility extensions defined in [14] are implemented by both the mobile node and the Home Agent. RFC 3775 defines a mechanism based on the successful exchange of Binding Update and Binding Acknowledgement messages. The IKE SA endpoints are updated on the Home Agent when it receives the Binding Update from the mobile node's new care-of address and on the mobile node when it receives the Binding acknowledgement sent by the Home Agent. This capability to change IKE endpoints is indicated through setting the Key Management Capability (K) flag [2] in the Binding Update and Binding Acknowledgement messages. If the mobile node or the Home Agent does not support this capability, then an IKEv2 exchange MUST be initiated to re-establish the IKE SA. Devarapalli Expires January 18, 2006 [Page 18]
Internet-Draft Mobile IPv6 with IKEv2 and IPsec July 2005 7. The use of EAP authentication In addition to using public key signatures and shared secrets, EAP [11] can be used with IKEv2 for authenticating the mobile node to the Home Agent. The mobile node indicates that it wants to use EAP by including the IDi payload but leaving out the AUTH payload in the first message during the IKE_AUTH exchange. The Home Agent then includes an EAP payload if it is willing to use an extensible authentication method. Security associations are not created until the subsequent IKE_AUTH exchange after successful EAP authentication. The use of EAP adds at least two round trips to the IKE negotiation. Mobile Node Home Agent ------------ ---------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr}--> <-- HDR, SK {IDr, [CERT,] AUTH, EAP } HDR, SK {EAP} --> <-- HDR, SK {EAP (success)} HDR, SK {AUTH} --> <-- HDR, SK {AUTH, SAr2, TSi, TSr} Some EAP methods generate a shared key on the mobile node and the Home Agent once the EAP authentication succeeds. In this case, the shared key is used to generate the AUTH payloads in the subsequent messages. The shared key, if used to generate the AUTH payloads, MUST NOT be used for any other purpose. For more details, refer to [4]. The use of EAP between the mobile node and the Home Agent might require the Home Agent to contact an authorization server like the AAA Home server, on the home link, to authenticate the mobile node. Please refer to [7] for more details. The IKEv2 specification [4] requires that public key based mechanism Devarapalli Expires January 18, 2006 [Page 19]
Internet-Draft Mobile IPv6 with IKEv2 and IPsec July 2005 be used to authenticate the Home Agent to the mobile node, when EAP is used. This should be used by default by the mobile node and the home agent. If the EAP method that is used, supports mutual authentication and key generation, then the mobile node MAY use EAP itself to authenticate the Home Agent. The mobile node can request this by including the EAP_ONLY_AUTHENTICATION notification payload [8] in message 3. If the Home Agent supports the EAP_ONLY_AUTHENTICATION notification payload and agrees to use EAP, it omits the public key based AUTH and CERT payloads in message 4. If the Home Agent does not support this mechanism, it rejects it by including an AUTH payload in message 4. More details can be found in [8]. 8. Dynamic Home Address Configuration The mobile node can dynamically configure a home address by including a Configuration Payload in the IKE_AUTH exchange, with a request for an address from the home link. The mobile node should include an INTERNAL_IP6_ADDRESS attribute in the CFG_REQUEST Payload. The mobile node MAY also include the INTERNAL_IP6_SUBNET attribute if it wants to obtain information about the IPv6 prefixes on the home link. If the mobile node wants to configure a DNS server from the home link it can request for the DNS server information by including an INTERNAL_IP6_DNS attribute in the CFG_REQUEST payload. When the Home Agent receives a configuration payload with a CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid home address for the mobile node. The INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY contains the prefix length of the home prefix in addition to a 128 bit home address. The Home Agent could use a local database or contact a DHCPv6 server on the home link to allocate a home address. The Home Agent should also include an INTERNAL_ADDRESS_EXPIRY attribute to indicate to the mobile node, the duration for which the dynamically allocated home address is valid. Mobile Node Home Agent ----------- ---------- HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, CP(CFG_REPLY), SAr2, TSi, TSr} The mobile node could suggest a home address that it wants to use in the CFG_REQUEST. For example, this could be a home address that it Devarapalli Expires January 18, 2006 [Page 20]
Internet-Draft Mobile IPv6 with IKEv2 and IPsec July 2005 was allocated before or could be an address the mobile node auto- configured from the IPv6 prefix on the home link. The Home Agent could let the mobile node use the same home address by setting the INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload to the same home address. If the Home Agent wants the mobile node to use a different home address, it sends a new home address in the INTERNAL_IP_ADDRESS attribute in the CFG_REPLY payload. The Mobile Node MUST stop using its old home address and start using the newly allocated home address. In case the Home Agent is unable to allocate a home address for the mobile node during the IKE_AUTH exchange, it MUST send a Notify Payload with an INTERNAL_ADDRESS_FAILURE message. 9. Security Considerations This document describes how IPsec can be used to secure Mobile IPv6 signaling messages. Please refer to RFC 3775 for security considerations related to the use of IPsec with Mobile IPv6. A misbehaving mobile node could create IPsec security associations for a home address that belongs to another mobile node. Therefore, the Home Agent should check if a particular mobile node is authorized to use a home address before creating IPsec security associations for the home address. If the home address is assigned as described in Section 8, the Home Agent MUST associate the home address with the identity used in IKE negotiation. The Home Agent MAY store the assigned home address in the SPD entries created for the mobile node. The use of EAP for authenticating the mobile node to the Home Agent is described in Section 7. This document recommends that if the EAP method used, supports mutual authentication, then EAP itself be used for authenticating the Home Agent to the mobile node also. This runs contrary to the recommendation in [4]. The Home Agent can ignore the recommendation in this document and implement EAP authentication as described in the IKEv2 specification. Security considerations related to the use of EAP with IKEv2 are described in [4] and [8]. 10. IANA Considerations This document requires no action from IANA. 11. Acknowledgements The author would like to thank Mika Joutsenvirta, Pasi Eronen, Francis Dupont, Jari Arkko and Gerardo Giaretta for reviewing the draft. Devarapalli Expires January 18, 2006 [Page 21]
Internet-Draft Mobile IPv6 with IKEv2 and IPsec July 2005 Many of the requirements listed in Section 4 are copied from RFC 3776. Therefore, the authors of RFC 3776 are acknowledged. 12. References 12.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] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. [5] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress), April 2005. [6] Kent, S., "IP Encapsulating Security Payload (ESP)", draft-ietf-ipsec-esp-v3-10 (work in progress), March 2005. 12.2 Informative References [7] Giaretta, G., "Goals for AAA-HA interface", draft-giaretta-mip6-aaa-ha-goals-00 (work in progress), September 2004. [8] Eronen, P., "Extension for EAP Authentication in IKEv2", draft-eronen-ipsec-ikev2-eap-auth-03 (work in progress), April 2005. [9] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ ISAKMP, IKEv2, and PKIX", draft-ietf-pki4ipsec-ikecert-profile-04 (work in progress), April 2005. [10] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [11] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. Devarapalli Expires January 18, 2006 [Page 22]
Internet-Draft Mobile IPv6 with IKEv2 and IPsec July 2005 [12] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [13] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [14] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", draft-ietf-mobike-protocol-00 (work in progress), June 2005. Author's Address Vijay Devarapalli Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA Email: vijay.devarapalli@nokia.com Devarapalli Expires January 18, 2006 [Page 23]
Internet-Draft Mobile IPv6 with IKEv2 and IPsec 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. 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 Expires January 18, 2006 [Page 24]
