idnits 2.17.1 draft-ietf-hip-esp-05.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1340. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1351. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1358. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1364. 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 IETF Trust 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 (February 14, 2007) is 6274 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) == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-06 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. 'I-D.ietf-hip-base') -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-09) exists of draft-nikander-esp-beet-mode-06 == Outdated reference: A later version (-05) exists of draft-ietf-hip-mm-04 -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Jokela 3 Internet-Draft Ericsson Research NomadicLab 4 Expires: August 18, 2007 R. Moskowitz 5 ICSAlabs, a Division of TruSecure 6 Corporation 7 P. Nikander 8 Ericsson Research NomadicLab 9 February 14, 2007 11 Using ESP transport format with HIP 12 draft-ietf-hip-esp-05 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 18, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This memo specifies an Encapsulated Security Payload (ESP) based 46 mechanism for transmission of user data packets, to be used with the 47 Host Identity Protocol (HIP). 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Conventions used in this document . . . . . . . . . . . . . . 5 53 3. Using ESP with HIP . . . . . . . . . . . . . . . . . . . . . . 6 54 3.1. ESP Packet Format . . . . . . . . . . . . . . . . . . . . 6 55 3.2. Conceptual ESP Packet Processing . . . . . . . . . . . . . 6 56 3.2.1. Semantics of the Security Parameter Index (SPI) . . . 7 57 3.3. Security Association Establishment and Maintenance . . . . 7 58 3.3.1. ESP Security Associations . . . . . . . . . . . . . . 8 59 3.3.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.3.3. Security Association Management . . . . . . . . . . . 9 61 3.3.4. Security Parameter Index (SPI) . . . . . . . . . . . . 9 62 3.3.5. Supported Transforms . . . . . . . . . . . . . . . . . 9 63 3.3.6. Sequence Number . . . . . . . . . . . . . . . . . . . 10 64 3.3.7. Lifetimes and Timers . . . . . . . . . . . . . . . . . 10 65 3.4. IPsec and HIP ESP Implementation Considerations . . . . . 10 66 4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 4.1. ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4.1.1. Setting up an ESP Security Association . . . . . . . . 12 69 4.1.2. Updating an Existing ESP SA . . . . . . . . . . . . . 13 70 5. Parameter and Packet Formats . . . . . . . . . . . . . . . . . 14 71 5.1. New Parameters . . . . . . . . . . . . . . . . . . . . . . 14 72 5.1.1. ESP_INFO . . . . . . . . . . . . . . . . . . . . . . . 14 73 5.1.2. ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 16 74 5.1.3. NOTIFY Parameter . . . . . . . . . . . . . . . . . . . 18 75 5.2. HIP ESP Security Association Setup . . . . . . . . . . . . 18 76 5.2.1. Setup During Base Exchange . . . . . . . . . . . . . . 18 77 5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . . 19 78 5.3.1. Initializing Rekeying . . . . . . . . . . . . . . . . 20 79 5.3.2. Responding to the Rekeying Initialization . . . . . . 20 80 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 21 81 5.4.1. Unknown SPI . . . . . . . . . . . . . . . . . . . . . 21 82 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 22 83 6.1. Processing Outgoing Application Data . . . . . . . . . . . 22 84 6.2. Processing Incoming Application Data . . . . . . . . . . . 22 85 6.3. HMAC and SIGNATURE Calculation and Verification . . . . . 23 86 6.4. Processing Incoming ESP SA Initialization (R1) . . . . . . 23 87 6.5. Processing Incoming Initialization Reply (I2) . . . . . . 24 88 6.6. Processing Incoming ESP SA Setup Finalization (R2) . . . . 24 89 6.7. Dropping HIP Associations . . . . . . . . . . . . . . . . 24 90 6.8. Initiating ESP SA Rekeying . . . . . . . . . . . . . . . . 24 91 6.9. Processing Incoming UPDATE Packets . . . . . . . . . . . . 26 92 6.9.1. Processing UPDATE Packet: No Outstanding Rekeying 93 Request . . . . . . . . . . . . . . . . . . . . . . . 26 94 6.10. Finalizing Rekeying . . . . . . . . . . . . . . . . . . . 27 95 6.11. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 28 96 7. Keying Material . . . . . . . . . . . . . . . . . . . . . . . 29 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 99 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 101 11.1. Normative references . . . . . . . . . . . . . . . . . . . 33 102 11.2. Informative references . . . . . . . . . . . . . . . . . . 33 103 Appendix A. A Note on Implementation Options . . . . . . . . . . 35 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 105 Intellectual Property and Copyright Statements . . . . . . . . . . 37 107 1. Introduction 109 In the Host Identity Protocol Architecture [RFC4423], hosts are 110 identified with public keys. The Host Identity Protocol 111 [I-D.ietf-hip-base] base exchange allows any two HIP-supporting hosts 112 to authenticate each other and to create a HIP association between 113 themselves. During the base exchange, the hosts generate a piece of 114 shared keying material using an authenticated Diffie-Hellman 115 exchange. 117 The HIP base exchange specification [I-D.ietf-hip-base] does not 118 describe any transport formats, or methods for user data, to be used 119 during the actual communication; it only defines that it is mandatory 120 to implement the Encapsulated Security Payload (ESP) [RFC4303] based 121 transport format and method. This document specifies how ESP is used 122 with HIP to carry actual user data. 124 To be more specific, this document specifies a set of HIP protocol 125 extensions and their handling. Using these extensions, a pair of ESP 126 Security Associations (SAs) is created between the hosts during the 127 base exchange. The resulting ESP Security Associations use keys 128 drawn from the keying material (KEYMAT) generated during the base 129 exchange. After the HIP association and required ESP SAs have been 130 established between the hosts, the user data communication is 131 protected using ESP. In addition, this document specifies methods to 132 update an existing ESP Security Association. 134 It should be noted that representations of host identity are not 135 carried explicitly in the headers of user data packets. Instead, the 136 ESP Security Parameter Index (SPI) is used to indicate the right host 137 context. The SPIs are selected during the HIP ESP setup exchange. 138 For user data packets, ESP SPIs (in possible combination with IP 139 addresses) are used indirectly to identify the host context, thereby 140 avoiding any additional explicit protocol headers. 142 2. Conventions used in this document 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC2119 [RFC2119]. 148 3. Using ESP with HIP 150 The HIP base exchange is used to set up a HIP association between two 151 hosts. The base exchange provides two-way host authentication and 152 key material generation, but it does not provide any means for 153 protecting data communication between the hosts. In this document we 154 specify the use of ESP for protecting user data traffic after the HIP 155 base exchange. Note that this use of ESP is intended only for host- 156 to-host traffic; security gateways are not supported. 158 To support ESP use, the HIP base exchange messages require some minor 159 additions to the parameters transported. In the R1 packet, the 160 responder adds the possible ESP transforms in a new ESP_TRANSFORM 161 parameter before sending it to the Initiator. The Initiator gets the 162 proposed transforms, selects one of those proposed transforms, and 163 adds it to the I2 packet in an ESP_TRANSFORM parameter. In this I2 164 packet, the Initiator also sends the SPI value that it wants to be 165 used for ESP traffic flowing from the Responder to the Initiator. 166 This information is carried using the new ESP_INFO parameter. When 167 finalizing the ESP SA setup, the Responder sends its SPI value to the 168 Initiator in the R2 packet, again using ESP_INFO. 170 3.1. ESP Packet Format 172 The ESP specification [RFC4303] defines the ESP packet format for 173 IPsec. The HIP ESP packet looks exactly the same as the IPsec ESP 174 transport format packet. The semantics, however, are a bit different 175 and are described in more detail in the next subsection. 177 3.2. Conceptual ESP Packet Processing 179 ESP packet processing can be implemented in different ways in HIP. 180 It is possible to implement it in a way that a standards compliant, 181 unmodified IPsec implementation [RFC4303] can be used. 183 When a standards compliant IPsec implementation that uses IP 184 addresses in the SPD and SAD is used, the packet processing may take 185 the following steps. For outgoing packets, assuming that the upper 186 layer pseudoheader has been built using IP addresses, the 187 implementation recalculates upper layer checksums using HITs and, 188 after that, changes the packet source and destination addresses back 189 to corresponding IP addresses. The packet is sent to the IPsec ESP 190 for transport mode handling and from there the encrypted packet is 191 sent to the network. When an ESP packet is received, the packet is 192 first put to the IPsec ESP transport mode handling, and after 193 decryption, the source and destination IP addresses are replaced with 194 HITs and finally, upper layer checksums are verified before passing 195 the packet to the upper layer. 197 An alternative way to implement the packet processing is the BEET 198 (Bound End-to-End Tunnel) [I-D.nikander-esp-beet-mode] mode. In BEET 199 mode, the ESP packet is formatted as a transport mode packet, but the 200 semantics of the connection are the same as for tunnel mode. The 201 "outer" addresses of the packet are the IP addresses and the "inner" 202 addresses are the HITs. For outgoing traffic, after the packet has 203 been encrypted, the packet's IP header is changed to a new one, 204 containing IP addresses instead of HITs and the packet is sent to the 205 network. When ESP packet is received, the SPI value, together with 206 the integrity protection, allow the packet to be securely associated 207 with the right HIT pair. The packet header is replaces with a new 208 header, containing HITs and the packet is decrypted. 210 3.2.1. Semantics of the Security Parameter Index (SPI) 212 SPIs are used in ESP to find the right Security Association for 213 received packets. The ESP SPIs have added significance when used 214 with HIP; they are a compressed representation of a pair of HITs. 215 Thus, SPIs MAY be used by intermediary systems in providing services 216 like address mapping. Note that since the SPI has significance at 217 the receiver, only the < DST, SPI >, where DST is a destination IP 218 address, uniquely identifies the receiver HIT at any given point of 219 time. The same SPI value may be used by several hosts. A single < 220 DST, SPI > value may denote different hosts and contexts at different 221 points of time, depending on the host that is currently reachable at 222 the DST. 224 Each host selects for itself the SPI it wants to see in packets 225 received from its peer. This allows it to select different SPIs for 226 different peers. The SPI selection SHOULD be random; the rules of 227 Section 2.1 of the ESP specification [RFC4303] must be followed. A 228 different SPI SHOULD be used for each HIP exchange with a particular 229 host; this is to avoid a replay attack. Additionally, when a host 230 rekeys, the SPI MUST be changed. Furthermore, if a host changes over 231 to use a different IP address, it MAY change the SPI. 233 One method for SPI creation that meets the above criteria would be to 234 concatenate the HIT with a 32-bit random or sequential number, hash 235 this (using SHA1), and then use the high order 32 bits as the SPI. 237 The selected SPI is communicated to the peer in the third (I2) and 238 fourth (R2) packets of the base HIP exchange. Changes in SPI are 239 signaled with ESP_INFO parameters. 241 3.3. Security Association Establishment and Maintenance 242 3.3.1. ESP Security Associations 244 In HIP, ESP Security Associations are setup between the HIP nodes 245 during the base exchange [I-D.ietf-hip-base]. Existing ESP SAs can 246 be updated later using UPDATE messages. The reason for updating the 247 ESP SA later can be e.g. need for rekeying the SA because of sequence 248 number rollover. 250 Upon setting up a HIP association, each association is linked to two 251 ESP SAs, one for incoming packets and one for outgoing packets. The 252 Initiator's incoming SA corresponds with the Responder's outgoing 253 one, and vice versa. The Initiator defines the SPI for its incoming 254 association, as defined in Section 3.2.1. This SA is herein called 255 SA-RI, and the corresponding SPI is called SPI-RI. Respectively, the 256 Responder's incoming SA corresponds with the Initiator's outgoing SA 257 and is called SA-IR, with the SPI being called SPI-IR. 259 The Initiator creates SA-RI as a part of R1 processing, before 260 sending out the I2, as explained in Section 6.4. The keys are 261 derived from KEYMAT, as defined in Section 7. The Responder creates 262 SA-RI as a part of I2 processing, see Section 6.5. 264 The Responder creates SA-IR as a part of I2 processing, before 265 sending out R2; see Section 6.5. The Initiator creates SA-IR when 266 processing R2; see Section 6.6. 268 The initial session keys are drawn from the generated keying 269 material, KEYMAT, after the HIP keys have been drawn as specified in 270 [I-D.ietf-hip-base]. 272 When the HIP association is removed, the related ESP SAs MUST also be 273 removed. 275 3.3.2. Rekeying 277 After the initial HIP base exchange and SA establishment, both hosts 278 are in the ESTABLISHED state. There are no longer Initiator and 279 Responder roles and the association is symmetric. In this 280 subsection, the party that initiates the rekey procedure is denoted 281 with I' and the peer with R'. 283 An existing HIP-created ESP SA may need updating during the lifetime 284 of the HIP association. This document specifies the rekeying of an 285 existing HIP-created ESP SA, using the UPDATE message. The ESP_INFO 286 parameter introduced above is used for this purpose. 288 I' initiates the ESP SA updating process when needed (see 289 Section 6.8). It creates an UPDATE packet with required information 290 and sends it to the peer node. The old SAs are still in use, local 291 policy permitting. 293 R', after receiving and processing the UPDATE (see Section 6.9), 294 generates new SAs: SA-I'R' and SA-R'I'. It does not take the new 295 outgoing SA into use, but still uses the old one, so there 296 temporarily exists two SA pairs towards the same peer host. The SPI 297 for the new outgoing SA, SPI-R'I', is specified in the received 298 ESP_INFO parameter in the UPDATE packet. For the new incoming SA, R' 299 generates the new SPI value, SPI-I'R', and includes it in the 300 response UPDATE packet. 302 When I' receives a response UPDATE from R', it generates new SAs, as 303 described in Section 6.9: SA-I'R' and SA-R'I'. It starts using the 304 new outgoing SA immediately. 306 R' starts using the new outgoing SA when it receives traffic on the 307 new incoming SA or when it receives the UPDATE ACK confirming 308 completion of rekeying. After this, R' can remove the old SAs. 309 Similarly, when the I' receives traffic from the new incoming SA, it 310 can safely remove the old SAs. 312 3.3.3. Security Association Management 314 An SA pair is indexed by the 2 SPIs and 2 HITs (both local and remote 315 HITs since a system can have more than one HIT). An inactivity timer 316 is RECOMMENDED for all SAs. If the state dictates the deletion of an 317 SA, a timer is set to allow for any late arriving packets. 319 3.3.4. Security Parameter Index (SPI) 321 The SPIs in ESP provide a simple compression of the HIP data from all 322 packets after the HIP exchange. This does require a per HIT-pair 323 Security Association (and SPI), and a decrease of policy granularity 324 over other Key Management Protocols like IKE. 326 When a host updates the ESP SA, it provides a new inbound SPI to and 327 gets a new outbound SPI from its partner. 329 3.3.5. Supported Transforms 331 All HIP implementations MUST support AES-CBC [RFC3602] and HMAC-SHA- 332 1-96 [RFC2404]. If the Initiator does not support any of the 333 transforms offered by the Responder, it should abandon the 334 negotiation and inform the peer with a NOTIFY message about a non- 335 supported transform. 337 In addition to AES-CBC, all implementations MUST implement the ESP 338 NULL encryption algorithm. When the ESP NULL encryption is used, it 339 MUST be used together with SHA1 or MD5 authentication as specified in 340 Section 5.1.2 342 3.3.6. Sequence Number 344 The Sequence Number field is MANDATORY when ESP is used with HIP. 345 Anti-replay protection MUST be used in an ESP SA established with 346 HIP. When ESP is used with HIP, a 64-bit sequence number MUST be 347 used. This means that each host MUST rekey before its sequence 348 number reaches 2^64. 350 When using a 64-bit sequence number, the higher 32 bits are NOT 351 included in the ESP header, but are simply kept local to both peers. 352 See [I-D.ietf-ipsec-rfc2401bis]. 354 3.3.7. Lifetimes and Timers 356 HIP does not negotiate any lifetimes. All ESP lifetimes are local 357 policy. The only lifetimes a HIP implementation MUST support are 358 sequence number rollover (for replay protection), and SHOULD support 359 timing out inactive ESP SAs. An SA times out if no packets are 360 received using that SA. The default timeout value is 15 minutes. 361 Implementations MAY support lifetimes for the various ESP transforms. 362 Each implementation SHOULD implement per-HIT configuration of the 363 inactivity timeout, allowing statically configured HIP associations 364 to stay alive for days, even when inactive. 366 3.4. IPsec and HIP ESP Implementation Considerations 368 When HIP is run on a node where a standards compliant IPsec is used, 369 some issues have to be considered. 371 The HIP implementation must be able to co-exist with other IPsec 372 keying protocols. When the HIP implementation selects the SPI value, 373 it may lead to a collision if not implemented properly. To avoid the 374 possibility for a collision, the HIP implementation MUST ensure that 375 the SPI values used for HIP SAs are not used for IPsec or other SAs, 376 and vice versa. 378 For outbound traffic the SPD or (coordinated) SPDs if there are two 379 (one for HIP and one for IPsec) MUST ensure that packets intended for 380 HIP processing are given a HIP-enabled SA and packets intended for 381 IPsec processing are given an IPsec-enabled SA. The SP then MUST be 382 bound to the matching SA and non-HIP packets will not be processed by 383 this SA. Data originating from a socket that is not using HIP, MUST 384 NOT have checksum recalculated as described in Section 3.2 paragraph 385 2 and data MUST NOT be passed to the SP or SA created by the HIP. 387 Incoming data packets using a SA that is not negotiated by HIP, MUST 388 NOT be processed as described in Section 3.2 paragraph 2. The SPI 389 will identify the correct SA for packet decryption and MUST be used 390 to identify that the packet has an upper-layer checksum that is 391 calculated as specified in [I-D.ietf-hip-base]. 393 4. The Protocol 395 In this section, the protocol for setting up an ESP association to be 396 used with HIP association is described. 398 4.1. ESP in HIP 400 4.1.1. Setting up an ESP Security Association 402 Setting up an ESP Security Association between hosts using HIP 403 consists of three messages passed between the hosts. The parameters 404 are included in R1, I2, and R2 messages during base exchange. 406 Initiator Responder 408 I1 409 ----------------------------------> 411 R1: ESP_TRANSFORM 412 <---------------------------------- 414 I2: ESP_TRANSFORM, ESP_INFO 415 ----------------------------------> 417 R2: ESP_INFO 418 <---------------------------------- 420 Setting up an ESP Security Association between HIP hosts requires 421 three messages to exchange the information that is required during an 422 ESP communication. 424 The R1 message contains the ESP_TRANSFORM parameter, in which the 425 sending host defines the possible ESP transforms it is willing to use 426 for the ESP SA. 428 The I2 message contains the response to an ESP_TRANSFORM received in 429 the R1 message. The sender must select one of the proposed ESP 430 transforms from the ESP_TRANSFORM parameter in the R1 message and 431 include the selected one in the ESP_TRANSFORM parameter in the I2 432 packet. In addition to the transform, the host includes the ESP_INFO 433 parameter, containing the SPI value to be used by the peer host. 435 In the R2 message, the ESP SA setup is finalized. The packet 436 contains the SPI information required by the Initiator for the ESP 437 SA. 439 4.1.2. Updating an Existing ESP SA 441 The update process is accomplished using two messages. The HIP 442 UPDATE message is used to update the parameters of an existing ESP 443 SA. The UPDATE mechanism and message is defined in 444 [I-D.ietf-hip-base] and the additional parameters for updating an 445 existing ESP SA are described here. 447 The following picture shows a typical exchange when an existing ESP 448 SA is updated. Messages include SEQ and ACK parameters required by 449 the UPDATE mechanism. 451 H1 H2 452 UPDATE: SEQ, ESP_INFO [, DIFFIE_HELLMAN] 453 -----------------------------------------------------> 455 UPDATE: SEQ, ACK, ESP_INFO [, DIFFIE_HELLMAN] 456 <----------------------------------------------------- 458 UPDATE: ACK 459 -----------------------------------------------------> 461 The host willing to update the ESP SA creates and sends an UPDATE 462 message. The message contains the ESP_INFO parameter, containing the 463 old SPI value that was used, the new SPI value to be used, and the 464 index value for the keying material, giving the point from where the 465 next keys will be drawn. If new keying material must be generated, 466 the UPDATE message will also contain the DIFFIE_HELLMAN parameter, 467 defined in [I-D.ietf-hip-base]. 469 The host receiving the UPDATE message requesting update of an 470 existing ESP SA, MUST reply with an UPDATE message. In the reply 471 message, the host sends the ESP_INFO parameter containing the 472 corresponding values: old SPI, new SPI, and the keying material 473 index. If the incoming UPDATE contained a DIFFIE_HELLMAN parameter, 474 the reply packet MUST also contain a DIFFIE_HELLMAN parameter. 476 5. Parameter and Packet Formats 478 In this section, new and modified HIP parameters are presented, as 479 well as modified HIP packets. 481 5.1. New Parameters 483 Two new HIP parameters are defined for setting up ESP transport 484 format associations in HIP communication and for rekeying existing 485 ones. Also, the NOTIFY parameter, described in [I-D.ietf-hip-base], 486 has two new error parameters. 488 Parameter Type Length Data 490 ESP_INFO 65 12 Remote's old SPI, 491 new SPI and other info 492 ESP_TRANSFORM 4095 variable ESP Encryption and 493 Authentication Transform(s) 495 5.1.1. ESP_INFO 497 During the establishment and update of an ESP SA, the SPI value of 498 both hosts must be transmitted between the hosts. Additional 499 information that is required when the hosts are drawing keys from the 500 generated keying material is the index value into the KEYMAT from 501 where the keys are drawn. The ESP_INFO parameter is used to transmit 502 this information between the hosts. 504 During the initial ESP SA setup, the hosts send the SPI value that 505 they want the peer to use when sending ESP data to them. The value 506 is set in the New SPI field of the ESP_INFO parameter. In the 507 initial setup, an old value for the SPI does not exist, thus the Old 508 SPI value field is set to zero. The Old SPI field value may also be 509 zero when additional SAs are set up between HIP hosts, e.g. in case 510 of multihomed HIP hosts [I-D.ietf-hip-mm]. However, such use is 511 beyond the scope of this specification. 513 RFC4301 [RFC4301] describes how to establish multiple SAs to properly 514 support QoS. If different classes of traffic (distinguished by 515 Differentiated Services Code Point (DSCP) bits [[RFC3474], [RFC3260]) 516 are sent on the same SA, and if the receiver is employing the 517 optional anti-replay feature available in ESP, this could result in 518 inappropriate discarding of lower priority packets due to the 519 windowing mechanism used by this feature. Therefore, a sender SHOULD 520 put traffic of different classes, but with the same selector values, 521 on different SAs to support Quality of Service (QoS) appropriately. 522 To permit this, the implementation MUST permit establishment and 523 maintenance of multiple SAs between a given sender and receiver, with 524 the same selectors. Distribution of traffic among these parallel SAs 525 to support QoS is locally determined by the sender and is not 526 negotiated by HIP. The receiver MUST process the packets from the 527 different SAs without prejudice. It is possible that the DSCP value 528 changes en route, but this should not cause problems with respect to 529 IPsec processing since the value is not employed for SA selection and 530 MUST NOT be checked as part of SA/packet validation. 532 The Keymat index value points to the place in the KEYMAT from where 533 the keying material for the ESP SAs is drawn. The Keymat index value 534 is zero only when the ESP_INFO is sent during a rekeying process and 535 new keying material is generated. 537 During the life of an SA established by HIP, one of the hosts may 538 need to reset the Sequence Number to one and rekey. The reason for 539 rekeying might be an approaching sequence number wrap in ESP, or a 540 local policy on use of a key. Rekeying ends the current SAs and 541 starts new ones on both peers. 543 During the rekeying process, the ESP_INFO parameter is used to 544 transmit the changed SPI values and the keying material index. 546 0 1 2 3 547 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Type | Length | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Reserved | Keymat Index | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Old SPI | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | New SPI | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 Type 65 559 Length 12 560 Keymat Index Index, in bytes, where to continue to draw ESP keys 561 from KEYMAT. If the packet includes a new 562 Diffie-Hellman key and the ESP_INFO is sent in an 563 UPDATE packet, the field MUST be zero. If the 564 ESP_INFO is included in base exchange messages, the 565 Keymat Index must have the index value of the point 566 from where the ESP SA keys are drawn. Note that the 567 length of this field limits the amount of 568 keying material that can be drawn from KEYMAT. If 569 that amount is exceeded, the packet MUST contain 570 a new Diffie-Hellman key. 571 Old SPI Old SPI for data sent to address(es) associated 572 with this SA. If this is an initial SA setup, the 573 Old SPI value is zero. 574 New SPI New SPI for data sent to address(es) associated 575 with this SA. 577 5.1.2. ESP_TRANSFORM 579 The ESP_TRANSFORM parameter is used during ESP SA establishment. The 580 first party sends a selection of transform families in the 581 ESP_TRANSFORM parameter and the peer must select one of the proposed 582 values and include it in the response ESP_TRANSFORM parameter. 584 0 1 2 3 585 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Type | Length | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Reserved | Suite-ID #1 | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Suite-ID #2 | Suite-ID #3 | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Suite-ID #n | Padding | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 Type 4095 597 Length length in octets, excluding Type, Length, and 598 padding 599 Reserved zero when sent, ignored when received 600 Suite-ID defines the ESP Suite to be used 602 The following Suite-IDs are defined in [RFC2104] (HMAC-SHA1, HMAC- 603 MD5), [RFC3602] (AES-CBC), and [RFC2451] (3DES-CBC, Blowfish): 605 Suite-ID Value 607 RESERVED 0 608 ESP-AES-CBC with HMAC-SHA1 1 609 ESP-3DES-CBC with HMAC-SHA1 2 610 ESP-3DES-CBC with HMAC-MD5 3 611 ESP-BLOWFISH-CBC with HMAC-SHA1 4 612 ESP-NULL with HMAC-SHA1 5 613 ESP-NULL with HMAC-MD5 6 615 The sender of an ESP transform parameter MUST make sure that there 616 are no more than six (6) Suite-IDs in one ESP transform parameter. 617 Conversely, a recipient MUST be prepared to handle received transport 618 parameters that contain more than six Suite-IDs. The limited number 619 of Suite-IDs sets the maximum size of ESP_TRANSFORM parameter. As 620 the default configuration, the ESP_TRANSFORM parameter MUST contain 621 at least one of the mandatory Suite-IDs. There MAY be a 622 configuration option that allows the administrator to override this 623 default. 625 Mandatory implementations: ESP-AES-CBC with HMAC-SHA1 and ESP-NULL 626 with HMAC-SHA1. 628 Under some conditions it is possible to use Traffic Flow 629 Confidentiality (TFC) [RFC4303] with ESP in BEET mode. However, the 630 definition of such operation is future work and must be done in a 631 separate specification. 633 5.1.3. NOTIFY Parameter 635 The HIP base specification defines a set of NOTIFY error types. The 636 following error types are required for describing errors in ESP 637 Transform crypto suites during negotiation. 639 NOTIFY PARAMETER - ERROR TYPES Value 640 ------------------------------ ----- 642 NO_ESP_PROPOSAL_CHOSEN 18 644 None of the proposed ESP Transform crypto suites was 645 acceptable. 647 INVALID_ESP_TRANSFORM_CHOSEN 19 649 The ESP Transform crypto suite does not correspond to 650 one offered by the responder. 652 5.2. HIP ESP Security Association Setup 654 The ESP Security Association is set up during the base exchange. The 655 following subsections define the ESP SA setup procedure both using 656 base exchange messages (R1, I2, R2) and using UPDATE messages. 658 5.2.1. Setup During Base Exchange 660 5.2.1.1. Modifications in R1 662 The ESP_TRANSFORM contains the ESP modes supported by the sender, in 663 the order of preference. All implementations MUST support AES-CBC 664 [RFC3602] with HMAC-SHA-1-96 [RFC2404]. 666 The following figure shows the resulting R1 packet layout. 668 The HIP parameters for the R1 packet: 670 IP ( HIP ( [ R1_COUNTER, ] 671 PUZZLE, 672 DIFFIE_HELLMAN, 673 HIP_TRANSFORM, 674 ESP_TRANSFORM, 675 HOST_ID, 676 [ ECHO_REQUEST, ] 677 HIP_SIGNATURE_2 ) 678 [, ECHO_REQUEST ]) 680 5.2.1.2. Modifications in I2 682 The ESP_INFO contains the sender's SPI for this association as well 683 as the keymat index from where the ESP SA keys will be drawn. The 684 Old SPI value is set to zero. 686 The ESP_TRANSFORM contains the ESP mode selected by the sender of R1. 687 All implementations MUST support AES-CBC [RFC3602] with HMAC-SHA-1-96 688 [RFC2404]. 690 The following figure shows the resulting I2 packet layout. 692 The HIP parameters for the I2 packet: 694 IP ( HIP ( ESP_INFO, 695 [R1_COUNTER,] 696 SOLUTION, 697 DIFFIE_HELLMAN, 698 HIP_TRANSFORM, 699 ESP_TRANSFORM, 700 ENCRYPTED { HOST_ID }, 701 [ ECHO_RESPONSE ,] 702 HMAC, 703 HIP_SIGNATURE 704 [, ECHO_RESPONSE] ) ) 706 5.2.1.3. Modifications in R2 708 The R2 contains an ESP_INFO parameter, which has the SPI value of the 709 sender of the R2 for this association. The ESP_INFO also has the 710 keymat index value specifying where the ESP SA keys are drawn. 712 The following figure shows the resulting R2 packet layout. 714 The HIP parameters for the R2 packet: 716 IP ( HIP ( ESP_INFO, HMAC_2, HIP_SIGNATURE ) ) 718 5.3. HIP ESP Rekeying 720 In this section, the procedure for rekeying an existing ESP SA is 721 presented. 723 Conceptually, the process can be represented by the following message 724 sequence using the host names I' and R' defined in Section 3.3.2. 725 For simplicity, HMAC and HIP_SIGNATURE are not depicted, and 726 DIFFIE_HELLMAN keys are optional. The UPDATE with ACK_I need not be 727 piggybacked with the UPDATE with SEQ_R; it may be acked separately 728 (in which case the sequence would include four packets). 730 I' R' 732 UPDATE(ESP_INFO, SEQ_I, [DIFFIE_HELLMAN]) 733 -----------------------------------> 734 UPDATE(ESP_INFO, SEQ_R, ACK_I, [DIFFIE_HELLMAN]) 735 <----------------------------------- 736 UPDATE(ACK_R) 737 -----------------------------------> 739 Below, the first two packets in this figure are explained. 741 5.3.1. Initializing Rekeying 743 When HIP is used with ESP, the UPDATE packet is used to initiate 744 rekeying. The UPDATE packet MUST carry an ESP_INFO and MAY carry a 745 DIFFIE_HELLMAN parameter. 747 Intermediate systems that use the SPI will have to inspect HIP 748 packets for those that carry rekeying information. The packet is 749 signed for the benefit of the intermediate systems. Since 750 intermediate systems may need the new SPI values, the contents cannot 751 be encrypted. 753 The following figure shows the contents of a rekeying initialization 754 UPDATE packet. 756 The HIP parameters for the UPDATE packet initiating rekeying: 758 IP ( HIP ( ESP_INFO, 759 SEQ, 760 [DIFFIE_HELLMAN, ] 761 HMAC, 762 HIP_SIGNATURE ) ) 764 5.3.2. Responding to the Rekeying Initialization 766 The UPDATE ACK is used to acknowledge the received UPDATE rekeying 767 initialization. The acknowledgement UPDATE packet MUST carry an 768 ESP_INFO and MAY carry a DIFFIE_HELLMAN parameter. 770 Intermediate systems that use the SPI will have to inspect HIP 771 packets for packets carrying rekeying information. The packet is 772 signed for the benefit of the intermediate systems. Since 773 intermediate systems may need the new SPI values, the contents cannot 774 be encrypted. 776 The following figure shows the contents of a rekeying acknowledgement 777 UPDATE packet. 779 The HIP parameters for the UPDATE packet: 781 IP ( HIP ( ESP_INFO, 782 SEQ, 783 ACK, 784 [ DIFFIE_HELLMAN, ] 785 HMAC, 786 HIP_SIGNATURE ) ) 788 5.4. ICMP Messages 790 The ICMP message handling is mainly described in the HIP base 791 specification [I-D.ietf-hip-base]. In this section, we describe the 792 actions related to ESP security associations. 794 5.4.1. Unknown SPI 796 If a HIP implementation receives an ESP packet that has an 797 unrecognized SPI number, it MAY respond (subject to rate limiting the 798 responses) with an ICMP packet with type "Parameter Problem", with 799 the Pointer pointing to the the beginning of SPI field in the ESP 800 header. 802 6. Packet Processing 804 Packet processing is mainly defined in the HIP base specification 805 [I-D.ietf-hip-base]. This section describes the changes and new 806 requirements for packet handling when the ESP transport format is 807 used. Note that all HIP packets (currently protocol 253) MUST bypass 808 ESP processing. 810 6.1. Processing Outgoing Application Data 812 Outgoing application data handling is specified in the HIP base 813 specification [I-D.ietf-hip-base]. When ESP transport format is 814 used, and there is an active HIP session for the given < source, 815 destination > HIT pair, the outgoing datagram is protected using the 816 ESP security association. In a typical implementation, this will 817 result in a BEET-mode ESP packet being sent. BEET-mode 818 [I-D.nikander-esp-beet-mode] was introduced above in Section 3.2. 820 1. Detect the proper ESP SA using the HITs in the packet header or 821 other information associated with the packet 823 2. Process the packet normally, as if the SA was a transport mode 824 SA. 826 3. Ensure that the outgoing ESP protected packet has proper IP 827 header format depending on the used IP address family, and proper 828 IP addresses in its IP header, e.g., by replacing HITs left by 829 the ESP processing. Note that this placement of proper IP 830 addresses MAY also be performed at some other point in the stack, 831 e.g., before ESP processing. 833 6.2. Processing Incoming Application Data 835 Incoming HIP user data packets arrive as ESP protected packets. In 836 the usual case the receiving host has a corresponding ESP security 837 association, identified by the SPI and destination IP address in the 838 packet. However, if the host has crashed or otherwise lost its HIP 839 state, it may not have such an SA. 841 The basic incoming data handling is specified in the HIP base 842 specification. Additional steps are required when ESP is used for 843 protecting the data traffic. The following steps define the 844 conceptual processing rules for incoming ESP protected datagrams 845 targeted to an ESP security association created with HIP. 847 1. Detect the proper ESP SA using the SPI. If the resulting SA is a 848 non-HIP ESP SA, process the packet according to standard IPsec 849 rules. If there are no SAs identified with the SPI, the host MAY 850 send an ICMP packet as defined in Section 5.4. How to handle 851 lost state is an implementation issue. 853 2. If the SPI matches with an active HIP-based ESP SA, the IP 854 addresses in the datagram are replaced with the HITs associated 855 with the SPI. Note that this IP-address-to-HIT conversion step 856 MAY also be performed at some other point in the stack, e.g., 857 after ESP processing. Note also that if the incoming packet has 858 IPv4 addresses, the packet must be converted to IPv6 format 859 before replacing the addresses with HITs (such that the transport 860 checksum will pass if there are no errors). 862 3. The transformed packet is next processed normally by ESP, as if 863 the packet were a transport mode packet. The packet may be 864 dropped by ESP, as usual. In a typical implementation, the 865 result of successful ESP decryption and verification is a 866 datagram with the associated HITs as source and destination. 868 4. The datagram is delivered to the upper layer. Demultiplexing the 869 datagram to the right upper layer socket is performed as usual, 870 except that the HITs are used in place of IP addresses during the 871 demultiplexing. 873 6.3. HMAC and SIGNATURE Calculation and Verification 875 The new HIP parameters described in this document, ESP_INFO and 876 ESP_TRANSFORM, must be protected using HMAC and signature 877 calculations. In a typical implementation, they are included in R1, 878 I2, R2, and UPDATE packet HMAC and SIGNATURE calculations as 879 described in [I-D.ietf-hip-base]. 881 6.4. Processing Incoming ESP SA Initialization (R1) 883 The ESP SA setup is initialized in the R1 message. The receiving 884 host (Initiator) select one of the ESP transforms from the presented 885 values. If no suitable value is found, the negotiation is 886 terminated. The selected values are subsequently used when 887 generating and using encryption keys, and when sending the reply 888 packet. If the proposed alternatives are not acceptable to the 889 system, it may abandon the ESP SA establishment negotiation, or it 890 may resend the I1 message within the retry bounds. 892 After selecting the ESP transform, and performing other R1 893 processing, the system prepares and creates an incoming ESP security 894 association. It may also prepare a security association for outgoing 895 traffic, but since it does not have the correct SPI value yet, it 896 cannot activate it. 898 6.5. Processing Incoming Initialization Reply (I2) 900 The following steps are required to process the incoming ESP SA 901 initialization replies in I2. The steps below assume that the I2 has 902 been accepted for processing (e.g., has not been dropped due to HIT 903 comparisons as described in [I-D.ietf-hip-base]). 905 o The ESP_TRANSFORM parameter is verified and it MUST contain a 906 single value in the parameter and it MUST match one of the values 907 offered in the initialization packet. 909 o The ESP_INFO New SPI field is parsed to obtain the SPI that will 910 be used for the Security Association outbound from the Responder 911 and inbound to the Initiator. For this initial ESP SA 912 establishment, the Old SPI value MUST be zero. The Keymat Index 913 field MUST contain the index value to the KEYMAT from where the 914 ESP SA keys are drawn. 916 o The system prepares and creates both incoming and outgoing ESP 917 security associations. 919 o Upon successful processing of the initialization reply message, 920 the possible old Security Associations (as left over from an 921 earlier incarnation of the HIP association) are dropped and the 922 new ones are installed, and a finalizing packet, R2, is sent. 923 Possible ongoing rekeying attempts are dropped. 925 6.6. Processing Incoming ESP SA Setup Finalization (R2) 927 Before the ESP SA can be finalized, the ESP_INFO New SPI field is 928 parsed to obtain the SPI that will be used for the ESP Security 929 Association inbound to the sender of the finalization message R2. 930 The system uses this SPI to create or activate the outgoing ESP 931 security association used for sending packets to the peer. 933 6.7. Dropping HIP Associations 935 When the system drops a HIP association, as described in the HIP base 936 specification, the associated ESP SAs MUST also be dropped. 938 6.8. Initiating ESP SA Rekeying 940 During ESP SA rekeying, the hosts draw new keys from the existing 941 keying material, or a new keying material is generated from where the 942 new keys are drawn. 944 A system may initiate the SA rekeying procedure at any time. It MUST 945 initiate a rekey if its incoming ESP sequence counter is about to 946 overflow. The system MUST NOT replace its keying material until the 947 rekeying packet exchange successfully completes. 949 Optionally, a system may include a new Diffie-Hellman key for use in 950 new KEYMAT generation. New KEYMAT generation occurs prior to drawing 951 the new keys. 953 The rekeying procedure uses the UPDATE mechanism defined in 954 [I-D.ietf-hip-base]. Because each peer must update its half of the 955 security association pair (including new SPI creation), the rekeying 956 process requires that each side both send and receive an UPDATE. A 957 system will then rekey the ESP SA when it has sent parameters to the 958 peer and has received both an ACK of the relevant UPDATE message and 959 corresponding peer's parameters. It may be that the ACK and the 960 required HIP parameters arrive in different UPDATE messages. This is 961 always true if a system does not initiate ESP SA update but responds 962 to an update request from the peer, but may also occur if two systems 963 initiate update nearly simultaneously. In such a case, if the system 964 has an outstanding update request, it saves the one parameter and 965 waits for the other before completing rekeying. 967 The following steps define the processing rules for initiating an ESP 968 SA update: 970 1. The system decides whether to continue to use the existing KEYMAT 971 or to generate new KEYMAT. In the latter case, the system MUST 972 generate a new Diffie-Hellman public key. 974 2. The system creates an UPDATE packet, which contains the ESP_INFO 975 parameter. In addition, the host may include the optional 976 DIFFIE_HELLMAN parameter. If the UDPATE contains the 977 DIFFIE_HELLMAN parameter, the Keymat Index in the ESP_INFO 978 parameter MUST be zero, and the Diffie-Hellman group ID must be 979 unchanged from that used in the initial handshake. If the UPDATE 980 does not contain DIFFIE_HELLMAN, the ESP_INFO Keymat Index MUST 981 be greater or equal to the index of the next byte to be drawn 982 from the current KEYMAT. 984 3. The system sends the UPDATE packet. For reliability, the 985 underlying UPDATE retransmission mechanism MUST be used. 987 4. The system MUST NOT delete its existing SAs, but continue using 988 them if its policy still allows. The rekeying procedure SHOULD 989 be initiated early enough to make sure that the SA replay 990 counters do not overflow. 992 5. In case a protocol error occurs and the peer system acknowledges 993 the UPDATE but does not itself send an ESP_INFO, the system may 994 not finalize the outstanding ESP SA update request. To guard 995 against this, a system MAY re-initiate the ESP SA update 996 procedure after some time waiting for the peer to respond, or it 997 MAY decide to abort the ESP SA after waiting for an 998 implementation-dependent time. The system MUST NOT keep an 999 oustanding ESP SA update request for an indefinite time. 1001 To simplify the state machine, a host MUST NOT generate new UPDATEs 1002 while it has an outstanding ESP SA update request, unless it is 1003 restarting the update process. 1005 6.9. Processing Incoming UPDATE Packets 1007 When a system receives an UPDATE packet, it must be processed if the 1008 following conditions hold (in addition to the generic conditions 1009 specified for UPDATE processing in Section 6.12 of 1010 [I-D.ietf-hip-base]): 1012 1. A corresponding HIP association must exist. This is usually 1013 ensured by the underlying UPDATE mechanism. 1015 2. The state of the HIP association is ESTABLISHED or R2-SENT. 1017 If the above conditions hold, the following steps define the 1018 conceptual processing rules for handling the received UPDATE packet: 1020 1. If the received UPDATE contains a DIFFIE_HELLMAN parameter, the 1021 received Keymat Index MUST be zero and the Group ID must match 1022 the Group ID in use on the association. If this test fails, the 1023 packet SHOULD be dropped and the system SHOULD log an error 1024 message. 1026 2. If there is no outstanding rekeying request, the packet 1027 processing continues as specified in Section 6.9.1. 1029 3. If there is an outstanding rekeying request, the UPDATE MUST be 1030 acknowledged, the received ESP_INFO (and possibly DIFFIE_HELLMAN) 1031 parameters must be saved, and the packet processing continues as 1032 specified in Section 6.10. 1034 6.9.1. Processing UPDATE Packet: No Outstanding Rekeying Request 1036 The following steps define the conceptual processing rules for 1037 handling a received UPDATE packet with ESP_INFO parameter: 1039 1. The system consults its policy to see if it needs to generate a 1040 new Diffie-Hellman key, and generates a new key (with same Group 1041 ID) if needed. The system records any newly generated or 1042 received Diffie-Hellman keys, for use in KEYMAT generation upon 1043 finalizing the ESP SA update. 1045 2. If the system generated a new Diffie-Hellman key in the previous 1046 step, or if it received a DIFFIE_HELLMAN parameter, it sets 1047 ESP_INFO Keymat Index to zero. Otherwise, the ESP_INFO Keymat 1048 Index MUST be greater or equal to the index of the next byte to 1049 be drawn from the current KEYMAT. In this case, it is 1050 RECOMMENDED that the host use the Keymat Index requested by the 1051 peer in the received ESP_INFO. 1053 3. The system creates an UPDATE packet, which contains an ESP_INFO 1054 parameter, and the optional DIFFIE_HELLMAN parameter. This 1055 UPDATE would also typically acknowledge the peer's UPDATE with an 1056 ACK parameter, although a separate UPDATE ACK may be sent. 1058 4. The system sends the UPDATE packet and stores any received 1059 ESP_INFO, and DIFFIE_HELLMAN parameters. At this point, it only 1060 needs to receive an acknowledgement for the newly sent UPDATE to 1061 finish ESP SA update. In the usual case, the acknowledgement is 1062 handled by the underlying UPDATE mechanism. 1064 6.10. Finalizing Rekeying 1066 A system finalizes rekeying when it has both received the 1067 corresponding UPDATE acknowledgement packet from the peer and it has 1068 successfully received the peer's UPDATE. The following steps are 1069 taken: 1071 1. If the received UPDATE messages contains a new Diffie-Hellman 1072 key, the system has a new Diffie-Hellman key due to initiating 1073 ESP SA update, or both, the system generates new KEYMAT. If 1074 there is only one new Diffie-Hellman key, the old existing key is 1075 used as the other key. 1077 2. If the system generated new KEYMAT in the previous step, it sets 1078 Keymat Index to zero, independent of whether the received UPDATE 1079 included a Diffie-Hellman key or not. If the system did not 1080 generate new KEYMAT, it uses the greater Keymat Index of the two 1081 (sent and received) ESP_INFO parameters. 1083 3. The system draws keys for new incoming and outgoing ESP SAs, 1084 starting from the Keymat Index, and prepares new incoming and 1085 outgoing ESP SAs. The SPI for the outgoing SA is the new SPI 1086 value received in an ESP_INFO parameter. The SPI for the 1087 incoming SA was generated when the ESP_INFO was sent to the peer. 1088 The order of the keys retrieved from the KEYMAT during rekeying 1089 process is similar to that described in Section 7. Note, that 1090 only IPsec ESP keys are retrieved during rekeying process, not 1091 the HIP keys. 1093 4. The system starts to send to the new outgoing SA and prepares to 1094 start receiving data on the new incoming SA. Once the system 1095 receives data on the new incoming SA it may safely delete the old 1096 SAs. 1098 6.11. Processing NOTIFY Packets 1100 The processing of NOTIFY packets is described in the HIP base 1101 specification. 1103 7. Keying Material 1105 The keying material is generated as described in the HIP base 1106 specification. During the base exchange, the initial keys are drawn 1107 from the generated material. After the HIP association keys have 1108 been drawn, the ESP keys are drawn in the following order: 1110 SA-gl ESP encryption key for HOST_g's outgoing traffic 1112 SA-gl ESP authentication key for HOST_g's outgoing traffic 1114 SA-lg ESP encryption key for HOST_l's outgoing traffic 1116 SA-lg ESP authentication key for HOST_l's outgoing traffic 1118 HOST_g denotes the host with the greater HIT value, and HOST_l the 1119 host with the lower HIT value. When HIT values are compared, they 1120 are interpreted as positive (unsigned) 128-bit integers in network 1121 byte order. 1123 The four HIP keys are only drawn from KEYMAT during a HIP I1->R2 1124 exchange. Subsequent rekeys using UPDATE will only draw the four ESP 1125 keys from KEYMAT. Section 6.9 describes the rules for reusing or 1126 regenerating KEYMAT based on the rekeying. 1128 The number of bits drawn for a given algorithm is the "natural" size 1129 of the keys. For the mandatory algorithms, the following sizes 1130 apply: 1132 AES 128 bits 1134 SHA-1 160 bits 1136 NULL 0 bits 1138 8. Security Considerations 1140 In this document the usage of ESP [RFC4303] between HIP hosts to 1141 protect data traffic is introduced. The Security Considerations for 1142 ESP are discussed in the ESP specification. 1144 There are different ways to establish an ESP Security Association 1145 between two nodes. This can be done, e.g. using IKE [RFC4306]. This 1146 document specifies how Host Identity Protocol is used to establish 1147 ESP Security Associations. 1149 The following issues are new, or changed from the standard ESP usage: 1151 o Initial keying material generation 1153 o Updating the keying material 1155 The initial keying material is generated using the Host Identity 1156 Protocol [I-D.ietf-hip-base] using Diffie-Hellman procedure. This 1157 document extends the usage of UDPATE packet, defined in the base 1158 specification, to modify existing ESP SAs. The hosts may rekey, i.e. 1159 force the generation of new keying material using Diffie-Hellman 1160 procedure. The initial setup of ESP SA between the hosts is done 1161 during the base ecxhange and the message exchange is protected with 1162 using methods provided by base exchange. Changing of connection 1163 parameters means basically that the old ESP SA is removed and a new 1164 one is generated once the UPDATE message exchange has been completed. 1165 The message exchange is protected using the HIP association keys. 1166 Both HMAC and signing of packets is used. 1168 9. IANA Considerations 1170 This document defines additional parameters and NOTIFY error types 1171 for the Host Identity Protocol [I-D.ietf-hip-base]. 1173 The new parameters and their type numbers are defined in 1174 Section 5.1.1 and Section 5.1.2 and they are added in the Parameter 1175 Type namespace, specified in [I-D.ietf-hip-base]. 1177 The new NOTFY error types and their values are defined in 1178 Section 5.1.3 and they are added in Notify Message Type namespace, 1179 specified in [I-D.ietf-hip-base]. 1181 10. Acknowledgments 1183 This document was separated from the base "Host Identity Protocol" 1184 specification in the beginning of 2005. Since then, a number of 1185 people have contributed to the text by giving comments and 1186 modification proposals. The list of people include Tom Henderson, 1187 Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu. Authors 1188 want also thank Charlie Kaufman for reviewing the document with the 1189 eye on the usage of crypto algorithms. 1191 Due to the history of this document, most of the ideas are inherited 1192 from the base "Host Identity Protocol" specification. Thus the list 1193 of people in the Acknowledgments section of that specification is 1194 also valid for this document. Many people have given valueable 1195 feedback, and our apologies for anyone whose name is missing. 1197 11. References 1199 11.1. Normative references 1201 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1202 Requirement Levels", BCP 14, RFC 2119, March 1997. 1204 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 1205 ESP and AH", RFC 2404, November 1998. 1207 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 1208 Algorithm and Its Use with IPsec", RFC 3602, 1209 September 2003. 1211 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1212 RFC 4303, December 2005. 1214 [I-D.ietf-hip-base] 1215 Moskowitz, R., "Host Identity Protocol", 1216 draft-ietf-hip-base-06 (work in progress), June 2006. 1218 11.2. Informative references 1220 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 1221 Algorithms", RFC 2451, November 1998. 1223 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1224 Hashing for Message Authentication", RFC 2104, 1225 February 1997. 1227 [I-D.ietf-ipsec-rfc2401bis] 1228 Kent, S. and K. Seo, "Security Architecture for the 1229 Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work 1230 in progress), April 2005. 1232 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1233 RFC 4306, December 2005. 1235 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1236 Internet Protocol", RFC 4301, December 2005. 1238 [I-D.nikander-esp-beet-mode] 1239 Melen, J. and P. Nikander, "A Bound End-to-End Tunnel 1240 (BEET) mode for ESP", draft-nikander-esp-beet-mode-06 1241 (work in progress), August 2006. 1243 [I-D.ietf-hip-mm] 1244 Nikander, P., "End-Host Mobility and Multihoming with the 1245 Host Identity Protocol", draft-ietf-hip-mm-04 (work in 1246 progress), June 2006. 1248 [RFC3260] Grossman, D., "New Terminology and Clarifications for 1249 Diffserv", RFC 3260, April 2002. 1251 [RFC3474] Lin, Z. and D. Pendarakis, "Documentation of IANA 1252 assignments for Generalized MultiProtocol Label Switching 1253 (GMPLS) Resource Reservation Protocol - Traffic 1254 Engineering (RSVP-TE) Usage and Extensions for 1255 Automatically Switched Optical Network (ASON)", RFC 3474, 1256 March 2003. 1258 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1259 (HIP) Architecture", RFC 4423, May 2006. 1261 Appendix A. A Note on Implementation Options 1263 It is possible to implement this specification in multiple different 1264 ways. As noted above, one possible way of implementing is to rewrite 1265 IP headers below IPsec. In such an implementation, IPsec is used as 1266 if it was processing IPv6 transport mode packets, with the IPv6 1267 header containing HITs instead of IP addresses in the source and 1268 destionation address fields. In outgoing packets, after IPsec 1269 processing, the HITs are replaced with actual IP addresses, based on 1270 the HITs and the SPI. In incoming packets, before IPsec processing, 1271 the IP addresses are replaced with HITs, based on the SPI in the 1272 incoming packet. In such an implementation, all IPsec policies are 1273 based on HITs and the upper layers only see packets with HITs in the 1274 place of IP addresses. Consequently, support of HIP does not 1275 conflict with other use of IPsec as long as the SPI spaces are kept 1276 separate. 1278 Another way for implementing is to use the proposed BEET mode (A 1279 Bound End-to-End mode for ESP) [I-D.nikander-esp-beet-mode]. The 1280 BEET mode provides some features from both IPsec tunnel and transport 1281 modes. The HIP uses HITs as the "inner" addresses and IP addresses 1282 as "outer" addresses like IP addresses are used in the tunnel mode. 1283 Instead of tunneling packets between hosts, a conversion between 1284 inner and outer addresses is made at end-hosts and the inner address 1285 is never sent in the wire after the initial HIP negotiation. BEET 1286 provides IPsec transport mode syntax (no inner headers) with limited 1287 tunnel mode semantics (fixed logical inner addresses - the HITs - and 1288 changeable outer IP addresses). 1290 Compared to the option of implementing the required address rewrites 1291 outside of IPsec, BEET has one implementation level benefit. The 1292 BEET-way of implementing the address rewriting keeps all the 1293 configuration information in one place, at the SADB. On the other 1294 hand, when address rewriting is implemented separately, the 1295 implementation must make sure that the information in the SADB and 1296 the separate address rewriting DB are kept in synchrony. As a 1297 result, the BEET mode based way of implementing is RECOMMENDED over 1298 the separate implementation. 1300 Authors' Addresses 1302 Petri Jokela 1303 Ericsson Research NomadicLab 1304 JORVAS FIN-02420 1305 FINLAND 1307 Phone: +358 9 299 1 1308 Email: petri.jokela@nomadiclab.com 1310 Robert Moskowitz 1311 ICSAlabs, a Division of TruSecure Corporation 1312 1000 Bent Creek Blvd, Suite 200 1313 Mechanicsburg, PA 1314 USA 1316 Email: rgm@icsalabs.com 1318 Pekka Nikander 1319 Ericsson Research NomadicLab 1320 JORVAS FIN-02420 1321 FINLAND 1323 Phone: +358 9 299 1 1324 Email: pekka.nikander@nomadiclab.com 1326 Full Copyright Statement 1328 Copyright (C) The IETF Trust (2007). 1330 This document is subject to the rights, licenses and restrictions 1331 contained in BCP 78, and except as set forth therein, the authors 1332 retain all their rights. 1334 This document and the information contained herein are provided on an 1335 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1336 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1337 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1338 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1339 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1340 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1342 Intellectual Property 1344 The IETF takes no position regarding the validity or scope of any 1345 Intellectual Property Rights or other rights that might be claimed to 1346 pertain to the implementation or use of the technology described in 1347 this document or the extent to which any license under such rights 1348 might or might not be available; nor does it represent that it has 1349 made any independent effort to identify any such rights. Information 1350 on the procedures with respect to rights in RFC documents can be 1351 found in BCP 78 and BCP 79. 1353 Copies of IPR disclosures made to the IETF Secretariat and any 1354 assurances of licenses to be made available, or the result of an 1355 attempt made to obtain a general license or permission for the use of 1356 such proprietary rights by implementers or users of this 1357 specification can be obtained from the IETF on-line IPR repository at 1358 http://www.ietf.org/ipr. 1360 The IETF invites any interested party to bring to its attention any 1361 copyrights, patents or patent applications, or other proprietary 1362 rights that may cover technology that may be required to implement 1363 this standard. Please address the information to the IETF at 1364 ietf-ipr@ietf.org. 1366 Acknowledgment 1368 Funding for the RFC Editor function is provided by the IETF 1369 Administrative Support Activity (IASA).