idnits 2.17.1 draft-ietf-hip-esp-04.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 on line 1307. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1284. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1291. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1297. ** 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 (Oct 2006) is 6396 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. '5') ** Downref: Normative reference to an Informational draft: draft-ietf-hip-arch (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '10') (Obsoleted by RFC 4306) == 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 Summary: 5 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: April 4, 2007 R. Moskowitz 5 ICSAlabs, a Division of TruSecure 6 Corporation 7 P. Nikander 8 Ericsson Research NomadicLab 9 Oct 2006 11 Using ESP transport format with HIP 12 draft-ietf-hip-esp-04 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 April 4, 2007. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . . . 15 74 5.1.3. NOTIFY Parameter . . . . . . . . . . . . . . . . . . . 16 75 5.2. HIP ESP Security Association Setup . . . . . . . . . . . . 17 76 5.2.1. Setup During Base Exchange . . . . . . . . . . . . . . 17 77 5.3. HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . . 18 78 5.3.1. Initializing Rekeying . . . . . . . . . . . . . . . . 19 79 5.3.2. Responding to the Rekeying Initialization . . . . . . 19 80 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 20 81 5.4.1. Unknown SPI . . . . . . . . . . . . . . . . . . . . . 20 82 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 21 83 6.1. Processing Outgoing Application Data . . . . . . . . . . . 21 84 6.2. Processing Incoming Application Data . . . . . . . . . . . 21 85 6.3. HMAC and SIGNATURE Calculation and Verification . . . . . 22 86 6.4. Processing Incoming ESP SA Initialization (R1) . . . . . . 22 87 6.5. Processing Incoming Initialization Reply (I2) . . . . . . 23 88 6.6. Processing Incoming ESP SA Setup Finalization (R2) . . . . 23 89 6.7. Dropping HIP Associations . . . . . . . . . . . . . . . . 23 90 6.8. Initiating ESP SA Rekeying . . . . . . . . . . . . . . . . 23 91 6.9. Processing Incoming UPDATE Packets . . . . . . . . . . . . 25 92 6.9.1. Processing UPDATE Packet: No Outstanding Rekeying 93 Request . . . . . . . . . . . . . . . . . . . . . . . 25 94 6.10. Finalizing Rekeying . . . . . . . . . . . . . . . . . . . 26 95 6.11. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 27 96 7. Keying Material . . . . . . . . . . . . . . . . . . . . . . . 28 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 99 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 101 11.1. Normative references . . . . . . . . . . . . . . . . . . . 32 102 11.2. Informative references . . . . . . . . . . . . . . . . . . 32 103 Appendix A. A Note on Implementation Options . . . . . . . . . . 33 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 105 Intellectual Property and Copyright Statements . . . . . . . . . . 35 107 1. Introduction 109 In the Host Identity Protocol Architecture [7], hosts are identified 110 with public keys. The Host Identity Protocol [5] base exchange 111 allows any two HIP-supporting hosts to authenticate each other and to 112 create a HIP association between themselves. During the base 113 exchange, the hosts generate a piece of shared keying material using 114 an authenticated Diffie-Hellman exchange. 116 The HIP base exchange specification [5] does not describe any 117 transport formats, or methods for user data, to be used during the 118 actual communication; it only defines that it is mandatory to 119 implement the Encapsulated Security Payload (ESP) [4] based transport 120 format and method. This document specifies how ESP is used with HIP 121 to carry actual user data. 123 To be more specific, this document specifies a set of HIP protocol 124 extensions and their handling. Using these extensions, a pair of ESP 125 Security Associations (SAs) is created between the hosts during the 126 base exchange. The resulting ESP Security Associations use keys 127 drawn from the keying material (KEYMAT) generated during the base 128 exchange. After the HIP association and required ESP SAs have been 129 established between the hosts, the user data communication is 130 protected using ESP. In addition, this document specifies methods to 131 update an existing ESP Security Association. 133 It should be noted that representations of host identity are not 134 carried explicitly in the headers of user data packets. Instead, the 135 ESP Security Parameter Index (SPI) is used to indicate the right host 136 context. The SPIs are selected during the HIP ESP setup exchange. 137 For user data packets, ESP SPIs (in possible combination with IP 138 addresses) are used indirectly to identify the host context, thereby 139 avoiding any additional explicit protocol headers. 141 2. Conventions used in this document 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC2119 [1]. 147 3. Using ESP with HIP 149 The HIP base exchange is used to set up a HIP association between two 150 hosts. The base exchange provides two-way host authentication and 151 key material generation, but it does not provide any means for 152 protecting data communication between the hosts. In this document we 153 specify the use of ESP for protecting user data traffic after the HIP 154 base exchange. Note that this use of ESP is intended only for host- 155 to-host traffic; security gateways are not supported. 157 To support ESP use, the HIP base exchange messages require some minor 158 additions to the parameters transported. In the R1 packet, the 159 responder adds the possible ESP transforms in a new ESP_TRANSFORM 160 parameter before sending it to the Initiator. The Initiator gets the 161 proposed transforms, selects one of those proposed transforms, and 162 adds it to the I2 packet in an ESP_TRANSFORM parameter. In this I2 163 packet, the Initiator also sends the SPI value that it wants to be 164 used for ESP traffic flowing from the Responder to the Initiator. 165 This information is carried using the new ESP_INFO parameter. When 166 finalizing the ESP SA setup, the Responder sends its SPI value to the 167 Initiator in the R2 packet, again using ESP_INFO. 169 3.1. ESP Packet Format 171 The ESP specification [4] defines the ESP packet format for IPsec. 172 The HIP ESP packet looks exactly the same as the IPsec ESP transport 173 format packet. The semantics, however, are a bit different and are 174 described in more detail in the next subsection. 176 3.2. Conceptual ESP Packet Processing 178 ESP packet processing can be implemented in different ways in HIP. 179 It is possible to implement it in a way that a standards compliant, 180 unmodified IPsec implementation [4] can be used. 182 When a standards compliant IPsec implementation that uses IP 183 addresses in the SPD and SAD is used, the packet processing may take 184 the following steps. For outgoing packets, assuming that the upper 185 layer pseudoheader has been built using IP addresses, the 186 implementation recalculates upper layer checksums using HITs and, 187 after that, changes the packet source and destination addresses back 188 to corresponding IP addresses. The packet is sent to the IPsec ESP 189 for transport mode handling and from there the encrypted packet is 190 sent to the network. When an ESP packet is received, the packet is 191 first put to the IPsec ESP transport mode handling, and after 192 decryption, the source and destination IP addresses are replaced with 193 HITs and finally, upper layer checksums are verified before passing 194 the packet to the upper layer. 196 An alternative way to implement the packet processing is the BEET 197 (Bound End-to-End Tunnel) [11] mode. In BEET mode, the ESP packet is 198 formatted as a transport mode packet, but the semantics of the 199 connection are the same as for tunnel mode. The "outer" addresses of 200 the packet are the IP addresses and the "inner" addresses are the 201 HITs. For outgoing traffic, after the packet has been encrypted, the 202 packet's IP header is changed to a new one, containing IP addresses 203 instead of HITs and the packet is sent to the network. When ESP 204 packet is received, the SPI value, together with the integrity 205 protection, allow the packet to be securely associated with the right 206 HIT pair. The packet header is replaces with a new header, 207 containing HITs and the packet is decrypted. 209 3.2.1. Semantics of the Security Parameter Index (SPI) 211 SPIs are used in ESP to find the right Security Association for 212 received packets. The ESP SPIs have added significance when used 213 with HIP; they are a compressed representation of a pair of HITs. 214 Thus, SPIs MAY be used by intermediary systems in providing services 215 like address mapping. Note that since the SPI has significance at 216 the receiver, only the < DST, SPI >, where DST is a destination IP 217 address, uniquely identifies the receiver HIT at any given point of 218 time. The same SPI value may be used by several hosts. A single < 219 DST, SPI > value may denote different hosts and contexts at different 220 points of time, depending on the host that is currently reachable at 221 the DST. 223 Each host selects for itself the SPI it wants to see in packets 224 received from its peer. This allows it to select different SPIs for 225 different peers. The SPI selection SHOULD be random; the rules of 226 Section 2.1 of the ESP specification [4] must be followed. A 227 different SPI SHOULD be used for each HIP exchange with a particular 228 host; this is to avoid a replay attack. Additionally, when a host 229 rekeys, the SPI MUST be changed. Furthermore, if a host changes over 230 to use a different IP address, it MAY change the SPI. 232 One method for SPI creation that meets the above criteria would be to 233 concatenate the HIT with a 32-bit random or sequential number, hash 234 this (using SHA1), and then use the high order 32 bits as the SPI. 236 The selected SPI is communicated to the peer in the third (I2) and 237 fourth (R2) packets of the base HIP exchange. Changes in SPI are 238 signaled with ESP_INFO parameters. 240 3.3. Security Association Establishment and Maintenance 241 3.3.1. ESP Security Associations 243 In HIP, ESP Security Associations are setup between the HIP nodes 244 during the base exchange [5]. Existing ESP SAs can be updated later 245 using UPDATE messages. The reason for updating the ESP SA later can 246 be e.g. need for rekeying the SA because of sequence number rollover. 248 Upon setting up a HIP association, each association is linked to two 249 ESP SAs, one for incoming packets and one for outgoing packets. The 250 Initiator's incoming SA corresponds with the Responder's outgoing 251 one, and vice versa. The Initiator defines the SPI for its incoming 252 association, as defined in Section 3.2.1. This SA is herein called 253 SA-RI, and the corresponding SPI is called SPI-RI. Respectively, the 254 Responder's incoming SA corresponds with the Initiator's outgoing SA 255 and is called SA-IR, with the SPI being called SPI-IR. 257 The Initiator creates SA-RI as a part of R1 processing, before 258 sending out the I2, as explained in Section 6.4. The keys are 259 derived from KEYMAT, as defined in Section 7. The Responder creates 260 SA-RI as a part of I2 processing, see Section 6.5. 262 The Responder creates SA-IR as a part of I2 processing, before 263 sending out R2; see Section 6.5. The Initiator creates SA-IR when 264 processing R2; see Section 6.6. 266 The initial session keys are drawn from the generated keying 267 material, KEYMAT, after the HIP keys have been drawn as specified in 268 [5]. 270 When the HIP association is removed, the related ESP SAs MUST also be 271 removed. 273 3.3.2. Rekeying 275 After the initial HIP base exchange and SA establishment, both hosts 276 are in the ESTABLISHED state. There are no longer Initiator and 277 Responder roles and the association is symmetric. In this 278 subsection, the party that initiates the rekey procedure is denoted 279 with I' and the peer with R'. 281 An existing HIP-created ESP SA may need updating during the lifetime 282 of the HIP association. This document specifies the rekeying of an 283 existing HIP-created ESP SA, using the UPDATE message. The ESP_INFO 284 parameter introduced above is used for this purpose. 286 I' initiates the ESP SA updating process when needed (see 287 Section 6.8). It creates an UPDATE packet with required information 288 and sends it to the peer node. The old SAs are still in use, local 289 policy permitting. 291 R', after receiving and processing the UPDATE (see Section 6.9), 292 generates new SAs: SA-I'R' and SA-R'I'. It does not take the new 293 outgoing SA into use, but still uses the old one, so there 294 temporarily exists two SA pairs towards the same peer host. The SPI 295 for the new outgoing SA, SPI-R'I', is specified in the received 296 ESP_INFO parameter in the UPDATE packet. For the new incoming SA, R' 297 generates the new SPI value, SPI-I'R', and includes it in the 298 response UPDATE packet. 300 When I' receives a response UPDATE from R', it generates new SAs, as 301 described in Section 6.9: SA-I'R' and SA-R'I'. It starts using the 302 new outgoing SA immediately. 304 R' starts using the new outgoing SA when it receives traffic on the 305 new incoming SA or when it receives the UPDATE ACK confirming 306 completion of rekeying. After this, R' can remove the old SAs. 307 Similarly, when the I' receives traffic from the new incoming SA, it 308 can safely remove the old SAs. 310 3.3.3. Security Association Management 312 An SA pair is indexed by the 2 SPIs and 2 HITs (both local and remote 313 HITs since a system can have more than one HIT). An inactivity timer 314 is RECOMMENDED for all SAs. If the state dictates the deletion of an 315 SA, a timer is set to allow for any late arriving packets. 317 3.3.4. Security Parameter Index (SPI) 319 The SPIs in ESP provide a simple compression of the HIP data from all 320 packets after the HIP exchange. This does require a per HIT-pair 321 Security Association (and SPI), and a decrease of policy granularity 322 over other Key Management Protocols like IKE. 324 When a host updates the ESP SA, it provides a new inbound SPI to and 325 gets a new outbound SPI from its partner. 327 3.3.5. Supported Transforms 329 All HIP implementations MUST support AES [3] and HMAC-SHA-1-96 [2]. 330 If the Initiator does not support any of the transforms offered by 331 the Responder, it should abandon the negotiation and inform the peer 332 with a NOTIFY message about a non-supported transform. 334 In addition to AES, all implementations MUST implement the ESP NULL 335 encryption algorithm. When the ESP NULL encryption is used, it MUST 336 be used together with SHA1 or MD5 authentication as specified in 337 Section 5.1.2 339 3.3.6. Sequence Number 341 The Sequence Number field is MANDATORY when ESP is used with HIP. 342 Anti-replay protection MUST be used in an ESP SA established with 343 HIP. When ESP is used with HIP, a 64-bit sequence number MUST be 344 used. This means that each host MUST rekey before its sequence 345 number reaches 2^64. 347 When using a 64-bit sequence number, the higher 32 bits are NOT 348 included in the ESP header, but are simply kept local to both peers. 349 See [9]. 351 3.3.7. Lifetimes and Timers 353 HIP does not negotiate any lifetimes. All ESP lifetimes are local 354 policy. The only lifetimes a HIP implementation MUST support are 355 sequence number rollover (for replay protection), and SHOULD support 356 timing out inactive ESP SAs. An SA times out if no packets are 357 received using that SA. The default timeout value is 15 minutes. 358 Implementations MAY support lifetimes for the various ESP transforms. 359 Each implementation SHOULD implement per-HIT configuration of the 360 inactivity timeout, allowing statically configured HIP associations 361 to stay alive for days, even when inactive. 363 3.4. IPsec and HIP ESP Implementation Considerations 365 When HIP is run on a node where a standards compliant IPsec is used, 366 some issues have to be considered. 368 The HIP implementation must be able to co-exist with other IPsec 369 keying protocols. When the HIP implementation selects the SPI value, 370 it may lead to a collision if not implemented properly. To avoid the 371 possibility for a collision, the HIP implementation MUST ensure that 372 the SPI values used for HIP SAs are not used for IPsec or other SAs, 373 and vice versa. 375 For outbound traffic the SPD or (coordinated) SPDs if there are two 376 (one for HIP and one for IPsec) MUST ensure that packets intended for 377 HIP processing are given a HIP-enabled SA and packets intended for 378 IPsec processing are given an IPsec-enabled SA. The SP then MUST be 379 bound to the matching SA and non-HIP packets will not be processed by 380 this SA. Data originating from a socket that is not using HIP, MUST 381 NOT have checksum recalculated as described in Section 3.2 paragraph 382 2 and data MUST NOT be passed to the SP or SA created by the HIP. 384 Incoming data packets using a SA that is not negotiated by HIP, MUST 385 NOT be processed as described in Section 3.2 paragraph 2. The SPI 386 will identify the correct SA for packet decryption and MUST be used 387 to identify that the packet has an upper-layer checksum that is 388 calculated as specified in [5]. 390 4. The Protocol 392 In this section, the protocol for setting up an ESP association to be 393 used with HIP association is described. 395 4.1. ESP in HIP 397 4.1.1. Setting up an ESP Security Association 399 Setting up an ESP Security Association between hosts using HIP 400 consists of three messages passed between the hosts. The parameters 401 are included in R1, I2, and R2 messages during base exchange. 403 Initiator Responder 405 I1 406 ----------------------------------> 408 R1: ESP_TRANSFORM 409 <---------------------------------- 411 I2: ESP_TRANSFORM, ESP_INFO 412 ----------------------------------> 414 R2: ESP_INFO 415 <---------------------------------- 417 Setting up an ESP Security Association between HIP hosts requires 418 three messages to exchange the information that is required during an 419 ESP communication. 421 The R1 message contains the ESP_TRANSFORM parameter, in which the 422 sending host defines the possible ESP transforms it is willing to use 423 for the ESP SA. 425 The I2 message contains the response to an ESP_TRANSFORM received in 426 the R1 message. The sender must select one of the proposed ESP 427 transforms from the ESP_TRANSFORM parameter in the R1 message and 428 include the selected one in the ESP_TRANSFORM parameter in the I2 429 packet. In addition to the transform, the host includes the ESP_INFO 430 parameter, containing the SPI value to be used by the peer host. 432 In the R2 message, the ESP SA setup is finalized. The packet 433 contains the SPI information required by the Initiator for the ESP 434 SA. 436 4.1.2. Updating an Existing ESP SA 438 The update process is accomplished using two messages. The HIP 439 UPDATE message is used to update the parameters of an existing ESP 440 SA. The UPDATE mechanism and message is defined in [5] and the 441 additional parameters for updating an existing ESP SA are described 442 here. 444 The following picture shows a typical exchange when an existing ESP 445 SA is updated. Messages include SEQ and ACK parameters required by 446 the UPDATE mechanism. 448 H1 H2 449 UPDATE: SEQ, ESP_INFO [, DIFFIE_HELLMAN] 450 -----------------------------------------------------> 452 UPDATE: SEQ, ACK, ESP_INFO [, DIFFIE_HELLMAN] 453 <----------------------------------------------------- 455 UPDATE: ACK 456 -----------------------------------------------------> 458 The host willing to update the ESP SA creates and sends an UPDATE 459 message. The message contains the ESP_INFO parameter, containing the 460 old SPI value that was used, the new SPI value to be used, and the 461 index value for the keying material, giving the point from where the 462 next keys will be drawn. If new keying material must be generated, 463 the UPDATE message will also contain the DIFFIE_HELLMAN parameter, 464 defined in [5]. 466 The host receiving the UPDATE message requesting update of an 467 existing ESP SA, MUST reply with an UPDATE message. In the reply 468 message, the host sends the ESP_INFO parameter containing the 469 corresponding values: old SPI, new SPI, and the keying material 470 index. If the incoming UPDATE contained a DIFFIE_HELLMAN parameter, 471 the reply packet MUST also contain a DIFFIE_HELLMAN parameter. 473 5. Parameter and Packet Formats 475 In this section, new and modified HIP parameters are presented, as 476 well as modified HIP packets. 478 5.1. New Parameters 480 Two new HIP parameters are defined for setting up ESP transport 481 format associations in HIP communication and for rekeying existing 482 ones. Also, the NOTIFY parameter, described in [5], has two new 483 error parameters. 485 Parameter Type Length Data 487 ESP_INFO 65 12 Remote's old SPI, 488 new SPI and other info 489 ESP_TRANSFORM 4095 variable ESP Encryption and 490 Authentication Transform(s) 492 5.1.1. ESP_INFO 494 During the establishment and update of an ESP SA, the SPI value of 495 both hosts must be transmitted between the hosts. Additional 496 information that is required when the hosts are drawing keys from the 497 generated keying material is the index value into the KEYMAT from 498 where the keys are drawn. The ESP_INFO parameter is used to transmit 499 this information between the hosts. 501 During the initial ESP SA setup, the hosts send the SPI value that 502 they want the peer to use when sending ESP data to them. The value 503 is set in the New SPI field of the ESP_INFO parameter. In the 504 initial setup, an old value for the SPI does not exist, thus the Old 505 SPI value field is set to zero. The Old SPI field value may also be 506 zero when additional SAs are set up between HIP hosts, e.g. in case 507 of multihomed HIP hosts [12]. However, such use is beyond the scope 508 of this specification. 510 The Keymat index value points to the place in the KEYMAT from where 511 the keying material for the ESP SAs is drawn. The Keymat index value 512 is zero only when the ESP_INFO is sent during a rekeying process and 513 new keying material is generated. 515 During the life of an SA established by HIP, one of the hosts may 516 need to reset the Sequence Number to one and rekey. The reason for 517 rekeying might be an approaching sequence number wrap in ESP, or a 518 local policy on use of a key. Rekeying ends the current SAs and 519 starts new ones on both peers. 521 During the rekeying process, the ESP_INFO parameter is used to 522 transmit the changed SPI values and the keying material index. 524 0 1 2 3 525 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 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Type | Length | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Reserved | Keymat Index | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Old SPI | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | New SPI | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 Type 65 537 Length 12 538 Keymat Index Index, in bytes, where to continue to draw ESP keys 539 from KEYMAT. If the packet includes a new 540 Diffie-Hellman key and the ESP_INFO is sent in an 541 UPDATE packet, the field MUST be zero. If the 542 ESP_INFO is included in base exchange messages, the 543 Keymat Index must have the index value of the point 544 from where the ESP SA keys are drawn. Note that the 545 length of this field limits the amount of 546 keying material that can be drawn from KEYMAT. If 547 that amount is exceeded, the packet MUST contain 548 a new Diffie-Hellman key. 549 Old SPI Old SPI for data sent to address(es) associated 550 with this SA. If this is an initial SA setup, the 551 Old SPI value is zero. 552 New SPI New SPI for data sent to address(es) associated 553 with this SA. 555 5.1.2. ESP_TRANSFORM 557 The ESP_TRANSFORM parameter is used during ESP SA establishment. The 558 first party sends a selection of transform families in the 559 ESP_TRANSFORM parameter and the peer must select one of the proposed 560 values and include it in the response ESP_TRANSFORM parameter. 562 0 1 2 3 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Type | Length | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Reserved | Suite-ID #1 | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Suite-ID #2 | Suite-ID #3 | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Suite-ID #n | Padding | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 Type 4095 575 Length length in octets, excluding Type, Length, and 576 padding 577 Reserved zero when sent, ignored when received 578 Suite-ID defines the ESP Suite to be used 580 The following Suite-IDs are defined ([6],[8]): 582 Suite-ID Value 584 RESERVED 0 585 ESP-AES-CBC with HMAC-SHA1 1 586 ESP-3DES-CBC with HMAC-SHA1 2 587 ESP-3DES-CBC with HMAC-MD5 3 588 ESP-BLOWFISH-CBC with HMAC-SHA1 4 589 ESP-NULL with HMAC-SHA1 5 590 ESP-NULL with HMAC-MD5 6 592 The sender of an ESP transform parameter MUST make sure that there 593 are no more than six (6) Suite-IDs in one ESP transform parameter. 594 Conversely, a recipient MUST be prepared to handle received transport 595 parameters that contain more than six Suite-IDs. The limited number 596 of Suite-IDs sets the maximum size of ESP_TRANSFORM parameter. As 597 the default configuration, the ESP_TRANSFORM parameter MUST contain 598 at least one of the mandatory Suite-IDs. There MAY be a 599 configuration option that allows the administrator to override this 600 default. 602 Mandatory implementations: ESP-AES-CBC with HMAC-SHA1 and ESP-NULL 603 with HMAC-SHA1. 605 5.1.3. NOTIFY Parameter 607 The HIP base specification defines a set of NOTIFY error types. The 608 following error types are required for describing errors in ESP 609 Transform crypto suites during negotiation. 611 NOTIFY PARAMETER - ERROR TYPES Value 612 ------------------------------ ----- 614 NO_ESP_PROPOSAL_CHOSEN 18 616 None of the proposed ESP Transform crypto suites was 617 acceptable. 619 INVALID_ESP_TRANSFORM_CHOSEN 19 621 The ESP Transform crypto suite does not correspond to 622 one offered by the responder. 624 5.2. HIP ESP Security Association Setup 626 The ESP Security Association is set up during the base exchange. The 627 following subsections define the ESP SA setup procedure both using 628 base exchange messages (R1, I2, R2) and using UPDATE messages. 630 5.2.1. Setup During Base Exchange 632 5.2.1.1. Modifications in R1 634 The ESP_TRANSFORM contains the ESP modes supported by the sender, in 635 the order of preference. All implementations MUST support AES [3] 636 with HMAC-SHA-1-96 [2]. 638 The following figure shows the resulting R1 packet layout. 640 The HIP parameters for the R1 packet: 642 IP ( HIP ( [ R1_COUNTER, ] 643 PUZZLE, 644 DIFFIE_HELLMAN, 645 HIP_TRANSFORM, 646 ESP_TRANSFORM, 647 HOST_ID, 648 [ ECHO_REQUEST, ] 649 HIP_SIGNATURE_2 ) 650 [, ECHO_REQUEST ]) 652 5.2.1.2. Modifications in I2 654 The ESP_INFO contains the sender's SPI for this association as well 655 as the keymat index from where the ESP SA keys will be drawn. The 656 Old SPI value is set to zero. 658 The ESP_TRANSFORM contains the ESP mode selected by the sender of R1. 659 All implementations MUST support AES [3] with HMAC-SHA-1-96 [2]. 661 The following figure shows the resulting I2 packet layout. 663 The HIP parameters for the I2 packet: 665 IP ( HIP ( ESP_INFO, 666 [R1_COUNTER,] 667 SOLUTION, 668 DIFFIE_HELLMAN, 669 HIP_TRANSFORM, 670 ESP_TRANSFORM, 671 ENCRYPTED { HOST_ID }, 672 [ ECHO_RESPONSE ,] 673 HMAC, 674 HIP_SIGNATURE 675 [, ECHO_RESPONSE] ) ) 677 5.2.1.3. Modifications in R2 679 The R2 contains an ESP_INFO parameter, which has the SPI value of the 680 sender of the R2 for this association. The ESP_INFO also has the 681 keymat index value specifying where the ESP SA keys are drawn. 683 The following figure shows the resulting R2 packet layout. 685 The HIP parameters for the R2 packet: 687 IP ( HIP ( ESP_INFO, HMAC_2, HIP_SIGNATURE ) ) 689 5.3. HIP ESP Rekeying 691 In this section, the procedure for rekeying an existing ESP SA is 692 presented. 694 Conceptually, the process can be represented by the following message 695 sequence using the host names I' and R' defined in Section 3.3.2. 696 For simplicity, HMAC and HIP_SIGNATURE are not depicted, and 697 DIFFIE_HELLMAN keys are optional. The UPDATE with ACK_I need not be 698 piggybacked with the UPDATE with SEQ_R; it may be acked separately 699 (in which case the sequence would include four packets). 701 I' R' 703 UPDATE(ESP_INFO, SEQ_I, [DIFFIE_HELLMAN]) 704 -----------------------------------> 705 UPDATE(ESP_INFO, SEQ_R, ACK_I, [DIFFIE_HELLMAN]) 706 <----------------------------------- 707 UPDATE(ACK_R) 708 -----------------------------------> 710 Below, the first two packets in this figure are explained. 712 5.3.1. Initializing Rekeying 714 When HIP is used with ESP, the UPDATE packet is used to initiate 715 rekeying. The UPDATE packet MUST carry an ESP_INFO and MAY carry a 716 DIFFIE_HELLMAN parameter. 718 Intermediate systems that use the SPI will have to inspect HIP 719 packets for those that carry rekeying information. The packet is 720 signed for the benefit of the intermediate systems. Since 721 intermediate systems may need the new SPI values, the contents cannot 722 be encrypted. 724 The following figure shows the contents of a rekeying initialization 725 UPDATE packet. 727 The HIP parameters for the UPDATE packet initiating rekeying: 729 IP ( HIP ( ESP_INFO, 730 SEQ, 731 [DIFFIE_HELLMAN, ] 732 HMAC, 733 HIP_SIGNATURE ) ) 735 5.3.2. Responding to the Rekeying Initialization 737 The UPDATE ACK is used to acknowledge the received UPDATE rekeying 738 initialization. The acknowledgement UPDATE packet MUST carry an 739 ESP_INFO and MAY carry a DIFFIE_HELLMAN parameter. 741 Intermediate systems that use the SPI will have to inspect HIP 742 packets for packets carrying rekeying information. The packet is 743 signed for the benefit of the intermediate systems. Since 744 intermediate systems may need the new SPI values, the contents cannot 745 be encrypted. 747 The following figure shows the contents of a rekeying acknowledgement 748 UPDATE packet. 750 The HIP parameters for the UPDATE packet: 752 IP ( HIP ( ESP_INFO, 753 SEQ, 754 ACK, 755 [ DIFFIE_HELLMAN, ] 756 HMAC, 757 HIP_SIGNATURE ) ) 759 5.4. ICMP Messages 761 The ICMP message handling is mainly described in the HIP base 762 specification [5]. In this section, we describe the actions related 763 to ESP security associations. 765 5.4.1. Unknown SPI 767 If a HIP implementation receives an ESP packet that has an 768 unrecognized SPI number, it MAY respond (subject to rate limiting the 769 responses) with an ICMP packet with type "Parameter Problem", with 770 the Pointer pointing to the the beginning of SPI field in the ESP 771 header. 773 6. Packet Processing 775 Packet processing is mainly defined in the HIP base specification 776 [5]. This section describes the changes and new requirements for 777 packet handling when the ESP transport format is used. Note that all 778 HIP packets (currently protocol 99) MUST bypass ESP processing. 780 6.1. Processing Outgoing Application Data 782 Outgoing application data handling is specified in the HIP base 783 specification [5]. When ESP transport format is used, and there is 784 an active HIP session for the given < source, destination > HIT pair, 785 the outgoing datagram is protected using the ESP security 786 association. In a typical implementation, this will result in a 787 BEET-mode ESP packet being sent. BEET-mode [11] was introduced above 788 in Section 3.2. 790 1. Detect the proper ESP SA using the HITs in the packet header or 791 other information associated with the packet 793 2. Process the packet normally, as if the SA was a transport mode 794 SA. 796 3. Ensure that the outgoing ESP protected packet has proper IP 797 header format depending on the used IP address family, and proper 798 IP addresses in its IP header, e.g., by replacing HITs left by 799 the ESP processing. Note that this placement of proper IP 800 addresses MAY also be performed at some other point in the stack, 801 e.g., before ESP processing. 803 6.2. Processing Incoming Application Data 805 Incoming HIP user data packets arrive as ESP protected packets. In 806 the usual case the receiving host has a corresponding ESP security 807 association, identified by the SPI and destination IP address in the 808 packet. However, if the host has crashed or otherwise lost its HIP 809 state, it may not have such an SA. 811 The basic incoming data handling is specified in the HIP base 812 specification. Additional steps are required when ESP is used for 813 protecting the data traffic. The following steps define the 814 conceptual processing rules for incoming ESP protected datagrams 815 targeted to an ESP security association created with HIP. 817 1. Detect the proper ESP SA using the SPI. If the resulting SA is a 818 non-HIP ESP SA, process the packet according to standard IPsec 819 rules. If there are no SAs identified with the SPI, the host MAY 820 send an ICMP packet as defined in Section 5.4. How to handle 821 lost state is an implementation issue. 823 2. If the SPI matches with an active HIP-based ESP SA, the IP 824 addresses in the datagram are replaced with the HITs associated 825 with the SPI. Note that this IP-address-to-HIT conversion step 826 MAY also be performed at some other point in the stack, e.g., 827 after ESP processing. Note also that if the incoming packet has 828 IPv4 addresses, the packet must be converted to IPv6 format 829 before replacing the addresses with HITs (such that the transport 830 checksum will pass if there are no errors). 832 3. The transformed packet is next processed normally by ESP, as if 833 the packet were a transport mode packet. The packet may be 834 dropped by ESP, as usual. In a typical implementation, the 835 result of successful ESP decryption and verification is a 836 datagram with the associated HITs as source and destination. 838 4. The datagram is delivered to the upper layer. Demultiplexing the 839 datagram to the right upper layer socket is performed as usual, 840 except that the HITs are used in place of IP addresses during the 841 demultiplexing. 843 6.3. HMAC and SIGNATURE Calculation and Verification 845 The new HIP parameters described in this document, ESP_INFO and 846 ESP_TRANSFORM, must be protected using HMAC and signature 847 calculations. In a typical implementation, they are included in R1, 848 I2, R2, and UPDATE packet HMAC and SIGNATURE calculations as 849 described in [5]. 851 6.4. Processing Incoming ESP SA Initialization (R1) 853 The ESP SA setup is initialized in the R1 message. The receiving 854 host (Initiator) select one of the ESP transforms from the presented 855 values. If no suitable value is found, the negotiation is 856 terminated. The selected values are subsequently used when 857 generating and using encryption keys, and when sending the reply 858 packet. If the proposed alternatives are not acceptable to the 859 system, it may abandon the ESP SA establishment negotiation, or it 860 may resend the I1 message within the retry bounds. 862 After selecting the ESP transform, and performing other R1 863 processing, the system prepares and creates an incoming ESP security 864 association. It may also prepare a security association for outgoing 865 traffic, but since it does not have the correct SPI value yet, it 866 cannot activate it. 868 6.5. Processing Incoming Initialization Reply (I2) 870 The following steps are required to process the incoming ESP SA 871 initialization replies in I2. The steps below assume that the I2 has 872 been accepted for processing (e.g., has not been dropped due to HIT 873 comparisons as described in [5]). 875 o The ESP_TRANSFORM parameter is verified and it MUST contain a 876 single value in the parameter and it MUST match one of the values 877 offered in the initialization packet. 879 o The ESP_INFO New SPI field is parsed to obtain the SPI that will 880 be used for the Security Association outbound from the Responder 881 and inbound to the Initiator. For this initial ESP SA 882 establishment, the Old SPI value MUST be zero. The Keymat Index 883 field MUST contain the index value to the KEYMAT from where the 884 ESP SA keys are drawn. 886 o The system prepares and creates both incoming and outgoing ESP 887 security associations. 889 o Upon successful processing of the initialization reply message, 890 the possible old Security Associations (as left over from an 891 earlier incarnation of the HIP association) are dropped and the 892 new ones are installed, and a finalizing packet, R2, is sent. 893 Possible ongoing rekeying attempts are dropped. 895 6.6. Processing Incoming ESP SA Setup Finalization (R2) 897 Before the ESP SA can be finalized, the ESP_INFO New SPI field is 898 parsed to obtain the SPI that will be used for the ESP Security 899 Association inbound to the sender of the finalization message R2. 900 The system uses this SPI to create or activate the outgoing ESP 901 security association used for sending packets to the peer. 903 6.7. Dropping HIP Associations 905 When the system drops a HIP association, as described in the HIP base 906 specification, the associated ESP SAs MUST also be dropped. 908 6.8. Initiating ESP SA Rekeying 910 During ESP SA rekeying, the hosts draw new keys from the existing 911 keying material, or a new keying material is generated from where the 912 new keys are drawn. 914 A system may initiate the SA rekeying procedure at any time. It MUST 915 initiate a rekey if its incoming ESP sequence counter is about to 916 overflow. The system MUST NOT replace its keying material until the 917 rekeying packet exchange successfully completes. 919 Optionally, a system may include a new Diffie-Hellman key for use in 920 new KEYMAT generation. New KEYMAT generation occurs prior to drawing 921 the new keys. 923 The rekeying procedure uses the UPDATE mechanism defined in [5]. 924 Because each peer must update its half of the security association 925 pair (including new SPI creation), the rekeying process requires that 926 each side both send and receive an UPDATE. A system will then rekey 927 the ESP SA when it has sent parameters to the peer and has received 928 both an ACK of the relevant UPDATE message and corresponding peer's 929 parameters. It may be that the ACK and the required HIP parameters 930 arrive in different UPDATE messages. This is always true if a system 931 does not initiate ESP SA update but responds to an update request 932 from the peer, but may also occur if two systems initiate update 933 nearly simultaneously. In such a case, if the system has an 934 outstanding update request, it saves the one parameter and waits for 935 the other before completing rekeying. 937 The following steps define the processing rules for initiating an ESP 938 SA update: 940 1. The system decides whether to continue to use the existing KEYMAT 941 or to generate new KEYMAT. In the latter case, the system MUST 942 generate a new Diffie-Hellman public key. 944 2. The system creates an UPDATE packet, which contains the ESP_INFO 945 parameter. In addition, the host may include the optional 946 DIFFIE_HELLMAN parameter. If the UDPATE contains the 947 DIFFIE_HELLMAN parameter, the Keymat Index in the ESP_INFO 948 parameter MUST be zero, and the Diffie-Hellman group ID must be 949 unchanged from that used in the initial handshake. If the UPDATE 950 does not contain DIFFIE_HELLMAN, the ESP_INFO Keymat Index MUST 951 be greater or equal to the index of the next byte to be drawn 952 from the current KEYMAT. 954 3. The system sends the UPDATE packet. For reliability, the 955 underlying UPDATE retransmission mechanism MUST be used. 957 4. The system MUST NOT delete its existing SAs, but continue using 958 them if its policy still allows. The rekeying procedure SHOULD 959 be initiated early enough to make sure that the SA replay 960 counters do not overflow. 962 5. In case a protocol error occurs and the peer system acknowledges 963 the UPDATE but does not itself send an ESP_INFO, the system may 964 not finalize the outstanding ESP SA update request. To guard 965 against this, a system MAY re-initiate the ESP SA update 966 procedure after some time waiting for the peer to respond, or it 967 MAY decide to abort the ESP SA after waiting for an 968 implementation-dependent time. The system MUST NOT keep an 969 oustanding ESP SA update request for an indefinite time. 971 To simplify the state machine, a host MUST NOT generate new UPDATEs 972 while it has an outstanding ESP SA update request, unless it is 973 restarting the update process. 975 6.9. Processing Incoming UPDATE Packets 977 When a system receives an UPDATE packet, it must be processed if the 978 following conditions hold (in addition to the generic conditions 979 specified for UPDATE processing in Section 6.12 of [5]): 981 1. A corresponding HIP association must exist. This is usually 982 ensured by the underlying UPDATE mechanism. 984 2. The state of the HIP association is ESTABLISHED or R2-SENT. 986 If the above conditions hold, the following steps define the 987 conceptual processing rules for handling the received UPDATE packet: 989 1. If the received UPDATE contains a DIFFIE_HELLMAN parameter, the 990 received Keymat Index MUST be zero and the Group ID must match 991 the Group ID in use on the association. If this test fails, the 992 packet SHOULD be dropped and the system SHOULD log an error 993 message. 995 2. If there is no outstanding rekeying request, the packet 996 processing continues as specified in Section 6.9.1. 998 3. If there is an outstanding rekeying request, the UPDATE MUST be 999 acknowledged, the received ESP_INFO (and possibly DIFFIE_HELLMAN) 1000 parameters must be saved, and the packet processing continues as 1001 specified in Section 6.10. 1003 6.9.1. Processing UPDATE Packet: No Outstanding Rekeying Request 1005 The following steps define the conceptual processing rules for 1006 handling a received UPDATE packet with ESP_INFO parameter: 1008 1. The system consults its policy to see if it needs to generate a 1009 new Diffie-Hellman key, and generates a new key (with same Group 1010 ID) if needed. The system records any newly generated or 1011 received Diffie-Hellman keys, for use in KEYMAT generation upon 1012 finalizing the ESP SA update. 1014 2. If the system generated a new Diffie-Hellman key in the previous 1015 step, or if it received a DIFFIE_HELLMAN parameter, it sets 1016 ESP_INFO Keymat Index to zero. Otherwise, the ESP_INFO Keymat 1017 Index MUST be greater or equal to the index of the next byte to 1018 be drawn from the current KEYMAT. In this case, it is 1019 RECOMMENDED that the host use the Keymat Index requested by the 1020 peer in the received ESP_INFO. 1022 3. The system creates an UPDATE packet, which contains an ESP_INFO 1023 parameter, and the optional DIFFIE_HELLMAN parameter. This 1024 UPDATE would also typically acknowledge the peer's UPDATE with an 1025 ACK parameter, although a separate UPDATE ACK may be sent. 1027 4. The system sends the UPDATE packet and stores any received 1028 ESP_INFO, and DIFFIE_HELLMAN parameters. At this point, it only 1029 needs to receive an acknowledgement for the newly sent UPDATE to 1030 finish ESP SA update. In the usual case, the acknowledgement is 1031 handled by the underlying UPDATE mechanism. 1033 6.10. Finalizing Rekeying 1035 A system finalizes rekeying when it has both received the 1036 corresponding UPDATE acknowledgement packet from the peer and it has 1037 successfully received the peer's UPDATE. The following steps are 1038 taken: 1040 1. If the received UPDATE messages contains a new Diffie-Hellman 1041 key, the system has a new Diffie-Hellman key due to initiating 1042 ESP SA update, or both, the system generates new KEYMAT. If 1043 there is only one new Diffie-Hellman key, the old existing key is 1044 used as the other key. 1046 2. If the system generated new KEYMAT in the previous step, it sets 1047 Keymat Index to zero, independent of whether the received UPDATE 1048 included a Diffie-Hellman key or not. If the system did not 1049 generate new KEYMAT, it uses the greater Keymat Index of the two 1050 (sent and received) ESP_INFO parameters. 1052 3. The system draws keys for new incoming and outgoing ESP SAs, 1053 starting from the Keymat Index, and prepares new incoming and 1054 outgoing ESP SAs. The SPI for the outgoing SA is the new SPI 1055 value received in an ESP_INFO parameter. The SPI for the 1056 incoming SA was generated when the ESP_INFO was sent to the peer. 1057 The order of the keys retrieved from the KEYMAT during rekeying 1058 process is similar to that described in Section 7. Note, that 1059 only IPsec ESP keys are retrieved during rekeying process, not 1060 the HIP keys. 1062 4. The system starts to send to the new outgoing SA and prepares to 1063 start receiving data on the new incoming SA. Once the system 1064 receives data on the new incoming SA it may safely delete the old 1065 SAs. 1067 6.11. Processing NOTIFY Packets 1069 The processing of NOTIFY packets is described in the HIP base 1070 specification. 1072 7. Keying Material 1074 The keying material is generated as described in the HIP base 1075 specification. During the base exchange, the initial keys are drawn 1076 from the generated material. After the HIP association keys have 1077 been drawn, the ESP keys are drawn in the following order: 1079 SA-gl ESP encryption key for HOST_g's outgoing traffic 1081 SA-gl ESP authentication key for HOST_g's outgoing traffic 1083 SA-lg ESP encryption key for HOST_l's outgoing traffic 1085 SA-lg ESP authentication key for HOST_l's outgoing traffic 1087 HOST_g denotes the host with the greater HIT value, and HOST_l the 1088 host with the lower HIT value. When HIT values are compared, they 1089 are interpreted as positive (unsigned) 128-bit integers in network 1090 byte order. 1092 The four HIP keys are only drawn from KEYMAT during a HIP I1->R2 1093 exchange. Subsequent rekeys using UPDATE will only draw the four ESP 1094 keys from KEYMAT. Section 6.9 describes the rules for reusing or 1095 regenerating KEYMAT based on the rekeying. 1097 The number of bits drawn for a given algorithm is the "natural" size 1098 of the keys. For the mandatory algorithms, the following sizes 1099 apply: 1101 AES 128 bits 1103 SHA-1 160 bits 1105 NULL 0 bits 1107 8. Security Considerations 1109 In this document the usage of ESP [4] between HIP hosts to protect 1110 data traffic is introduced. The Security Considerations for ESP are 1111 discussed in the ESP specification. 1113 There are different ways to establish an ESP Security Association 1114 between two nodes. This can be done, e.g. using IKE [10]. This 1115 document specifies how Host Identity Protocol is used to establish 1116 ESP Security Associations. 1118 The following issues are new, or changed from the standard ESP usage: 1120 o Initial keying material generation 1122 o Updating the keying material 1124 The initial keying material is generated using the Host Identity 1125 Protocol [5] using Diffie-Hellman procedure. This document extends 1126 the usage of UDPATE packet, defined in the base specification, to 1127 modify existing ESP SAs. The hosts may rekey, i.e. force the 1128 generation of new keying material using Diffie-Hellman procedure. 1129 The initial setup of ESP SA between the hosts is done during the base 1130 ecxhange and the message exchange is protected with using methods 1131 provided by base exchange. Changing of connection parameters means 1132 basically that the old ESP SA is removed and a new one is generated 1133 once the UPDATE message exchange has been completed. The message 1134 exchange is protected using the HIP association keys. Both HMAC and 1135 signing of packets is used. 1137 9. IANA Considerations 1139 This document defines additional parameters for the Host Identity 1140 Protocol [5]. These parameters are defined in Section 5.1.1 and 1141 Section 5.1.2 with the following numbers: 1143 o ESP_INFO is 65. 1145 o ESP_TRANSFORM is 4095. 1147 10. Acknowledgments 1149 This document was separated from the base "Host Identity Protocol" 1150 specification in the beginning of 2005. Since then, a number of 1151 people have contributed to the text by giving comments and 1152 modification proposals. The list of people include Tom Henderson, 1153 Jeff Ahrenholz, Jan Melen, Jukka Ylitalo, and Miika Komu. Authors 1154 want also thank Charlie Kaufman for reviewing the document with the 1155 eye on the usage of crypto algorithms. 1157 Due to the history of this document, most of the ideas are inherited 1158 from the base "Host Identity Protocol" specification. Thus the list 1159 of people in the Acknowledgments section of that specification is 1160 also valid for this document. Many people have given valueable 1161 feedback, and our apologies for anyone whose name is missing. 1163 11. References 1165 11.1. Normative references 1167 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1168 Levels", BCP 14, RFC 2119, March 1997. 1170 [2] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP 1171 and AH", RFC 2404, November 1998. 1173 [3] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 1174 Algorithm and Its Use with IPsec", RFC 3602, September 2003. 1176 [4] Kent, S., "IP Encapsulating Security Payload (ESP)", 1177 draft-ietf-ipsec-esp-v3-10 (work in progress), March 2005. 1179 [5] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-06 1180 (work in progress), June 2006. 1182 [6] Schiller, J., "Cryptographic Algorithms for use in the Internet 1183 Key Exchange Version 2", draft-ietf-ipsec-ikev2-algorithms-05 1184 (work in progress), April 2004. 1186 [7] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1187 Architecture", draft-ietf-hip-arch-03 (work in progress), 1188 August 2005. 1190 [8] Schneier, B., "Applied Cryptography Second Edition: protocols 1191 algorithms and source in code in C", 1996. 1193 11.2. Informative references 1195 [9] Kent, S. and K. Seo, "Security Architecture for the Internet 1196 Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress), 1197 April 2005. 1199 [10] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 1200 RFC 2409, November 1998. 1202 [11] Melen, J. and P. Nikander, "A Bound End-to-End Tunnel (BEET) 1203 mode for ESP", draft-nikander-esp-beet-mode-06 (work in 1204 progress), August 2006. 1206 [12] Nikander, P., "End-Host Mobility and Multihoming with the Host 1207 Identity Protocol", draft-ietf-hip-mm-04 (work in progress), 1208 June 2006. 1210 Appendix A. A Note on Implementation Options 1212 It is possible to implement this specification in multiple different 1213 ways. As noted above, one possible way of implementing is to rewrite 1214 IP headers below IPsec. In such an implementation, IPsec is used as 1215 if it was processing IPv6 transport mode packets, with the IPv6 1216 header containing HITs instead of IP addresses in the source and 1217 destionation address fields. In outgoing packets, after IPsec 1218 processing, the HITs are replaced with actual IP addresses, based on 1219 the HITs and the SPI. In incoming packets, before IPsec processing, 1220 the IP addresses are replaced with HITs, based on the SPI in the 1221 incoming packet. In such an implementation, all IPsec policies are 1222 based on HITs and the upper layers only see packets with HITs in the 1223 place of IP addresses. Consequently, support of HIP does not 1224 conflict with other use of IPsec as long as the SPI spaces are kept 1225 separate. 1227 Another way for implementing is to use the proposed BEET mode (A 1228 Bound End-to-End mode for ESP) [11]. The BEET mode provides some 1229 features from both IPsec tunnel and transport modes. The HIP uses 1230 HITs as the "inner" addresses and IP addresses as "outer" addresses 1231 like IP addresses are used in the tunnel mode. Instead of tunneling 1232 packets between hosts, a conversion between inner and outer addresses 1233 is made at end-hosts and the inner address is never sent in the wire 1234 after the initial HIP negotiation. BEET provides IPsec transport 1235 mode syntax (no inner headers) with limited tunnel mode semantics 1236 (fixed logical inner addresses - the HITs - and changeable outer IP 1237 addresses). 1239 Compared to the option of implementing the required address rewrites 1240 outside of IPsec, BEET has one implementation level benefit. The 1241 BEET-way of implementing the address rewriting keeps all the 1242 configuration information in one place, at the SADB. On the other 1243 hand, when address rewriting is implemented separately, the 1244 implementation must make sure that the information in the SADB and 1245 the separate address rewriting DB are kept in synchrony. As a 1246 result, the BEET mode based way of implementing is RECOMMENDED over 1247 the separate implementation. 1249 Authors' Addresses 1251 Petri Jokela 1252 Ericsson Research NomadicLab 1253 JORVAS FIN-02420 1254 FINLAND 1256 Phone: +358 9 299 1 1257 Email: petri.jokela@nomadiclab.com 1259 Robert Moskowitz 1260 ICSAlabs, a Division of TruSecure Corporation 1261 1000 Bent Creek Blvd, Suite 200 1262 Mechanicsburg, PA 1263 USA 1265 Email: rgm@icsalabs.com 1267 Pekka Nikander 1268 Ericsson Research NomadicLab 1269 JORVAS FIN-02420 1270 FINLAND 1272 Phone: +358 9 299 1 1273 Email: pekka.nikander@nomadiclab.com 1275 Intellectual Property Statement 1277 The IETF takes no position regarding the validity or scope of any 1278 Intellectual Property Rights or other rights that might be claimed to 1279 pertain to the implementation or use of the technology described in 1280 this document or the extent to which any license under such rights 1281 might or might not be available; nor does it represent that it has 1282 made any independent effort to identify any such rights. Information 1283 on the procedures with respect to rights in RFC documents can be 1284 found in BCP 78 and BCP 79. 1286 Copies of IPR disclosures made to the IETF Secretariat and any 1287 assurances of licenses to be made available, or the result of an 1288 attempt made to obtain a general license or permission for the use of 1289 such proprietary rights by implementers or users of this 1290 specification can be obtained from the IETF on-line IPR repository at 1291 http://www.ietf.org/ipr. 1293 The IETF invites any interested party to bring to its attention any 1294 copyrights, patents or patent applications, or other proprietary 1295 rights that may cover technology that may be required to implement 1296 this standard. Please address the information to the IETF at 1297 ietf-ipr@ietf.org. 1299 Disclaimer of Validity 1301 This document and the information contained herein are provided on an 1302 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1303 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1304 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1305 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1306 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1307 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1309 Copyright Statement 1311 Copyright (C) The Internet Society (2006). This document is subject 1312 to the rights, licenses and restrictions contained in BCP 78, and 1313 except as set forth therein, the authors retain all their rights. 1315 Acknowledgment 1317 Funding for the RFC Editor function is currently provided by the 1318 Internet Society.