idnits 2.17.1 draft-ietf-mip6-ikev2-ipsec-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1033. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1010. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1017. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1023. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 17, 2005) is 6858 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'CERTREQ' on line 807 -- Looks like a reference, but probably isn't: 'N' on line 757 -- Looks like a reference, but probably isn't: 'KEi' on line 757 -- Looks like a reference, but probably isn't: 'KEr' on line 760 == Unused Reference: '13' is defined on line 985, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) == Outdated reference: A later version (-07) exists of draft-eronen-ipsec-ikev2-eap-auth-03 == Outdated reference: A later version (-12) exists of draft-ietf-pki4ipsec-ikecert-profile-04 -- Obsolete informational reference (is this intentional?): RFC 822 (ref. '10') (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '12') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '13') (Obsoleted by RFC 4306) == Outdated reference: A later version (-08) exists of draft-ietf-mobike-protocol-00 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Working Group V. Devarapalli 3 Internet-Draft Nokia 4 Expires: January 18, 2006 July 17, 2005 6 Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture 7 draft-ietf-mip6-ikev2-ipsec-02.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 18, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document describes Mobile IPv6 operation with the revised IPsec 41 architecture and IKEv2. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 3 48 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 4.1 General Requirements . . . . . . . . . . . . . . . . . . . 4 50 4.2 Policy Requirements . . . . . . . . . . . . . . . . . . . 5 51 4.3 IPsec Protocol Processing Requirements . . . . . . . . . . 6 52 4.4 Dynamic Keying Requirements . . . . . . . . . . . . . . . 8 53 5. Manual Configuration . . . . . . . . . . . . . . . . . . . . . 8 54 5.1 Binding Update and Acknowledgements . . . . . . . . . . . 8 55 5.2 Return Routabililty Messages . . . . . . . . . . . . . . . 9 56 5.3 Mobile Prefix Discovery Messages . . . . . . . . . . . . . 10 57 5.4 Payload Packets . . . . . . . . . . . . . . . . . . . . . 11 58 6. Dynamic Configuration . . . . . . . . . . . . . . . . . . . . 11 59 6.1 Security Policy Database Entries . . . . . . . . . . . . . 12 60 6.1.1 Binding Updates and Acknowledgements . . . . . . . . . 12 61 6.1.2 Return Routability Messages . . . . . . . . . . . . . 13 62 6.1.3 Mobile Prefix Discovery Messages . . . . . . . . . . . 14 63 6.1.4 Payload Packets . . . . . . . . . . . . . . . . . . . 15 64 6.2 Security Association negotiation using IKEv2 . . . . . . . 16 65 6.3 Movements and Dynamic Keying . . . . . . . . . . . . . . . 18 66 7. The use of EAP authentication . . . . . . . . . . . . . . . . 19 67 8. Dynamic Home Address Configuration . . . . . . . . . . . . . . 20 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 69 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 70 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 71 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 72 12.1 Normative References . . . . . . . . . . . . . . . . . . . 22 73 12.2 Informative References . . . . . . . . . . . . . . . . . . 22 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 23 75 Intellectual Property and Copyright Statements . . . . . . . . 24 77 1. Introduction 79 RFC 3776 describes how IPsec [12] is used with Mobile IPv6 [2] to 80 protect the signaling messages. It also illustrates examples of 81 Security Policy Database and Security Association Database entries 82 that can be used to protect Mobile IPv6 signaling messages. 84 The IPsec architecture has been revised [5]. Among the many changes, 85 the list of selectors has been expanded to included the Mobility 86 Header message type. This has an impact on how security policies and 87 security associations are configured for protecting mobility header 88 messages. It becomes easier to differentiate between the various 89 Mobility Header messages based on the type value instead of checking 90 if a particular mobility header message is being sent on a tunnel 91 interface between the mobile node and the home agent, as it was in 92 RFC 3776. The revised IPsec architecture specification also includes 93 ICMP message type and code as selectors. This makes it possible to 94 protect Mobile Prefix Discovery messages without applying the same 95 security associations to all ICMPv6 messages. 97 This document discusses new requirements for the Home Agent and the 98 mobile node to use the revised IPsec architecture and IKEv2. 99 Section 4 lists the requirements. Section 5 and Section 6 describe 100 the required Security Policy Database (SPD) and Security Association 101 Database (SAD) entries. 103 The Internet Key Exchange (IKE) has also been substantially revised 104 and simplified [4]. Section 6.2 of this document describes how IKEv2 105 can be used to setup security associations for Mobile IPv6. 107 The use of EAP within IKEv2 is allowed to authenticate the mobile 108 node to the Home Agent. This is described in Section 7. A method 109 for dynamically configuring a home address from the Home Agent using 110 the Configuration Payload in IKEv2 is described in Section 8. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [1]. 118 3. Packet Formats 120 The mobile node and the Home Agent must support the packet formats as 121 defined in Section 3 of RFC 3776. This document does not update the 122 packet formats described in RFC 3776. 124 4. Requirements 126 This section describes mandatory rules and requirements for all 127 Mobile IPv6 mobile nodes and Home Agents so that IPsec, with IKEv2 as 128 the key negotiation protocol, can be used to protect traffic between 129 the mobile node and the Home Agent. Many of the requirements are 130 repeated from RFC 3776 to make this document self-contained and 131 complete. 133 4.1 General Requirements 135 o RFC 3775 states that manual configuration of IPsec security 136 associations MUST be supported and automated key management MAY be 137 supported. This document does not make any recommendations 138 regarding the support of manual IPsec configuration and dynamic 139 IPsec configuration. This document just describes the use of 140 manually created IPsec security associations and the use of IKEv2 141 as the automated IPsec key management protocol for protecting 142 Mobile IPv6 signaling messages. 144 o ESP encapsulation for Binding Updates and Binding Acknowledgements 145 MUST be supported and used. 147 o ESP encapsulation in tunnel mode for the Home Test Init and Home 148 Test messages tunneled between the mobile node and the Home Agent 149 MUST be supported and SHOULD be used. 151 o ESP encapsulation of the ICMPv6 messages related to mobile prefix 152 discovery MUST be supported and SHOULD be used. 154 o ESP encapsulation of the payload packets tunneled between the 155 mobile node and the home agent MAY be supported and used. 157 o If multicast group membership control protocols or stateful 158 address autoconfiguration protocols are supported, payload data 159 protection MUST be supported for those protocols. 161 o The Home Agent and the mobile node MAY support authentication 162 using EAP in IKEv2 as described in Section 7. 164 o The Home Agent and the mobile node MAY support remote 165 configuration of home address as described in Section 8. When the 166 Home Agent receives a configuration payload with a CFG_REQUEST for 167 INTERNAL_IP6_ADDR, it must reply with a valid home address for the 168 mobile node. The Home Agent could pick a home address from a 169 local database or from a DHCPv6 server on the home link. 171 4.2 Policy Requirements 173 The following requirements are related to the configuration of 174 security policy database on the Home Agent and the mobile node. 176 o RFC 3776 required configuration of the security policies per 177 interface in order to be able to differentiate between mobility 178 header messages sent to the Home Agent and tunneled through the 179 Home Agent to the correspondent node. Since the Mobility Header 180 message type is a selector, it is now easy to differentiate 181 between HoTi and HoT messages from other mobility header messages. 182 Therefore per-interface configuration of security policies is not 183 required. 185 o The Home Agent MUST be able to prevent a mobile node from using 186 its security association to send a Binding Update on behalf of 187 another mobile node. With manual IPsec configuration, the Home 188 Agent MUST be able to verify that a security association was 189 created for a particular home address. With dynamic keying, it 190 should be possible for the Home Agent to verify that the identity 191 presented in the IKE_AUTH exchange is allowed to create security 192 associations for a particular home address. 194 o The Home Agent MAY use the Peer Authorization Database (PAD) [5] 195 to store per-mobile node state. The PAD entry for a mobile node 196 can contain a shared key, public key or a trust anchor to verify 197 the mobile node's certificate for authenticating the mobile node. 199 o As required in the base specification [7], when a packet destined 200 to the receiving node is matched against IPsec security policy or 201 selectors of a security association, an address appearing in a 202 Home Address destination option is considered as the source 203 address of the packet. 205 Note that the home address option appears before IPsec headers. 206 Section 11.3.2 of the base specification describes one possible 207 implementation approach for this: The IPsec policy operations can 208 be performed at the time when the packet has not yet been modified 209 per Mobile IPv6 rules, or has been brought back to its normal form 210 after Mobile IPv6 processing. That is, the processing of the Home 211 Address option is seen as a fixed transformation of the packets 212 that does not affect IPsec processing. 214 o Similarly, a home address within a Type 2 Routing header destined 215 to the receiving node is considered as the destination address of 216 the packet, when a packet is matched against IPsec security policy 217 or selectors of a security association. 219 Similar implementation considerations apply to the Routing header 220 processing as was described above for the Home Address destination 221 option. 223 o When the mobile node returns home and de-registers with the Home 224 Agent, the tunnel between the home agent and the mobile node's 225 care-of address is torn down. The security policy entries, which 226 were used for protecting tunneled traffic between the mobile node 227 and the home agent MUST be made inactive (for instance, by 228 removing them and installing them back later through an API). The 229 corresponding security associations could be kept as they are or 230 deleted depending on how they were created. If the security 231 associations were created dynamically using IKE, they are 232 automatically deleted when they expire. If the security 233 associations were created through manual configuration, they MUST 234 be retained and used later when the mobile node moves away from 235 home again. The security associations protecting Binding Updates 236 and Acknowledgements, and prefix discovery SHOULD NOT be deleted 237 as they do not depend on care-of addresses and can be used again. 239 o The mobile node MUST use the Home Address destination option in 240 Binding Updates and Mobile Prefix Solicitations, sent to the home 241 agent from a care-of address. 243 o The home agent MUST use the Type 2 Routing header in Binding 244 Acknowledgements and Mobile Prefix Advertisements sent to the 245 mobile node, again due to the need to have the home address 246 visible when the policy checks are made. 248 4.3 IPsec Protocol Processing Requirements 250 The following lists requirements for IPsec processing at the Home 251 Agent and the mobile node. 253 o The Home Agent and mobile node MUST support Mobility Header 254 message type as an IPsec selector. 256 o The Home Agent and mobile node MUST support ICMPv6 message type as 257 an IPsec selector. 259 o The Home Agent MUST be able to distinguish between HoTi messages 260 sent to itself, when it is acting as a Correspondent Node, from 261 those sent to Correspondent Nodes when it is acting as a Home 262 Agent, based on the destination address of the packet. 264 o When securing Binding Updates, Binding Acknowledgements, and 265 prefix discovery, both the mobile nodes and the home agents MUST 266 support and SHOULD use the Encapsulating Security Payload (ESP) 268 [6] header in transport mode and MUST use a non-null payload 269 authentication algorithm to provide data origin authentication, 270 connectionless integrity and optional anti-replay protection. 272 o Tunnel mode IPsec ESP MUST be supported and SHOULD be used for the 273 protection of packets belonging to the return routability 274 procedure. A non-null encryption transform and a non-null 275 authentication algorithm MUST be applied. 277 o When ESP is used to protect Binding Updates, there is no 278 protection for the care-of address that appears in the IPv6 header 279 outside the area protected by ESP. It is important for the home 280 agent to verify that the care-of address has not been tampered 281 with. As a result, the attacker would have redirected the mobile 282 node's traffic to another address. In order to prevent this, 283 Mobile IPv6 implementations MUST use the Alternate Care-of Address 284 mobility option in Binding Updates sent by mobile nodes while away 285 from home. The exception to this is when the mobile node returns 286 home and sends a Binding Update to the home agent in order to de- 287 register. 289 When IPsec is used to protect return routability signaling or 290 payload packets, the mobile node MUST set the source address it 291 uses for the outgoing tunnel packets to the current primary care- 292 of address. 294 o When IPsec is used to protect return routability signaling or 295 payload packets, IPsec security associations are needed to provide 296 this protection. When the care-of address for the mobile node 297 changes as a result of an accepted Binding Update, special 298 treatment is needed for the next packets sent using these security 299 associations. The home agent MUST set the new care-of address as 300 the destination address of these packets, as if the outer header 301 destination address in the security association had changed. 302 Similarly, the home agent starts to expect the new source address 303 in the tunnel packets received from the mobile node. 305 Such address changes can be implemented, for instance, through an 306 API from the Mobile IPv6 implementation to the IPsec 307 implementation. It should be noted that the use of such an API 308 and the address changes MUST only be done based on the Binding 309 Updates received by the home agent and protected by the use of 310 IPsec. Address modifications based on other sources, such as 311 Binding Updates to the correspondent nodes protected by return 312 routability, or open access to an API from any application may 313 result in security vulnerabilities. 315 4.4 Dynamic Keying Requirements 317 The following requirements are related to the use of a dynamic key 318 management protocol by the mobile node and the Home Agent. 319 Section 6.2 describes the use of IKEv2 as the dynamic key management 320 protocol. 322 o The mobile node MUST use its Care-of Address as source address in 323 protocol exchanges, when using dynamic keying. 325 o The mobile node and the Home Agent MUST create security 326 associations based on the home address, so that the security 327 associations survive change in Care-of Address. When using IKEv2 328 as the key exchange protocol, the home address should be carried 329 as the initiator IP address in the TSi payload during the 330 CREATE_CHILD_SA exchange [4]. 332 o If the mobile node has used IKEv2 to establish security 333 associations with its home agent, it should follow the procedures 334 discussed in Section 11.7.1 and 11.7.3 of the base specification 335 [2] to determine whether the IKE endpoints can be moved or if IKE 336 SA has to be re-established. 338 o If the home agent has used IKEv2 to establish security 339 associations with the mobile node, it should follow the procedures 340 discussed in Section 10.3.1 and 10.3.2 of the base specification 341 [2] to determine whether the IKE endpoints can be moved or if IKE 342 SA has to be re-established. 344 5. Manual Configuration 346 This section describes the SPD and SAD entries that can be used to 347 protect Mobile IPv6 signaling messages. The SPD and SAD entries are 348 only example configurations. A particular mobile node implementation 349 and a Home Agent implementation could configure different SPD and SAD 350 entries as long as they provide the required security of the Mobile 351 IPv6 signaling messages. 353 For the examples described in this document, a mobile node with home 354 address, "home_address_1", a Home Agent with address, "home_agent_1" 355 and a user of the mobile node with identity "user_1" are assumed. If 356 the home address of the mobile node changes, the SPD and SAD entries 357 need to re-created or updated for the new home address. 359 5.1 Binding Update and Acknowledgements 361 The following are the SPD and SAD entries on the mobile node and the 362 Home Agent to protect Binding Updates and Acknowledgements. 364 mobile node SPD-S: 365 - IF source = home_address_1 & destination = home_agent_1 & 366 proto = MH & mh_type = BU 367 Then use SA SA1 369 mobile node SPD-I: 370 - IF source = home_agent_1 & destination = home_address_1 & 371 proto = MH & mh_type = BAck 372 Then use SA SA2 374 mobile node SAD: 375 - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT): 376 source = home_address_1 & destination = home_agent_1 & 377 proto = MH & mh_type = BU 378 - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT): 379 source = home_agent_1 & destination = home_address_1 & 380 proto = MH & mh_type = BAck 382 home agent SPD-S: 383 - IF source = home_agent_1 & destination = home_address_1 & 384 proto = MH & mh_type = BAck 385 Then use SA SA2 387 home agent SPD-I: 388 - IF source = home_address_1 & destination = home_agent_1 & 389 proto = MH & mh_type = BU 390 Then use SA SA1 392 home agent SAD: 393 - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT): 394 source = home_agent_1 & destination = home_address_1 & 395 proto = MH & mh_type = BAck 396 - SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT): 397 source = home_address_1 & destination = home_agent_1 & 398 proto = MH & mh_type = BU 400 5.2 Return Routabililty Messages 402 The following are the SPD and SAD entries on the mobile node and the 403 Home Agent to protect Return Routability messages. 405 mobile node SPD-S: 406 - IF source = home_address_1 & destination = any & 407 proto = MH & mh_type = HoTi 408 Then use SA SA3 410 mobile node SPD-I: 411 - IF destination = home_address_1 & source = any & 412 proto = MH & mh_type = HoT 413 Then use SA SA4 415 mobile node SAD: 416 - SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL): 417 source = home_address_1 & destination = any & proto = MH & 418 mh_type = HoTi 419 - SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL): 420 source = any & destination = home_address_1 & proto = MH & 421 mh_type = HoT 423 home agent SPD-S: 424 - IF destination = home_address_1 & source = any & 425 proto = MH & mh_type = HoT 426 Then use SA SA4 428 home agent SPD-I: 429 - IF source = home_address_1 & destination = any & 430 proto = MH & mh_type = HoTi 431 Then use SA SA3 433 home agent SAD: 434 - SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL): 435 source = any & destination = home_address_1 & proto = MH & 436 mh_type = HoT 437 - SA3(IN, spi_c, home_agent_1, ESP, TUNNEL): 438 source = home_address_1 & destination = any & proto = MH & 439 mh_type = HoTi 441 5.3 Mobile Prefix Discovery Messages 443 The following are the SPD and SAD entries used to protect Mobile 444 Prefix Discovery messages. 446 mobile node SPD-S: 447 - IF source = home_address_1 & destination = home_agent_1 & 448 proto = ICMPv6 & icmp6_type = MPS 449 Then use SA SA5. 451 mobile node SPD-I: 452 - IF source = home_agent_1 & destination = home_address_1 & 453 proto = ICMPv6 & icmp6_type = MPA 454 Then use SA SA6 456 mobile node SAD: 457 - SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT): 458 source = home_address_1 & destination = home_agent_1 & 459 proto = ICMPv6 & icmp6_type = MPS 460 - SA6(IN, spi_f, home_address_1, ESP, TRANSPORT): 461 source = home_agent_1 & destination = home_address_1 & 462 proto = ICMPv6 & icmp6_type = MPA 464 home agent SPD-S: 465 - IF source = home_agent_1 & destination = home_address_1 & 466 proto = ICMPv6 & icmp6_type = MPA 467 Then use SA SA6 469 home agent SPD-I: 470 - IF source = home_address_1 & destination = home_agent_1 & 471 proto = ICMPv6 & icmp6_type = MPS 472 Then use SA SA5 474 home agent SAD: 475 - SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT): 476 source = home_agent_1 & destination = home_address_1 & 477 proto = ICMPv6 & icmp6_type = MPA 478 - SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT): 479 source = home_address_1 & destination = home_agent_1 & 480 proto = ICMPv6 & icmp6_type = MPS 482 5.4 Payload Packets 484 Payload traffic tunneled through the Home Agent can be protected by 485 IPsec, if required. The mobile node and the Home Agent use ESP in 486 tunnel mode to protect the tunneled traffic. The SPD and SAD entries 487 shown in Section 5.2.4 of [3] are applicable here. 489 6. Dynamic Configuration 491 This section describes the use of IKEv2 to setup the required 492 security associations. 494 6.1 Security Policy Database Entries 496 The following sections describe the security policy entries on the 497 mobile node and the Home Agent. The SPD entries are only example 498 configurations. A particular mobile node implementation and a Home 499 Agent implementation could configure different SPD entries as long as 500 they provide the required security of the Mobile IPv6 signaling 501 messages. In the examples shown below, the identity of the user of 502 the mobile node is assumed to be user_1, the home address of the 503 mobile node is assumed to be home_address_1 and the IPv6 address of 504 the Home Agent is assumed to be home_agent_1. 506 6.1.1 Binding Updates and Acknowledgements 508 The following are the SPD entries on the mobile node and the Home 509 Agent for protecting Binding Updates and Acknowledgements. 511 mobile node SPD-S: 512 - IF destination = home_agent_1 & proto = MH & mh_type = BU 513 Then use SA ESP transport mode 514 IDi = user_1, IDr = home_agent_1, 515 TSi = home_address_1 517 mobile node SPD-I: 518 - IF source = home_agent_1 & proto = MH & mh_type = BAck 519 Then use SA ESP transport mode 520 IDi = user_1, IDr = home_agent_1, 521 TSi = home_address_1 523 home agent SPD-S: 524 - IF source = home_agent_1 & proto = MH & mh_type = BAck 525 Then use SA ESP transport mode 526 IDr = user_1, IDi = home_agent_1, 527 TSr = home_address_1 529 home agent SPD-I: 530 - IF destination = home_agent_1 & proto = MH & mh_type = BU 531 Then use SA ESP transport mode 532 IDr = user_1, IDi = home_agent_1, 533 TSr = home_address_1 535 In the examples shown above, the home address of the mobile node 536 might not be available all the time. For instance, the mobile node 537 might have not configured a home address yet. When the mobile node 538 acquires a new home address, it must either add the address to the 539 corresponding SPD entries or create the SPD entries for the home 540 address. 542 The Home Agent should have named SPD entries per mobile node, based 543 on the identity of the mobile node. The identity of the mobile node 544 is stored in the "Name" selector in the SPD [5]. The Home Address 545 presented by the mobile node during the IKE negotiation is stored as 546 the Remote IP address in the resultant IPsec security associations. 547 The home agent MAY also have generic SPD entries to prevent mobility 548 header traffic that requires IPsec protection from bypassing the 549 IPsec filters. 551 The Mobility Header message type is negotiated by placing it in the 552 most significant eight bits of the 16 bit local "port" selector 553 during IKEv2 exchange. For more details, refer to [5]. The TSi and 554 TSr payloads in the above examples will contain many other selectors 555 apart from home_address_1. For the sake of brevity, they are not 556 shown here. 558 6.1.2 Return Routability Messages 560 The following are the SPD entries on the mobile node and the Home 561 Agent for protecting the Return Routability messages. 563 mobile node SPD-S: 564 - IF proto = MH & mh_type = HoTi 565 Then use SA ESP tunnel mode 566 IDi = user_1, 567 outer src addr = coa 568 outer dst addr = home_agent_1, 569 inner src addr = home_address_1 571 mobile node SPD-I: 572 - IF destination = home_address_1 & proto = MH & mh_type = HoT 573 Then use SA ESP tunnel mode 574 IDi = user_1, 575 outer src addr = home_agent_1, 576 outer dst addr = coa, 578 home agent SPD-S: 579 - IF proto = MH & mh_type = HoT 580 Then use SA ESP tunnel mode 581 IDr = user_1, 582 outer src addr = home_agent_1, 583 outer dst addr = coa, 584 inner dst addr = home_address_1 586 home agent SPD-I: 587 - IF proto = MH & mh_type = HoTi 588 Then use SA ESP tunnel mode 589 IDr = user_1, 590 outer src addr = coa, 591 outer dst addr = home_agent_1, 592 inner src addr = home_address_1 594 When the mobile node's Care-of Address changes the SPD entries on 595 both the mobile node and the Home Agent must be updated. The Home 596 Agent knows about the change in Care-of Address of the mobile node 597 when it receives a Binding Update from the mobile node. 599 6.1.3 Mobile Prefix Discovery Messages 601 The following are the SPD entries on the mobile node and the Home 602 Agent for protecting Mobile Prefix Discovery messages. 604 mobile node SPD-S: 605 - IF destination = home_agent_1 & proto = ICMPv6 & 606 icmp6_type = MPS 607 Then use SA ESP transport mode 608 IDi = user_1, IDr = home_agent_1, 609 TSi = home_address_1 610 mobile node SPD-I: 611 - IF source = home_agent_1 & proto = ICMPv6 & icmp6_type = MPA 612 Then use SA ESP transport mode 613 IDi = user_1, IDr = home_agent_1, 614 TSi = home_address_1 616 home agent SPD-S: 617 - IF source = home_agent_1 & proto = ICMPv6 & icmp6_type = MPA 618 Then use SA ESP transport mode 619 IDr = user_1, IDi = home_agent_1, 620 TSr = home_address_1 622 home agent SPD-I: 623 - IF destination = home_agent_1 & proto = ICMPv6 & 624 icmp6_type = MPS 625 Then use SA ESP transport mode 626 IDr = user_1, IDi = home_agent_1, 627 TSr = home_address_1 629 In the examples shown above, the home address of the mobile node 630 might not be available all the time. When the mobile node acquires a 631 new home address, it must add the address to the corresponding SPD 632 entries. 634 The TSi and TSr payloads in the above examples will contain many 635 other selectors apart from home_address_1. For brevity, they are not 636 show here. 638 6.1.4 Payload Packets 640 The following are the SPD entries on the mobile node and the Home 641 Agent if payload traffic exchanged between the mobile node and its 642 Correspondent Node needs to be protected. The SPD entries are 643 similar to the entries for protecting Return Routability messages and 644 have lower priority than the above SPD entries. 646 mobile node SPD-S: 647 - IF interface = IPv6 tunnel to home_agent_1 & 648 proto = X 649 Then use SA ESP tunnel mode 650 IDi = user_1, 651 outer src addr = coa 652 outer dst addr = home_agent_1, 653 inner src addr = home_address_1 655 mobile node SPD-I: 656 - IF destination = home_address_1 & proto = X & 657 source = any_cn 658 Then use SA ESP tunnel mode 659 IDi = user_1, 660 outer src addr = home_agent_1, 661 outer dst addr = coa, 663 home agent SPD-S: 664 - IF interface = IPv6 tunnel to home_address_1 & 665 proto = X 666 Then use SA ESP tunnel mode 667 IDr = user_1, 668 outer src addr = home_agent_1, 669 outer dst addr = coa, 670 inner dst addr = home_address_1 672 home agent SPD-I: 673 - IF interface = IPv6 tunnel to home_address_1 & 674 proto = X 675 Then use SA ESP tunnel mode 676 IDr = user_1, 677 outer src addr = coa, 678 outer dst addr = home_agent_1, 679 inner src addr = home_address_1 681 6.2 Security Association negotiation using IKEv2 683 Mobile IPv6 signaling messages are typically initiated by the mobile 684 node. The mobile node sends a Binding Update to the Home Agent 685 whenever it moves and acquires a new Care-of Address. 687 The mobile node initiates an IKEv2 protocol exchange if the required 688 security associations are not present. The default mechanism used 689 for mutual authentication is a shared secret between the mobile node 690 and the Home Agent. The Home Agent uses the identity of the mobile 691 node to identify the corresponding shared secret. If public key 692 based mechanism is available, it should be the preferred mechanism 693 for mutual authentication. The Home Agent and the mobile node should 694 use their private keys to generate the AUTH payload, when a public 695 key based mechanism is used. The mobile node and the Home Agent 696 should use CERTREQ and CERT payloads if the identities need to be 697 verified. If the mobile node is configured with the Home Agent 698 information including the public key that corresponds to the Home 699 Agent, then the mobile node MAY exclude the CERTREQ payload in 700 message 3. Similarly, the Home Agent MAY exclude the CERTREQ payload 701 in message 2, if it is configured with the mobile node information. 703 If a shared secret is being used, the mobile node uses the shared 704 secret to generate the AUTH payload in the IKE_AUTH exchange. If the 705 mobile node is using a public key based mechanism, then it uses its 706 private key to generate the AUTH payload in the IKE_AUTH exchange. 708 Mobile Node Home Agent 709 ----------- ---------- 710 HDR, SAi1, KEi, Ni --> 712 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 714 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 715 AUTH, SAi2, TSi, TSr} 716 --> 718 <-- HDR, SK {IDr, [CERT,] AUTH, 719 SAr2, TSi, TSr} 721 The mobile node MUST always includes its identity in the IDi payload 722 in the IKE_AUTH exchange. The mobile node could use the following 723 different types of identities to identity itself to the Home Agent. 725 o Home Address - The mobile node could use its statically configured 726 home address as its identity. In this case the ID Type field is 727 set to ID_IPV6_ADDR. 728 o FQDN - The mobile node can use a Fully Qualified Domain Name as 729 the identifier and set the ID Type field to ID_FQDN. 730 o RFC 822 identifier - If the mobile node uses a RFC 822 identifier 731 [10], it sets the ID Type field to ID_RFC822_ADDR. 733 In the IKE_AUTH exchange, the mobile node includes the home address 734 and the appropriate selectors in the TSi (Traffic Selector-initiator) 735 payload to negotiate IPsec security associations for protecting the 736 Binding Update and Binding Acknowledgement messages. The mobile node 737 MAY use a range of selectors that includes the mobility message types 738 for Binding Update and Binding Acknowledgement to use the same pair 739 of IPsec security association for both messages. 741 After the IKE_AUTH exchange completes, the mobile node and the Home 742 Agent initiate CREATE_CHILD_SA exchanges to negotiate additional 743 security associations for protecting Return Routability signaling, 744 Mobile Prefix Discovery messages and optionally payload traffic. The 745 CREATE_CHILD_SA exchanges are protected by the security association 746 created during the IKE_AUTH exchange. 748 It is important that the security associations are created based on 749 the home address of the mobile node, so that the security 750 associations survive Care-of Address change. The mobile node MUST 751 use its home address as the initiator IP address in the TSi payload 752 in the CREATE_CHILD_SA exchange in order to create the security 753 associations for the home address. 755 Mobile Node Home Agent 756 ----------- ---------- 757 HDR, SK {[N], SA, Ni, [KEi], 758 [TSi, TSr]} --> 760 <-- HDR, SK {SA, Nr, [KEr], 761 [TSi, TSr]} 763 When PKI based authentication is used between the mobile and the Home 764 Agent, the identity presented by the mobile node in the IDi payload 765 must correspond to the identity in the certificate obtained by the 766 Home Agent. The Home Agent uses the identity presented in the IDi 767 payload to lookup the policy and the certificate that corresponds to 768 the mobile node. If the mobile node presents its home address in the 769 IDi payload, then the Home Agent MUST verify that the home address 770 matches the address in the iPAddress field in the SubjectAltName 771 extension [9]. 773 6.3 Movements and Dynamic Keying 775 If the mobile node moves and its care-of address changes, the IKEv2 776 SA might not be valid, unless the mobility extensions defined in [14] 777 are implemented by both the mobile node and the Home Agent. RFC 3775 778 defines a mechanism based on the successful exchange of Binding 779 Update and Binding Acknowledgement messages. The IKE SA endpoints 780 are updated on the Home Agent when it receives the Binding Update 781 from the mobile node's new care-of address and on the mobile node 782 when it receives the Binding acknowledgement sent by the Home Agent. 783 This capability to change IKE endpoints is indicated through setting 784 the Key Management Capability (K) flag [2] in the Binding Update and 785 Binding Acknowledgement messages. If the mobile node or the Home 786 Agent does not support this capability, then an IKEv2 exchange MUST 787 be initiated to re-establish the IKE SA. 789 7. The use of EAP authentication 791 In addition to using public key signatures and shared secrets, EAP 792 [11] can be used with IKEv2 for authenticating the mobile node to the 793 Home Agent. 795 The mobile node indicates that it wants to use EAP by including the 796 IDi payload but leaving out the AUTH payload in the first message 797 during the IKE_AUTH exchange. The Home Agent then includes an EAP 798 payload if it is willing to use an extensible authentication method. 799 Security associations are not created until the subsequent IKE_AUTH 800 exchange after successful EAP authentication. The use of EAP adds at 801 least two round trips to the IKE negotiation. 803 Mobile Node Home Agent 804 ------------ ---------- 805 HDR, SAi1, KEi, Ni --> 807 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 809 HDR, SK {IDi, [CERTREQ,] [IDr,] 810 SAi2, TSi, TSr}--> 812 <-- HDR, SK {IDr, [CERT,] AUTH, 813 EAP } 815 HDR, SK {EAP} --> 817 <-- HDR, SK {EAP (success)} 819 HDR, SK {AUTH} --> 821 <-- HDR, SK {AUTH, SAr2, TSi, 822 TSr} 824 Some EAP methods generate a shared key on the mobile node and the 825 Home Agent once the EAP authentication succeeds. In this case, the 826 shared key is used to generate the AUTH payloads in the subsequent 827 messages. The shared key, if used to generate the AUTH payloads, 828 MUST NOT be used for any other purpose. For more details, refer to 829 [4]. 831 The use of EAP between the mobile node and the Home Agent might 832 require the Home Agent to contact an authorization server like the 833 AAA Home server, on the home link, to authenticate the mobile node. 834 Please refer to [7] for more details. 836 The IKEv2 specification [4] requires that public key based mechanism 837 be used to authenticate the Home Agent to the mobile node, when EAP 838 is used. This should be used by default by the mobile node and the 839 home agent. If the EAP method that is used, supports mutual 840 authentication and key generation, then the mobile node MAY use EAP 841 itself to authenticate the Home Agent. The mobile node can request 842 this by including the EAP_ONLY_AUTHENTICATION notification payload 843 [8] in message 3. If the Home Agent supports the 844 EAP_ONLY_AUTHENTICATION notification payload and agrees to use EAP, 845 it omits the public key based AUTH and CERT payloads in message 4. 846 If the Home Agent does not support this mechanism, it rejects it by 847 including an AUTH payload in message 4. More details can be found in 848 [8]. 850 8. Dynamic Home Address Configuration 852 The mobile node can dynamically configure a home address by including 853 a Configuration Payload in the IKE_AUTH exchange, with a request for 854 an address from the home link. The mobile node should include an 855 INTERNAL_IP6_ADDRESS attribute in the CFG_REQUEST Payload. The 856 mobile node MAY also include the INTERNAL_IP6_SUBNET attribute if it 857 wants to obtain information about the IPv6 prefixes on the home link. 858 If the mobile node wants to configure a DNS server from the home link 859 it can request for the DNS server information by including an 860 INTERNAL_IP6_DNS attribute in the CFG_REQUEST payload. 862 When the Home Agent receives a configuration payload with a 863 CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid home 864 address for the mobile node. The INTERNAL_IP6_ADDRESS attribute in 865 the CFG_REPLY contains the prefix length of the home prefix in 866 addition to a 128 bit home address. The Home Agent could use a local 867 database or contact a DHCPv6 server on the home link to allocate a 868 home address. The Home Agent should also include an 869 INTERNAL_ADDRESS_EXPIRY attribute to indicate to the mobile node, the 870 duration for which the dynamically allocated home address is valid. 872 Mobile Node Home Agent 873 ----------- ---------- 874 HDR, SK {IDi, [CERT,] [CERTREQ,] 875 [IDr,] AUTH, CP(CFG_REQUEST), 876 SAi2, TSi, TSr} 877 --> 879 <-- HDR, SK {IDr, [CERT,] AUTH, 880 CP(CFG_REPLY), SAr2, 881 TSi, TSr} 883 The mobile node could suggest a home address that it wants to use in 884 the CFG_REQUEST. For example, this could be a home address that it 885 was allocated before or could be an address the mobile node auto- 886 configured from the IPv6 prefix on the home link. The Home Agent 887 could let the mobile node use the same home address by setting the 888 INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload to the same 889 home address. If the Home Agent wants the mobile node to use a 890 different home address, it sends a new home address in the 891 INTERNAL_IP_ADDRESS attribute in the CFG_REPLY payload. The Mobile 892 Node MUST stop using its old home address and start using the newly 893 allocated home address. 895 In case the Home Agent is unable to allocate a home address for the 896 mobile node during the IKE_AUTH exchange, it MUST send a Notify 897 Payload with an INTERNAL_ADDRESS_FAILURE message. 899 9. Security Considerations 901 This document describes how IPsec can be used to secure Mobile IPv6 902 signaling messages. Please refer to RFC 3775 for security 903 considerations related to the use of IPsec with Mobile IPv6. 905 A misbehaving mobile node could create IPsec security associations 906 for a home address that belongs to another mobile node. Therefore, 907 the Home Agent should check if a particular mobile node is authorized 908 to use a home address before creating IPsec security associations for 909 the home address. If the home address is assigned as described in 910 Section 8, the Home Agent MUST associate the home address with the 911 identity used in IKE negotiation. The Home Agent MAY store the 912 assigned home address in the SPD entries created for the mobile node. 914 The use of EAP for authenticating the mobile node to the Home Agent 915 is described in Section 7. This document recommends that if the EAP 916 method used, supports mutual authentication, then EAP itself be used 917 for authenticating the Home Agent to the mobile node also. This runs 918 contrary to the recommendation in [4]. The Home Agent can ignore the 919 recommendation in this document and implement EAP authentication as 920 described in the IKEv2 specification. Security considerations 921 related to the use of EAP with IKEv2 are described in [4] and [8]. 923 10. IANA Considerations 925 This document requires no action from IANA. 927 11. Acknowledgements 929 The author would like to thank Mika Joutsenvirta, Pasi Eronen, 930 Francis Dupont, Jari Arkko and Gerardo Giaretta for reviewing the 931 draft. 933 Many of the requirements listed in Section 4 are copied from RFC 934 3776. Therefore, the authors of RFC 3776 are acknowledged. 936 12. References 938 12.1 Normative References 940 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 941 Levels", BCP 14, RFC 2119, March 1997. 943 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 944 IPv6", RFC 3775, June 2004. 946 [3] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 947 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 948 Agents", RFC 3776, June 2004. 950 [4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 951 draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. 953 [5] Kent, S. and K. Seo, "Security Architecture for the Internet 954 Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress), 955 April 2005. 957 [6] Kent, S., "IP Encapsulating Security Payload (ESP)", 958 draft-ietf-ipsec-esp-v3-10 (work in progress), March 2005. 960 12.2 Informative References 962 [7] Giaretta, G., "Goals for AAA-HA interface", 963 draft-giaretta-mip6-aaa-ha-goals-00 (work in progress), 964 September 2004. 966 [8] Eronen, P., "Extension for EAP Authentication in IKEv2", 967 draft-eronen-ipsec-ikev2-eap-auth-03 (work in progress), 968 April 2005. 970 [9] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ 971 ISAKMP, IKEv2, and PKIX", 972 draft-ietf-pki4ipsec-ikecert-profile-04 (work in progress), 973 April 2005. 975 [10] Crocker, D., "Standard for the format of ARPA Internet text 976 messages", STD 11, RFC 822, August 1982. 978 [11] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 979 Levkowetz, "Extensible Authentication Protocol (EAP)", 980 RFC 3748, June 2004. 982 [12] Kent, S. and R. Atkinson, "Security Architecture for the 983 Internet Protocol", RFC 2401, November 1998. 985 [13] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 986 RFC 2409, November 1998. 988 [14] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", 989 draft-ietf-mobike-protocol-00 (work in progress), June 2005. 991 Author's Address 993 Vijay Devarapalli 994 Nokia Research Center 995 313 Fairchild Drive 996 Mountain View, CA 94043 997 USA 999 Email: vijay.devarapalli@nokia.com 1001 Intellectual Property Statement 1003 The IETF takes no position regarding the validity or scope of any 1004 Intellectual Property Rights or other rights that might be claimed to 1005 pertain to the implementation or use of the technology described in 1006 this document or the extent to which any license under such rights 1007 might or might not be available; nor does it represent that it has 1008 made any independent effort to identify any such rights. Information 1009 on the procedures with respect to rights in RFC documents can be 1010 found in BCP 78 and BCP 79. 1012 Copies of IPR disclosures made to the IETF Secretariat and any 1013 assurances of licenses to be made available, or the result of an 1014 attempt made to obtain a general license or permission for the use of 1015 such proprietary rights by implementers or users of this 1016 specification can be obtained from the IETF on-line IPR repository at 1017 http://www.ietf.org/ipr. 1019 The IETF invites any interested party to bring to its attention any 1020 copyrights, patents or patent applications, or other proprietary 1021 rights that may cover technology that may be required to implement 1022 this standard. Please address the information to the IETF at 1023 ietf-ipr@ietf.org. 1025 Disclaimer of Validity 1027 This document and the information contained herein are provided on an 1028 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1029 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1030 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1031 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1032 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1033 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1035 Copyright Statement 1037 Copyright (C) The Internet Society (2005). This document is subject 1038 to the rights, licenses and restrictions contained in BCP 78, and 1039 except as set forth therein, the authors retain all their rights. 1041 Acknowledgment 1043 Funding for the RFC Editor function is currently provided by the 1044 Internet Society.