idnits 2.17.1 draft-ietf-hip-esp-00.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 1245. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1222. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1229. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1235. ** 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 (June 23, 2005) is 6881 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) == Unused Reference: '11' is defined on line 1141, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-ipsec-esp-v3-05 == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. '5') == Outdated reference: A later version (-05) exists of draft-ietf-hip-mm-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-mm (ref. '6') == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-07 == Outdated reference: A later version (-03) exists of draft-ietf-hip-arch-01 ** Downref: Normative reference to an Informational draft: draft-ietf-hip-arch (ref. '8') == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-rfc2401bis-00 -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '11') (Obsoleted by RFC 4306) == Outdated reference: A later version (-09) exists of draft-nikander-esp-beet-mode-00 Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 8 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: December 25, 2005 R. Moskowitz 5 ICSAlabs, a Division of TruSecure 6 Corporation 7 P. Nikander 8 Ericsson Research NomadicLab 9 June 23, 2005 11 Using ESP transport format with HIP 12 draft-ietf-hip-esp-00 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 December 25, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 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 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 4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.1 ESP in HIP . . . . . . . . . . . . . . . . . . . . . . . . 11 67 4.1.1 Setting up an ESP Security Association . . . . . . . . 11 68 4.1.2 Updating an Existing ESP SA . . . . . . . . . . . . . 12 69 5. Parameter and Packet Formats . . . . . . . . . . . . . . . . . 13 70 5.1 New Parameters . . . . . . . . . . . . . . . . . . . . . . 13 71 5.1.1 ESP_INFO . . . . . . . . . . . . . . . . . . . . . . . 13 72 5.1.2 ESP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 14 73 5.1.3 NOTIFY Parameter . . . . . . . . . . . . . . . . . . . 15 74 5.2 HIP ESP Security Association Setup . . . . . . . . . . . . 16 75 5.2.1 Setup During Base Exchange . . . . . . . . . . . . . . 16 76 5.3 HIP ESP Rekeying . . . . . . . . . . . . . . . . . . . . . 17 77 5.3.1 Initializing Rekeying . . . . . . . . . . . . . . . . 17 78 5.3.2 Responding to the Rekeying Initialization . . . . . . 18 79 5.4 ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 18 80 5.4.1 Unknown SPI . . . . . . . . . . . . . . . . . . . . . 19 81 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 20 82 6.1 Processing Outgoing Application Data . . . . . . . . . . . 20 83 6.2 Processing Incoming Application Data . . . . . . . . . . . 20 84 6.3 HMAC and SIGNATURE Calculation and Verification . . . . . 21 85 6.4 Processing Incoming ESP SA Initialization (R1) . . . . . . 21 86 6.5 Processing Incoming Initialization Reply (I2) . . . . . . 22 87 6.6 Processing Incoming ESP SA Setup Finalization (R2) . . . . 22 88 6.7 Dropping HIP Associations . . . . . . . . . . . . . . . . 22 89 6.8 Initiating ESP SA Rekeying . . . . . . . . . . . . . . . . 22 90 6.9 Processing Incoming UPDATE Packets . . . . . . . . . . . . 24 91 6.9.1 Processing UPDATE Packet: No Outstanding Rekeying 92 Request . . . . . . . . . . . . . . . . . . . . . . . 24 93 6.10 Finalizing Rekeying . . . . . . . . . . . . . . . . . . . 25 94 6.11 Processing NOTIFY Packets . . . . . . . . . . . . . . . . 26 95 7. Keying Material . . . . . . . . . . . . . . . . . . . . . . . 27 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 99 10.1 Normative references . . . . . . . . . . . . . . . . . . . 30 100 10.2 Informative references . . . . . . . . . . . . . . . . . . 30 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 31 102 A. A Note on Implementation Options . . . . . . . . . . . . . . . 32 103 Intellectual Property and Copyright Statements . . . . . . . . 33 105 1. Introduction 107 In the Host Identity Protocol Architecture [8], hosts are identified 108 with public keys. The Host Identity Protocol [5] base exchange 109 allows any two HIP-supporting hosts to authenticate each other and to 110 create a HIP association between themselves. During the base 111 exchange, the hosts generate a piece of shared keying material using 112 an authenticated Diffie-Hellman exchange. 114 The HIP base exchange specification [5] does not describe any 115 transport formats, or methods for user data, to be used during the 116 actual communication; it only defines that it is mandatory to 117 implement the Encapsulated Security Payload (ESP) [4] based 118 transport format and method. This document specifies how ESP is used 119 with HIP to carry actual user data. 121 To be more specific, this document specifies a set of HIP protocol 122 extensions and their handling. Using these extensions, a pair of ESP 123 Security Associations (SAs) is created between the hosts during the 124 base exchange. The resulting ESP Security Associations use keys 125 drawn from the keying material (KEYMAT) generated during the base 126 exchange. After the HIP association and required ESP SAs have been 127 established between the hosts, the user data communication is 128 protected using ESP. In addition, this document specifies methods to 129 update an existing ESP Security Association. 131 It should be noted that representations of host identity are not 132 carried explicitly in the headers of user data packets. Instead, the 133 ESP Security Parameter Index (SPI) is used to indicate the right host 134 context. The SPIs are selected during the HIP ESP setup exchange. 135 For user data packets, ESP SPIs (in possible combination with IP 136 addresses) are used indirectly to identify the host context, thereby 137 avoiding any additional explicit protocol headers. 139 2. Conventions used in this document 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC2119 [1]. 145 3. Using ESP with HIP 147 The HIP base exchange is used to set up a HIP association between two 148 hosts. The base exchange provides two-way host authentication and 149 key material generation, but it does not provide any means for 150 protecting data communication between the hosts. In this document we 151 specify the use of ESP for protecting user data traffic after the HIP 152 base exchange. Note that this use of ESP is intended only for host- 153 to-host traffic; security gateways are not supported. 155 To support ESP use, the HIP base exchange messages require some minor 156 additions to the parameters transported. In the R1 packet, the 157 responder adds the possible ESP transforms in a new ESP_TRANSFORM 158 parameter before sending it to the Initiator. The Initiator gets the 159 proposed transforms, selects one of those proposed transforms, and 160 adds it to the I2 packet in an ESP_TRANSFORM parameter. In this I2 161 packet, the Initiator also sends the SPI value that it wants to be 162 used for ESP traffic flowing from the Responder to the Initiator. 163 This information is carried using the new ESP_INFO parameter. When 164 finalizing the ESP SA setup, the Responder sends its SPI value to the 165 Initiator in the R2 packet, again using ESP_INFO. 167 3.1 ESP Packet Format 169 The ESP specification [4] defines the ESP packet format for IPsec. 170 The HIP ESP packet looks exactly the same as the IPsec ESP transport 171 format packet. The semantics, however, are a bit different and are 172 described in more detail in the next subsection. 174 3.2 ESP Packet Processing 176 The ESP specification [4] defines packet processing for ESP, and 177 defines two modes of operation: tunnel mode and transport mode. 178 This section reviews the main changes to ESP packet processing when 179 ESP is combined with HIP. 181 The main difference between standard ESP and HIP's use of ESP is the 182 use by HIP of a new mode for operation, which has been called "Bound 183 End-to-End Tunnel" (BEET) mode [12]. In BEET mode, the ESP packet is 184 formatted as a transport mode packet, but the semantics of the 185 connection are the same as for tunnel mode. The "outer" addresses of 186 the packet are the IP addresses and the "inner" addresses are the 187 HITs. The HITs do not need to be transmitted over the network, 188 because the SPI value in the ESP packet is used as the hint for the 189 correct HIT pair used for the connection. This mode of operation 190 avoids overhead typically associated with ESP tunnel mode. 192 In ESP, the packet processing and SA lookup are based on IP 193 addresses. In HIP, however, SAs are bound to end-host HITs instead 194 of IP addresses. When a HIP ESP SA packet arrives at the end-host, 195 the host changes the IP addresses in the packet to the corresponding 196 HITs before ESP processing. 198 It should be noted that it is possible to support the HIP way of 199 using ESP with a fully standards compliant IPsec implementation by 200 adding the necessary header rewriting mechanisms below IPsec in the 201 stack. These mechanisms can be considered to be on the network side 202 of IPsec, thus they cannot add any integrity or confidentiality 203 problems that would not exist without them. However, explicit care 204 must be taken to avoid introducing any new denial-of-service attacks. 206 3.2.1 Semantics of the Security Parameter Index (SPI) 208 SPIs are used in ESP to find the right Security Association for 209 received packets. The ESP SPIs have added significance when used 210 with HIP; they are a compressed representation of a pair of HITs. 211 Thus, SPIs MAY be used by intermediary systems in providing services 212 like address mapping. Note that since the SPI has significance at 213 the receiver, only the < DST, SPI >, where DST is a destination IP 214 address, uniquely identifies the receiver HIT at any given point of 215 time. The same SPI value may be used by several hosts. A single < 216 DST, SPI > value may denote different hosts and contexts at different 217 points of time, depending on the host that is currently reachable at 218 the DST. 220 Each host selects for itself the SPI it wants to see in packets 221 received from its peer. This allows it to select different SPIs for 222 different peers. The SPI selection SHOULD be random; the rules of 223 Section 2.1 of the ESP specification [4] must be followed. A 224 different SPI SHOULD be used for each HIP exchange with a particular 225 host; this is to avoid a replay attack. Additionally, when a host 226 rekeys, the SPI MUST be changed. Furthermore, if a host changes over 227 to use a different IP address, it MAY change the SPI. 229 One method for SPI creation that meets the above criteria would be to 230 concatenate the HIT with a 32-bit random or sequential number, hash 231 this (using SHA1), and then use the high order 32 bits as the SPI. 233 The selected SPI is communicated to the peer in the third (I2) and 234 fourth (R2) packets of the base HIP exchange. Changes in SPI are 235 signaled with ESP_INFO parameters. 237 3.3 Security Association Establishment and Maintenance 238 3.3.1 ESP Security Associations 240 In HIP, ESP Security Associations are setup between the HIP nodes 241 during the base exchange [5]. Existing ESP SAs can be updated later 242 using UPDATE messages. The reason for updating the ESP SA later can 243 be e.g. need for rekeying the SA because of sequence number rollover. 245 Upon setting up a HIP association, each association is linked to two 246 ESP SAs, one for incoming packets and one for outgoing packets. The 247 Initiator's incoming SA corresponds with the Responder's outgoing 248 one, and vice versa. The Initiator defines the SPI for the former 249 association, as defined in Section 3.2.1. This SA is called SA-RI, 250 and the corresponding SPI is called SPI-RI. Respectively, the 251 Responder's incoming SA corresponds with the Initiator's outgoing SA 252 and is called SA-IR, with the SPI being called SPI-IR. 254 The Initiator creates SA-RI as a part of R1 processing, before 255 sending out the I2, as explained in Section 6.4. The keys are 256 derived from KEYMAT, as defined in Section 7. The Responder creates 257 SA-RI as a part of I2 processing, see Section 6.5. 259 The Responder creates SA-IR as a part of I2 processing, before 260 sending out R2; see Section 6.5. The Initiator creates SA-IR when 261 processing R2; see Section 6.6. 263 The initial session keys are drawn from the generated keying 264 material, KEYMAT, after the HIP keys have been drawn as specified in 265 [5]. 267 When the HIP association is removed, the related ESP SAs MUST also be 268 removed. 270 3.3.2 Rekeying 272 After the initial HIP base exchange and SA establishment, both hosts 273 are in the ESTABLISHED state. There are no longer Initiator and 274 Responder roles and the association is symmetric. In this 275 subsection, the party that initiates the rekey procedure is denoted 276 with I' and the peer with R'. 278 An existing HIP-created ESP SA may need updating during the lifetime 279 of the HIP association. This document specifies the rekeying of an 280 existing HIP-created ESP SA, using the UPDATE message. The ESP_INFO 281 parameter introduced above is used for this purpose. 283 I' initiates the ESP SA updating process when needed (see 284 Section 6.8). It creates an UPDATE packet with required information 285 and sends it to the peer node. The old SAs are still in use, local 286 policy permitting. 288 R', after receiving and processing the UPDATE (see Section 6.9), 289 generates new SAs: SA-I'R' and SA-R'I'. It does not take the new 290 outgoing SA into use, but still uses the old one, so there 291 temporarily exists two SA pairs towards the same peer host. The SPI 292 for the new outgoing SA, SPI-R'I', is specified in the received 293 ESP_INFO parameter in the UPDATE packet. For the new incoming SA, R' 294 generates the new SPI value, SPI-I'R', and includes it in the 295 response UPDATE packet. 297 When I' receives a response UPDATE from R', it generates new SAs, as 298 described in Section 6.9: SA-I'R' and SA-R'I'. It starts using the 299 new outgoing SA immediately. 301 R' starts using the new outgoing SA when it receives traffic on the 302 new incoming SA. After this, R' can remove the old SAs. Similarly, 303 when the I' receives traffic from the new incoming SA, it can safely 304 remove the old SAs. 306 3.3.3 Security Association Management 308 An SA pair is indexed by the 2 SPIs and 2 HITs (both local and remote 309 HITs since a system can have more than one HIT). An inactivity timer 310 is RECOMMENDED for all SAs. If the state dictates the deletion of an 311 SA, a timer is set to allow for any late arriving packets. 313 3.3.4 Security Parameter Index (SPI) 315 The SPIs in ESP provide a simple compression of the HIP data from all 316 packets after the HIP exchange. This does require a per HIT-pair 317 Security Association (and SPI), and a decrease of policy granularity 318 over other Key Management Protocols like IKE. 320 When a host updates the ESP SA, it provides a new inbound SPI to and 321 gets a new outbound SPI from its partner. 323 3.3.5 Supported Transforms 325 All HIP implementations MUST support AES [3] and HMAC-SHA-1-96 [2]. 326 If the Initiator does not support any of the transforms offered by 327 the Responder, it should abandon the negotiation and inform the peer 328 with a NOTIFY message about a non-supported transform. 330 In addition to AES, all implementations MUST implement the ESP NULL 331 encryption algorithm. When the ESP NULL encryption is used, it MUST 332 be used together with SHA1 or MD5 authentication as specified in 333 Section 5.1.2 335 3.3.6 Sequence Number 337 The Sequence Number field is MANDATORY when ESP is used with HIP. 338 Anti-replay protection MUST be used in an ESP SA established with 339 HIP. This means that each host MUST rekey before its sequence number 340 reaches 2^32, or if extended sequence numbers are used, 2^64. 342 In some instances, a 32-bit sequence number is inadequate. In the 343 ESP_TRANSFORM parameter, a peer MAY require that a 64-bit sequence 344 numbers be used. In this case the higher 32 bits are NOT included in 345 the ESP header, but are simply kept local to both peers. The 64-bit 346 sequence number is required in fast networks when there is a risk 347 that the sequence number will rollover too often. See [10]. 349 3.3.7 Lifetimes and Timers 351 HIP does not negotiate any lifetimes. All ESP lifetimes are local 352 policy. The only lifetimes a HIP implementation MUST support are 353 sequence number rollover (for replay protection), and SHOULD support 354 timing out inactive ESP SAs. An SA times out if no packets are 355 received using that SA. The default timeout value is 15 minutes. 356 Implementations MAY support lifetimes for the various ESP transforms. 357 Each implementation SHOULD implement per-HIT configuration of the 358 inactivity timeout, allowing statically configured HIP associations 359 to stay alive for days, even when inactive. 361 4. The Protocol 363 In this section, the protocol for setting up an ESP association to be 364 used with HIP association is described. 366 4.1 ESP in HIP 368 4.1.1 Setting up an ESP Security Association 370 Setting up an ESP Security Association between hosts using HIP 371 consists of three messages passed between the hosts. The parameters 372 are included in R1, I2, and R2 messages during base exchange. 374 Initiator Responder 376 I1 377 ----------------------------------> 379 R1: ESP_TRANSFORM 380 <---------------------------------- 382 I2: ESP_TRANSFORM, ESP_INFO 383 ----------------------------------> 385 R2: ESP_INFO 386 <---------------------------------- 388 Setting up an ESP Security Association between HIP hosts requires 389 three messages to exchange the information that is required during an 390 ESP communication. 392 The R1 message contains the ESP_TRANSFORM parameter, in which the 393 sending host defines the possible ESP transforms it is willing to use 394 for the ESP SA. 396 The I2 message contains the response to an ESP_TRANSFORM received in 397 the R1 message. The sender must select one of the proposed ESP 398 transforms from the ESP_TRANSFORM parameter in the R1 message and 399 include the selected one in the ESP_TRANSFORM parameter in the I2 400 packet. In addition to the transform, the host includes the ESP_INFO 401 parameter, containing the SPI value to be used by the peer host. 403 In the R2 message, the ESP SA setup is finalized. The packet 404 contains the SPI information required by the Initiator for the ESP 405 SA. 407 4.1.2 Updating an Existing ESP SA 409 The update process is accomplished using two messages. The HIP 410 UPDATE message is used to update the parameters of an existing ESP 411 SA. The UPDATE mechanism and message is defined in [5] and the 412 additional parameters for updating an existing ESP SA are described 413 here. 415 H1 H2 416 UPDATE: ESP_INFO [, DIFFIE_HELLMAN] 417 -----------------------------------------------------> 419 UPDATE: ESP_INFO [, DIFFIE_HELLMAN] 420 <----------------------------------------------------- 422 Not shown in the above figures are the corresponding SEQ and ACK 423 parameters; at a minimum, the exchange shown above would include a 424 SEQ parameter in the first packet shown, both a SEQ and an ACK in the 425 second packet, and a third packet containing only an ACK. 427 The host willing to update the ESP SA creates and sends an UPDATE 428 message. The message contains the ESP_INFO parameter, containing the 429 old SPI value that was used, the new SPI value to be used, and the 430 index value for the keying material, giving the point from where the 431 next keys will be drawn. If new keying material must be generated, 432 the UPDATE message will also contain the DIFFIE_HELLMAN parameter, 433 defined in [5]. 435 The host receiving the UPDATE message requesting update of an 436 existing ESP SA, MUST reply with an UPDATE message. In the reply 437 message, the host sends the ESP_INFO parameter containing the 438 corresponding values: old SPI, new SPI, and the keying material 439 index. If the incoming UPDATE contained a DIFFIE_HELLMAN parameter, 440 the reply packet MUST also contain a DIFFIE_HELLMAN parameter. 442 5. Parameter and Packet Formats 444 In this section, new and modified HIP parameters are presented, as 445 well as modified HIP packets. 447 5.1 New Parameters 449 Two new HIP parameters are defined for setting up ESP transport 450 format associations in HIP communication and for rekeying existing 451 ones. Also, the NOTIFY parameter, described in [5], has two new 452 error parameters. 454 Parameter Type Length Data 456 ESP_INFO 65 12 Remote's old SPI, 457 new SPI and other info 458 ESP_TRANSFORM 2048 variable ESP Encryption and 459 Authentication Transform(s) 461 5.1.1 ESP_INFO 463 During the establishment and update of an ESP SA, the SPI value of 464 both hosts must be transmitted between the hosts. Additional 465 information that is required when the hosts are drawing keys from the 466 generated keying material is the index value into the KEYMAT from 467 where the keys are drawn. The ESP_INFO parameter is used to transmit 468 this information between the hosts. 470 During the initial ESP SA setup, the hosts send the SPI value that 471 they want the peer to use when sending ESP data to them. The value 472 is set in the New SPI field of the ESP_INFO parameter. In the 473 initial setup, an old value for the SPI does not exist, thus the Old 474 SPI value field is set to zero. The Old SPI field value may also be 475 zero when additional SAs are set up between HIP hosts, e.g. in case 476 of multihomed HIP hosts [6]. However, such use is beyond the scope 477 of this specification. 479 The Keymat index value points to the place in the KEYMAT from where 480 the keying material for the ESP SAs is drawn. The Keymat index value 481 is zero only when the ESP_INFO is sent during a rekeying process and 482 new keying material is generated. 484 During the life of an SA established by HIP, one of the hosts may 485 need to reset the Sequence Number to one and rekey. The reason for 486 rekeying might be an approaching sequence number wrap in ESP, or a 487 local policy on use of a key. Rekeying ends the current SAs and 488 starts new ones on both peers. 490 During the rekeying process, the ESP_INFO parameter is used to 491 transmit the changed SPI values and the keying material index. 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Type | Length | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Reserved | Keymat Index | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Old SPI | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | New SPI | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 Type 65 506 Length 12 507 Keymat Index Index, in bytes, where to continue to draw ESP keys 508 from KEYMAT. If the packet includes a new 509 Diffie-Hellman key and the ESP_INFO is sent in an 510 UPDATE packet, the field MUST be zero. If the 511 ESP_INFO is included in base exchange messages, the 512 Keymat Index must have the index value of the point 513 from where the ESP SA keys are drawn. Note that the 514 length of this field limits the amount of 515 keying material that can be drawn from KEYMAT. If 516 that amount is exceeded, the packet MUST contain 517 a new Diffie-Hellman key. 518 Old SPI Old SPI for data sent to address(es) associated 519 with this SA. If this is an initial SA setup, the 520 Old SPI value is zero. 521 New SPI New SPI for data sent to address(es) associated 522 with this SA." 524 5.1.2 ESP_TRANSFORM 526 The ESP_TRANSFORM parameter is used during ESP SA establishment. The 527 first party sends a selection of transfrom families in the 528 ESP_TRANSFORM parameter and the peer must select one of the proposed 529 values and include it in the response ESP_TRANSFORM parameter. 531 0 1 2 3 532 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 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Type | Length | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Reserved |E| Suite-ID #1 | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Suite-ID #2 | Suite-ID #3 | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Suite-ID #n | Padding | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 Type 2048 544 Length length in octets, excluding Type, Length, and 545 padding 546 E One if the ESP transform requires 64-bit 547 sequence numbers 548 (see 549 Section 3.3.6 551 Reserved zero when sent, ignored when received 552 Suite-ID defines the ESP Suite to be used 554 The following Suite-IDs are defined ([7],[9]): 556 Suite-ID Value 558 RESERVED 0 559 ESP-AES-CBC with HMAC-SHA1 1 560 ESP-3DES-CBC with HMAC-SHA1 2 561 ESP-3DES-CBC with HMAC-MD5 3 562 ESP-BLOWFISH-CBC with HMAC-SHA1 4 563 ESP-NULL with HMAC-SHA1 5 564 ESP-NULL with HMAC-MD5 6 566 There MUST NOT be more than six (6) ESP Suite-IDs in one 567 ESP_TRANSFORM parameter. The limited number of Suite-IDs sets the 568 maximum size of ESP_TRANSFORM parameter. The ESP_TRANSFORM MUST 569 contain at least one of the mandatory Suite-IDs. 571 Mandatory implementations: ESP-AES-CBC with HMAC-SHA1 and ESP-NULL 572 with HMAC-SHA1. 574 5.1.3 NOTIFY Parameter 576 The HIP base specification defines a set of NOTIFY error types. The 577 following error types are required for describing errors in ESP 578 Transform crypto suites during negotiation. 580 NOTIFY PARAMETER - ERROR TYPES Value 581 ------------------------------ ----- 583 NO_ESP_PROPOSAL_CHOSEN 18 585 None of the proposed ESP Transform crypto suites was 586 acceptable. 588 INVALID_ESP_TRANSFORM_CHOSEN 19 590 The ESP Transform crypto suite does not correspond to 591 one offered by the responder. 593 5.2 HIP ESP Security Association Setup 595 The ESP Security Association is set up during the base exchange. The 596 following subsections define the ESP SA setup procedure both using 597 base exchange messages (R1, I2, R2) and using UPDATE messages. 599 5.2.1 Setup During Base Exchange 601 5.2.1.1 Modifications in R1 603 The ESP_TRANSFORM contains the ESP modes supported by the sender, in 604 the order of preference. All implementations MUST support AES [3] 605 with HMAC-SHA-1-96 [2]. 607 The following figure shows the resulting R1 packet layout. 609 The HIP parameters for the R1 packet: 611 IP ( HIP ( [ R1_COUNTER, ] 612 PUZZLE, 613 DIFFIE_HELLMAN, 614 HIP_TRANSFORM, 615 ESP_TRANSFORM, 616 HOST_ID, 617 [ ECHO_REQUEST, ] 618 HIP_SIGNATURE_2 ) 619 [, ECHO_REQUEST ]) 621 5.2.1.2 Modifications in I2 623 The ESP_INFO contains the sender's SPI for this association as well 624 as the keymat index from where the ESP SA keys will be drawn. The 625 Old SPI value is set to zero. 627 The ESP_TRANSFORM contains the ESP mode selected by the sender of R1. 628 All implementations MUST support AES [3] with HMAC-SHA-1-96 [2]. 630 The following figure shows the resulting I2 packet layout. 632 The HIP parameters for the I2 packet: 634 IP ( HIP ( ESP_INFO, 635 [R1_COUNTER,] 636 SOLUTION, 637 DIFFIE_HELLMAN, 638 HIP_TRANSFORM, 639 ESP_TRANSFORM, 640 ENCRYPTED { HOST_ID }, 641 [ ECHO_RESPONSE ,] 642 HMAC, 643 HIP_SIGNATURE 644 [, ECHO_RESPONSE] ) ) 646 5.2.1.3 Modifications in R2 648 The R2 contains an ESP_INFO parameter, which has the SPI value of the 649 sender of the R2 for this association. The ESP_INFO also has the 650 keymat index value specifying where the ESP SA keys are drawn. 652 The following figure shows the resulting R2 packet layout. 654 The HIP parameters for the R2 packet: 656 IP ( HIP ( ESP_INFO, HMAC_2, HIP_SIGNATURE ) ) 658 5.3 HIP ESP Rekeying 660 In this section, the procedure for rekeying an existing ESP SA is 661 presented. 663 5.3.1 Initializing Rekeying 665 When HIP is used with ESP, the UPDATE packet is used to initiate 666 rekeying. The UPDATE packet MUST carry an ESP_INFO and MAY carry a 667 DIFFIE_HELLMAN parameter. 669 Intermediate systems that use the SPI will have to inspect HIP 670 packets for those that carry rekeying information. The packet is 671 signed for the benefit of the intermediate systems. Since 672 intermediate systems may need the new SPI values, the contents cannot 673 be encrypted. 675 The following figure shows the contents of a rekeying initialization 676 UPDATE packet. 678 The HIP parameters for the UPDATE packet initiating rekeying: 680 IP ( HIP ( ESP_INFO, 681 SEQ, 682 [DIFFIE_HELLMAN, ] 683 HMAC, 684 HIP_SIGNATURE ) ) 686 5.3.2 Responding to the Rekeying Initialization 688 The UPDATE ACK is used to acknowledge the received UPDATE rekeying 689 initialization. The acknowledgement UPDATE packet MUST carry an 690 ESP_INFO and MAY carry a DIFFIE_HELLMAN parameter. 692 Intermediate systems that use the SPI will have to inspect HIP 693 packets for packets carrying rekeying information. The packet is 694 signed for the benefit of the intermediate systems. Since 695 intermediate systems may need the new SPI values, the contents cannot 696 be encrypted. 698 The following figure shows the contents of a rekeying acknowledgement 699 UPDATE packet. 701 The HIP parameters for the UPDATE packet: 703 IP ( HIP ( ESP_INFO, 704 SEQ, 705 ACK, 706 [ DIFFIE_HELLMAN, ] 707 HMAC, 708 HIP_SIGNATURE ) ) 710 5.4 ICMP Messages 712 The ICMP message handling is mainly described in the HIP base 713 specification [5]. In this section, we describe the actions related 714 to ESP security associations. 716 5.4.1 Unknown SPI 718 If a HIP implementation receives an ESP packet that has an 719 unrecognized SPI number, it MAY respond (subject to rate limiting the 720 responses) with an ICMP packet with type "Parameter Problem", with 721 the Pointer pointing to the the beginning of SPI field in the ESP 722 header. 724 6. Packet Processing 726 Packet processing is mainly defined in the HIP base specification 727 [5]. This section describes the changes and new requirements for 728 packet handling when the ESP transport format is used. Note that all 729 HIP packets (currently protocol 99) MUST bypass ESP processing. 731 6.1 Processing Outgoing Application Data 733 Outgoing application data handling is specified in the HIP base 734 specification [5]. When ESP transport format is used, and there is 735 an active HIP session for the given < source, destination > HIT pair, 736 the outgoing datagram is protected using the ESP security 737 association. In a typical implementation, this will result in a 738 BEET-mode ESP packet being sent. BEET-mode [12] was introduced above 739 in Section 3.2. 741 1. Detect the proper ESP SA using the HITs in the packet header or 742 other information associated with the packet 744 2. Process the packet normally, as if the SA was a transport mode 745 SA. 747 3. Ensure that the outgoing ESP protected packet has proper IP 748 addresses in its IP header, e.g., by replacing HITs left by the 749 ESP processing. Note that this placement of proper IP addresses 750 MAY also be performed at some other point in the stack, e.g., 751 before ESP processing. 753 6.2 Processing Incoming Application Data 755 Incoming HIP user data packets arrive as ESP protected packets. In 756 the usual case the receiving host has a corresponding ESP security 757 association, identified by the SPI and destination IP address in the 758 packet. However, if the host has crashed or otherwise lost its HIP 759 state, it may not have such an SA. 761 The basic incoming data handling is specified in the HIP base 762 specification. Additional steps are required when ESP is used for 763 protecting the data traffic. The following steps define the 764 conceptual processing rules for incoming ESP protected datagrams 765 targeted to an ESP security association created with HIP. 767 1. Detect the proper ESP SA using the SPI. If the resulting SA is a 768 non-HIP ESP SA, process the packet according to standard IPsec 769 rules. If there are no SAs identified with the SPI, the host MAY 770 send an ICMP packet as defined in Section 5.4. How to handle 771 lost state is an implementation issue. 773 2. If the SPI matches with an active HIP-based ESP SA, the IP 774 addresses in the datagram are replaced with the HITs associated 775 with the SPI. Note that this IP-address-to-HIT conversion step 776 MAY also be performed at some other point in the stack, e.g., 777 after ESP processing. Note also that if the incoming packet has 778 IPv4 addresses, the packet must be converted to IPv6 format 779 before replacing the addresses with HITs (such that the transport 780 checksum will pass if there are no errors). 782 3. The transformed packet is next processed normally by ESP, as if 783 the packet were a transport mode packet. The packet may be 784 dropped by ESP, as usual. In a typical implementation, the 785 result of successful ESP decryption and verification is a 786 datagram with the associated HITs as source and destination. 788 4. If LSIs are used, the address field is converted to contain the 789 LSI value before the packet is sent to the application. 791 5. The datagram is delivered to the upper layer. Demultiplexing the 792 datagram to the right upper layer socket is performed as usual, 793 except that the HITs are used in place of IP addresses during the 794 demultiplexing. 796 6.3 HMAC and SIGNATURE Calculation and Verification 798 The new HIP parameters described in this document, ESP_INFO and 799 ESP_TRANSFORM, must be protected using HMAC and signature 800 calculations. In a typical implementation, they are included in R1, 801 I2, R2, and UPDATE packet HMAC and SIGNATURE calculations as 802 described in [5]. 804 6.4 Processing Incoming ESP SA Initialization (R1) 806 The ESP SA setup is initialized in the R1 message. The receiving 807 host (Initiator) select one of the ESP transforms from the presented 808 values. If no suitable value is found, the negotiation is 809 terminated. The selected values are subsequently used when 810 generating and using encryption keys, and when sending the reply 811 packet. If the proposed alternatives are not acceptable to the 812 system, it may abandon the ESP SA establishment negotiation, or it 813 may resend the I1 message within the retry bounds. 815 After selecting the ESP transform, and performing other R1 816 processing, the system prepares and creates an incoming ESP security 817 association. It may also prepare a security association for outgoing 818 traffic, but since it does not have the correct SPI value yet, it 819 cannot activate it. 821 6.5 Processing Incoming Initialization Reply (I2) 823 The following steps are required to process the incoming ESP SA 824 initialization replies in I2. The steps below assume that the I2 has 825 been accepted for processing (e.g., has not been dropped due to HIT 826 comparisons as described in [5]). 828 o The ESP_TRANSFORM parameter is verified and it MUST contain a 829 single value in the parameter and it MUST match one of the values 830 offered in the initialization packet. 832 o The ESP_INFO New SPI field is parsed to obtain the SPI that will 833 be used for the Security Association outbound from the Responder 834 and inbound to the Initiator. For this initial ESP SA 835 establishment, the Old SPI value MUST be zero. The Keymat Index 836 field MUST contain the index value to the KEYMAT from where the 837 ESP SA keys are drawn. 839 o The system prepares and creates both incoming and outgoing ESP 840 security associations. 842 o Upon successful processing of the initialization reply message, 843 the possible old Security Associations (as left over from an 844 earlier incarnation of the HIP association) are dropped and the 845 new ones are installed, and a finalizing packet, R2, is sent. 846 Possible ongoing rekeying attempts are dropped. 848 6.6 Processing Incoming ESP SA Setup Finalization (R2) 850 Before the ESP SA can be finalized, the ESP_INFO New SPI field is 851 parsed to obtain the SPI that will be used for the ESP Security 852 Association inbound to the sender of the finalization message R2. 853 The system uses this SPI to create or activate the outgoing ESP 854 security association used for sending packets to the peer. 856 6.7 Dropping HIP Associations 858 When the system drops a HIP association, as described in the HIP base 859 specification, the associated ESP SAs MUST also be dropped. 861 6.8 Initiating ESP SA Rekeying 863 During ESP SA rekeying, the hosts draw new keys from the existing 864 keying material, or a new keying material is generated from where the 865 new keys are drawn. 867 A system may initiate the SA rekeying procedure at any time. It MUST 868 initiate a rekey if its incoming ESP sequence counter is about to 869 overflow. The system MUST NOT replace its keying material until the 870 rekeying packet exchange successfully completes. 872 Optionally, a system may include a new Diffie-Hellman key for use in 873 new KEYMAT generation. New KEYMAT generation occurs prior to drawing 874 the new keys. 876 The rekeying procedure uses the UPDATE mechanism defined in [5]. 877 Because each peer must update its half of the security association 878 pair (including new SPI creation), the rekeying process requires that 879 each side both send and receive an UPDATE. A system will then rekey 880 the ESP SA when it has sent parameters to the peer and has received 881 both an ACK of the relevant UPDATE message and corresponding peer's 882 parameters. It may be that the ACK and the required HIP parameters 883 arrive in different UPDATE messages. This is always true if a system 884 does not initiate ESP SA update but responds to an update request 885 from the peer, but may also occur if two systems initiate update 886 nearly simultaneously. In such a case, if the system has an 887 outstanding update request, it saves the one parameter and waits for 888 the other before completing rekeying. 890 The following steps define the processing rules for initiating an ESP 891 SA update: 893 1. The system decides whether to continue to use the existing KEYMAT 894 or to generate new KEYMAT. In the latter case, the system MUST 895 generate a new Diffie-Hellman public key. 897 2. The system creates an UPDATE packet, which contains the ESP_INFO 898 parameter. In addition, the host may include the optional 899 DIFFIE_HELLMAN parameter. If the UDPATE contains the 900 DIFFIE_HELLMAN parameter, the Keymat Index in the ESP_INFO 901 parameter MUST be zero, and the Diffie-Hellman group ID must be 902 unchanged from that used in the initial handshake. If the UPDATE 903 does not contain DIFFIE_HELLMAN, the ESP_INFO Keymat Index MUST 904 be greater or equal to the index of the next byte to be drawn 905 from the current KEYMAT. 907 3. The system sends the UPDATE packet. For reliability, the 908 underlying UPDATE retransmission mechanism SHOULD be used. 910 4. The system MUST NOT delete its existing SAs, but continue using 911 them if its policy still allows. The rekeying procedure SHOULD 912 be initiated early enough to make sure that the SA replay 913 counters do not overflow. 915 5. In case a protocol error occurs and the peer system acknowledges 916 the UPDATE but does not itself send an ESP_INFO, the system may 917 not finalize the outstanding ESP SA update request. To guard 918 against this, a system MAY re-initiate the ESP SA update 919 procedure after some time waiting for the peer to respond, or it 920 MAY decide to abort the ESP SA after waiting for an 921 implementation-dependent time. The system MUST NOT keep an 922 oustanding ESP SA update request for an indefinite time. 924 To simplify the state machine, a host MUST NOT generate new UPDATEs 925 while it has an outstanding ESP SA update request, unless it is 926 restarting the update process. 928 6.9 Processing Incoming UPDATE Packets 930 When a system receives an UPDATE packet, it must be processed if the 931 following conditions hold: 933 1. A corresponding HIP association must exist. This is usually 934 ensured by the underlying UPDATE mechanism. 936 2. The state of the HIP association is ESTABLISHED or R2-SENT. 938 If the above conditions hold, the following steps define the 939 conceptual processing rules for handling the received UPDATE packet: 941 1. If the received UPDATE contains a DIFFIE_HELLMAN parameter, the 942 received Keymat Index MUST be zero and the Group ID must match 943 the Group ID in use on the association. If this test fails, the 944 packet SHOULD be dropped and the system SHOULD log an error 945 message. 947 2. If there is no outstanding rekeying request, the packet 948 processing continues as specified in Section 6.9.1. 950 3. If there is an outstanding rekeying request, the UPDATE MUST be 951 acknowledged, the received ESP_INFO (and possibly DIFFIE_HELLMAN) 952 parameters must be saved, and the packet processing continues as 953 specified in Section 6.10. 955 6.9.1 Processing UPDATE Packet: No Outstanding Rekeying Request 957 The following steps define the conceptual processing rules for 958 handling a received UPDATE packet with ESP_INFO parameter: 960 1. The system consults its policy to see if it needs to generate a 961 new Diffie-Hellman key, and generates a new key (with same Group 962 ID) if needed. The system records any newly generated or 963 received Diffie-Hellman keys, for use in KEYMAT generation upon 964 finalizing the ESP SA update. 966 2. If the system generated new Diffie-Hellman key in the previous 967 step, or it received a DIFFIE_HELLMAN parameter, it sets ESP_INFO 968 Keymat Index to zero. Otherwise, the ESP_INFO Keymat Index MUST 969 be greater or equal to the index of the next byte to be drawn 970 from the current KEYMAT. In this case, it is RECOMMENDED that 971 the host use the Keymat Index requested by the peer in the 972 received ESP_INFO. 974 3. The system creates an UPDATE packet, which contains an ESP_INFO 975 parameter, and the optional DIFFIE_HELLMAN parameter. 977 4. The system sends the UPDATE packet and stores any received 978 ESP_INFO, and DIFFIE_HELLMAN parameters. At this point, it only 979 needs to receive an acknowledgement for the sent UPDATE to finish 980 ESP SA update. In the usual case, the acknowledgement is handled 981 by the underlying UPDATE mechanism. 983 6.10 Finalizing Rekeying 985 A system finalizes rekeying when it has both received the 986 corresponding UPDATE acknowledgement packet from the peer and it has 987 successfully received the peer's UPDATE. The following steps are 988 taken: 990 1. If the received UPDATE messages contains a new Diffie-Hellman 991 key, the system has a new Diffie-Hellman key from initiating ESP 992 SA update, or both, the system generates new KEYMAT. If there is 993 only one new Diffie-Hellman key, the old existing key is used as 994 the other key. 996 2. If the system generated new KEYMAT in the previous step, it sets 997 Keymat Index to zero, independent on whether the received UPDATE 998 included a Diffie-Hellman key or not. If the system did not 999 generate new KEYMAT, it uses the greater Keymat Index of the two 1000 (sent and received) ESP_INFO parameters. 1002 3. The system draws keys for new incoming and outgoing ESP SAs, 1003 starting from the Keymat Index, and prepares new incoming and 1004 outgoing ESP SAs. The SPI for the outgoing SA is the new SPI 1005 value received in an ESP_INFO parameter. The SPI for the 1006 incoming SA was generated when the ESP_INFO was sent to the peer. 1008 The order of the keys retrieved from the KEYMAT during rekeying 1009 process is similar to that described in Section 7. Note, that 1010 only IPsec ESP keys are retrieved during rekeying process, not 1011 the HIP keys. 1013 4. The system cancels any timers protecting the UPDATE. 1015 5. The system starts to send to the new outgoing SA and prepares to 1016 start receiving data on the new incoming SA. 1018 6.11 Processing NOTIFY Packets 1020 The processing of NOTIFY packets is described in the HIP base 1021 specification. 1023 7. Keying Material 1025 The keying material is generated as described in the HIP base 1026 specification. During the base exchange, the initial keys are drawn 1027 from the generated material. After the HIP association keys have 1028 been drawn, the ESP keys are drawn in the following order: 1030 SA-gl ESP encryption key for HOST_g's outgoing traffic 1032 SA-gl ESP authentication key for HOST_g's outgoing traffic 1034 SA-lg ESP encryption key for HOST_l's outgoing traffic 1036 SA-lg ESP authentication key for HOST_l's outgoing traffic 1038 The four HIP keys are only drawn from KEYMAT during a HIP I1->R2 1039 exchange. Subsequent rekeys using UPDATE will only draw the four ESP 1040 keys from KEYMAT. Section 6.9 describes the rules for reusing or 1041 regenerating KEYMAT based on the rekeying. 1043 The number of bits drawn for a given algorithm is the "natural" size 1044 of the keys. For the mandatory algorithms, the following sizes 1045 apply: 1047 AES 128 bits 1049 SHA-1 160 bits 1051 NULL 0 bits 1053 8. Security Considerations 1055 In this document the usage of ESP [4] between HIP hosts to protect 1056 data traffic is introduced. The Security Considerations for ESP are 1057 discussed in the ESP specification. 1059 There are different ways to establish an ESP Security Association 1060 between two nodes. This can be done, e.g. using IKE [[11]]. This 1061 document specifies how Host Identity Protocol is used to establish 1062 ESP Security Associations. 1064 The following issues are new, or changed from the standard ESP usage: 1066 o Initial keying material generation 1068 o Updating the keying material 1070 o Using the BEET mode 1072 The initial keying material is generated using the Host Identity 1073 Protocol [5] using Diffie-Hellman procedure. This document extends 1074 the usage of UDPATE packet, defined in the base specification, to 1075 modify existing ESP SAs. The hosts may rekey, i.e. force the 1076 generation of new keying material using Diffie-Hellman procedure. 1077 The initial setup of ESP SA between the hosts is done during the base 1078 ecxhange and the message exchange is protected with using methods 1079 provided by base exchange. Changing of connection parameters means 1080 basically that the old ESP SA is removed and a new one is generated 1081 once the UPDATE message exchange has been completed. The message 1082 exchange is protected using the HIP association keys. Both HMAC and 1083 signing of packets is used. 1085 IPsec ESP defines two modes of operation: tunnel mode and transport 1086 mode. This document takes advantage of the so called Bound End-to- 1087 End Tunneling (BEET) [12], that is a combination of tunnel and 1088 transport modes. The packet looks like a transport mode packet, but 1089 the semantics is like in tunnel mode packets. The security issues 1090 are discussed in the Security Considerations section in the BEET 1091 specification. 1093 9. IANA Considerations 1095 This document defines additional parameters for the Host Identity 1096 Protocol [5]. These parameters are defined in Section 5.1.1 and 1097 Section 5.1.2 with the following numbers: 1099 o ESP_INFO is 65. 1101 o ESP_TRANSFORM is 2048. 1103 10. References 1105 10.1 Normative references 1107 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1108 Levels", BCP 14, RFC 2119, March 1997. 1110 [2] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP 1111 and AH", RFC 2404, November 1998. 1113 [3] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 1114 Algorithm and Its Use with IPsec", RFC 3602, September 2003. 1116 [4] Kent, S., "IP Encapsulating Security Payload (ESP)", 1117 draft-ietf-ipsec-esp-v3-05 (work in progress), April 2003. 1119 [5] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-00 1120 (work in progress), June 2004. 1122 [6] Nikander, P., "End-Host Mobility and Multi-Homing with Host 1123 Identity Protocol", draft-ietf-hip-mm-00 (work in progress), 1124 October 2004. 1126 [7] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1127 draft-ietf-ipsec-ikev2-07 (work in progress), April 2003. 1129 [8] Moskowitz, R., "Host Identity Protocol Architecture", 1130 draft-ietf-hip-arch-01 (work in progress), December 2004. 1132 10.2 Informative references 1134 [9] Bellovin, S. and W. Aiello, "Just Fast Keying (JFK)", 1135 draft-ietf-ipsec-jfk-04 (work in progress), July 2002. 1137 [10] Kent, S., "Security Architecture for the Internet Protocol", 1138 draft-ietf-ipsec-rfc2401bis-00 (work in progress), 1139 October 2003. 1141 [11] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 1142 RFC 2409, November 1998. 1144 [12] Nikander, P., "A Bound End-to-End Tunnel (BEET) mode for ESP", 1145 draft-nikander-esp-beet-mode-00 (expired) (work in progress), 1146 Oct 2003. 1148 Authors' Addresses 1150 Petri Jokela 1151 Ericsson Research NomadicLab 1152 JORVAS FIN-02420 1153 FINLAND 1155 Phone: +358 9 299 1 1156 Email: petri.jokela@nomadiclab.com 1158 Robert Moskowitz 1159 ICSAlabs, a Division of TruSecure Corporation 1160 1000 Bent Creek Blvd, Suite 200 1161 Mechanicsburg, PA 1162 USA 1164 Email: rgm@icsalabs.com 1166 Pekka Nikander 1167 Ericsson Research NomadicLab 1168 JORVAS FIN-02420 1169 FINLAND 1171 Phone: +358 9 299 1 1172 Email: pekka.nikander@nomadiclab.com 1174 Appendix A. A Note on Implementation Options 1176 It is possible to implement this specification in multiple different 1177 ways. As noted above, one possible way of implementing is to rewrite 1178 IP headers below IPsec. In such an implementation, IPsec is used as 1179 if it was processing IPv6 transport mode packets, with the IPv6 1180 header containing HITs instead of IP addresses in the source and 1181 destionation address fields. In outgoing packets, after IPsec 1182 processing, the HITs are replaced with actual IP addresses, based on 1183 the HITs and the SPI. In incoming packets, before IPsec processing, 1184 the IP addresses are replaced with HITs, based on the SPI in the 1185 incoming packet. In such an implementation, all IPsec policies are 1186 based on HITs and the upper layers only see packets with HITs in the 1187 place of IP addresses. Consequently, support of HIP does not 1188 conflict with other use of IPsec as long as the SPI spaces are kept 1189 separate. 1191 Another way for implementing is to use the proposed BEET mode (A 1192 Bound End-to-End mode for ESP) [12]. The BEET mode provides some 1193 features from both IPsec tunnel and transport modes. The HIP uses 1194 HITs as the "inner" addresses and IP addresses as "outer" addresses 1195 like IP addresses are used in the tunnel mode. Instead of tunneling 1196 packets between hosts, a conversion between inner and outer addresses 1197 is made at end-hosts and the inner address is never sent in the wire 1198 after the initial HIP negotiation. BEET provides IPsec transport 1199 mode syntax (no inner headers) with limited tunnel mode semantics 1200 (fixed logical inner addresses - the HITs - and changeable outer IP 1201 addresses). 1203 Compared to the option of implementing the required address rewrites 1204 outside of IPsec, BEET has one implementation level benefit. The 1205 BEET-way of implementing the address rewriting keeps all the 1206 configuration information in one place, at the SADB. On the other 1207 hand, when address rewriting is implemented separately, the 1208 implementation must make sure that the information in the SADB and 1209 the separate address rewriting DB are kept in synchrony. As a 1210 result, the BEET mode based way of implementing is RECOMMENDED over 1211 the separate implementation. 1213 Intellectual Property Statement 1215 The IETF takes no position regarding the validity or scope of any 1216 Intellectual Property Rights or other rights that might be claimed to 1217 pertain to the implementation or use of the technology described in 1218 this document or the extent to which any license under such rights 1219 might or might not be available; nor does it represent that it has 1220 made any independent effort to identify any such rights. Information 1221 on the procedures with respect to rights in RFC documents can be 1222 found in BCP 78 and BCP 79. 1224 Copies of IPR disclosures made to the IETF Secretariat and any 1225 assurances of licenses to be made available, or the result of an 1226 attempt made to obtain a general license or permission for the use of 1227 such proprietary rights by implementers or users of this 1228 specification can be obtained from the IETF on-line IPR repository at 1229 http://www.ietf.org/ipr. 1231 The IETF invites any interested party to bring to its attention any 1232 copyrights, patents or patent applications, or other proprietary 1233 rights that may cover technology that may be required to implement 1234 this standard. Please address the information to the IETF at 1235 ietf-ipr@ietf.org. 1237 Disclaimer of Validity 1239 This document and the information contained herein are provided on an 1240 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1241 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1242 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1243 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1244 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1245 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1247 Copyright Statement 1249 Copyright (C) The Internet Society (2005). This document is subject 1250 to the rights, licenses and restrictions contained in BCP 78, and 1251 except as set forth therein, the authors retain all their rights. 1253 Acknowledgment 1255 Funding for the RFC Editor function is currently provided by the 1256 Internet Society.