idnits 2.17.1 draft-ietf-ipsecme-ikev2bis-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 8035 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC4306, but the abstract doesn't seem to directly say this. It does mention RFC4306 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC4718, but the abstract doesn't seem to directly say this. It does mention RFC4718 though, so this could be OK. -- The abstract seems to indicate that this document updates RFC4306, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 8, 2010) is 5132 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CERTREQ' is mentioned on line 2362, but not defined == Missing Reference: 'KEi' is mentioned on line 7506, but not defined == Missing Reference: 'KEr' is mentioned on line 7509, but not defined == Missing Reference: 'CP' is mentioned on line 801, but not defined -- Looks like a reference, but probably isn't: '0' on line 4303 -- Looks like a reference, but probably isn't: '1' on line 4304 == Missing Reference: 'RFC4306' is mentioned on line 5816, but not defined ** Obsolete undefined reference: RFC 4306 (Obsoleted by RFC 5996) == Missing Reference: 'IDr' is mentioned on line 6270, but not defined == Missing Reference: 'RFC5282' is mentioned on line 7121, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEV2IANA' ** Obsolete normative reference: RFC 3447 (ref. 'PKCS1') (Obsoleted by RFC 8017) -- Obsolete informational reference (is this intentional?): RFC 4718 (ref. 'Clarif') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 2407 (ref. 'DOI') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 5335 (ref. 'EAI') (Obsoleted by RFC 6532) -- Obsolete informational reference (is this intentional?): RFC 3490 (ref. 'IDNA') (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. 'IKEV1') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. 'IKEV2') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'IPSECARCH-OLD') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2408 (ref. 'ISAKMP') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. 'MIPV6') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4282 (ref. 'NAI') (Obsoleted by RFC 7542) Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Kaufman 3 Internet-Draft Microsoft 4 Obsoletes: 4306, 4718 P. Hoffman 5 (if approved) VPN Consortium 6 Intended status: Standards Track Y. Nir 7 Expires: October 10, 2010 Check Point 8 P. Eronen 9 Nokia 10 April 8, 2010 12 Internet Key Exchange Protocol: IKEv2 13 draft-ietf-ipsecme-ikev2bis-09 15 Abstract 17 This document describes version 2 of the Internet Key Exchange (IKE) 18 protocol. IKE is a component of IPsec used for performing mutual 19 authentication and establishing and maintaining security associations 20 (SAs). This document replaces and updates RFC 4306, and includes all 21 of the clarifications from RFC 4718. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 10, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction 70 1.1. Usage Scenarios 71 1.1.1. Security Gateway to Security Gateway Tunnel Mode 72 1.1.2. Endpoint-to-Endpoint Transport Mode 73 1.1.3. Endpoint to Security Gateway Tunnel Mode 74 1.1.4. Other Scenarios 75 1.2. The Initial Exchanges 76 1.3. The CREATE_CHILD_SA Exchange 77 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA 78 Exchange 79 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange 80 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA 81 Exchange 82 1.4. The INFORMATIONAL Exchange 83 1.4.1. Deleting an SA with INFORMATIONAL Exchanges 84 1.5. Informational Messages outside of an IKE SA 85 1.6. Requirements Terminology 86 1.7. Significant Differences Between RFC 4306 and This 87 Document 88 2. IKE Protocol Details and Variations 89 2.1. Use of Retransmission Timers 90 2.2. Use of Sequence Numbers for Message ID 91 2.3. Window Size for Overlapping Requests 92 2.4. State Synchronization and Connection Timeouts 93 2.5. Version Numbers and Forward Compatibility 94 2.6. IKE SA SPIs and Cookies 95 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD 96 2.7. Cryptographic Algorithm Negotiation 97 2.8. Rekeying 98 2.8.1. Simultaneous Child SA rekeying 99 2.8.2. Simultaneous IKE SA Rekeying 100 2.8.3. Rekeying the IKE SA Versus Reauthentication 101 2.9. Traffic Selector Negotiation 102 2.9.1. Traffic Selectors Violating Own Policy 103 2.10. Nonces 104 2.11. Address and Port Agility 105 2.12. Reuse of Diffie-Hellman Exponentials 106 2.13. Generating Keying Material 107 2.14. Generating Keying Material for the IKE SA 108 2.15. Authentication of the IKE SA 109 2.16. Extensible Authentication Protocol Methods 110 2.17. Generating Keying Material for Child SAs 111 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange 112 2.19. Requesting an Internal Address on a Remote Network 113 2.20. Requesting the Peer's Version 114 2.21. Error Handling 115 2.21.1. Error Handling in IKE_SA_INIT 116 2.21.2. Error Handling in IKE_AUTH 117 2.21.3. Error Handling after IKE SA is Authenticated 118 2.21.4. Error Handling Outside IKE SA 119 2.22. IPComp 120 2.23. NAT Traversal 121 2.23.1. Transport Mode NAT Traversal 122 2.24. Explicit Congestion Notification (ECN) 123 2.25. Exchange Collisions 124 2.25.1. Collisions While Rekeying or Closing Child SAs 125 2.25.2. Collisions While Rekeying or Closing IKE SAs 126 3. Header and Payload Formats 127 3.1. The IKE Header 128 3.2. Generic Payload Header 129 3.3. Security Association Payload 130 3.3.1. Proposal Substructure 131 3.3.2. Transform Substructure 132 3.3.3. Valid Transform Types by Protocol 133 3.3.4. Mandatory Transform IDs 134 3.3.5. Transform Attributes 135 3.3.6. Attribute Negotiation 136 3.4. Key Exchange Payload 137 3.5. Identification Payloads 138 3.6. Certificate Payload 139 3.7. Certificate Request Payload 140 3.8. Authentication Payload 141 3.9. Nonce Payload 142 3.10. Notify Payload 143 3.10.1. Notify Message Types 144 3.11. Delete Payload 145 3.12. Vendor ID Payload 146 3.13. Traffic Selector Payload 147 3.13.1. Traffic Selector 148 3.14. Encrypted Payload 149 3.15. Configuration Payload 150 3.15.1. Configuration Attributes 151 3.15.2. Meaning of INTERNAL_IP4_SUBNET and 152 INTERNAL_IP6_SUBNET 153 3.15.3. Configuration payloads for IPv6 154 3.15.4. Address Assignment Failures 155 3.16. Extensible Authentication Protocol (EAP) Payload 156 4. Conformance Requirements 157 5. Security Considerations 158 5.1. Traffic selector authorization 159 6. IANA Considerations 160 7. Acknowledgements 161 8. References 162 8.1. Normative References 163 8.2. Informative References 164 Appendix A. Summary of changes from IKEv1 165 Appendix B. Diffie-Hellman Groups 166 B.1. Group 1 - 768 Bit MODP 167 B.2. Group 2 - 1024 Bit MODP 168 Appendix C. Exchanges and Payloads 169 C.1. IKE_SA_INIT Exchange 170 C.2. IKE_AUTH Exchange without EAP 171 C.3. IKE_AUTH Exchange with EAP 172 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying 173 Child SAs 174 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA 175 C.6. INFORMATIONAL Exchange 176 Appendix D. Changes Between Internet Draft Versions 177 D.1. Changes from IKEv2 to draft -00 178 D.2. Changes from draft -00 to draft -01 179 D.3. Changes from draft -00 to draft -01 180 D.4. Changes from draft -01 to draft -02 181 D.5. Changes from draft -02 to draft -03 182 D.6. Changes from draft -03 to 183 draft-ietf-ipsecme-ikev2bis-00 184 D.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to 185 draft-ietf-ipsecme-ikev2bis-01 186 D.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to 187 draft-ietf-ipsecme-ikev2bis-02 188 D.9. Changes from draft-ietf-ipsecme-ikev2bis-01 to 189 draft-ietf-ipsecme-ikev2bis-02 190 D.10. Changes from draft-ietf-ipsecme-ikev2bis-02 to 191 draft-ietf-ipsecme-ikev2bis-03 192 D.11. Changes from draft-ietf-ipsecme-ikev2bis-03 to 193 draft-ietf-ipsecme-ikev2bis-04 194 D.12. Changes from draft-ietf-ipsecme-ikev2bis-04 to 195 draft-ietf-ipsecme-ikev2bis-05 196 D.13. Changes from draft-ietf-ipsecme-ikev2bis-05 to 197 draft-ietf-ipsecme-ikev2bis-06 198 D.14. Changes from draft-ietf-ipsecme-ikev2bis-06 to 199 draft-ietf-ipsecme-ikev2bis-07 200 D.15. Changes from draft-ietf-ipsecme-ikev2bis-07 to 201 draft-ietf-ipsecme-ikev2bis-08 202 D.16. Changes from draft-ietf-ipsecme-ikev2bis-08 to 203 draft-ietf-ipsecme-ikev2bis-09 204 Authors' Addresses 206 1. Introduction 208 IP Security (IPsec) provides confidentiality, data integrity, access 209 control, and data source authentication to IP datagrams. These 210 services are provided by maintaining shared state between the source 211 and the sink of an IP datagram. This state defines, among other 212 things, the specific services provided to the datagram, which 213 cryptographic algorithms will be used to provide the services, and 214 the keys used as input to the cryptographic algorithms. 216 Establishing this shared state in a manual fashion does not scale 217 well. Therefore, a protocol to establish this state dynamically is 218 needed. This document describes such a protocol -- the Internet Key 219 Exchange (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI], 220 2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 replaced all of those RFCs. 221 IKEv2 was defined in [IKEV2] (RFC 4306) and was clarified in [Clarif] 222 (RFC 4718). This document replaces and updates RFC 4306 and RFC 223 4718. IKEv2 was a change to the IKE protocol that was not backward 224 compatible. In contrast, the current document not only provides a 225 clarification of IKEv2, but makes minimum changes to the IKE 226 protocol. A list of the significant differences between RFC 4306 and 227 this document is given in Section 1.7. 229 IKE performs mutual authentication between two parties and 230 establishes an IKE security association (SA) that includes shared 231 secret information that can be used to efficiently establish SAs for 232 Encapsulating Security Payload (ESP) [ESP] or Authentication Header 233 (AH) [AH] and a set of cryptographic algorithms to be used by the SAs 234 to protect the traffic that they carry. In this document, the term 235 "suite" or "cryptographic suite" refers to a complete set of 236 algorithms used to protect an SA. An initiator proposes one or more 237 suites by listing supported algorithms that can be combined into 238 suites in a mix-and-match fashion. IKE can also negotiate use of IP 239 Compression (IPComp) [IP-COMP] in connection with an ESP or AH SA. 240 The SAs for ESP or AH that get set up through that IKE SA we call 241 "Child SAs". 243 All IKE communications consist of pairs of messages: a request and a 244 response. The pair is called an "exchange", and is sometimes called 245 "request/response pair". The first exchange of messages establishing 246 an IKE SA are called the IKE_SA_INIT and IKE_AUTH exchanges; 247 subsequent IKE exchanges are called the CREATE_CHILD_SA or 248 INFORMATIONAL exchanges. In the common case, there is a single 249 IKE_SA_INIT exchange and a single IKE_AUTH exchange (a total of four 250 messages) to establish the IKE SA and the first Child SA. In 251 exceptional cases, there may be more than one of each of these 252 exchanges. In all cases, all IKE_SA_INIT exchanges MUST complete 253 before any other exchange type, then all IKE_AUTH exchanges MUST 254 complete, and following that any number of CREATE_CHILD_SA and 255 INFORMATIONAL exchanges may occur in any order. In some scenarios, 256 only a single Child SA is needed between the IPsec endpoints, and 257 therefore there would be no additional exchanges. Subsequent 258 exchanges MAY be used to establish additional Child SAs between the 259 same authenticated pair of endpoints and to perform housekeeping 260 functions. 262 An IKE message flow always consists of a request followed by a 263 response. It is the responsibility of the requester to ensure 264 reliability. If the response is not received within a timeout 265 interval, the requester needs to retransmit the request (or abandon 266 the connection). 268 The first exchange of an IKE session, IKE_SA_INIT, negotiates 269 security parameters for the IKE SA, sends nonces, and sends Diffie- 270 Hellman values. 272 The second exchange, IKE_AUTH, transmits identities, proves knowledge 273 of the secrets corresponding to the two identities, and sets up an SA 274 for the first (and often only) AH or ESP Child SA (unless there is 275 failure setting up the AH or ESP Child SA, in which case the IKE SA 276 is still established without the Child SA). 278 The types of subsequent exchanges are CREATE_CHILD_SA (which creates 279 a Child SA) and INFORMATIONAL (which deletes an SA, reports error 280 conditions, or does other housekeeping). Every request requires a 281 response. An INFORMATIONAL request with no payloads (other than the 282 empty Encrypted payload required by the syntax) is commonly used as a 283 check for liveness. These subsequent exchanges cannot be used until 284 the initial exchanges have completed. 286 In the description that follows, we assume that no errors occur. 287 Modifications to the flow when errors occur are described in 288 Section 2.21. 290 1.1. Usage Scenarios 292 IKE is used to negotiate ESP or AH SAs in a number of different 293 scenarios, each with its own special requirements. 295 1.1.1. Security Gateway to Security Gateway Tunnel Mode 297 +-+-+-+-+-+ +-+-+-+-+-+ 298 | | IPsec | | 299 Protected |Tunnel | tunnel |Tunnel | Protected 300 Subnet <-->|Endpoint |<---------->|Endpoint |<--> Subnet 301 | | | | 302 +-+-+-+-+-+ +-+-+-+-+-+ 304 Figure 1: Security Gateway to Security Gateway Tunnel 306 In this scenario, neither endpoint of the IP connection implements 307 IPsec, but network nodes between them protect traffic for part of the 308 way. Protection is transparent to the endpoints, and depends on 309 ordinary routing to send packets through the tunnel endpoints for 310 processing. Each endpoint would announce the set of addresses 311 "behind" it, and packets would be sent in tunnel mode where the inner 312 IP header would contain the IP addresses of the actual endpoints. 314 1.1.2. Endpoint-to-Endpoint Transport Mode 316 +-+-+-+-+-+ +-+-+-+-+-+ 317 | | IPsec transport | | 318 |Protected| or tunnel mode SA |Protected| 319 |Endpoint |<---------------------------------------->|Endpoint | 320 | | | | 321 +-+-+-+-+-+ +-+-+-+-+-+ 323 Figure 2: Endpoint to Endpoint 325 In this scenario, both endpoints of the IP connection implement 326 IPsec, as required of hosts in [IPSECARCH]. Transport mode will 327 commonly be used with no inner IP header. A single pair of addresses 328 will be negotiated for packets to be protected by this SA. These 329 endpoints MAY implement application layer access controls based on 330 the IPsec authenticated identities of the participants. This 331 scenario enables the end-to-end security that has been a guiding 332 principle for the Internet since [ARCHPRINC], [TRANSPARENCY], and a 333 method of limiting the inherent problems with complexity in networks 334 noted by [ARCHGUIDEPHIL]. Although this scenario may not be fully 335 applicable to the IPv4 Internet, it has been deployed successfully in 336 specific scenarios within intranets using IKEv1. It should be more 337 broadly enabled during the transition to IPv6 and with the adoption 338 of IKEv2. 340 It is possible in this scenario that one or both of the protected 341 endpoints will be behind a network address translation (NAT) node, in 342 which case the tunneled packets will have to be UDP encapsulated so 343 that port numbers in the UDP headers can be used to identify 344 individual endpoints "behind" the NAT (see Section 2.23). 346 1.1.3. Endpoint to Security Gateway Tunnel Mode 348 +-+-+-+-+-+ +-+-+-+-+-+ 349 | | IPsec | | Protected 350 |Protected| tunnel |Tunnel | Subnet 351 |Endpoint |<------------------------>|Endpoint |<--- and/or 352 | | | | Internet 353 +-+-+-+-+-+ +-+-+-+-+-+ 355 Figure 3: Endpoint to Security Gateway Tunnel 357 In this scenario, a protected endpoint (typically a portable roaming 358 computer) connects back to its corporate network through an IPsec- 359 protected tunnel. It might use this tunnel only to access 360 information on the corporate network, or it might tunnel all of its 361 traffic back through the corporate network in order to take advantage 362 of protection provided by a corporate firewall against Internet-based 363 attacks. In either case, the protected endpoint will want an IP 364 address associated with the security gateway so that packets returned 365 to it will go to the security gateway and be tunneled back. This IP 366 address may be static or may be dynamically allocated by the security 367 gateway. In support of the latter case, IKEv2 includes a mechanism 368 (namely, configuration payloads) for the initiator to request an IP 369 address owned by the security gateway for use for the duration of its 370 SA. 372 In this scenario, packets will use tunnel mode. On each packet from 373 the protected endpoint, the outer IP header will contain the source 374 IP address associated with its current location (i.e., the address 375 that will get traffic routed to the endpoint directly), while the 376 inner IP header will contain the source IP address assigned by the 377 security gateway (i.e., the address that will get traffic routed to 378 the security gateway for forwarding to the endpoint). The outer 379 destination address will always be that of the security gateway, 380 while the inner destination address will be the ultimate destination 381 for the packet. 383 In this scenario, it is possible that the protected endpoint will be 384 behind a NAT. In that case, the IP address as seen by the security 385 gateway will not be the same as the IP address sent by the protected 386 endpoint, and packets will have to be UDP encapsulated in order to be 387 routed properly. Interaction with NATs is covered in detail in 388 Section 2.23. 390 1.1.4. Other Scenarios 392 Other scenarios are possible, as are nested combinations of the 393 above. One notable example combines aspects of 1.1.1 and 1.1.3. A 394 subnet may make all external accesses through a remote security 395 gateway using an IPsec tunnel, where the addresses on the subnet are 396 routed to the security gateway by the rest of the Internet. An 397 example would be someone's home network being virtually on the 398 Internet with static IP addresses even though connectivity is 399 provided by an ISP that assigns a single dynamically assigned IP 400 address to the user's security gateway (where the static IP addresses 401 and an IPsec relay are provided by a third party located elsewhere). 403 1.2. The Initial Exchanges 405 Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH 406 exchanges (known in IKEv1 as Phase 1). These initial exchanges 407 normally consist of four messages, though in some scenarios that 408 number can grow. All communications using IKE consist of request/ 409 response pairs. We'll describe the base exchange first, followed by 410 variations. The first pair of messages (IKE_SA_INIT) negotiate 411 cryptographic algorithms, exchange nonces, and do a Diffie-Hellman 412 exchange [DH]. 414 The second pair of messages (IKE_AUTH) authenticate the previous 415 messages, exchange identities and certificates, and establish the 416 first Child SA. Parts of these messages are encrypted and integrity 417 protected with keys established through the IKE_SA_INIT exchange, so 418 the identities are hidden from eavesdroppers and all fields in all 419 the messages are authenticated. See Section 2.14 for information on 420 how the encryption keys are generated. (A man-in-the-middle who 421 cannot complete the IKE_AUTH exchange can nonetheless see the 422 identity of the initiator.) 424 All messages following the initial exchange are cryptographically 425 protected using the cryptographic algorithms and keys negotiated in 426 the IKE_SA_INIT exchange. These subsequent messages use the syntax 427 of the Encrypted Payload described in Section 3.14, encrypted with 428 keys that are derived as described in Section 2.14. All subsequent 429 messages include an Encrypted Payload, even if they are referred to 430 in the text as "empty". For the CREATE_CHILD_SA, IKE_AUTH, or 431 INFORMATIONAL exchanges, the message following the header is 432 encrypted and the message including the header is integrity protected 433 using the cryptographic algorithms negotiated for the IKE SA. 435 Every IKE message contains a Message ID as part of its fixed header. 436 This Message ID is used to match up requests and responses, and to 437 identify retransmissions of messages. 439 In the following descriptions, the payloads contained in the message 440 are indicated by names as listed below. 442 Notation Payload 443 ----------------------------------------- 444 AUTH Authentication 445 CERT Certificate 446 CERTREQ Certificate Request 447 CP Configuration 448 D Delete 449 EAP Extensible Authentication 450 HDR IKE Header (not a payload) 451 IDi Identification - Initiator 452 IDr Identification - Responder 453 KE Key Exchange 454 Ni, Nr Nonce 455 N Notify 456 SA Security Association 457 SK Encrypted and Authenticated 458 TSi Traffic Selector - Initiator 459 TSr Traffic Selector - Responder 460 V Vendor ID 462 The details of the contents of each payload are described in section 463 3. Payloads that may optionally appear will be shown in brackets, 464 such as [CERTREQ]; this indicates that a certificate request payload 465 can optionally be included. 467 The initial exchanges are as follows: 469 Initiator Responder 470 ------------------------------------------------------------------- 471 HDR, SAi1, KEi, Ni --> 473 HDR contains the Security Parameter Indexes (SPIs), version numbers, 474 and flags of various sorts. The SAi1 payload states the 475 cryptographic algorithms the initiator supports for the IKE SA. The 476 KE payload sends the initiator's Diffie-Hellman value. Ni is the 477 initiator's nonce. 479 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 481 The responder chooses a cryptographic suite from the initiator's 482 offered choices and expresses that choice in the SAr1 payload, 483 completes the Diffie-Hellman exchange with the KEr payload, and sends 484 its nonce in the Nr payload. 486 At this point in the negotiation, each party can generate SKEYSEED, 487 from which all keys are derived for that IKE SA. The messages that 488 follow are encrypted and integrity protected in their entirety, with 489 the exception of the message headers. The keys used for the 490 encryption and integrity protection are derived from SKEYSEED and are 491 known as SK_e (encryption) and SK_a (authentication, a.k.a. integrity 492 protection); see Section 2.13 and Section 2.14 for details on the key 493 derivation. A separate SK_e and SK_a is computed for each direction. 494 In addition to the keys SK_e and SK_a derived from the Diffie-Hellman 495 value for protection of the IKE SA, another quantity SK_d is derived 496 and used for derivation of further keying material for Child SAs. 497 The notation SK { ... } indicates that these payloads are encrypted 498 and integrity protected using that direction's SK_e and SK_a. 500 HDR, SK {IDi, [CERT,] [CERTREQ,] 501 [IDr,] AUTH, SAi2, 502 TSi, TSr} --> 504 The initiator asserts its identity with the IDi payload, proves 505 knowledge of the secret corresponding to IDi and integrity protects 506 the contents of the first message using the AUTH payload (see 507 Section 2.15). It might also send its certificate(s) in CERT 508 payload(s) and a list of its trust anchors in CERTREQ payload(s). If 509 any CERT payloads are included, the first certificate provided MUST 510 contain the public key used to verify the AUTH field. 512 The optional payload IDr enables the initiator to specify which of 513 the responder's identities it wants to talk to. This is useful when 514 the machine on which the responder is running is hosting multiple 515 identities at the same IP address. If the IDr proposed by the 516 initiator is not acceptable to the responder, the responder might use 517 some other IDr to finish the exchange. If the initiator then does 518 not accept the fact that responder used an IDr different than the one 519 that was requested, the initiator can close the SA after noticing the 520 fact. 522 The traffic selectors (TSi and TSr) are discussed in Section 2.9. 524 The initiator begins negotiation of a Child SA using the SAi2 525 payload. The final fields (starting with SAi2) are described in the 526 description of the CREATE_CHILD_SA exchange. 528 <-- HDR, SK {IDr, [CERT,] AUTH, 529 SAr2, TSi, TSr} 531 The responder asserts its identity with the IDr payload, optionally 532 sends one or more certificates (again with the certificate containing 533 the public key used to verify AUTH listed first), authenticates its 534 identity and protects the integrity of the second message with the 535 AUTH payload, and completes negotiation of a Child SA with the 536 additional fields described below in the CREATE_CHILD_SA exchange. 538 Both parties in the IKE_SA_INIT exchange MUST verify that all 539 signatures and MACs are computed correctly. If either side uses a 540 shared secret for authentication, the names in the ID payload MUST 541 correspond to the key used to generate the AUTH payload. 543 Because the initiator sends its Diffie-Hellman value in the 544 IKE_SA_INIT, it must guess the Diffie-Hellman group that the 545 responder will select from its list of supported groups. If the 546 initiator guesses wrong, the responder will respond with a Notify 547 payload of type INVALID_KE_PAYLOAD indicating the selected group. In 548 this case, the initiator MUST retry the IKE_SA_INIT with the 549 corrected Diffie-Hellman group. The initiator MUST again propose its 550 full set of acceptable cryptographic suites because the rejection 551 message was unauthenticated and otherwise an active attacker could 552 trick the endpoints into negotiating a weaker suite than a stronger 553 one that they both prefer. 555 If creating the Child SA during the IKE_AUTH exchange fails for some 556 reason, the IKE SA is still created as usual. The list of Notify 557 message types in the IKE_AUTH exchange that do not prevent an IKE SA 558 from being set up include at least the following: NO_PROPOSAL_CHOSEN, 559 TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and 560 FAILED_CP_REQUIRED. 562 If the failure is related to creating the IKE SA (for example, an 563 AUTHENTICATION_FAILED Notify error message is returned), the IKE SA 564 is not created. Note that although the IKE_AUTH messages are 565 encrypted and integrity protected, if the peer receiving this Notify 566 error message has not yet authenticated the other end (or if the peer 567 fails to authenticate the other end for some reason), the information 568 needs to be treated with caution. More precisely, assuming that the 569 MAC verifies correctly, the sender of the error Notify message is 570 known to be the responder of the IKE_SA_INIT exchange, but the 571 sender's identity cannot be assured. 573 Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads. 574 Thus, the SA payloads in the IKE_AUTH exchange cannot contain 575 Transform Type 4 (Diffie-Hellman Group) with any value other than 576 NONE. Implementations SHOULD omit the whole transform substructure 577 instead of sending value NONE. 579 1.3. The CREATE_CHILD_SA Exchange 581 The CREATE_CHILD_SA exchange is used to create new Child SAs and to 582 rekey both IKE SAs and Child SAs. This exchange consists of a single 583 request/response pair, and some of its function was referred to as a 584 phase 2 exchange in IKEv1. It MAY be initiated by either end of the 585 IKE SA after the initial exchanges are completed. 587 An SA is rekeyed by creating a new SA and then deleting the old one. 588 This section describes the first part of rekeying, the creation of 589 new SAs; Section 2.8 covers the mechanics of rekeying, including 590 moving traffic from old to new SAs and the deletion of the old SAs. 591 The two sections must be read together to understand the entire 592 process of rekeying. 594 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this 595 section the term initiator refers to the endpoint initiating this 596 exchange. An implementation MAY refuse all CREATE_CHILD_SA requests 597 within an IKE SA. 599 The CREATE_CHILD_SA request MAY optionally contain a KE payload for 600 an additional Diffie-Hellman exchange to enable stronger guarantees 601 of forward secrecy for the Child SA. The keying material for the 602 Child SA is a function of SK_d established during the establishment 603 of the IKE SA, the nonces exchanged during the CREATE_CHILD_SA 604 exchange, and the Diffie-Hellman value (if KE payloads are included 605 in the CREATE_CHILD_SA exchange). 607 If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of 608 the SA offers MUST include the Diffie-Hellman group of the KEi. The 609 Diffie-Hellman group of the KEi MUST be an element of the group the 610 initiator expects the responder to accept (additional Diffie-Hellman 611 groups can be proposed). If the responder selects a proposal using a 612 different Diffie-Hellman group (other than NONE), the responder MUST 613 reject the request and indicate its preferred Diffie-Hellman group in 614 the INVALID_KE_PAYLOAD Notify payload. There are two octets of data 615 associated with this notification: the accepted Diffie-Hellman Group 616 number in big endian order. In the case of such a rejection, the 617 CREATE_CHILD_SA exchange fails, and the initiator will probably retry 618 the exchange with a Diffie-Hellman proposal and KEi in the group that 619 the responder gave in the INVALID_KE_PAYLOAD Notify payload. 621 The responder sends a NO_ADDITIONAL_SAS notification to indicate that 622 a CREATE_CHILD_SA request is unacceptable because the responder is 623 unwilling to accept any more Child SAs on this IKE SA. This 624 notification can also be used to reject IKE SA rekey. Some minimal 625 implementations may only accept a single Child SA setup in the 626 context of an initial IKE exchange and reject any subsequent attempts 627 to add more. 629 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA Exchange 631 A Child SA may be created by sending a CREATE_CHILD_SA request. The 632 CREATE_CHILD_SA request for creating a new Child SA is: 634 Initiator Responder 635 ------------------------------------------------------------------- 636 HDR, SK {SA, Ni, [KEi], 637 TSi, TSr} --> 639 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 640 payload, optionally a Diffie-Hellman value in the KEi payload, and 641 the proposed traffic selectors for the proposed Child SA in the TSi 642 and TSr payloads. 644 The CREATE_CHILD_SA response for creating a new Child SA is: 646 <-- HDR, SK {SA, Nr, [KEr], 647 TSi, TSr} 649 The responder replies (using the same Message ID to respond) with the 650 accepted offer in an SA payload, and a Diffie-Hellman value in the 651 KEr payload if KEi was included in the request and the selected 652 cryptographic suite includes that group. 654 The traffic selectors for traffic to be sent on that SA are specified 655 in the TS payloads in the response, which may be a subset of what the 656 initiator of the Child SA proposed. 658 The USE_TRANSPORT_MODE notification MAY be included in a request 659 message that also includes an SA payload requesting a Child SA. It 660 requests that the Child SA use transport mode rather than tunnel mode 661 for the SA created. If the request is accepted, the response MUST 662 also include a notification of type USE_TRANSPORT_MODE. If the 663 responder declines the request, the Child SA will be established in 664 tunnel mode. If this is unacceptable to the initiator, the initiator 665 MUST delete the SA. Note: Except when using this option to negotiate 666 transport mode, all Child SAs will use tunnel mode. 668 The ESP_TFC_PADDING_NOT_SUPPORTED notification asserts that the 669 sending endpoint will not accept packets that contain Traffic Flow 670 Confidentiality (TFC) padding over the Child SA being negotiated. If 671 neither endpoint accepts TFC padding, this notification is included 672 in both the request and the response. If this notification is 673 included in only one of the messages, TFC padding can still be sent 674 in the other direction. 676 The NON_FIRST_FRAGMENTS_ALSO notification is used for fragmentation 677 control. See [IPSECARCH] for a fuller explanation. Both parties 678 need to agree to sending non-first fragments before either party does 679 so. It is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is 680 included in both the request proposing an SA and the response 681 accepting it. If the responder does not want to send or receive non- 682 first fragments, it only omits NON_FIRST_FRAGMENTS_ALSO notification 683 from its response, but does not reject the whole Child SA creation. 685 An IPCOMP_SUPPORTED notification, covered in Section 2.22, can also 686 be included in the exchange. 688 A failed attempt to create a Child SA SHOULD NOT tear down the IKE 689 SA: there is no reason to lose the work done to set up the IKE SA. 690 See Section 2.21 for a list of error messages that might occur if 691 creating a Child SA fails. 693 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange 695 The CREATE_CHILD_SA request for rekeying an IKE SA is: 697 Initiator Responder 698 ------------------------------------------------------------------- 699 HDR, SK {SA, Ni, KEi} --> 701 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 702 payload, and a Diffie-Hellman value in the KEi payload. The KEi 703 payload MUST be included. A new initiator SPI is supplied in the SPI 704 field of the SA payload. Once a peer receives a request to rekey an 705 IKE SA or sends a request to rekey an IKE SA, it SHOULD NOT start any 706 new CREATE_CHILD_SA exchanges on the IKE SA that is being rekeyed. 708 The CREATE_CHILD_SA response for rekeying an IKE SA is: 710 <-- HDR, SK {SA, Nr, KEr} 712 The responder replies (using the same Message ID to respond) with the 713 accepted offer in an SA payload, and a Diffie-Hellman value in the 714 KEr payload if the selected cryptographic suite includes that group. 715 A new responder SPI is supplied in the SPI field of the SA payload. 717 The new IKE SA has its message counters set to 0, regardless of what 718 they were in the earlier IKE SA. The first IKE requests from both 719 sides on the new IKE SA will have message ID 0. The old IKE SA 720 retains its numbering, so any further requests (for example, to 721 delete the IKE SA) will have consecutive numbering. The new IKE SA 722 also has its window size reset to 1, and the initiator in this rekey 723 exchange is the new "original initiator" of the new IKE SA. 725 Section 2.18 also covers IKE SA rekeying in detail. 727 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange 729 The CREATE_CHILD_SA request for rekeying a Child SA is: 731 Initiator Responder 732 ------------------------------------------------------------------- 733 HDR, SK {N(REKEY_SA), SA, Ni, [KEi], 734 TSi, TSr} --> 736 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 737 payload, optionally a Diffie-Hellman value in the KEi payload, and 738 the proposed traffic selectors for the proposed Child SA in the TSi 739 and TSr payloads. 741 The notifications described in Section 1.3.1 may also be sent in a 742 rekeying exchange. Usually these will be the same notifications that 743 were used in the original exchange; for example, when rekeying a 744 transport mode SA, the USE_TRANSPORT_MODE notification will be used. 746 The REKEY_SA notification MUST be included in a CREATE_CHILD_SA 747 exchange if the purpose of the exchange is to replace an existing ESP 748 or AH SA. The SA being rekeyed is identified by the SPI field in the 749 Notify payload; this is the SPI the exchange initiator would expect 750 in inbound ESP or AH packets. There is no data associated with this 751 Notify message type. The Protocol ID field of the REKEY_SA 752 notification is set to match the protocol of the SA we are rekeying, 753 for example, 3 for ESP and 2 for AH. 755 The CREATE_CHILD_SA response for rekeying a Child SA is: 757 <-- HDR, SK {SA, Nr, [KEr], 758 TSi, TSr} 760 The responder replies (using the same Message ID to respond) with the 761 accepted offer in an SA payload, and a Diffie-Hellman value in the 762 KEr payload if KEi was included in the request and the selected 763 cryptographic suite includes that group. 765 The traffic selectors for traffic to be sent on that SA are specified 766 in the TS payloads in the response, which may be a subset of what the 767 initiator of the Child SA proposed. 769 1.4. The INFORMATIONAL Exchange 771 At various points during the operation of an IKE SA, peers may desire 772 to convey control messages to each other regarding errors or 773 notifications of certain events. To accomplish this, IKE defines an 774 INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur 775 after the initial exchanges and are cryptographically protected with 776 the negotiated keys. Note that some informational messages, not 777 exchanges, can be sent outside the context of an IKE SA. Section 778 2.21 also covers error messages in great detail. 780 Control messages that pertain to an IKE SA MUST be sent under that 781 IKE SA. Control messages that pertain to Child SAs MUST be sent 782 under the protection of the IKE SA which generated them (or its 783 successor if the IKE SA was rekeyed). 785 Messages in an INFORMATIONAL exchange contain zero or more 786 Notification, Delete, and Configuration payloads. The recipient of 787 an INFORMATIONAL exchange request MUST send some response; otherwise, 788 the sender will assume the message was lost in the network and will 789 retransmit it. That response MAY be an empty message. The request 790 message in an INFORMATIONAL exchange MAY also contain no payloads. 791 This is the expected way an endpoint can ask the other endpoint to 792 verify that it is alive. 794 The INFORMATIONAL exchange is defined as: 796 Initiator Responder 797 ------------------------------------------------------------------- 798 HDR, SK {[N,] [D,] 799 [CP,] ...} --> 800 <-- HDR, SK {[N,] [D,] 801 [CP], ...} 803 The processing of an INFORMATIONAL exchange is determined by its 804 component payloads. 806 1.4.1. Deleting an SA with INFORMATIONAL Exchanges 808 ESP and AH SAs always exist in pairs, with one SA in each direction. 809 When an SA is closed, both members of the pair MUST be closed (that 810 is, deleted). Each endpoint MUST close its incoming SAs and allow 811 the other endpoint to close the other SA in each pair. To delete an 812 SA, an INFORMATIONAL exchange with one or more Delete payloads is 813 sent listing the SPIs (as they would be expected in the headers of 814 inbound packets) of the SAs to be deleted. The recipient MUST close 815 the designated SAs. Note that one never sends delete payloads for 816 the two sides of an SA in a single message. If there are many SAs to 817 delete at the same time, one includes Delete payloads for the inbound 818 half of each SA pair in the INFORMATIONAL exchange. 820 Normally, the response in the INFORMATIONAL exchange will contain 821 delete payloads for the paired SAs going in the other direction. 822 There is one exception. If by chance both ends of a set of SAs 823 independently decide to close them, each may send a delete payload 824 and the two requests may cross in the network. If a node receives a 825 delete request for SAs for which it has already issued a delete 826 request, it MUST delete the outgoing SAs while processing the request 827 and the incoming SAs while processing the response. In that case, 828 the responses MUST NOT include delete payloads for the deleted SAs, 829 since that would result in duplicate deletion and could in theory 830 delete the wrong SA. 832 Similar to ESP and AH SAs, IKE SAs are also deleted by sending an 833 Informational exchange. Deleting an IKE SA implicitly closes any 834 remaining Child SAs negotiated under it. The response to a request 835 that deletes the IKE SA is an empty INFORMATIONAL response. 837 Half-closed ESP or AH connections are anomalous, and a node with 838 auditing capability should probably audit their existence if they 839 persist. Note that this specification does not specify time periods, 840 so it is up to individual endpoints to decide how long to wait. A 841 node MAY refuse to accept incoming data on half-closed connections 842 but MUST NOT unilaterally close them and reuse the SPIs. If 843 connection state becomes sufficiently messed up, a node MAY close the 844 IKE SA, as described above. It can then rebuild the SAs it needs on 845 a clean base under a new IKE SA. 847 1.5. Informational Messages outside of an IKE SA 849 There are some cases in which a node receives a packet that it cannot 850 process, but it may want to notify the sender about this situation. 852 o If an ESP or AH packet arrives with an unrecognized SPI. This 853 might be due to the receiving node having recently crashed and 854 lost state, or because of some other system malfunction or attack. 856 o If an encrypted IKE request packet arrives on port 500 or 4500 857 with an unrecognized IKE SPI. This might be due to the receiving 858 node having recently crashed and lost state, or because of some 859 other system malfunction or attack. 861 o If an IKE request packet arrives with a higher major version 862 number than the implementation supports. 864 In the first case, if the receiving node has an active IKE SA to the 865 IP address from whence the packet came, it MAY send an INVALID_SPI 866 notification of the wayward packet over that IKE SA in an 867 INFORMATIONAL exchange. The Notification Data contains the SPI of 868 the invalid packet. The recipient of this notification cannot tell 869 whether the SPI is for AH or ESP, but this is not important because 870 the SPIs are supposed to be different for the two. If no suitable 871 IKE SA exists, the node MAY send an informational message without 872 cryptographic protection to the source IP address, using the source 873 UDP port as the destination port if the packet was UDP (UDP- 874 encapsulated ESP or AH). In this case, it should only be used by the 875 recipient as a hint that something might be wrong (because it could 876 easily be forged). This message is not part of an INFORMATIONAL 877 exchange, and the receiving node MUST NOT respond to it because doing 878 so could cause a message loop. The message is constructed as 879 follows: there are no IKE SPI values that would be meaningful to the 880 recipient of such a notification; using zero values or random values 881 are both acceptable, this being the exception to the rule in 882 Section 3.1 that prohibits zero IKE Initiator SPIs. The Initiator 883 flag is set to 1, the Response flag is set to 0, and the version 884 flags are set in the normal fashion; these flags are described in 885 Section 3.1. 887 In the second and third cases, the message is always sent without 888 cryptographic protection (outside of an IKE SA), and includes either 889 an INVALID_IKE_SPI or an INVALID_MAJOR_VERSION notification (with no 890 notification data). The message is a response message, and thus it 891 is sent to the IP address and port from whence it came with the same 892 IKE SPIs and the Message ID and Exchange Type are copied from the 893 request. The Response flag is set to 1, and the version flags are 894 set in the normal fashion. 896 1.6. Requirements Terminology 898 Definitions of the primitive terms in this document (such as Security 899 Association or SA) can be found in [IPSECARCH]. It should be noted 900 that parts of IKEv2 rely on some of the processing rules in 901 [IPSECARCH], as described in various sections of this document. 903 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 904 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 905 document are to be interpreted as described in [MUSTSHOULD]. 907 1.7. Significant Differences Between RFC 4306 and This Document 909 This document contains clarifications and amplifications to IKEv2 910 [IKEV2]. The clarifications are mostly based on [Clarif]. The 911 changes listed in that document were discussed in the IPsec Working 912 Group and, after the Working Group was disbanded, on the IPsec 913 mailing list. That document contains detailed explanations of areas 914 that were unclear in IKEv2, and is thus useful to implementers of 915 IKEv2. 917 The protocol described in this document retains the same major 918 version number (2) and minor version number (0) as was used in RFC 919 4306. That is, the version number is *not* changed from RFC 4306. 921 This document makes the figures and references a bit more consistent 922 than they were in [IKEV2]. 924 IKEv2 developers have noted that the SHOULD-level requirements in RFC 925 4306 are often unclear in that they don't say when it is OK to not 926 obey the requirements. They also have noted that there are MUST- 927 level requirements that are not related to interoperability. This 928 document has more explanation of some of these requirements. All 929 non-capitalized uses of the words SHOULD and MUST now mean their 930 normal English sense, not the interoperability sense of [MUSTSHOULD]. 932 IKEv2 (and IKEv1) developers have noted that there is a great deal of 933 material in the tables of codes in Section 3.10.1 in RFC 4306. This 934 leads to implementers not having all the needed information in the 935 main body of the document. Much of the material from those tables 936 has been moved into the associated parts of the main body of the 937 document. 939 This document removes discussion of nesting AH and ESP. This was a 940 mistake in RFC 4306 caused by the lag between finishing RFC 4306 and 941 RFC 4301. Basically, IKEv2 is based on RFC 4301, which does not 942 include "SA bundles" that were part of RFC 2401. While a single 943 packet can go through IPsec processing multiple times, each of these 944 passes uses a separate SA, and the passes are coordinated by the 945 forwarding tables. In IKEv2, each of these SAs has to be created 946 using a separate CREATE_CHILD_SA exchange. 948 This document removes discussion of the INTERNAL_ADDRESS_EXPIRY 949 configuration attribute because its implementation was very 950 problematic. Implementations that conform to this document MUST 951 ignore proposals that have configuration attribute type 5, the old 952 value for INTERNAL_ADDRESS_EXPIRY. This document also removed 953 INTERNAL_IP6_NBNS as a configuration attribute. 955 This document removes the allowance for rejecting messages where the 956 payloads were not in the "right" order; now implementations MUST NOT 957 reject them. This is due to the lack of clarity where the orders for 958 the payloads are described. 960 The lists of items from RFC 4306 that ended up in the IANA registry 961 were trimmed to only include items that were actually defined in RFC 962 4306. Also, many of those lists are now preceded with the very 963 important instruction to developers that they really should look at 964 the IANA registry at the time of development because new items have 965 been added since RFC 4306. 967 This document adds clarification on when notifications are and are 968 not sent encrypted, depending on the state of the negotiation at the 969 time. 971 This document discusses more about how to negotiate combined-mode 972 ciphers. 974 In section 1.3.2, changed "The KEi payload SHOULD be included" to be 975 "The KEi payload MUST be included". This also led to changes in 976 section 2.18. 978 In Section 2.1, there is new material covering how the initiator's 979 SPI and/or IP is used to differentiate if this is a "half-open" IKE 980 SA or a new request. 982 This document clarifies the use of the critical flag in Section 2.5. 984 In 2.8, changed "Note that, when rekeying, the new Child SA MAY have 985 different traffic selectors and algorithms than the old one" to "Note 986 that, when rekeying, the new Child SA SHOULD NOT have different 987 traffic selectors and algorithms than the old one". 989 The new Section 2.8.2 covers simultaneous IKE SA rekeying. 991 The new Section 2.9.2 covers traffic selectors in rekeying. 993 This document adds the restriction in Section 2.13 that all pseudo- 994 random functions (PRFs) used with IKEv2 MUST take variable-sized 995 keys. This should not affect any implementations because there were 996 no standardized PRFs that have fixed-size keys. 998 Section 2.18 requires doing a Diffie-Hellman exchange when rekeying 999 the IKE_SA. In theory, RFC 4306 allowed a policy where the Diffie- 1000 Hellman exchange was optional, but this was not useful (or 1001 appropriate) when rekeying the IKE_SA. 1003 Section 2.21 has been greatly expanded to cover the different cases 1004 where error responses are needed and the appropriate responses to 1005 them. 1007 Section 2.23 clarified that, in NAT traversal, now both UDP 1008 encapsulated IPsec packets and non-UDP encapsulated IPsec packets 1009 packets need to be understood when receiving. 1011 Added Section 2.23.1 to describe NAT traversal when transport mode is 1012 requested. 1014 Added Section 2.25 to explain how to act when there are timing 1015 collisions when deleting and/or rekeying SAs, and two new error 1016 notifications (TEMPORARY_FAILURE and CHILD_SA_NOT_FOUND) were 1017 defined. 1019 In Section 3.6, added "Implementations MUST support the HTTP method 1020 for hash-and-URL lookup. The behavior of other URL methods is not 1021 currently specified, and such methods SHOULD NOT be used in the 1022 absence of a document specifying them." 1024 In Section 3.15.3, added a pointer to a new document that is related 1025 to configuration of IPv6 addresses. 1027 Appendix C was expanded and clarified. 1029 2. IKE Protocol Details and Variations 1031 IKE normally listens and sends on UDP port 500, though IKE messages 1032 may also be received on UDP port 4500 with a slightly different 1033 format (see Section 2.23). Since UDP is a datagram (unreliable) 1034 protocol, IKE includes in its definition recovery from transmission 1035 errors, including packet loss, packet replay, and packet forgery. 1036 IKE is designed to function so long as (1) at least one of a series 1037 of retransmitted packets reaches its destination before timing out; 1038 and (2) the channel is not so full of forged and replayed packets so 1039 as to exhaust the network or CPU capacities of either endpoint. Even 1040 in the absence of those minimum performance requirements, IKE is 1041 designed to fail cleanly (as though the network were broken). 1043 Although IKEv2 messages are intended to be short, they contain 1044 structures with no hard upper bound on size (in particular, digital 1045 certificates), and IKEv2 itself does not have a mechanism for 1046 fragmenting large messages. IP defines a mechanism for fragmentation 1047 of oversized UDP messages, but implementations vary in the maximum 1048 message size supported. Furthermore, use of IP fragmentation opens 1049 an implementation to denial of service (DoS) attacks [DOSUDPPROT]. 1050 Finally, some NAT and/or firewall implementations may block IP 1051 fragments. 1053 All IKEv2 implementations MUST be able to send, receive, and process 1054 IKE messages that are up to 1280 octets long, and they SHOULD be able 1055 to send, receive, and process messages that are up to 3000 octets 1056 long. IKEv2 implementations need to be aware of the maximum UDP 1057 message size supported and MAY shorten messages by leaving out some 1058 certificates or cryptographic suite proposals if that will keep 1059 messages below the maximum. Use of the "Hash and URL" formats rather 1060 than including certificates in exchanges where possible can avoid 1061 most problems. Implementations and configuration need to keep in 1062 mind, however, that if the URL lookups are possible only after the 1063 Child SA is established, recursion issues could prevent this 1064 technique from working. 1066 The UDP payload of all packets containing IKE messages sent on port 1067 4500 MUST begin with the prefix of four zeros; otherwise, the 1068 receiver won't know how to handle them. 1070 2.1. Use of Retransmission Timers 1072 All messages in IKE exist in pairs: a request and a response. The 1073 setup of an IKE SA normally consists of two exchanges. Once the IKE 1074 SA is set up, either end of the security association may initiate 1075 requests at any time, and there can be many requests and responses 1076 "in flight" at any given moment. But each message is labeled as 1077 either a request or a response, and for each exchange, one end of the 1078 security association is the initiator and the other is the responder. 1080 For every pair of IKE messages, the initiator is responsible for 1081 retransmission in the event of a timeout. The responder MUST never 1082 retransmit a response unless it receives a retransmission of the 1083 request. In that event, the responder MUST ignore the retransmitted 1084 request except insofar as it causes a retransmission of the response. 1085 The initiator MUST remember each request until it receives the 1086 corresponding response. The responder MUST remember each response 1087 until it receives a request whose sequence number is larger than or 1088 equal to the sequence number in the response plus its window size 1089 (see Section 2.3). In order to allow saving memory, responders are 1090 allowed to forget the response after a timeout of several minutes. 1091 If the responder receives a retransmitted request for which it has 1092 already forgotten the response, it MUST ignore the request (and not, 1093 for example, attempt constructing a new response). 1095 IKE is a reliable protocol: the initiator MUST retransmit a request 1096 until either it receives a corresponding response, or until it deems 1097 the IKE SA to have failed. In the latter case, the initiator 1098 discards all state associated with the IKE SA and any Child SAs that 1099 were negotiated using that IKE SA. A retransmission from the 1100 initiator MUST be bitwise identical to the original request. That 1101 is, everything starting from the IKE Header (the IKE SA initiator's 1102 SPI onwards) must be bitwise identical; items before it (such as the 1103 IP and UDP headers) do not have to be identical. 1105 Retransmissions of the IKE_SA_INIT request require some special 1106 handling. When a responder receives an IKE_SA_INIT request, it has 1107 to determine whether the packet is a retransmission belonging to an 1108 existing "half-open" IKE SA (in which case the responder retransmits 1109 the same response), or a new request (in which case the responder 1110 creates a new IKE SA and sends a fresh response), or it belongs to an 1111 existing IKE SA where the IKE_AUTH request has been already received 1112 (in which case the responder ignores it). 1114 It is not sufficient to use the initiator's SPI and/or IP address to 1115 differentiate between these three cases because two different peers 1116 behind a single NAT could choose the same initiator SPI. Instead, a 1117 robust responder will do the IKE SA lookup using the whole packet, 1118 its hash, or the Ni payload. 1120 The retransmission policy for one-way messages is somewhat different 1121 from that for regular messages. Because no acknowledgement is ever 1122 sent, there is no reason to gratuitously retransmit one-way messages. 1123 Given that all these messages are errors, it makes sense to send them 1124 only once per "offending" packet, and only retransmit if further 1125 offending packets are received. Still, it also makes sense to limit 1126 retransmissions of such error messages. 1128 2.2. Use of Sequence Numbers for Message ID 1130 Every IKE message contains a Message ID as part of its fixed header. 1131 This Message ID is used to match up requests and responses, and to 1132 identify retransmissions of messages. Retransmission of a message 1133 MUST use the same Message ID as the original message. 1135 The Message ID is a 32-bit quantity, which is zero for the 1136 IKE_SA_INIT messages (including retries of the message due to 1137 responses such as COOKIE and INVALID_KE_PAYLOAD), and incremented for 1138 each subsequent exchange. Thus, the first pair of IKE_AUTH messages 1139 will have ID of 1, the second (when EAP is used) will be 2, and so 1140 on. The Message ID is reset to zero in the new IKE SA after the IKE 1141 SA is rekeyed. 1143 Each endpoint in the IKE Security Association maintains two "current" 1144 Message IDs: the next one to be used for a request it initiates and 1145 the next one it expects to see in a request from the other end. 1146 These counters increment as requests are generated and received. 1147 Responses always contain the same message ID as the corresponding 1148 request. That means that after the initial exchange, each integer n 1149 may appear as the message ID in four distinct messages: the nth 1150 request from the original IKE initiator, the corresponding response, 1151 the nth request from the original IKE responder, and the 1152 corresponding response. If the two ends make very different numbers 1153 of requests, the Message IDs in the two directions can be very 1154 different. There is no ambiguity in the messages, however, because 1155 the Initiator and Response flags in the message header specify which 1156 of the four messages a particular one is. 1158 Throughout this document, "initiator" refers to the party who 1159 initiated the exchange being described. The "original initiator" 1160 always refers to the party who initiated the exchange which resulted 1161 in the current IKE SA. In other words, if the "original responder" 1162 starts rekeying the IKE SA, that party becomes the "original 1163 initiator" of the new IKE SA. 1165 Note that Message IDs are cryptographically protected and provide 1166 protection against message replays. In the unlikely event that 1167 Message IDs grow too large to fit in 32 bits, the IKE SA MUST be 1168 closed or rekeyed. 1170 2.3. Window Size for Overlapping Requests 1172 The SET_WINDOW_SIZE notification asserts that the sending endpoint is 1173 capable of keeping state for multiple outstanding exchanges, 1174 permitting the recipient to send multiple requests before getting a 1175 response to the first. The data associated with a SET_WINDOW_SIZE 1176 notification MUST be 4 octets long and contain the big endian 1177 representation of the number of messages the sender promises to keep. 1178 The window size is always one until the initial exchanges complete. 1180 An IKE endpoint MUST wait for a response to each of its messages 1181 before sending a subsequent message unless it has received a 1182 SET_WINDOW_SIZE Notify message from its peer informing it that the 1183 peer is prepared to maintain state for multiple outstanding messages 1184 in order to allow greater throughput. 1186 After an IKE SA is set up, in order to maximize IKE throughput, an 1187 IKE endpoint MAY issue multiple requests before getting a response to 1188 any of them, up to the limit set by its peer's SET_WINDOW_SIZE. 1189 These requests may pass one another over the network. An IKE 1190 endpoint MUST be prepared to accept and process a request while it 1191 has a request outstanding in order to avoid a deadlock in this 1192 situation. An IKE endpoint may also accept and process multiple 1193 requests while it has a request outstanding. 1195 An IKE endpoint MUST NOT exceed the peer's stated window size for 1196 transmitted IKE requests. In other words, if the responder stated 1197 its window size is N, then when the initiator needs to make a request 1198 X, it MUST wait until it has received responses to all requests up 1199 through request X-N. An IKE endpoint MUST keep a copy of (or be able 1200 to regenerate exactly) each request it has sent until it receives the 1201 corresponding response. An IKE endpoint MUST keep a copy of (or be 1202 able to regenerate exactly) the number of previous responses equal to 1203 its declared window size in case its response was lost and the 1204 initiator requests its retransmission by retransmitting the request. 1206 An IKE endpoint supporting a window size greater than one ought to be 1207 capable of processing incoming requests out of order to maximize 1208 performance in the event of network failures or packet reordering. 1210 The window size is normally a (possibly configurable) property of a 1211 particular implementation, and is not related to congestion control 1212 (unlike the window size in TCP, for example). In particular, it is 1213 not defined what the responder should do when it receives a 1214 SET_WINDOW_SIZE notification containing a smaller value than is 1215 currently in effect. Thus, there is currently no way to reduce the 1216 window size of an existing IKE SA; you can only increase it. When 1217 rekeying an IKE SA, the new IKE SA starts with window size 1 until it 1218 is explicitly increased by sending a new SET_WINDOW_SIZE 1219 notification. 1221 The INVALID_MESSAGE_ID notification is sent when an IKE message ID 1222 outside the supported window is received. This Notify message MUST 1223 NOT be sent in a response; the invalid request MUST NOT be 1224 acknowledged. Instead, inform the other side by initiating an 1225 INFORMATIONAL exchange with Notification data containing the four 1226 octet invalid message ID. Sending this notification is OPTIONAL, and 1227 notifications of this type MUST be rate limited. 1229 2.4. State Synchronization and Connection Timeouts 1231 An IKE endpoint is allowed to forget all of its state associated with 1232 an IKE SA and the collection of corresponding Child SAs at any time. 1233 This is the anticipated behavior in the event of an endpoint crash 1234 and restart. It is important when an endpoint either fails or 1235 reinitializes its state that the other endpoint detect those 1236 conditions and not continue to waste network bandwidth by sending 1237 packets over discarded SAs and having them fall into a black hole. 1239 The INITIAL_CONTACT notification asserts that this IKE SA is the only 1240 IKE SA currently active between the authenticated identities. It MAY 1241 be sent when an IKE SA is established after a crash, and the 1242 recipient MAY use this information to delete any other IKE SAs it has 1243 to the same authenticated identity without waiting for a timeout. 1244 This notification MUST NOT be sent by an entity that may be 1245 replicated (e.g., a roaming user's credentials where the user is 1246 allowed to connect to the corporate firewall from two remote systems 1247 at the same time). The INITIAL_CONTACT notification, if sent, MUST 1248 be in the first IKE_AUTH request or response, not as a separate 1249 exchange afterwards; receiving parties MAY ignore it in other 1250 messages. 1252 Since IKE is designed to operate in spite of DoS attacks from the 1253 network, an endpoint MUST NOT conclude that the other endpoint has 1254 failed based on any routing information (e.g., ICMP messages) or IKE 1255 messages that arrive without cryptographic protection (e.g., Notify 1256 messages complaining about unknown SPIs). An endpoint MUST conclude 1257 that the other endpoint has failed only when repeated attempts to 1258 contact it have gone unanswered for a timeout period or when a 1259 cryptographically protected INITIAL_CONTACT notification is received 1260 on a different IKE SA to the same authenticated identity. An 1261 endpoint should suspect that the other endpoint has failed based on 1262 routing information and initiate a request to see whether the other 1263 endpoint is alive. To check whether the other side is alive, IKE 1264 specifies an empty INFORMATIONAL message that (like all IKE requests) 1265 requires an acknowledgement (note that within the context of an IKE 1266 SA, an "empty" message consists of an IKE header followed by an 1267 Encrypted payload that contains no payloads). If a cryptographically 1268 protected (fresh, i.e. not retransmitted) message has been received 1269 from the other side recently, unprotected Notify messages MAY be 1270 ignored. Implementations MUST limit the rate at which they take 1271 actions based on unprotected messages. 1273 Numbers of retries and lengths of timeouts are not covered in this 1274 specification because they do not affect interoperability. It is 1275 suggested that messages be retransmitted at least a dozen times over 1276 a period of at least several minutes before giving up on an SA, but 1277 different environments may require different rules. To be a good 1278 network citizen, retransmission times MUST increase exponentially to 1279 avoid flooding the network and making an existing congestion 1280 situation worse. If there has only been outgoing traffic on all of 1281 the SAs associated with an IKE SA, it is essential to confirm 1282 liveness of the other endpoint to avoid black holes. If no 1283 cryptographically protected messages have been received on an IKE SA 1284 or any of its Child SAs recently, the system needs to perform a 1285 liveness check in order to prevent sending messages to a dead peer. 1286 (This is sometimes called "dead peer detection" or "DPD", although it 1287 is really detecting live peers, not dead ones.) Receipt of a fresh 1288 cryptographically protected message on an IKE SA or any of its Child 1289 SAs ensures liveness of the IKE SA and all of its Child SAs. Note 1290 that this places requirements on the failure modes of an IKE 1291 endpoint. An implementation needs to stop sending on any SA if some 1292 failure prevents it from receiving on all of the associated SAs. If 1293 a system creates Child SAs that can fail independently from one 1294 another without the associated IKE SA being able to send a delete 1295 message, then the system MUST negotiate such Child SAs using separate 1296 IKE SAs. 1298 There is a DoS attack on the initiator of an IKE SA that can be 1299 avoided if the initiator takes the proper care. Since the first two 1300 messages of an SA setup are not cryptographically protected, an 1301 attacker could respond to the initiator's message before the genuine 1302 responder and poison the connection setup attempt. To prevent this, 1303 the initiator MAY be willing to accept multiple responses to its 1304 first message, treat each as potentially legitimate, respond to it, 1305 and then discard all the invalid half-open connections when it 1306 receives a valid cryptographically protected response to any one of 1307 its requests. Once a cryptographically valid response is received, 1308 all subsequent responses should be ignored whether or not they are 1309 cryptographically valid. 1311 Note that with these rules, there is no reason to negotiate and agree 1312 upon an SA lifetime. If IKE presumes the partner is dead, based on 1313 repeated lack of acknowledgement to an IKE message, then the IKE SA 1314 and all Child SAs set up through that IKE SA are deleted. 1316 An IKE endpoint may at any time delete inactive Child SAs to recover 1317 resources used to hold their state. If an IKE endpoint chooses to 1318 delete Child SAs, it MUST send Delete payloads to the other end 1319 notifying it of the deletion. It MAY similarly time out the IKE SA. 1320 Closing the IKE SA implicitly closes all associated Child SAs. In 1321 this case, an IKE endpoint SHOULD send a Delete payload indicating 1322 that it has closed the IKE SA unless the other endpoint is no longer 1323 responding. 1325 2.5. Version Numbers and Forward Compatibility 1327 This document describes version 2.0 of IKE, meaning the major version 1328 number is 2 and the minor version number is 0. This document is a 1329 replacement for [IKEV2]. It is likely that some implementations will 1330 want to support version 1.0 and version 2.0, and in the future, other 1331 versions. 1333 The major version number should be incremented only if the packet 1334 formats or required actions have changed so dramatically that an 1335 older version node would not be able to interoperate with a newer 1336 version node if it simply ignored the fields it did not understand 1337 and took the actions specified in the older specification. The minor 1338 version number indicates new capabilities, and MUST be ignored by a 1339 node with a smaller minor version number, but used for informational 1340 purposes by the node with the larger minor version number. For 1341 example, it might indicate the ability to process a newly defined 1342 Notify message type. The node with the larger minor version number 1343 would simply note that its correspondent would not be able to 1344 understand that message and therefore would not send it. 1346 If an endpoint receives a message with a higher major version number, 1347 it MUST drop the message and SHOULD send an unauthenticated Notify 1348 message of type INVALID_MAJOR_VERSION containing the highest 1349 (closest) version number it supports. If an endpoint supports major 1350 version n, and major version m, it MUST support all versions between 1351 n and m. If it receives a message with a major version that it 1352 supports, it MUST respond with that version number. In order to 1353 prevent two nodes from being tricked into corresponding with a lower 1354 major version number than the maximum that they both support, IKE has 1355 a flag that indicates that the node is capable of speaking a higher 1356 major version number. 1358 Thus, the major version number in the IKE header indicates the 1359 version number of the message, not the highest version number that 1360 the transmitter supports. If the initiator is capable of speaking 1361 versions n, n+1, and n+2, and the responder is capable of speaking 1362 versions n and n+1, then they will negotiate speaking n+1, where the 1363 initiator will set a flag indicating its ability to speak a higher 1364 version. If they mistakenly (perhaps through an active attacker 1365 sending error messages) negotiate to version n, then both will notice 1366 that the other side can support a higher version number, and they 1367 MUST break the connection and reconnect using version n+1. 1369 Note that IKEv1 does not follow these rules, because there is no way 1370 in v1 of noting that you are capable of speaking a higher version 1371 number. So an active attacker can trick two v2-capable nodes into 1372 speaking v1. When a v2-capable node negotiates down to v1, it should 1373 note that fact in its logs. 1375 Also for forward compatibility, all fields marked RESERVED MUST be 1376 set to zero by an implementation running version 2.0, and their 1377 content MUST be ignored by an implementation running version 2.0 ("Be 1378 conservative in what you send and liberal in what you receive"). In 1379 this way, future versions of the protocol can use those fields in a 1380 way that is guaranteed to be ignored by implementations that do not 1381 understand them. Similarly, payload types that are not defined are 1382 reserved for future use; implementations of a version where they are 1383 undefined MUST skip over those payloads and ignore their contents. 1385 IKEv2 adds a "critical" flag to each payload header for further 1386 flexibility for forward compatibility. If the critical flag is set 1387 and the payload type is unrecognized, the message MUST be rejected 1388 and the response to the IKE request containing that payload MUST 1389 include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an 1390 unsupported critical payload was included. In that Notify payload, 1391 the notification data contains the one-octet payload type. If the 1392 critical flag is not set and the payload type is unsupported, that 1393 payload MUST be ignored. Payloads sent in IKE response messages MUST 1394 NOT have the critical flag set. Note that the critical flag applies 1395 only to the payload type, not the contents. If the payload type is 1396 recognized, but the payload contains something which is not (such as 1397 an unknown transform inside an SA payload, or an unknown Notify 1398 Message Type inside a Notify payload), the critical flag is ignored. 1400 Although new payload types may be added in the future and may appear 1401 interleaved with the fields defined in this specification, 1402 implementations SHOULD send the payloads defined in this 1403 specification in the order shown in the figures in Sections 1 and 2; 1404 implementations MUST NOT reject as invalid a message with those 1405 payloads in any other order. 1407 2.6. IKE SA SPIs and Cookies 1409 The initial two eight-octet fields in the header, called the "IKE 1410 SPIs", are used as a connection identifier at the beginning of IKE 1411 packets. Each endpoint chooses one of the two SPIs and MUST choose 1412 them so as to be unique identifiers of an IKE SA. An SPI value of 1413 zero is special: it indicates that the remote SPI value is not yet 1414 known by the sender. 1416 Incoming IKE packets are mapped to an IKE SA only using the packet's 1417 SPI, not using (for example) the source IP address of the packet. 1419 Unlike ESP and AH where only the recipient's SPI appears in the 1420 header of a message, in IKE the sender's SPI is also sent in every 1421 message. Since the SPI chosen by the original initiator of the IKE 1422 SA is always sent first, an endpoint with multiple IKE SAs open that 1423 wants to find the appropriate IKE SA using the SPI it assigned must 1424 look at the Initiator flag in the header to determine whether it 1425 assigned the first or the second eight octets. 1427 In the first message of an initial IKE exchange, the initiator will 1428 not know the responder's SPI value and will therefore set that field 1429 to zero. When the IKE_SA_INIT exchange does not result in the 1430 creation of an IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, 1431 or COOKIE (see Section 2.6), the responder's SPI will be zero also in 1432 the response message. However, if the responder sends a non-zero 1433 responder SPI, the initiator should not reject the response for only 1434 that reason. 1436 Two expected attacks against IKE are state and CPU exhaustion, where 1437 the target is flooded with session initiation requests from forged IP 1438 addresses. This attack can be made less effective a responder uses 1439 minimal CPU and commits no state to an SA until it knows the 1440 initiator can receive packets at the address from which it claims to 1441 be sending them. 1443 When a responder detects a large number of half-open IKE SAs, it 1444 SHOULD reply to IKE_SA_INIT requests with a response containing the 1445 COOKIE notification. The data associated with this notification MUST 1446 be between 1 and 64 octets in length (inclusive), and its generation 1447 is described later in this section. If the IKE_SA_INIT response 1448 includes the COOKIE notification, the initiator MUST then retry the 1449 IKE_SA_INIT request, and include the COOKIE notification containing 1450 the received data as the first payload, and all other payloads 1451 unchanged. The initial exchange will then be as follows: 1453 Initiator Responder 1454 ------------------------------------------------------------------- 1455 HDR(A,0), SAi1, KEi, Ni --> 1456 <-- HDR(A,0), N(COOKIE) 1457 HDR(A,0), N(COOKIE), SAi1, 1458 KEi, Ni --> 1459 <-- HDR(A,B), SAr1, KEr, 1460 Nr, [CERTREQ] 1461 HDR(A,B), SK {IDi, [CERT,] 1462 [CERTREQ,] [IDr,] AUTH, 1463 SAi2, TSi, TSr} --> 1464 <-- HDR(A,B), SK {IDr, [CERT,] 1465 AUTH, SAr2, TSi, TSr} 1467 The first two messages do not affect any initiator or responder state 1468 except for communicating the cookie. In particular, the message 1469 sequence numbers in the first four messages will all be zero and the 1470 message sequence numbers in the last two messages will be one. 'A' 1471 is the SPI assigned by the initiator, while 'B' is the SPI assigned 1472 by the responder. 1474 An IKE implementation can implement its responder cookie generation 1475 in such a way as to not require any saved state to recognize its 1476 valid cookie when the second IKE_SA_INIT message arrives. The exact 1477 algorithms and syntax used to generate cookies do not affect 1478 interoperability and hence are not specified here. The following is 1479 an example of how an endpoint could use cookies to implement limited 1480 DoS protection. 1482 A good way to do this is to set the responder cookie to be: 1484 Cookie = | Hash(Ni | IPi | SPIi | ) 1486 where is a randomly generated secret known only to the 1487 responder and periodically changed and | indicates concatenation. 1488 should be changed whenever is 1489 regenerated. The cookie can be recomputed when the IKE_SA_INIT 1490 arrives the second time and compared to the cookie in the received 1491 message. If it matches, the responder knows that the cookie was 1492 generated since the last change to and that IPi must be the 1493 same as the source address it saw the first time. Incorporating SPIi 1494 into the calculation ensures that if multiple IKE SAs are being set 1495 up in parallel they will all get different cookies (assuming the 1496 initiator chooses unique SPIi's). Incorporating Ni in the hash 1497 ensures that an attacker who sees only message 2 can't successfully 1498 forge a message 3. Also, incorporating SPIi in the hash prevents an 1499 attacker from fetching one cookie from the other end, and then 1500 initiating many IKE_SA_INIT exchanges all with different initiator 1501 SPIs (and perhaps port numbers) so that the responder thinks that 1502 there are lots of machines behind one NAT box who are all trying to 1503 connect. 1505 If a new value for is chosen while there are connections in 1506 the process of being initialized, an IKE_SA_INIT might be returned 1507 with other than the current . The responder in 1508 that case MAY reject the message by sending another response with a 1509 new cookie or it MAY keep the old value of around for a 1510 short time and accept cookies computed from either one. The 1511 responder should not accept cookies indefinitely after is 1512 changed, since that would defeat part of the DoS protection. The 1513 responder should change the value of frequently, especially 1514 if under attack. 1516 When one party receives an IKE_SA_INIT request containing a cookie 1517 whose contents do not match the value expected, that party MUST 1518 ignore the cookie and process the message as if no cookie had been 1519 included; usually this means sending a response containing a new 1520 cookie. The initiator should limit the number of cookie exchanges it 1521 tries before giving up, possibly using exponential back-off. An 1522 attacker can forge multiple cookie responses to the initiator's 1523 IKE_SA_INIT message, and each of those forged cookie replies will 1524 cause two packets to be sent: one packet from the initiator to the 1525 responder (which will reject those cookies), and one response from 1526 responder to initiator that includes the correct cookie. 1528 A note on terminology: the term "cookies" originates with Karn and 1529 Simpson [PHOTURIS] in Photuris, an early proposal for key management 1530 with IPsec, and it has persisted. The Internet Security Association 1531 and Key Management Protocol (ISAKMP) [ISAKMP] fixed message header 1532 includes two eight-octet fields called "cookies", and that syntax is 1533 used by both IKEv1 and IKEv2, although in IKEv2 they are referred to 1534 as the "IKE SPI" and there is a new separate field in a Notify 1535 payload holding the cookie. 1537 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD 1539 There are two common reasons why the initiator may have to retry the 1540 IKE_SA_INIT exchange: the responder requests a cookie or wants a 1541 different Diffie-Hellman group than was included in the KEi payload. 1542 If the initiator receives a cookie from the responder, the initiator 1543 needs to decide whether or not to include the cookie in only the next 1544 retry of the IKE_SA_INIT request, or in all subsequent retries as 1545 well. 1547 If the initiator includes the cookie only in the next retry, one 1548 additional roundtrip may be needed in some cases. An additional 1549 roundtrip is needed also if the initiator includes the cookie in all 1550 retries, but the responder does not support this. For instance, if 1551 the responder includes the KEi payloads in cookie calculation, it 1552 will reject the request by sending a new cookie. 1554 If both peers support including the cookie in all retries, a slightly 1555 shorter exchange can happen. 1557 Initiator Responder 1558 ----------------------------------------------------------- 1559 HDR(A,0), SAi1, KEi, Ni --> 1560 <-- HDR(A,0), N(COOKIE) 1561 HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> 1562 <-- HDR(A,0), N(INVALID_KE_PAYLOAD) 1563 HDR(A,0), N(COOKIE), SAi1, KEi', Ni --> 1564 <-- HDR(A,B), SAr1, KEr, Nr 1566 Implementations SHOULD support this shorter exchange, but MUST NOT 1567 fail if other implementations do not support this shorter exchange. 1569 2.7. Cryptographic Algorithm Negotiation 1571 The payload type known as "SA" indicates a proposal for a set of 1572 choices of IPsec protocols (IKE, ESP, or AH) for the SA as well as 1573 cryptographic algorithms associated with each protocol. 1575 An SA payload consists of one or more proposals. Each proposal 1576 includes one protocol. Each protocol contains one or more transforms 1577 -- each specifying a cryptographic algorithm. Each transform 1578 contains zero or more attributes (attributes are needed only if the 1579 transform identifier does not completely specify the cryptographic 1580 algorithm). 1582 This hierarchical structure was designed to efficiently encode 1583 proposals for cryptographic suites when the number of supported 1584 suites is large because multiple values are acceptable for multiple 1585 transforms. The responder MUST choose a single suite, which may be 1586 any subset of the SA proposal following the rules below: 1588 Each proposal contains one protocol. If a proposal is accepted, the 1589 SA response MUST contain the same protocol. The responder MUST 1590 accept a single proposal or reject them all and return an error. The 1591 error is given in a notification of type NO_PROPOSAL_CHOSEN. 1593 Each IPsec protocol proposal contains one or more transforms. Each 1594 transform contains a transform type. The accepted cryptographic 1595 suite MUST contain exactly one transform of each type included in the 1596 proposal. For example: if an ESP proposal includes transforms 1597 ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, 1598 AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one 1599 of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six 1600 combinations are acceptable. 1602 If an initiator proposes both normal ciphers with integrity 1603 protection as well as combined-mode ciphers, then two proposals are 1604 needed. One of the proposals includes the normal ciphers with the 1605 integrity algoritms for them, and the other proposal includes all the 1606 combined mode ciphers without the integrity algorithms (because 1607 combined mode ciphers are not allowed to have any integrity algorithm 1608 other than "none"). 1610 2.8. Rekeying 1612 IKE, ESP, and AH security associations use secret keys that should be 1613 used only for a limited amount of time and to protect a limited 1614 amount of data. This limits the lifetime of the entire security 1615 association. When the lifetime of a security association expires, 1616 the security association MUST NOT be used. If there is demand, new 1617 security associations MAY be established. Reestablishment of 1618 security associations to take the place of ones that expire is 1619 referred to as "rekeying". 1621 To allow for minimal IPsec implementations, the ability to rekey SAs 1622 without restarting the entire IKE SA is optional. An implementation 1623 MAY refuse all CREATE_CHILD_SA requests within an IKE SA. If an SA 1624 has expired or is about to expire and rekeying attempts using the 1625 mechanisms described here fail, an implementation MUST close the IKE 1626 SA and any associated Child SAs and then MAY start new ones. 1627 Implementations may wish to support in-place rekeying of SAs, since 1628 doing so offers better performance and is likely to reduce the number 1629 of packets lost during the transition. 1631 To rekey a Child SA within an existing IKE SA, create a new, 1632 equivalent SA (see Section 2.17 below), and when the new one is 1633 established, delete the old one. Note that, when rekeying, the new 1634 Child SA SHOULD NOT have different traffic selectors and algorithms 1635 than the old one. 1637 To rekey an IKE SA, establish a new equivalent IKE SA (see 1638 Section 2.18 below) with the peer to whom the old IKE SA is shared 1639 using a CREATE_CHILD_SA within the existing IKE SA. An IKE SA so 1640 created inherits all of the original IKE SA's Child SAs, and the new 1641 IKE SA is used for all control messages needed to maintain those 1642 Child SAs. After the new equivalent IKE SA is created, the initiator 1643 deletes the old IKE SA, and the Delete payload to delete itself MUST 1644 be the last request sent over the old IKE SA. 1646 SAs should be rekeyed proactively, i.e., the new SA should be 1647 established before the old one expires and becomes unusable. Enough 1648 time should elapse between the time the new SA is established and the 1649 old one becomes unusable so that traffic can be switched over to the 1650 new SA. 1652 A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes 1653 were negotiated. In IKEv2, each end of the SA is responsible for 1654 enforcing its own lifetime policy on the SA and rekeying the SA when 1655 necessary. If the two ends have different lifetime policies, the end 1656 with the shorter lifetime will end up always being the one to request 1657 the rekeying. If an SA has been inactive for a long time and if an 1658 endpoint would not initiate the SA in the absence of traffic, the 1659 endpoint MAY choose to close the SA instead of rekeying it when its 1660 lifetime expires. It can also do so if there has been no traffic 1661 since the last time the SA was rekeyed. 1663 Note that IKEv2 deliberately allows parallel SAs with the same 1664 traffic selectors between common endpoints. One of the purposes of 1665 this is to support traffic quality of service (QoS) differences among 1666 the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and section 4.1 of 1667 [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints 1668 and the traffic selectors may not uniquely identify an SA between 1669 those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on 1670 the basis of duplicate traffic selectors SHOULD NOT be used. 1672 There are timing windows -- particularly in the presence of lost 1673 packets -- where endpoints may not agree on the state of an SA. The 1674 responder to a CREATE_CHILD_SA MUST be prepared to accept messages on 1675 an SA before sending its response to the creation request, so there 1676 is no ambiguity for the initiator. The initiator MAY begin sending 1677 on an SA as soon as it processes the response. The initiator, 1678 however, cannot receive on a newly created SA until it receives and 1679 processes the response to its CREATE_CHILD_SA request. How, then, is 1680 the responder to know when it is OK to send on the newly created SA? 1682 From a technical correctness and interoperability perspective, the 1683 responder MAY begin sending on an SA as soon as it sends its response 1684 to the CREATE_CHILD_SA request. In some situations, however, this 1685 could result in packets unnecessarily being dropped, so an 1686 implementation MAY defer such sending. 1688 The responder can be assured that the initiator is prepared to 1689 receive messages on an SA if either (1) it has received a 1690 cryptographically valid message on the other half of the SA pair, or 1691 (2) the new SA rekeys an existing SA and it receives an IKE request 1692 to close the replaced SA. When rekeying an SA, the responder 1693 continues to send traffic on the old SA until one of those events 1694 occurs. When establishing a new SA, the responder MAY defer sending 1695 messages on a new SA until either it receives one or a timeout has 1696 occurred. If an initiator receives a message on an SA for which it 1697 has not received a response to its CREATE_CHILD_SA request, it 1698 interprets that as a likely packet loss and retransmits the 1699 CREATE_CHILD_SA request. An initiator MAY send a dummy ESP message 1700 on a newly created ESP SA if it has no messages queued in order to 1701 assure the responder that the initiator is ready to receive messages. 1703 2.8.1. Simultaneous Child SA rekeying 1705 If the two ends have the same lifetime policies, it is possible that 1706 both will initiate a rekeying at the same time (which will result in 1707 redundant SAs). To reduce the probability of this happening, the 1708 timing of rekeying requests SHOULD be jittered (delayed by a random 1709 amount of time after the need for rekeying is noticed). 1711 This form of rekeying may temporarily result in multiple similar SAs 1712 between the same pairs of nodes. When there are two SAs eligible to 1713 receive packets, a node MUST accept incoming packets through either 1714 SA. If redundant SAs are created though such a collision, the SA 1715 created with the lowest of the four nonces used in the two exchanges 1716 SHOULD be closed by the endpoint that created it. "Lowest" means an 1717 octet-by-octet comparison (instead of, for instance, comparing the 1718 nonces as large integers). In other words, start by comparing the 1719 first octet; if they're equal, move to the next octet, and so on. If 1720 you reach the end of one nonce, that nonce is the lower one. The 1721 node that initiated the surviving rekeyed SA should delete the 1722 replaced SA after the new one is established. 1724 The following is an explanation on the impact this has on 1725 implementations. Assume that hosts A and B have an existing Child SA 1726 pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same 1727 time: 1729 Host A Host B 1730 ------------------------------------------------------------------- 1731 send req1: N(REKEY_SA,SPIa1), 1732 SA(..,SPIa2,..),Ni1,.. --> 1733 <-- send req2: N(REKEY_SA,SPIb1), 1734 SA(..,SPIb2,..),Ni2 1735 recv req2 <-- 1737 At this point, A knows there is a simultaneous rekeying going on. 1738 However, it cannot yet know which of the exchanges will have the 1739 lowest nonce, so it will just note the situation and respond as 1740 usual. 1742 send resp2: SA(..,SPIa3,..), 1743 Nr1,.. --> 1744 --> recv req1 1746 Now B also knows that simultaneous rekeying is going on. It responds 1747 as usual. 1749 <-- send resp1: SA(..,SPIb3,..), 1750 Nr2,.. 1751 recv resp1 <-- 1752 --> recv resp2 1754 At this point, there are three Child SA pairs between A and B (the 1755 old one and two new ones). A and B can now compare the nonces. 1756 Suppose that the lowest nonce was Nr1 in message resp2; in this case, 1757 B (the sender of req2) deletes the redundant new SA, and A (the node 1758 that initiated the surviving rekeyed SA), deletes the old one. 1760 send req3: D(SPIa1) --> 1761 <-- send req4: D(SPIb2) 1762 --> recv req3 1763 <-- send resp3: D(SPIb1) 1764 recv req4 <-- 1765 send resp4: D(SPIa3) --> 1767 The rekeying is now finished. 1769 However, there is a second possible sequence of events that can 1770 happen if some packets are lost in the network, resulting in 1771 retransmissions. The rekeying begins as usual, but A's first packet 1772 (req1) is lost. 1774 Host A Host B 1775 ------------------------------------------------------------------- 1776 send req1: N(REKEY_SA,SPIa1), 1777 SA(..,SPIa2,..), 1778 Ni1,.. --> (lost) 1779 <-- send req2: N(REKEY_SA,SPIb1), 1780 SA(..,SPIb2,..),Ni2 1781 recv req2 <-- 1782 send resp2: SA(..,SPIa3,..), 1783 Nr1,.. --> 1784 --> recv resp2 1785 <-- send req3: D(SPIb1) 1786 recv req3 <-- 1787 send resp3: D(SPIa1) --> 1788 --> recv resp3 1790 From B's point of view, the rekeying is now completed, and since it 1791 has not yet received A's req1, it does not even know that there was 1792 simultaneous rekeying. However, A will continue retransmitting the 1793 message, and eventually it will reach B. 1795 resend req1 --> 1796 --> recv req1 1798 To B, it looks like A is trying to rekey an SA that no longer exists; 1799 thus, B responds to the request with something non-fatal such as 1800 CHILD_SA_NOT_FOUND. 1802 <-- send resp1: N(CHILD_SA_NOT_FOUND) 1803 recv resp1 <-- 1805 When A receives this error, it already knows there was simultaneous 1806 rekeying, so it can ignore the error message. 1808 2.8.2. Simultaneous IKE SA Rekeying 1810 Probably the most complex case occurs when both peers try to rekey 1811 the IKE_SA at the same time. Basically, the text in Section 2.8 1812 applies to this case as well; however, it is important to ensure that 1813 the Child SAs are inherited by the correct IKE_SA. 1815 The case where both endpoints notice the simultaneous rekeying works 1816 the same way as with Child SAs. After the CREATE_CHILD_SA exchanges, 1817 three IKE SAs exist between A and B: the old IKE SA and two new IKE 1818 SAs. The new IKE SA containing the lowest nonce SHOULD be deleted by 1819 the node that created it, and the other suriving new IKE SA MUST 1820 inherit all the Child SAs. 1822 In addition to normal simultaneous rekeying cases, there is a special 1823 case where one peer finishes its rekey before it even notices that 1824 other peer is doing a rekey. If only one peer detects a simultaneous 1825 rekey, redundant SAs are not created. In this case, when the peer 1826 that did not notice the simultaneous rekey gets the request to rekey 1827 the IKE SA that it has already successfully rekeyed, it SHOULD return 1828 TEMPORARY_FAILURE because it is an IKE SA that it is currently trying 1829 to close (whether or not it has already sent the delete notification 1830 for the SA). If the peer that did notice the simultaneous rekey gets 1831 the delete request from the other peer for the old IKE SA, it knows 1832 that the other peer did not detect the simultaneous rekey, and the 1833 first peer can forget its own rekey attempt. 1835 Host A Host B 1836 ------------------------------------------------------------------- 1837 send req1: 1838 SA(..,SPIa1,..),Ni1,.. --> 1839 <-- send req2: SA(..,SPIb1,..),Ni2,.. 1840 --> recv req1 1841 <-- send resp1: SA(..,SPIb2,..),Nr2,.. 1842 recv resp1 <-- 1843 send req3: D() --> 1844 --> recv req3 1846 At this point, host B sees a request to close the IKE_SA. There's 1847 not much more to do than to reply as usual. However, at this point 1848 host B should stop retransmitting req2, since once host A receives 1849 resp3, it will delete all the state associated with the old IKE_SA 1850 and will not be able to reply to it. 1852 <-- send resp3: () 1854 The TEMPORARY_FAILURE notification was not included in RFC 4306, and 1855 support of the TEMPORARY_FAILURE notification is not negotiated. 1856 Thus, older peers that implement RFC 4306 but not this document may 1857 receive these notifications. In that case, they will treat it the 1858 same as any other unknown error notification, and will stop the 1859 exchange. Because the other peer has already rekeyed the exchange, 1860 doing so does not have any ill effects. 1862 2.8.3. Rekeying the IKE SA Versus Reauthentication 1864 Rekeying the IKE SA and reauthentication are different concepts in 1865 IKEv2. Rekeying the IKE SA establishes new keys for the IKE SA and 1866 resets the Message ID counters, but it does not authenticate the 1867 parties again (no AUTH or EAP payloads are involved). 1869 Although rekeying the IKE SA may be important in some environments, 1870 reauthentication (the verification that the parties still have access 1871 to the long-term credentials) is often more important. 1873 IKEv2 does not have any special support for reauthentication. 1874 Reauthentication is done by creating a new IKE SA from scratch (using 1875 IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify 1876 payloads), creating new Child SAs within the new IKE SA (without 1877 REKEY_SA Notify payloads), and finally deleting the old IKE SA (which 1878 deletes the old Child SAs as well). 1880 This means that reauthentication also establishes new keys for the 1881 IKE SA and Child SAs. Therefore, while rekeying can be performed 1882 more often than reauthentication, the situation where "authentication 1883 lifetime" is shorter than "key lifetime" does not make sense. 1885 While creation of a new IKE SA can be initiated by either party 1886 (initiator or responder in the original IKE SA), the use of EAP 1887 authentication and/or configuration payloads means in practice that 1888 reauthentication has to be initiated by the same party as the 1889 original IKE SA. IKEv2 does not currently allow the responder to 1890 request reauthentication in this case; however, there are extensions 1891 that add this functionality such as [REAUTH]. 1893 2.9. Traffic Selector Negotiation 1895 When an RFC4301-compliant IPsec subsystem receives an IP packet that 1896 matches a "protect" selector in its Security Policy Database (SPD), 1897 the subsystem protects that packet with IPsec. When no SA exists 1898 yet, it is the task of IKE to create it. Maintenance of a system's 1899 SPD is outside the scope of IKE, although some implementations might 1900 update their SPD in connection with the running of IKE (for an 1901 example scenario, see Section 1.1.3). 1903 Traffic Selector (TS) payloads allow endpoints to communicate some of 1904 the information from their SPD to their peers. These must be 1905 communicated to IKE from the SPD (for example, the PF_KEY API [PFKEY] 1906 uses the SADB_ACQUIRE message). TS payloads specify the selection 1907 criteria for packets that will be forwarded over the newly set up SA. 1908 This can serve as a consistency check in some scenarios to assure 1909 that the SPDs are consistent. In others, it guides the dynamic 1910 update of the SPD. 1912 Two TS payloads appear in each of the messages in the exchange that 1913 creates a Child SA pair. Each TS payload contains one or more 1914 Traffic Selectors. Each traffic selector consists of an address 1915 range (IPv4 or IPv6), a port range, and an IP protocol ID. 1917 The first of the two TS payloads is known as TSi (Traffic Selector- 1918 initiator). The second is known as TSr (Traffic Selector-responder). 1919 TSi specifies the source address of traffic forwarded from (or the 1920 destination address of traffic forwarded to) the initiator of the 1921 Child SA pair. TSr specifies the destination address of the traffic 1922 forwarded to (or the source address of the traffic forwarded from) 1923 the responder of the Child SA pair. For example, if the original 1924 initiator requests the creation of a Child SA pair, and wishes to 1925 tunnel all traffic from subnet 198.51.100.* on the initiator's side 1926 to subnet 192.0.2.* on the responder's side, the initiator would 1927 include a single traffic selector in each TS payload. TSi would 1928 specify the address range (198.51.100.0 - 198.51.100.255) and TSr 1929 would specify the address range (192.0.2.0 - 192.0.2.255). Assuming 1930 that proposal was acceptable to the responder, it would send 1931 identical TS payloads back. 1933 IKEv2 allows the responder to choose a subset of the traffic proposed 1934 by the initiator. This could happen when the configurations of the 1935 two endpoints are being updated but only one end has received the new 1936 information. Since the two endpoints may be configured by different 1937 people, the incompatibility may persist for an extended period even 1938 in the absence of errors. It also allows for intentionally different 1939 configurations, as when one end is configured to tunnel all addresses 1940 and depends on the other end to have the up-to-date list. 1942 When the responder chooses a subset of the traffic proposed by the 1943 initiator, it narrows the traffic selectors to some subset of the 1944 initiator's proposal (provided the set does not become the null set). 1945 If the type of traffic selector proposed is unknown, the responder 1946 ignores that traffic selector, so that the unknown type is not 1947 returned in the narrowed set. 1949 To enable the responder to choose the appropriate range in this case, 1950 if the initiator has requested the SA due to a data packet, the 1951 initiator SHOULD include as the first traffic selector in each of TSi 1952 and TSr a very specific traffic selector including the addresses in 1953 the packet triggering the request. In the example, the initiator 1954 would include in TSi two traffic selectors: the first containing the 1955 address range (198.51.100.43 - 198.51.100.43) and the source port and 1956 IP protocol from the packet and the second containing (198.51.100.0 - 1957 198.51.100.255) with all ports and IP protocols. The initiator would 1958 similarly include two traffic selectors in TSr. If the initiator 1959 creates the Child SA pair not in response to an arriving packet, but 1960 rather, say, upon startup, then there may be no specific addresses 1961 the initiator prefers for the initial tunnel over any other. In that 1962 case, the first values in TSi and TSr can be ranges rather than 1963 specific values. 1965 The responder performs the narrowing as follows: 1967 o If the responder's policy does not allow it to accept any part of 1968 the proposed traffic selectors, it responds with a TS_UNACCEPTABLE 1969 Notify message. 1971 o If the responder's policy allows the entire set of traffic covered 1972 by TSi and TSr, no narrowing is necessary, and the responder can 1973 return the same TSi and TSr values. 1975 o If the responder's policy allows it to accept the first selector 1976 of TSi and TSr, then the responder MUST narrow the traffic 1977 selectors to a subset that includes the initiator's first choices. 1978 In this example above, the responder might respond with TSi being 1979 (198.51.100.43 - 198.51.100.43) with all ports and IP protocols. 1981 o If the responder's policy does not allow it to accept the first 1982 selector of TSi and TSr, the responder narrows to an acceptable 1983 subset of TSi and TSr. 1985 When narrowing is done, there may be several subsets that are 1986 acceptable but their union is not. In this case, the responder 1987 arbitrarily chooses one of them, and MAY include an 1988 ADDITIONAL_TS_POSSIBLE notification in the response. The 1989 ADDITIONAL_TS_POSSIBLE notification asserts that the responder 1990 narrowed the proposed traffic selectors but that other traffic 1991 selectors would also have been acceptable, though only in a separate 1992 SA. There is no data associated with this Notify type. This case 1993 will occur only when the initiator and responder are configured 1994 differently from one another. If the initiator and responder agree 1995 on the granularity of tunnels, the initiator will never request a 1996 tunnel wider than the responder will accept. 1998 It is possible for the responder's policy to contain multiple smaller 1999 ranges, all encompassed by the initiator's traffic selector, and with 2000 the responder's policy being that each of those ranges should be sent 2001 over a different SA. Continuing the example above, the responder 2002 might have a policy of being willing to tunnel those addresses to and 2003 from the initiator, but might require that each address pair be on a 2004 separately negotiated Child SA. If the initiator didn't generate its 2005 request based on the packet, but (for example) upon startup, there 2006 would not be the very specific first traffic selectors helping the 2007 responder to select the correct range. There would be no way for the 2008 responder to determine which pair of addresses should be included in 2009 this tunnel, and it would have to make a guess or reject the request 2010 with a SINGLE_PAIR_REQUIRED Notify message. 2012 The SINGLE_PAIR_REQUIRED error indicates that a CREATE_CHILD_SA 2013 request is unacceptable because its sender is only willing to accept 2014 traffic selectors specifying a single pair of addresses. The 2015 requestor is expected to respond by requesting an SA for only the 2016 specific traffic it is trying to forward. 2018 Few implementations will have policies that require separate SAs for 2019 each address pair. Because of this, if only some parts of the TSi 2020 and TSr proposed by the initiator are acceptable to the responder, 2021 responders SHOULD narrow the selectors to an acceptable subset rather 2022 than use SINGLE_PAIR_REQUIRED. 2024 2.9.1. Traffic Selectors Violating Own Policy 2026 When creating a new SA, the initiator needs to avoid proposing 2027 traffic selectors that violate its own policy. If this rule is not 2028 followed, valid traffic may be dropped. If you use decorrelated 2029 policies from [IPSECARCH], this kind of policy violations cannot 2030 happen. 2032 This is best illustrated by an example. Suppose that host A has a 2033 policy whose effect is that traffic to 198.51.100.66 is sent via host 2034 B encrypted using AES, and traffic to all other hosts in 2035 198.51.100.0/24 is also sent via B, but must use 3DES. Suppose also 2036 that host B accepts any combination of AES and 3DES. 2038 If host A now proposes an SA that uses 3DES, and includes TSr 2039 containing (198.51.100.0-198.51.100.255), this will be accepted by 2040 host B. Now, host B can also use this SA to send traffic from 2041 198.51.100.66, but those packets will be dropped by A since it 2042 requires the use of AES for this traffic. Even if host A creates a 2043 new SA only for 198.51.100.66 that uses AES, host B may freely 2044 continue to use the first SA for the traffic. In this situation, 2045 when proposing the SA, host A should have followed its own policy, 2046 and included a TSr containing ((198.51.100.0- 2047 198.51.100.65),(198.51.100.67-198.51.100.255)) instead. 2049 In general, if (1) the initiator makes a proposal "for traffic X 2050 (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator 2051 does not actually accept traffic X' with SA, and (3) the initiator 2052 would be willing to accept traffic X' with some SA' (!=SA), valid 2053 traffic can be unnecessarily dropped since the responder can apply 2054 either SA or SA' to traffic X'. 2056 2.10. Nonces 2058 The IKE_SA_INIT messages each contain a nonce. These nonces are used 2059 as inputs to cryptographic functions. The CREATE_CHILD_SA request 2060 and the CREATE_CHILD_SA response also contain nonces. These nonces 2061 are used to add freshness to the key derivation technique used to 2062 obtain keys for Child SA, and to ensure creation of strong pseudo- 2063 random bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST 2064 be randomly chosen, MUST be at least 128 bits in size, and MUST be at 2065 least half the key size of the negotiated pseudo-random function 2066 (PRF). However, the initiator chooses the nonce before the outcome 2067 of the negotiation is known. Because of that, the nonce has to be 2068 long enough for all the PRFs being proposed. If the same random 2069 number source is used for both keys and nonces, care must be taken to 2070 ensure that the latter use does not compromise the former. 2072 2.11. Address and Port Agility 2074 IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and 2075 AH associations for the same IP addresses it runs over. The IP 2076 addresses and ports in the outer header are, however, not themselves 2077 cryptographically protected, and IKE is designed to work even through 2078 Network Address Translation (NAT) boxes. An implementation MUST 2079 accept incoming requests even if the source port is not 500 or 4500, 2080 and MUST respond to the address and port from which the request was 2081 received. It MUST specify the address and port at which the request 2082 was received as the source address and port in the response. IKE 2083 functions identically over IPv4 or IPv6. 2085 2.12. Reuse of Diffie-Hellman Exponentials 2087 IKE generates keying material using an ephemeral Diffie-Hellman 2088 exchange in order to gain the property of "perfect forward secrecy". 2089 This means that once a connection is closed and its corresponding 2090 keys are forgotten, even someone who has recorded all of the data 2091 from the connection and gets access to all of the long-term keys of 2092 the two endpoints cannot reconstruct the keys used to protect the 2093 conversation without doing a brute force search of the session key 2094 space. 2096 Achieving perfect forward secrecy requires that when a connection is 2097 closed, each endpoint MUST forget not only the keys used by the 2098 connection but also any information that could be used to recompute 2099 those keys. 2101 Because computing Diffie-Hellman exponentials is computationally 2102 expensive, an endpoint may find it advantageous to reuse those 2103 exponentials for multiple connection setups. There are several 2104 reasonable strategies for doing this. An endpoint could choose a new 2105 exponential only periodically though this could result in less-than- 2106 perfect forward secrecy if some connection lasts for less than the 2107 lifetime of the exponential. Or it could keep track of which 2108 exponential was used for each connection and delete the information 2109 associated with the exponential only when some corresponding 2110 connection was closed. This would allow the exponential to be reused 2111 without losing perfect forward secrecy at the cost of maintaining 2112 more state. 2114 Whether and when to reuse Diffie-Hellman exponentials are private 2115 decisions in the sense that they will not affect interoperability. 2116 An implementation that reuses exponentials MAY choose to remember the 2117 exponential used by the other endpoint on past exchanges and if one 2118 is reused to avoid the second half of the calculation. See [REUSE] 2119 for a security analysis of this practice and for additional security 2120 considerations when reusing ephemeral Diffie-Hellman keys. 2122 2.13. Generating Keying Material 2124 In the context of the IKE SA, four cryptographic algorithms are 2125 negotiated: an encryption algorithm, an integrity protection 2126 algorithm, a Diffie-Hellman group, and a pseudo-random function 2127 (PRF). The PRF is used for the construction of keying material for 2128 all of the cryptographic algorithms used in both the IKE SA and the 2129 Child SAs. 2131 We assume that each encryption algorithm and integrity protection 2132 algorithm uses a fixed-size key and that any randomly chosen value of 2133 that fixed size can serve as an appropriate key. For algorithms that 2134 accept a variable length key, a fixed key size MUST be specified as 2135 part of the cryptographic transform negotiated (see Section 3.3.5 for 2136 the definition of the Key Length transform attribute). For 2137 algorithms for which not all values are valid keys (such as DES or 2138 3DES with key parity), the algorithm by which keys are derived from 2139 arbitrary values MUST be specified by the cryptographic transform. 2140 For integrity protection functions based on Hashed Message 2141 Authentication Code (HMAC), the fixed key size is the size of the 2142 output of the underlying hash function. 2144 It is assumed that PRFs accept keys of any length, but have a 2145 preferred key size. The preferred key size MUST be used as the 2146 length of SK_d, SK_pi, and SK_pr (see Section 2.14). For PRFs based 2147 on the HMAC construction, the preferred key size is equal to the 2148 length of the output of the underlying hash function. Other types of 2149 PRFs MUST specify their preferred key size. 2151 Keying material will always be derived as the output of the 2152 negotiated PRF algorithm. Since the amount of keying material needed 2153 may be greater than the size of the output of the PRF, the PRF is 2154 used iteratively. The term "prf+" describes a function that outputs 2155 a pseudo-random stream based on the inputs to a pseudo-random 2156 function called "prf". 2158 In the following, | indicates concatenation. prf+ is defined as: 2160 prf+ (K,S) = T1 | T2 | T3 | T4 | ... 2162 where: 2163 T1 = prf (K, S | 0x01) 2164 T2 = prf (K, T1 | S | 0x02) 2165 T3 = prf (K, T2 | S | 0x03) 2166 T4 = prf (K, T3 | S | 0x04) 2167 ... 2169 This continues until all the material needed to compute all required 2170 keys has been output from prf+. The keys are taken from the output 2171 string without regard to boundaries (e.g., if the required keys are a 2172 256-bit Advanced Encryption Standard (AES) key and a 160-bit HMAC 2173 key, and the prf function generates 160 bits, the AES key will come 2174 from T1 and the beginning of T2, while the HMAC key will come from 2175 the rest of T2 and the beginning of T3). 2177 The constant concatenated to the end of each prf function is a single 2178 octet. The prf+ function is not defined beyond 255 times the size of 2179 the prf function output. 2181 2.14. Generating Keying Material for the IKE SA 2183 The shared keys are computed as follows. A quantity called SKEYSEED 2184 is calculated from the nonces exchanged during the IKE_SA_INIT 2185 exchange and the Diffie-Hellman shared secret established during that 2186 exchange. SKEYSEED is used to calculate seven other secrets: SK_d 2187 used for deriving new keys for the Child SAs established with this 2188 IKE SA; SK_ai and SK_ar used as a key to the integrity protection 2189 algorithm for authenticating the component messages of subsequent 2190 exchanges; SK_ei and SK_er used for encrypting (and of course 2191 decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are 2192 used when generating an AUTH payload. The lengths of SK_d, SK_pi, 2193 and SK_pr MUST be the preferred key length of the agreed-to PRF. 2195 SKEYSEED and its derivatives are computed as follows: 2197 SKEYSEED = prf(Ni | Nr, g^ir) 2199 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } 2200 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) 2202 (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, 2203 SK_pi, and SK_pr are taken in order from the generated bits of the 2204 prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman 2205 exchange. g^ir is represented as a string of octets in big endian 2206 order padded with zeros if necessary to make it the length of the 2207 modulus. Ni and Nr are the nonces, stripped of any headers. For 2208 historical backwards-compatibility reasons, there are two PRFs that 2209 are treated specially in this calculation. If the negotiated PRF is 2210 AES-XCBC-PRF-128 [AESXCBCPRF128] or AES-CMAC-PRF-128 [AESCMACPRF128], 2211 only the first 64 bits of Ni and the first 64 bits of Nr are used in 2212 calculating SKEYSEED, but all the bits are used for input to the prf+ 2213 function. 2215 The two directions of traffic flow use different keys. The keys used 2216 to protect messages from the original initiator are SK_ai and SK_ei. 2217 The keys used to protect messages in the other direction are SK_ar 2218 and SK_er. 2220 2.15. Authentication of the IKE SA 2222 When not using extensible authentication (see Section 2.16), the 2223 peers are authenticated by having each sign (or MAC using a padded 2224 shared secret as the key, as described later in this section) a block 2225 of data. In these calculations, IDi' and IDr' are the entire ID 2226 payloads excluding the fixed header. For the responder, the octets 2227 to be signed start with the first octet of the first SPI in the 2228 header of the second message (IKE_SA_INIT response) and end with the 2229 last octet of the last payload in the second message. Appended to 2230 this (for purposes of computing the signature) are the initiator's 2231 nonce Ni (just the value, not the payload containing it), and the 2232 value prf(SK_pr, IDr'). Note that neither the nonce Ni nor the value 2233 prf(SK_pr, IDr') are transmitted. Similarly, the initiator signs the 2234 first message (IKE_SA_INIT request), starting with the first octet of 2235 the first SPI in the header and ending with the last octet of the 2236 last payload. Appended to this (for purposes of computing the 2237 signature) are the responder's nonce Nr, and the value prf(SK_pi, 2238 IDi'). It is critical to the security of the exchange that each side 2239 sign the other side's nonce. 2241 The initiator's signed octets can be described as: 2243 InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI 2244 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 2245 RealIKEHDR = SPIi | SPIr | . . . | Length 2246 RealMessage1 = RealIKEHDR | RestOfMessage1 2247 NonceRPayload = PayloadHeader | NonceRData 2248 InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload 2249 RestOfInitIDPayload = IDType | RESERVED | InitIDData 2250 MACedIDForI = prf(SK_pi, RestOfInitIDPayload) 2252 The responder's signed octets can be described as: 2254 ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR 2255 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 2256 RealIKEHDR = SPIi | SPIr | . . . | Length 2257 RealMessage2 = RealIKEHDR | RestOfMessage2 2258 NonceIPayload = PayloadHeader | NonceIData 2259 ResponderIDPayload = PayloadHeader | RestOfRespIDPayload 2260 RestOfRespIDPayload = IDType | RESERVED | RespIDData 2261 MACedIDForR = prf(SK_pr, RestOfRespIDPayload) 2263 Note that all of the payloads are included under the signature, 2264 including any payload types not defined in this document. If the 2265 first message of the exchange is sent multiple times (such as with a 2266 responder cookie and/or a different Diffie-Hellman group), it is the 2267 latest version of the message that is signed. 2269 Optionally, messages 3 and 4 MAY include a certificate, or 2270 certificate chain providing evidence that the key used to compute a 2271 digital signature belongs to the name in the ID payload. The 2272 signature or MAC will be computed using algorithms dictated by the 2273 type of key used by the signer, and specified by the Auth Method 2274 field in the Authentication payload. There is no requirement that 2275 the initiator and responder sign with the same cryptographic 2276 algorithms. The choice of cryptographic algorithms depends on the 2277 type of key each has. In particular, the initiator may be using a 2278 shared key while the responder may have a public signature key and 2279 certificate. It will commonly be the case (but it is not required) 2280 that if a shared secret is used for authentication that the same key 2281 is used in both directions. 2283 Note that it is a common but typically insecure practice to have a 2284 shared key derived solely from a user-chosen password without 2285 incorporating another source of randomness. This is typically 2286 insecure because user-chosen passwords are unlikely to have 2287 sufficient unpredictability to resist dictionary attacks and these 2288 attacks are not prevented in this authentication method. 2289 (Applications using password-based authentication for bootstrapping 2290 and IKE SA should use the authentication method in Section 2.16, 2291 which is designed to prevent off-line dictionary attacks.) The pre- 2292 shared key needs to contain as much unpredictability as the strongest 2293 key being negotiated. In the case of a pre-shared key, the AUTH 2294 value is computed as: 2296 For the initiator: 2297 AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), 2298 ) 2299 For the responder: 2300 AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), 2301 ) 2303 where the string "Key Pad for IKEv2" is 17 ASCII characters without 2304 null termination. The shared secret can be variable length. The pad 2305 string is added so that if the shared secret is derived from a 2306 password, the IKE implementation need not store the password in 2307 cleartext, but rather can store the value prf(Shared Secret,"Key Pad 2308 for IKEv2"), which could not be used as a password equivalent for 2309 protocols other than IKEv2. As noted above, deriving the shared 2310 secret from a password is not secure. This construction is used 2311 because it is anticipated that people will do it anyway. The 2312 management interface by which the Shared Secret is provided MUST 2313 accept ASCII strings of at least 64 octets and MUST NOT add a null 2314 terminator before using them as shared secrets. It MUST also accept 2315 a hex encoding of the Shared Secret. The management interface MAY 2316 accept other encodings if the algorithm for translating the encoding 2317 to a binary string is specified. 2319 There are two types of EAP authentication (described in 2320 Section 2.16), and each type uses different values in the AUTH 2321 computations shown above. If the EAP method is key-generating, 2322 substitute MSK for the Shared Secret in the computation. For non- 2323 key-generating methods, substitute SK_pi and SK_pr, respectively, for 2324 the Shared Secret in the two AUTH computations. 2326 2.16. Extensible Authentication Protocol Methods 2328 In addition to authentication using public key signatures and shared 2329 secrets, IKE supports authentication using methods defined in RFC 2330 3748 [EAP]. Typically, these methods are asymmetric (designed for a 2331 user authenticating to a server), and they may not be mutual. For 2332 this reason, these protocols are typically used to authenticate the 2333 initiator to the responder and MUST be used in conjunction with a 2334 public key signature based authentication of the responder to the 2335 initiator. These methods are often associated with mechanisms 2336 referred to as "Legacy Authentication" mechanisms. 2338 While this document references [EAP] with the intent that new methods 2339 can be added in the future without updating this specification, some 2340 simpler variations are documented here. [EAP] defines an 2341 authentication protocol requiring a variable number of messages. 2342 Extensible Authentication is implemented in IKE as additional 2343 IKE_AUTH exchanges that MUST be completed in order to initialize the 2344 IKE SA. 2346 An initiator indicates a desire to use extensible authentication by 2347 leaving out the AUTH payload from the first message in the IKE_AUTH 2348 exchange. (Note that the AUTH payload is required for non-EAP 2349 authentication, and is thus not marked as optional in the rest of 2350 this document.) By including an IDi payload but not an AUTH payload, 2351 the initiator has declared an identity but has not proven it. If the 2352 responder is willing to use an extensible authentication method, it 2353 will place an Extensible Authentication Protocol (EAP) payload in the 2354 response of the IKE_AUTH exchange and defer sending SAr2, TSi, and 2355 TSr until initiator authentication is complete in a subsequent 2356 IKE_AUTH exchange. In the case of a minimal extensible 2357 authentication, the initial SA establishment will appear as follows: 2359 Initiator Responder 2360 ------------------------------------------------------------------- 2361 HDR, SAi1, KEi, Ni --> 2362 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 2363 HDR, SK {IDi, [CERTREQ,] 2364 [IDr,] SAi2, 2365 TSi, TSr} --> 2366 <-- HDR, SK {IDr, [CERT,] AUTH, 2367 EAP } 2368 HDR, SK {EAP} --> 2369 <-- HDR, SK {EAP (success)} 2370 HDR, SK {AUTH} --> 2371 <-- HDR, SK {AUTH, SAr2, TSi, TSr } 2373 As described in Section 2.2, when EAP is used, each pair of IKE SA 2374 initial setup messages will have their message numbers incremented; 2375 the first pair of AUTH messages will have an ID of 1, the second will 2376 be 2, and so on. 2378 For EAP methods that create a shared key as a side effect of 2379 authentication, that shared key MUST be used by both the initiator 2380 and responder to generate AUTH payloads in messages 7 and 8 using the 2381 syntax for shared secrets specified in Section 2.15. The shared key 2382 from EAP is the field from the EAP specification named MSK. This 2383 shared key generated during an IKE exchange MUST NOT be used for any 2384 other purpose. 2386 EAP methods that do not establish a shared key SHOULD NOT be used, as 2387 they are subject to a number of man-in-the-middle attacks [EAPMITM] 2388 if these EAP methods are used in other protocols that do not use a 2389 server-authenticated tunnel. Please see the Security Considerations 2390 section for more details. If EAP methods that do not generate a 2391 shared key are used, the AUTH payloads in messages 7 and 8 MUST be 2392 generated using SK_pi and SK_pr, respectively. 2394 The initiator of an IKE SA using EAP needs to be capable of extending 2395 the initial protocol exchange to at least ten IKE_AUTH exchanges in 2396 the event the responder sends notification messages and/or retries 2397 the authentication prompt. Once the protocol exchange defined by the 2398 chosen EAP authentication method has successfully terminated, the 2399 responder MUST send an EAP payload containing the Success message. 2400 Similarly, if the authentication method has failed, the responder 2401 MUST send an EAP payload containing the Failure message. The 2402 responder MAY at any time terminate the IKE exchange by sending an 2403 EAP payload containing the Failure message. 2405 Following such an extended exchange, the EAP AUTH payloads MUST be 2406 included in the two messages following the one containing the EAP 2407 Success message. 2409 When the initiator authentication uses EAP, it is possible that the 2410 contents of the IDi payload is used only for AAA routing purposes and 2411 selecting which EAP method to use. This value may be different from 2412 the identity authenticated by the EAP method. It is important that 2413 policy lookups and access control decisions use the actual 2414 authenticated identity. Often the EAP server is implemented in a 2415 separate AAA server that communicates with the IKEv2 responder. In 2416 this case, the authenticated identity, if different from that in the 2417 IDi payload, has to be sent from the AAA server to the IKEv2 2418 responder. 2420 2.17. Generating Keying Material for Child SAs 2422 A single Child SA is created by the IKE_AUTH exchange, and additional 2423 Child SAs can optionally be created in CREATE_CHILD_SA exchanges. 2424 Keying material for them is generated as follows: 2426 KEYMAT = prf+(SK_d, Ni | Nr) 2428 Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this 2429 request is the first Child SA created or the fresh Ni and Nr from the 2430 CREATE_CHILD_SA exchange if this is a subsequent creation. 2432 For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman 2433 exchange, the keying material is defined as: 2435 KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) 2437 where g^ir (new) is the shared secret from the ephemeral Diffie- 2438 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 2439 octet string in big endian order padded with zeros in the high-order 2440 bits if necessary to make it the length of the modulus). 2442 A single CHILD_SA negotiation may result in multiple security 2443 associations. ESP and AH SAs exist in pairs (one in each direction), 2444 so two SAs are created in a single Child SA negotiation for them. 2445 Furthermore, Child SA negotiation may include some future IPsec 2446 protocol(s) in addition to, or instead of, ESP or AH (for example, 2447 ROHC_INTEG as described in [ROHCV2]). In any case, keying material 2448 for each child SA MUST be taken from the expanded KEYMAT using the 2449 following rules: 2451 o All keys for SAs carrying data from the initiator to the responder 2452 are taken before SAs going from the responder to the initiator. 2454 o If multiple IPsec protocols are negotiated, keying material for 2455 each Child SA is taken in the order in which the protocol headers 2456 will appear in the encapsulated packet. 2458 o If an IPsec protocol requires multiple keys, the order in which 2459 they are taken from the SA's keying material needs to be described 2460 in the protocol's specification. For ESP and AH, [IPSECARCH] 2461 defines the order, namely: the encryption key (if any) MUST be 2462 taken from the first bits and the integrity key (if any) MUST be 2463 taken from the remaining bits. 2465 Each cryptographic algorithm takes a fixed number of bits of keying 2466 material specified as part of the algorithm, or negotiated in SA 2467 payloads (see Section 2.13 for description of key lengths, and 2468 Section 3.3.5 for the definition of the Key Length transform 2469 attribute). 2471 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange 2473 The CREATE_CHILD_SA exchange can be used to rekey an existing IKE SA 2474 (see Section 1.3.2 and Section 2.8). New initiator and responder 2475 SPIs are supplied in the SPI fields in the Proposal structures inside 2476 the Security Association (SA) payloads (not the SPI fields in the IKE 2477 header). The TS payloads are omitted when rekeying an IKE SA. 2478 SKEYSEED for the new IKE SA is computed using SK_d from the existing 2479 IKE SA as follows: 2481 SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr) 2483 where g^ir (new) is the shared secret from the ephemeral Diffie- 2484 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 2485 octet string in big endian order padded with zeros if necessary to 2486 make it the length of the modulus) and Ni and Nr are the two nonces 2487 stripped of any headers. 2489 The old and new IKE SA may have selected a different PRF. Because 2490 the rekeying exchange belongs to the old IKE SA, it is the old IKE 2491 SA's PRF that is used to generate SKEYSEED. 2493 The main reason for rekeying the IKE SA is to ensure that the 2494 compromise of old keying material does not provide information about 2495 the current keys, or vice versa. Therefore, implementations MUST 2496 perform a new Diffie-Hellman exchange when rekeying the IKE SA. In 2497 other words, an initiator MUST NOT propose the value "NONE" for the 2498 Diffie-Hellman transform, and a responder MUST NOT accept such a 2499 proposal. This means that a successful exchange rekeying the IKE SA 2500 always includes the KEi/KEr payloads. 2502 The new IKE SA MUST reset its message counters to 0. 2504 SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as 2505 specified in Section 2.14, using SPIi, SPIr, Ni, and Nr from the new 2506 exchange, and using the new IKE SA's PRF. 2508 2.19. Requesting an Internal Address on a Remote Network 2510 Most commonly occurring in the endpoint-to-security-gateway scenario, 2511 an endpoint may need an IP address in the network protected by the 2512 security gateway and may need to have that address dynamically 2513 assigned. A request for such a temporary address can be included in 2514 any request to create a Child SA (including the implicit request in 2515 message 3) by including a CP payload. Note, however, it is usual to 2516 only assign one IP address during the IKE_AUTH exchange. That 2517 address persists at least until the deletion of the IKE SA. 2519 This function provides address allocation to an IPsec Remote Access 2520 Client (IRAC) trying to tunnel into a network protected by an IPsec 2521 Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an 2522 IKE SA and a Child SA, the IRAC MUST request the IRAS-controlled 2523 address (and optionally other information concerning the protected 2524 network) in the IKE_AUTH exchange. The IRAS may procure an address 2525 for the IRAC from any number of sources such as a DHCP/BOOTP server 2526 or its own address pool. 2528 Initiator Responder 2529 ------------------------------------------------------------------- 2530 HDR, SK {IDi, [CERT,] 2531 [CERTREQ,] [IDr,] AUTH, 2532 CP(CFG_REQUEST), SAi2, 2533 TSi, TSr} --> 2534 <-- HDR, SK {IDr, [CERT,] AUTH, 2535 CP(CFG_REPLY), SAr2, 2536 TSi, TSr} 2538 In all cases, the CP payload MUST be inserted before the SA payload. 2539 In variations of the protocol where there are multiple IKE_AUTH 2540 exchanges, the CP payloads MUST be inserted in the messages 2541 containing the SA payloads. 2543 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute 2544 (either IPv4 or IPv6) but MAY contain any number of additional 2545 attributes the initiator wants returned in the response. 2547 For example, message from initiator to responder: 2549 CP(CFG_REQUEST)= 2550 INTERNAL_ADDRESS() 2551 TSi = (0, 0-65535,0.0.0.0-255.255.255.255) 2552 TSr = (0, 0-65535,0.0.0.0-255.255.255.255) 2554 NOTE: Traffic selectors contain (protocol, port range, address 2555 range). 2557 Message from responder to initiator: 2559 CP(CFG_REPLY)= 2560 INTERNAL_ADDRESS(192.0.2.202) 2561 INTERNAL_NETMASK(255.255.255.0) 2562 INTERNAL_SUBNET(192.0.2.0/255.255.255.0) 2563 TSi = (0, 0-65535,192.0.2.202-192.0.2.202) 2564 TSr = (0, 0-65535,192.0.2.0-192.0.2.255) 2566 All returned values will be implementation dependent. As can be seen 2567 in the above example, the IRAS MAY also send other attributes that 2568 were not included in CP(CFG_REQUEST) and MAY ignore the non- 2569 mandatory attributes that it does not support. 2571 The responder MUST NOT send a CFG_REPLY without having first received 2572 a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS 2573 to perform an unnecessary configuration lookup if the IRAC cannot 2574 process the REPLY. 2576 In the case where the IRAS's configuration requires that CP be used 2577 for a given identity IDi, but IRAC has failed to send a 2578 CP(CFG_REQUEST), IRAS MUST fail the request, and terminate the Child 2579 SA creation with a FAILED_CP_REQUIRED error. The FAILED_CP_REQUIRED 2580 is not fatal to the IKE SA; it simply causes the Child SA creation to 2581 fail. The initiator can fix this by later starting a new 2582 configuration payload request. There is no associated data in the 2583 FAILED_CP_REQUIRED error. 2585 2.20. Requesting the Peer's Version 2587 An IKE peer wishing to inquire about the other peer's IKE software 2588 version information MAY use the method below. This is an example of 2589 a configuration request within an INFORMATIONAL exchange, after the 2590 IKE SA and first Child SA have been created. 2592 An IKE implementation MAY decline to give out version information 2593 prior to authentication or even after authentication in case some 2594 implementation is known to have some security weakness. In that 2595 case, it MUST either return an empty string or no CP payload if CP is 2596 not supported. 2598 Initiator Responder 2599 ------------------------------------------------------------------- 2600 HDR, SK{CP(CFG_REQUEST)} --> 2601 <-- HDR, SK{CP(CFG_REPLY)} 2603 CP(CFG_REQUEST)= 2604 APPLICATION_VERSION("") 2606 CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar 2607 Inc.") 2609 2.21. Error Handling 2611 There are many kinds of errors that can occur during IKE processing. 2612 The general rule is that if a request is received that is badly 2613 formatted, or unacceptable for reasons of policy (such as no matching 2614 cryptographic algorithms), the response contains a Notify payload 2615 indicating the error. The decision whether or not to send such a 2616 response depends whether or not there is an authenticated IKE SA. 2618 If there is an error parsing or processing a response packet, the 2619 general rule is to not send back any error message because responses 2620 should not generate new requests (and a new request would be the only 2621 way to send back an error message). Such errors in parsing or 2622 processing response packets should still cause the recipient to clean 2623 up the IKE state (for example, by sending a DELETE for a bad SA). 2625 Only authentication failures (AUTHENTICATION_FAILED and EAP failure) 2626 and malformed messages (INVALID_SYNTAX) lead to a deletion of the IKE 2627 SA without requiring an explicit INFORMATIONAL exchange carrying a 2628 DELETE payload. Other error conditions MAY require such an exchange 2629 if policy dictates that this is needed. If the exchange is 2630 terminated with EAP Failure, an AUTHENTICATION_FAILED notification is 2631 not sent. 2633 2.21.1. Error Handling in IKE_SA_INIT 2635 Errors that occur before a cryptographically protected IKE SA is 2636 established need to be handled very carefully. There is a trade-off 2637 between wanting to help the peer to diagnose a problem and thus 2638 responding to the error, and wanting to avoid being part of a DoS 2639 attack based on forged messages. 2641 In an IKE_SA_INIT exchange, any error notification causes the 2642 exchange to fail. Note that some error notifications such as COOKIE, 2643 INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent 2644 successful exchange. Because all error notifications are completely 2645 unauthenticated, the recipient should continue trying for some time 2646 before giving up. The recipient should not immediately act based on 2647 the error notification unless corrective actions are defined in this 2648 specification, such as for COOKIE, INVALID_KE_PAYLOAD, and 2649 INVALID_MAJOR_VERSION. 2651 2.21.2. Error Handling in IKE_AUTH 2653 All errors that occur in an IKE_AUTH exchange, causing the 2654 authentication to fail for whatever reason (invalid shared secret, 2655 invalid ID, untrusted certificate issuer, revoked or expired 2656 certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED 2657 notification. If the error occurred on the responder, the 2658 notification is returned in the protected response, and is usually 2659 the only payload in that response. Although the IKE_AUTH messages 2660 are encrypted and integrity protected, if the peer receiving this 2661 notification has not authenticated the other end yet, that peer needs 2662 to treat the information with caution. 2664 If the error occurs on the initiator, the notification MAY be 2665 returned in a separate INFORMATIONAL exchange, usually with no other 2666 payloads. This is an exception for the general rule of not starting 2667 new exchanges based on errors in responses. 2669 Note, however, that request messages that contain an unsupported 2670 critical payload, or where the whole message is malformed (rather 2671 than just bad payload contents), MUST be rejected in their entirety, 2672 and MUST only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or 2673 INVALID_SYNTAX Notification sent as a response. The receiver should 2674 not verify the payloads related to authentication in this case. 2676 If authentication has succeeded in the IKE_AUTH exchange, the IKE SA 2677 is established; however, establishing the Child SA or requesting 2678 configuration information may still fail. This failure does not 2679 automatically cause the IKE SA to be deleted. Specifically, a 2680 responder may include all the payloads associated with authentication 2681 (IDr, Cert and AUTH) while sending error notifications for the 2682 piggybacked exchanges (FAILED_CP_REQUIRED, NO_PROPOSAL_CHOSEN, and so 2683 on), and the initiator MUST NOT fail the authentication because of 2684 this. The initiator MAY, of course, for reasons of policy later 2685 delete such an IKE SA. 2687 In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately 2688 following it (in case an error happened when processing a response to 2689 IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and 2690 AUTHENTICATION_FAILED notifications are the only ones to cause the 2691 IKE SA to be deleted or not created, without a DELETE payload. 2692 Extension documents may define new error notifications with these 2693 semantics, but MUST NOT use them unless the peer has been shown to 2694 understand them using the Vendor ID payload. 2696 2.21.3. Error Handling after IKE SA is Authenticated 2698 After the IKE SA is authenticated all requests having errors MUST 2699 result in a response notifying about the error. 2701 In normal situations, there should not be cases where a valid 2702 response from one peer results in an error situation in the other 2703 peer, so there should not be any reason for a peer to send error 2704 messages to the other end except as a response. Because sending such 2705 error messages as an INFORMATIONAL exchange might lead to further 2706 errors that could cause loops, such errors SHOULD NOT be sent. If 2707 errors are seen that indicate that the peers do not have the same 2708 state, it might be good to delete the IKE SA to clean up state and 2709 start over. 2711 If a peer parsing a request notices that it is badly formatted (after 2712 it has passed the message authentication code checks and window 2713 checks) and it returns an INVALID_SYNTAX notification, then this 2714 error notification is considered fatal in both peers, meaning that 2715 the IKE SA is deleted without needing an explicit DELETE payload. 2717 2.21.4. Error Handling Outside IKE SA 2719 A node needs to limit the rate at which it will send messages in 2720 response to unprotected messages. 2722 If a node receives a message on UDP port 500 or 4500 outside the 2723 context of an IKE SA known to it (and the message is not a request to 2724 start an IKE SA), this may be the result of a recent crash of the 2725 node. If the message is marked as a response, the node can audit the 2726 suspicious event but MUST NOT respond. If the message is marked as a 2727 request, the node can audit the suspicious event and MAY send a 2728 response. If a response is sent, the response MUST be sent to the IP 2729 address and port from where it came with the same IKE SPIs and the 2730 Message ID copied. The response MUST NOT be cryptographically 2731 protected and MUST contain an INVALID_IKE_SPI Notify payload. The 2732 INVALID_IKE_SPI notification indicates an IKE message was received 2733 with an unrecognized destination SPI; this usually indicates that the 2734 recipient has rebooted and forgotten the existence of an IKE SA. 2736 A peer receiving such an unprotected Notify payload MUST NOT respond 2737 and MUST NOT change the state of any existing SAs. The message might 2738 be a forgery or might be a response that a genuine correspondent was 2739 tricked into sending. A node should treat such a message (and also a 2740 network message like ICMP destination unreachable) as a hint that 2741 there might be problems with SAs to that IP address and should 2742 initiate a liveness check for any such IKE SA. An implementation 2743 SHOULD limit the frequency of such tests to avoid being tricked into 2744 participating in a DoS attack. 2746 If an error occurs outside the context of an IKE request (e.g., the 2747 node is getting ESP messages on a nonexistent SPI), the node SHOULD 2748 initiate an INFORMATIONAL exchange with a Notify payload describing 2749 the problem. 2751 A node receiving a suspicious message from an IP address (and port, 2752 if NAT traversal is used) with which it has an IKE SA SHOULD send an 2753 IKE Notify payload in an IKE INFORMATIONAL exchange over that SA. 2754 The recipient MUST NOT change the state of any SAs as a result, but 2755 may wish to audit the event to aid in diagnosing malfunctions. 2757 2.22. IPComp 2759 Use of IP compression [IP-COMP] can be negotiated as part of the 2760 setup of a Child SA. While IP compression involves an extra header 2761 in each packet and a compression parameter index (CPI), the virtual 2762 "compression association" has no life outside the ESP or AH SA that 2763 contains it. Compression associations disappear when the 2764 corresponding ESP or AH SA goes away. It is not explicitly mentioned 2765 in any DELETE payload. 2767 Negotiation of IP compression is separate from the negotiation of 2768 cryptographic parameters associated with a Child SA. A node 2769 requesting a Child SA MAY advertise its support for one or more 2770 compression algorithms through one or more Notify payloads of type 2771 IPCOMP_SUPPORTED. This Notify message may be included only in a 2772 message containing an SA payload negotiating a Child SA and indicates 2773 a willingness by its sender to use IPComp on this SA. The response 2774 MAY indicate acceptance of a single compression algorithm with a 2775 Notify payload of type IPCOMP_SUPPORTED. These payloads MUST NOT 2776 occur in messages that do not contain SA payloads. 2778 The data associated with this Notify message includes a two-octet 2779 IPComp CPI followed by a one-octet transform ID optionally followed 2780 by attributes whose length and format are defined by that transform 2781 ID. A message proposing an SA may contain multiple IPCOMP_SUPPORTED 2782 notifications to indicate multiple supported algorithms. A message 2783 accepting an SA may contain at most one. 2785 The transform IDs are listed here. The values in the following table 2786 are only current as of the publication date of RFC 4306. Other 2787 values may have been added since then or will be added after the 2788 publication of this document. Readers should refer to [IKEV2IANA] 2789 for the latest values. 2791 Name Number Defined In 2792 ------------------------------------- 2793 IPCOMP_OUI 1 2794 IPCOMP_DEFLATE 2 RFC 2394 2795 IPCOMP_LZS 3 RFC 2395 2796 IPCOMP_LZJH 4 RFC 3051 2798 Although there has been discussion of allowing multiple compression 2799 algorithms to be accepted and to have different compression 2800 algorithms available for the two directions of a Child SA, 2801 implementations of this specification MUST NOT accept an IPComp 2802 algorithm that was not proposed, MUST NOT accept more than one, and 2803 MUST NOT compress using an algorithm other than one proposed and 2804 accepted in the setup of the Child SA. 2806 A side effect of separating the negotiation of IPComp from 2807 cryptographic parameters is that it is not possible to propose 2808 multiple cryptographic suites and propose IP compression with some of 2809 them but not others. 2811 In some cases, Robust Header Compression (ROHC) may be more 2812 appropriate than IP Compression. [ROHCV2] defines the use of ROHC 2813 with IKEv2 and IPsec. 2815 2.23. NAT Traversal 2817 Network Address Translation (NAT) gateways are a controversial 2818 subject. This section briefly describes what they are and how they 2819 are likely to act on IKE traffic. Many people believe that NATs are 2820 evil and that we should not design our protocols so as to make them 2821 work better. IKEv2 does specify some unintuitive processing rules in 2822 order that NATs are more likely to work. 2824 NATs exist primarily because of the shortage of IPv4 addresses, 2825 though there are other rationales. IP nodes that are "behind" a NAT 2826 have IP addresses that are not globally unique, but rather are 2827 assigned from some space that is unique within the network behind the 2828 NAT but that are likely to be reused by nodes behind other NATs. 2829 Generally, nodes behind NATs can communicate with other nodes behind 2830 the same NAT and with nodes with globally unique addresses, but not 2831 with nodes behind other NATs. There are exceptions to that rule. 2832 When those nodes make connections to nodes on the real Internet, the 2833 NAT gateway "translates" the IP source address to an address that 2834 will be routed back to the gateway. Messages to the gateway from the 2835 Internet have their destination addresses "translated" to the 2836 internal address that will route the packet to the correct endnode. 2838 NATs are designed to be "transparent" to endnodes. Neither software 2839 on the node behind the NAT nor the node on the Internet requires 2840 modification to communicate through the NAT. Achieving this 2841 transparency is more difficult with some protocols than with others. 2842 Protocols that include IP addresses of the endpoints within the 2843 payloads of the packet will fail unless the NAT gateway understands 2844 the protocol and modifies the internal references as well as those in 2845 the headers. Such knowledge is inherently unreliable, is a network 2846 layer violation, and often results in subtle problems. 2848 Opening an IPsec connection through a NAT introduces special 2849 problems. If the connection runs in transport mode, changing the IP 2850 addresses on packets will cause the checksums to fail and the NAT 2851 cannot correct the checksums because they are cryptographically 2852 protected. Even in tunnel mode, there are routing problems because 2853 transparently translating the addresses of AH and ESP packets 2854 requires special logic in the NAT and that logic is heuristic and 2855 unreliable in nature. For that reason, IKEv2 will use UDP 2856 encapsulation of IKE and ESP packets. This encoding is slightly less 2857 efficient but is easier for NATs to process. In addition, firewalls 2858 may be configured to pass UDP-encapsulated IPsec traffic but not 2859 plain, unencapsulated ESP/AH or vice versa. 2861 It is a common practice of NATs to translate TCP and UDP port numbers 2862 as well as addresses and use the port numbers of inbound packets to 2863 decide which internal node should get a given packet. For this 2864 reason, even though IKE packets MUST be sent from and to UDP port 500 2865 or 4500, they MUST be accepted coming from any port and responses 2866 MUST be sent to the port from whence they came. This is because the 2867 ports may be modified as the packets pass through NATs. Similarly, 2868 IP addresses of the IKE endpoints are generally not included in the 2869 IKE payloads because the payloads are cryptographically protected and 2870 could not be transparently modified by NATs. 2872 Port 4500 is reserved for UDP-encapsulated ESP and IKE. An IPsec 2873 endpoint that discovers a NAT between it and its correspondent (as 2874 described below) MUST send all subsequent traffic from port 4500, 2875 which NATs should not treat specially (as they might with port 500). 2877 An initiator can use port 4500 for both IKE and ESP, regardless of 2878 whether or not there is a NAT, even at the beginning of IKE. When 2879 either side is using port 4500, sending ESP with UDP encapsulation is 2880 not required, but understanding received UDP encapsulated ESP packets 2881 is required. If NAT-T is supported (that is, if NAT_DETECTION_*_IP 2882 payloads were exchanged during IKE_SA_INIT), all devices MUST be able 2883 to receive and process both UDP encapsulated ESP and non-UDP 2884 encapsulated ESP packets at any time. Either side can decide whether 2885 or not to use UDP encapsulation for ESP irrespective of the choice 2886 made by the other side. However, if a NAT is detected, both devices 2887 MUST use UDP encapsulation for ESP. 2889 The specific requirements for supporting NAT traversal [NATREQ] are 2890 listed below. Support for NAT traversal is optional. In this 2891 section only, requirements listed as MUST apply only to 2892 implementations supporting NAT traversal. 2894 o Both IKE initiator and responder MUST include in their IKE_SA_INIT 2895 packets Notify payloads of type NAT_DETECTION_SOURCE_IP and 2896 NAT_DETECTION_DESTINATION_IP. Those payloads can be used to 2897 detect if there is NAT between the hosts, and which end is behind 2898 the NAT. The location of the payloads in the IKE_SA_INIT packets 2899 is just after the Ni and Nr payloads (before the optional CERTREQ 2900 payload). 2902 o The data associated with the NAT_DETECTION_SOURCE_IP notification 2903 is a SHA-1 digest of the SPIs (in the order they appear in the 2904 header), IP address, and port from which this packet was sent. 2905 There MAY be multiple NAT_DETECTION_SOURCE_IP payloads in a 2906 message if the sender does not know which of several network 2907 attachments will be used to send the packet. 2909 o The data associated with the NAT_DETECTION_DESTINATION_IP 2910 notification is a SHA-1 digest of the SPIs (in the order they 2911 appear in the header), IP address, and port to which this packet 2912 was sent. 2914 o The recipient of either the NAT_DETECTION_SOURCE_IP or 2915 NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied 2916 value to a SHA-1 hash of the SPIs, source or recipient IP address 2917 (respectively), address, and port, and if they don't match it 2918 SHOULD enable NAT traversal. In the case there is a mismatch of 2919 the NAT_DETECTION_SOURCE_IP hash with all of the 2920 NAT_DETECTION_SOURCE_IP payloads received, the recipient MAY 2921 reject the connection attempt if NAT traversal is not supported. 2922 In the case of a mismatching NAT_DETECTION_DESTINATION_IP hash, it 2923 means that the system receiving the NAT_DETECTION_DESTINATION_IP 2924 payload is behind a NAT and that system SHOULD start sending 2925 keepalive packets as defined in [UDPENCAPS]; alternately, it MAY 2926 reject the connection attempt if NAT traversal is not supported. 2928 o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches 2929 the expected value of the source IP and port found from the IP 2930 header of the packet containing the payload, it means that the 2931 system sending those payloads is behind NAT (i.e., someone along 2932 the route changed the source address of the original packet to 2933 match the address of the NAT box). In this case, the system 2934 receiving the payloads should allow dynamic update of the other 2935 systems' IP address, as described later. 2937 o The IKE initiator MUST check the NAT_DETECTION_SOURCE_IP or 2938 NAT_DETECTION_DESTINATION_IP payloads if present and if they do 2939 not match the addresses in the outer packet MUST tunnel all future 2940 IKE and ESP packets associated with this IKE SA over UDP port 2941 4500. 2943 o To tunnel IKE packets over UDP port 4500, the IKE header has four 2944 octets of zero prepended and the result immediately follows the 2945 UDP header. To tunnel ESP packets over UDP port 4500, the ESP 2946 header immediately follows the UDP header. Since the first four 2947 octets of the ESP header contain the SPI, and the SPI cannot 2948 validly be zero, it is always possible to distinguish ESP and IKE 2949 messages. 2951 o Implementations MUST process received UDP-encapsulated ESP packets 2952 even when no NAT was detected. 2954 o The original source and destination IP address required for the 2955 transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) 2956 are obtained from the traffic selectors associated with the 2957 exchange. In the case of transport mode NAT traversal, the 2958 traffic selectors MUST contain exactly one IP address, which is 2959 then used as the original IP address. This is covered in greater 2960 detail in Section 2.23.1. 2962 o There are cases where a NAT box decides to remove mappings that 2963 are still alive (for example, the keepalive interval is too long, 2964 or the NAT box is rebooted). This will be apparent to a host if 2965 it receives a packet whose integrity protection validates, but has 2966 a different port, address, or both from the one that was 2967 associated with the SA in the validated packet. When such a 2968 validated packet is found, a host that does not support other 2969 methods of recovery such as MOBIKE [MOBIKE], and that is not 2970 behind a NAT, SHOULD send all packets (including retransmission 2971 packets) to the IP address and port in the validated packet, and 2972 SHOULD store this as the new address and port combination for the 2973 SA (that is, they SHOULD dynamically update the address). A host 2974 behind a NAT SHOULD NOT do this type of dynamic address update if 2975 a validated packet has different port and/or address values 2976 because it opens a possible DoS attack (such as allowing an 2977 attacker to break the connection with a single packet). Also, 2978 dynamic address update should only be done in response to a new 2979 packet; otherwise, an attacker can revert the addresses with old 2980 replayed packets. Because of this, dynamic update can only be 2981 done safely if replay protection is enabled. When IKEv2 is used 2982 with MOBIKE, dynamically updating the addresses described above 2983 interferes with MOBIKE's way of recovering from the same 2984 situation. See Section 3.8 of [MOBIKE] for more information. 2986 2.23.1. Transport Mode NAT Traversal 2988 Transport mode used with NAT Traversal requires special handling of 2989 the traffic selectors used in the IKEv2. The complete scenario looks 2990 like: 2992 +------+ +------+ +------+ +------+ 2993 |Client| IP1 | NAT | IPN1 IPN2 | NAT | IP2 |Server| 2994 |node |<------>| A |<---------->| B |<------->| | 2995 +------+ +------+ +------+ +------+ 2997 (Other scenarios are simplifications of this complex case, so this 2998 discussion uses the complete scenario.) 3000 In this scenario, there are two address translating NATs: NAT A and 3001 NAT B. NAT A is dynamic NAT that maps the clients source address IP1 3002 to IPN1. NAT B is static NAT configured so that connections coming 3003 to IPN2 address are mapped to the gateways address IP2, that is, IPN2 3004 destination address is mapped to IP2. This allows the client to 3005 connect to a server by connecting to the IPN2. NAT B does not 3006 necessarily need to be a static NAT, but the client needs to know how 3007 to connect to the server, and it can only do that if it somehow knows 3008 the outer address of the NAT B, that is, the IPN2 address. If NAT B 3009 is a static NAT, then its address can be configured to the client's 3010 configuration. Other options would be find it using some other 3011 protocol (like DNS), but those are outside of scope of IKEv2. 3013 In this scenario, both client and server are configured to use 3014 transport mode for the traffic originating from the client node and 3015 destined to the server. 3017 When the client starts creating the IKEv2 SA and Child SA for sending 3018 traffic to the server, it may have a triggering packet with source IP 3019 address of IP1, and a destination IP address of IPN2. Its PAD and 3020 SPD needs to have configuration matching those addresses (or wildcard 3021 entries covering them). Because this is transport mode, it uses 3022 exactly same addresses as the traffic selectors and outer IP address 3023 of the IKE packets. For transport mode, it MUST use exactly one IP 3024 address in the TSi and TSr payloads. It can have multiple traffic 3025 selectors if it has, for example, multiple port ranges that it wants 3026 to negotiate, but all TSi entries must use IP1-IP1 range as the IP 3027 addresses, and all TSr entries must have the IPN2-IPN2 range as IP 3028 addresses. The first traffic selector of TSi and TSr SHOULD have 3029 very specific traffic selectors including protocol and port numbers, 3030 such as from the packet triggering the request. 3032 NAT A will then replace the source address of the IKE packet from IP1 3033 to IPN1, and NAT B will replace the destination address of the IKE 3034 packet from IPN2 to IP2, so when the packet arrives to the server it 3035 will still have the exactly same traffic selectors which were sent by 3036 the client, but the IP address of the IKE packet has been replaced to 3037 IPN1 and IP2. 3039 When the server receives this packet, it normally looks in the Peer 3040 Authorization Database (PAD) described in RFC 4301 [IPSECARCH] based 3041 on the ID and then searches the SPD based on the traffic selectors. 3042 Because IP1 does not really mean anything to the server (it is the 3043 address client has behind the NAT), it is useless to do a lookup 3044 based on that if transport mode is used. On the other hand, the 3045 server cannot know whether transport mode is allowed by its policy 3046 before it finds the matching SPD entry. 3048 In this case, the server should first check that the initiator 3049 requested transport mode, and then do address substitution on the 3050 traffic selectors. It needs to first store the old traffic selector 3051 IP addresses to be used later for the incremental checksum fixup (the 3052 IP address in the TSi can be stored as the original source address 3053 and the IP address in the TSr can be stored as the original 3054 destination address). After that, if the other end was detected as 3055 being behind a NAT, the server replaces the IP address in TSi 3056 payloads with the IP address obtained from the source address of the 3057 IKE packet received (that is, it replaces IP1 in TSi with IPN1). If 3058 the server's end was detected to be behind NAT, it replaces the IP 3059 address in the TSr payloads with the IP address obtained from the 3060 destination address of the IKE packet received (that is, it replaces 3061 IPN2 in TSr with IP2). 3063 After this address substitution, both the traffic selectors and the 3064 IKE UDP source/destination addresses look the same, and the server 3065 does SPD lookup based on those new traffic selectors. If an entry is 3066 found and it allows transport mode, then that entry is used. If an 3067 entry is found but it does not allow transport mode, then the server 3068 MAY undo the address substitution and redo the SPD lookup using the 3069 original traffic selectors. If the second lookup succeeds, the 3070 server will create an SA in tunnel mode using real traffic selectors 3071 sent by the other end. 3073 This address substitution in transport mode is needed because the SPD 3074 is looked up using the addresses that will be seen by the local host. 3075 This also will make sure the SAD entries for the tunnel exit checks 3076 and return packets is added using the addresses as seen by the local 3077 operating system stack. 3079 The most common case is that the server's SPD will contain wildcard 3080 entries matching any addresses, but this allows also making different 3081 SPD entries, for example, for different known NAT's outer addresses. 3083 After the SPD lookup, the server will do traffic selector narrowing 3084 based on the SPD entry it found. It will again use the already- 3085 substituted traffic selectors, and it will thus send back traffic 3086 selectors having IPN1 and IP2 as their IP addresses; it can still 3087 narrow down the protocol number or port ranges used by the traffic 3088 selectors. The SAD entry created for the Child SA will have the 3089 addresses as seen by the server, namely IPN1 and IP2. 3091 When the client receives the server's response to the Child SA, it 3092 will do similar processing. If the transport mode SA was created, 3093 the client can store the original returned traffic selectors as 3094 original source and destination addresses. It will replace the IP 3095 addresses in the traffic selectors with the ones from the IP header 3096 of the IKE packet: it will replace IPN1 with IP1 and IP2 with IPN2. 3097 Then it will use those traffic selectors when verifying the SA 3098 against sent traffic selectors, and when installing the SAD entry. 3100 A summary of the rules for NAT-traversal in transport mode is: 3102 For the client proposing transport mode: 3104 - The TSi entries MUST have exactly one IP address, and that MUST 3105 match the source address of the IKE SA. 3107 - The TSr entries MUST have exactly one IP address, and that MUST 3108 match the destination address of the IKE SA. 3110 - The first TSi and TSr traffic selectors SHOULD have very specific 3111 traffic selectors including protocol and port numbers, such as 3112 from the packet triggering the request. 3114 - There MAY be multiple TSi and TSr entries. 3116 - If transport mode for the SA was selected (that is, if the server 3117 included USE_TRANSPORT_MODE notification in its response): 3119 - Store the original traffic selectors as the received source and 3120 destination address. 3122 - If the server is behind a NAT, substitute the IP address in the 3123 TSr entries with the remote address of the IKE SA. 3125 - If the client is behind a NAT, substitute the IP address in the 3126 TSi entries with the local address of the IKE SA. 3128 - Do address substitution before using those traffic selectors 3129 for anything else other than storing original content of them. 3130 This includes verification that traffic selectors were narrowed 3131 correctly by other end, creation of the SAD entry, and so on. 3133 For the responder, when transport mode is proposed by client: 3135 - Store the original traffic selector IP addresses as received source 3136 and destination address, both in case we need to undo address 3137 substitution, and to use as the "real source and destination 3138 address" specified by [UDPENCAPS], and for TCP/UDP checksum fixup. 3140 - If the client is behind a NAT, substitute the IP address in the 3141 TSi entries with the remote address of the IKE SA. 3143 - If the server is behind a NAT substitute the IP address in the 3144 TSr entries with the local address of the IKE SA. 3146 - Do PAD and SPD lookup using the ID and substituted traffic 3147 selectors. 3149 - If no SPD entry was found, or if found SPD entry does not 3150 allow transport mode, undo the traffic selector substitutions. 3151 Do PAD and SPD lookup again using the ID and original traffic 3152 selectors, but also searching for tunnel mode SPD entry (that 3153 is, fall back to tunnel mode). 3155 - However, if a transport mode SPD entry was found, do normal 3156 traffic selection narrowing based on the substituted traffic 3157 selectors and SPD entry. Use the resulting traffic selectors when 3158 creating SAD entries, and when sending traffic selectors back to 3159 the client. 3161 2.24. Explicit Congestion Notification (ECN) 3163 When IPsec tunnels behave as originally specified in [IPSECARCH-OLD], 3164 ECN usage is not appropriate for the outer IP headers because tunnel 3165 decapsulation processing discards ECN congestion indications to the 3166 detriment of the network. ECN support for IPsec tunnels for IKEv1- 3167 based IPsec requires multiple operating modes and negotiation (see 3168 [ECN]). IKEv2 simplifies this situation by requiring that ECN be 3169 usable in the outer IP headers of all tunnel-mode Child SAs created 3170 by IKEv2. Specifically, tunnel encapsulators and decapsulators for 3171 all tunnel-mode SAs created by IKEv2 MUST support the ECN full- 3172 functionality option for tunnels specified in [ECN] and MUST 3173 implement the tunnel encapsulation and decapsulation processing 3174 specified in [IPSECARCH] to prevent discarding of ECN congestion 3175 indications. 3177 2.25. Exchange Collisions 3179 Because IKEv2 exchanges can be initiated by either peer, it is 3180 possible that two exchanges affecting the same SA partly overlap. 3181 This can lead to a situation where the SA state information is 3182 temporarily not synchronized, and a peer can receive a request that 3183 it cannot process in a normal fashion. 3185 Obviously, using a window size greater than 1 leads to more complex 3186 situations, especially if requests are processed out of order. This 3187 section concentrates on problems that can arise even with a window 3188 size of 1, and recommends solutions. 3190 A TEMPORARY_FAILURE notification SHOULD be sent when a peer receives 3191 a request that cannot be completed due to a temporary condition such 3192 as a rekeying operation. When a peer receives a TEMPORARY_FAILURE 3193 notification, it MUST NOT immediately retry the operation; it MUST 3194 wait so that the sender may complete whatever operation caused the 3195 temporary condition. The recipient MAY retry the request one or more 3196 times over a period of several minutes. If a peer continues to 3197 receive TEMPORARY_FAILURE on the same IKE SA after several minutes, 3198 it SHOULD conclude that the state information is out-of-sync and 3199 close the IKE SA. 3201 A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives 3202 a request to rekey a Child SA that does not exist. The SA that the 3203 initiator attempted to rekey is indicated by the SPI field in the 3204 Notify Payload, which is copied from the SPI field in the REYEY_SA 3205 notification. A peer that receives a CHILD_SA_NOT_FOUND notification 3206 SHOULD silently delete the Child SA (if it still exists) and send a 3207 request to create a new Child SA from scratch (if the Child SA does 3208 not yet exist). 3210 2.25.1. Collisions While Rekeying or Closing Child SAs 3212 If a peer receives a request to rekey a Child SA that it is currently 3213 trying to close, it SHOULD reply with TEMPORARY_FAILURE. If a peer 3214 receives a request to rekey a Child SA that it is currently rekeying, 3215 it SHOULD reply as usual, and SHOULD prepare to close redundant SAs 3216 later based on the nonces (see Section 2.8.1). If a peer receives a 3217 request to rekey a Child SA that does not exist, it SHOULD reply with 3218 CHILD_SA_NOT_FOUND. 3220 If a peer receives a request to close a Child SA that it is currently 3221 trying to close, it SHOULD reply without Delete payloads (see 3222 Section 1.4.1). If a peer receives a request to close a Child SA 3223 that it is currently rekeying, it SHOULD reply as usual, with a 3224 Delete payload. If a peer receives a request to close a Child SA 3225 that does not exist, it SHOULD reply without Delete payloads. 3227 If a peer receives a request to rekey the IKE SA, and it is currently 3228 creating, rekeying, or closing a Child SA of that IKE SA, it SHOULD 3229 reply with TEMPORARY_FAILURE. 3231 2.25.2. Collisions While Rekeying or Closing IKE SAs 3233 If a peer receives a request to rekey an IKE SA that it is currently 3234 rekeying, it SHOULD reply as usual, and SHOULD prepare to close 3235 redundant SAs and move inherited Child SAs later based on the nonces 3236 (see Section 2.8.2). If a peer receives a request to rekey an IKE SA 3237 that it is currently trying to close, it SHOULD reply with 3238 TEMPORARY_FAILURE. 3240 If a peer receives a request to close an IKE SA that it is currently 3241 rekeying, it SHOULD reply as usual, and forget about its own rekeying 3242 request. If a peer receives a request to close an IKE SA that it is 3243 currently trying to close, it SHOULD reply as usual, and forget about 3244 its own close request. 3246 If a peer receives a request to create or rekey a Child SA when it is 3247 currently rekeying the IKE SA, it SHOULD reply with 3248 TEMPORARY_FAILURE. If a peer receives a request to delete a Child SA 3249 when it is currently rekeying the IKE SA, it SHOULD reply as usual, 3250 with a Delete payload. 3252 3. Header and Payload Formats 3254 In the tables in this section, some cryptographic primitives and 3255 configuration attributes are marked as "UNSPECIFIED". These are 3256 items for which there are no known specifications and therefore 3257 interoperability is currently impossible. A future specification may 3258 describe their use, but until such specification is made, 3259 implementations SHOULD NOT attempt to use items marked as 3260 "UNSPECIFIED" in implementations that are meant to be interoperable. 3262 3.1. The IKE Header 3264 IKE messages use UDP ports 500 and/or 4500, with one IKE message per 3265 UDP datagram. Information from the beginning of the packet through 3266 the UDP header is largely ignored except that the IP addresses and 3267 UDP ports from the headers are reversed and used for return packets. 3268 When sent on UDP port 500, IKE messages begin immediately following 3269 the UDP header. When sent on UDP port 4500, IKE messages have 3270 prepended four octets of zero. These four octets of zero are not 3271 part of the IKE message and are not included in any of the length 3272 fields or checksums defined by IKE. Each IKE message begins with the 3273 IKE header, denoted HDR in this document. Following the header are 3274 one or more IKE payloads each identified by a "Next Payload" field in 3275 the preceding payload. Payloads are identified in the order in which 3276 they appear in an IKE message by looking in the "Next Payload" field 3277 in the IKE header, and subsequently according to the "Next Payload" 3278 field in the IKE payload itself until a "Next Payload" field of zero 3279 indicates that no payloads follow. If a payload of type "Encrypted" 3280 is found, that payload is decrypted and its contents parsed as 3281 additional payloads. An Encrypted payload MUST be the last payload 3282 in a packet and an Encrypted payload MUST NOT contain another 3283 Encrypted payload. 3285 The responder's SPI in the header identifies an instance of an IKE 3286 security association. It is therefore possible for a single instance 3287 of IKE to multiplex distinct sessions with multiple peers, including 3288 multiple sessions per peer. 3290 All multi-octet fields representing integers are laid out in big 3291 endian order (also known as "most significant byte first", or 3292 "network byte order"). 3294 The format of the IKE header is shown in Figure 4. 3296 1 2 3 3297 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 3298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3299 | IKE SA Initiator's SPI | 3300 | | 3301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3302 | IKE SA Responder's SPI | 3303 | | 3304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3305 | Next Payload | MjVer | MnVer | Exchange Type | Flags | 3306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3307 | Message ID | 3308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3309 | Length | 3310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3312 Figure 4: IKE Header Format 3314 o Initiator's SPI (8 octets) - A value chosen by the initiator to 3315 identify a unique IKE security association. This value MUST NOT 3316 be zero. 3318 o Responder's SPI (8 octets) - A value chosen by the responder to 3319 identify a unique IKE security association. This value MUST be 3320 zero in the first message of an IKE Initial Exchange (including 3321 repeats of that message including a cookie). 3323 o Next Payload (1 octet) - Indicates the type of payload that 3324 immediately follows the header. The format and value of each 3325 payload are defined below. 3327 o Major Version (4 bits) - Indicates the major version of the IKE 3328 protocol in use. Implementations based on this version of IKE 3329 MUST set the Major Version to 2. Implementations based on 3330 previous versions of IKE and ISAKMP MUST set the Major Version to 3331 1. Implementations based on this version of IKE MUST reject or 3332 ignore messages containing a version number greater than 2 with an 3333 INVALID_MAJOR_VERSION notification message as described in Section 3334 2.5. 3336 o Minor Version (4 bits) - Indicates the minor version of the IKE 3337 protocol in use. Implementations based on this version of IKE 3338 MUST set the Minor Version to 0. They MUST ignore the minor 3339 version number of received messages. 3341 o Exchange Type (1 octet) - Indicates the type of exchange being 3342 used. This constrains the payloads sent in each message in an 3343 exchange. The values in the following table are only current as 3344 of the publication date of RFC 4306. Other values may have been 3345 added since then or will be added after the publication of this 3346 document. Readers should refer to [IKEV2IANA] for the latest 3347 values. 3349 Exchange Type Value 3350 ---------------------------------- 3351 IKE_SA_INIT 34 3352 IKE_AUTH 35 3353 CREATE_CHILD_SA 36 3354 INFORMATIONAL 37 3356 o Flags (1 octet) - Indicates specific options that are set for the 3357 message. Presence of options is indicated by the appropriate bit 3358 in the flags field being set. The bits are as follows: 3360 +-+-+-+-+-+-+-+-+ 3361 |X|X|R|V|I|X|X|X| 3362 +-+-+-+-+-+-+-+-+ 3364 In the description below, a bit being 'set' means its value is 3365 '1', while 'cleared' means its value is '0'. "X" bits MUST be 3366 cleared when sending and MUST be ignored on receipt. 3368 * R (Response) - This bit indicates that this message is a 3369 response to a message containing the same message ID. This bit 3370 MUST be cleared in all request messages and MUST be set in all 3371 responses. An IKE endpoint MUST NOT generate a response to a 3372 message that is marked as being a response (with one exception; 3373 see Section 2.21.2). 3375 * V (Version) - This bit indicates that the transmitter is 3376 capable of speaking a higher major version number of the 3377 protocol than the one indicated in the major version number 3378 field. Implementations of IKEv2 MUST clear this bit when 3379 sending and MUST ignore it in incoming messages. 3381 * I (Initiator) - This bit MUST be set in messages sent by the 3382 original initiator of the IKE SA and MUST be cleared in 3383 messages sent by the original responder. It is used by the 3384 recipient to determine which eight octets of the SPI were 3385 generated by the recipient. This bit changes to reflect who 3386 initiated the last rekey of the IKE SA. 3388 o Message ID (4 octets, unsigned integer) - Message identifier used 3389 to control retransmission of lost packets and matching of requests 3390 and responses. It is essential to the security of the protocol 3391 because it is used to prevent message replay attacks. See 3392 Section 2.1 and Section 2.2. 3394 o Length (4 octets, unsigned integer) - Length of total message 3395 (header + payloads) in octets. 3397 3.2. Generic Payload Header 3399 Each IKE payload defined in Section 3.3 through Section 3.16 begins 3400 with a generic payload header, shown in Figure 5. Figures for each 3401 payload below will include the generic payload header, but for 3402 brevity the description of each field will be omitted. 3404 1 2 3 3405 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 3406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3407 | Next Payload |C| RESERVED | Payload Length | 3408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3410 Figure 5: Generic Payload Header 3412 The Generic Payload Header fields are defined as follows: 3414 o Next Payload (1 octet) - Identifier for the payload type of the 3415 next payload in the message. If the current payload is the last 3416 in the message, then this field will be 0. This field provides a 3417 "chaining" capability whereby additional payloads can be added to 3418 a message by appending each one to the end of the message and 3419 setting the "Next Payload" field of the preceding payload to 3420 indicate the new payload's type. An Encrypted payload, which must 3421 always be the last payload of a message, is an exception. It 3422 contains data structures in the format of additional payloads. In 3423 the header of an Encrypted payload, the Next Payload field is set 3424 to the payload type of the first contained payload (instead of 0); 3425 conversely, the Next Payload field of the last contained payload 3426 is set to zero). The payload type values are listed here. The 3427 values in the following table are only current as of the 3428 publication date of RFC 4306. Other values may have been added 3429 since then or will be added after the publication of this 3430 document. Readers should refer to [IKEV2IANA] for the latest 3431 values. 3433 Next Payload Type Notation Value 3434 -------------------------------------------------- 3435 No Next Payload 0 3436 Security Association SA 33 3437 Key Exchange KE 34 3438 Identification - Initiator IDi 35 3439 Identification - Responder IDr 36 3440 Certificate CERT 37 3441 Certificate Request CERTREQ 38 3442 Authentication AUTH 39 3443 Nonce Ni, Nr 40 3444 Notify N 41 3445 Delete D 42 3446 Vendor ID V 43 3447 Traffic Selector - Initiator TSi 44 3448 Traffic Selector - Responder TSr 45 3449 Encrypted and Authenticated SK 46 3450 Configuration CP 47 3451 Extensible Authentication EAP 48 3453 (Payload type values 1-32 should not be assigned in the 3454 future so that there is no overlap with the code assignments 3455 for IKEv1.) 3457 o Critical (1 bit) - MUST be set to zero if the sender wants the 3458 recipient to skip this payload if it does not understand the 3459 payload type code in the Next Payload field of the previous 3460 payload. MUST be set to one if the sender wants the recipient to 3461 reject this entire message if it does not understand the payload 3462 type. MUST be ignored by the recipient if the recipient 3463 understands the payload type code. MUST be set to zero for 3464 payload types defined in this document. Note that the critical 3465 bit applies to the current payload rather than the "next" payload 3466 whose type code appears in the first octet. The reasoning behind 3467 not setting the critical bit for payloads defined in this document 3468 is that all implementations MUST understand all payload types 3469 defined in this document and therefore must ignore the Critical 3470 bit's value. Skipped payloads are expected to have valid Next 3471 Payload and Payload Length fields. See Section 2.5 for more 3472 information on this bit. 3474 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on 3475 receipt. 3477 o Payload Length (2 octets, unsigned integer) - Length in octets of 3478 the current payload, including the generic payload header. 3480 Many payloads contain fields marked as "RESERVED". Some payloads in 3481 IKEv2 (and historically in IKEv1) are not aligned to 4-octet 3482 boundaries. 3484 3.3. Security Association Payload 3486 The Security Association Payload, denoted SA in this document, is 3487 used to negotiate attributes of a security association. Assembly of 3488 Security Association Payloads requires great peace of mind. An SA 3489 payload MAY contain multiple proposals. If there is more than one, 3490 they MUST be ordered from most preferred to least preferred. Each 3491 proposal contains a single IPsec protocol (where a protocol is IKE, 3492 ESP, or AH), each protocol MAY contain multiple transforms, and each 3493 transform MAY contain multiple attributes. When parsing an SA, an 3494 implementation MUST check that the total Payload Length is consistent 3495 with the payload's internal lengths and counts. Proposals, 3496 Transforms, and Attributes each have their own variable length 3497 encodings. They are nested such that the Payload Length of an SA 3498 includes the combined contents of the SA, Proposal, Transform, and 3499 Attribute information. The length of a Proposal includes the lengths 3500 of all Transforms and Attributes it contains. The length of a 3501 Transform includes the lengths of all Attributes it contains. 3503 The syntax of Security Associations, Proposals, Transforms, and 3504 Attributes is based on ISAKMP; however the semantics are somewhat 3505 different. The reason for the complexity and the hierarchy is to 3506 allow for multiple possible combinations of algorithms to be encoded 3507 in a single SA. Sometimes there is a choice of multiple algorithms, 3508 whereas other times there is a combination of algorithms. For 3509 example, an initiator might want to propose using ESP with either 3510 (3DES and HMAC_MD5) or (AES and HMAC_SHA1). 3512 One of the reasons the semantics of the SA payload has changed from 3513 ISAKMP and IKEv1 is to make the encodings more compact in common 3514 cases. 3516 The Proposal structure contains within it a Proposal Num and an IPsec 3517 protocol ID. Each structure MUST have a proposal number one (1) 3518 greater than the previous structure. The first Proposal in the 3519 initiator's SA payload MUST have a Proposal Num of one (1). One 3520 reason to use multiple proposals is to propose both standard crypto 3521 ciphers and combined-mode ciphers. Combined-mode ciphers include 3522 both integrity and encryption in a single encryption algorithm, and 3523 MUST either offer no integrity algorithm or a single integrity 3524 algorithm of "none", with no integrity algorithm being the 3525 RECOMMENDED method. If an initiator wants to propose both combined- 3526 mode ciphers and normal ciphers, it must include two proposals: one 3527 will have all the combined-mode ciphers, and the other will have all 3528 the normal ciphers with the integrity algorithms. For example, one 3529 such proposal would have two proposal structures. Proposal 1 is ESP 3530 with AES-128, AES-192, and AES-256 bits in CBC mode, with either 3531 HMAC-SHA1-96 or XCBC-96 as the integrity algorithm; Proposal 2 is 3532 AES-128 or AES-256 in GCM mode with an 8-octet ICV. Both proposals 3533 allow but do not require the use of ESN (extended sequence numbers). 3534 This can be illustrated as: 3536 SA Payload 3537 | 3538 +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4, 3539 | | 7 transforms, SPI = 0x052357bb ) 3540 | | 3541 | +-- Transform ENCR ( Name = ENCR_AES_CBC ) 3542 | | +-- Attribute ( Key Length = 128 ) 3543 | | 3544 | +-- Transform ENCR ( Name = ENCR_AES_CBC ) 3545 | | +-- Attribute ( Key Length = 192 ) 3546 | | 3547 | +-- Transform ENCR ( Name = ENCR_AES_CBC ) 3548 | | +-- Attribute ( Key Length = 256 ) 3549 | | 3550 | +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 ) 3551 | +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 ) 3552 | +-- Transform ESN ( Name = ESNs ) 3553 | +-- Transform ESN ( Name = No ESNs ) 3554 | 3555 +--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4, 3556 | 4 transforms, SPI = 0x35a1d6f2 ) 3557 | 3558 +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) 3559 | +-- Attribute ( Key Length = 128 ) 3560 | 3561 +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) 3562 | +-- Attribute ( Key Length = 256 ) 3563 | 3564 +-- Transform ESN ( Name = ESNs ) 3565 +-- Transform ESN ( Name = No ESNs ) 3567 Each Proposal/Protocol structure is followed by one or more transform 3568 structures. The number of different transforms is generally 3569 determined by the Protocol. AH generally has two transforms: 3570 Extended Sequence Numbers (ESN) and an integrity check algorithm. 3571 ESP generally has three: ESN, an encryption algorithm and an 3572 integrity check algorithm. IKE generally has four transforms: a 3573 Diffie-Hellman group, an integrity check algorithm, a PRF algorithm, 3574 and an encryption algorithm. For each Protocol, the set of 3575 permissible transforms is assigned transform ID numbers, which appear 3576 in the header of each transform. 3578 If there are multiple transforms with the same Transform Type, the 3579 proposal is an OR of those transforms. If there are multiple 3580 Transforms with different Transform Types, the proposal is an AND of 3581 the different groups. For example, to propose ESP with (3DES or AES- 3582 CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two 3583 Transform Type 1 candidates (one for 3DES and one for AEC-CBC) and 3584 two Transform Type 3 candidates (one for HMAC_MD5 and one for 3585 HMAC_SHA). This effectively proposes four combinations of 3586 algorithms. If the initiator wanted to propose only a subset of 3587 those, for example (3DES and HMAC_MD5) or (IDEA and HMAC_SHA), there 3588 is no way to encode that as multiple transforms within a single 3589 Proposal. Instead, the initiator would have to construct two 3590 different Proposals, each with two transforms. 3592 A given transform MAY have one or more Attributes. Attributes are 3593 necessary when the transform can be used in more than one way, as 3594 when an encryption algorithm has a variable key size. The transform 3595 would specify the algorithm and the attribute would specify the key 3596 size. Most transforms do not have attributes. A transform MUST NOT 3597 have multiple attributes of the same type. To propose alternate 3598 values for an attribute (for example, multiple key sizes for the AES 3599 encryption algorithm), an implementation MUST include multiple 3600 Transforms with the same Transform Type each with a single Attribute. 3602 Note that the semantics of Transforms and Attributes are quite 3603 different from those in IKEv1. In IKEv1, a single Transform carried 3604 multiple algorithms for a protocol with one carried in the Transform 3605 and the others carried in the Attributes. 3607 1 2 3 3608 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 3609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3610 | Next Payload |C| RESERVED | Payload Length | 3611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3612 | | 3613 ~ ~ 3614 | | 3615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3617 Figure 6: Security Association Payload 3619 o Proposals (variable) - One or more proposal substructures. 3621 The payload type for the Security Association Payload is thirty three 3622 (33). 3624 3.3.1. Proposal Substructure 3626 1 2 3 3627 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 3628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3629 | 0 (last) or 2 | RESERVED | Proposal Length | 3630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3631 | Proposal Num | Protocol ID | SPI Size |Num Transforms| 3632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3633 ~ SPI (variable) ~ 3634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3635 | | 3636 ~ ~ 3637 | | 3638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3640 Figure 7: Proposal Substructure 3642 o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the 3643 last Proposal Substructure in the SA. This syntax is inherited 3644 from ISAKMP, but is unnecessary because the last Proposal could be 3645 identified from the length of the SA. The value (2) corresponds 3646 to a Payload Type of Proposal in IKEv1, and the first four octets 3647 of the Proposal structure are designed to look somewhat like the 3648 header of a Payload. 3650 o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on 3651 receipt. 3653 o Proposal Length (2 octets, unsigned integer) - Length of this 3654 proposal, including all transforms and attributes that follow. 3656 o Proposal Num (1 octet) - When a proposal is made, the first 3657 proposal in an SA payload MUST be 1, and subsequent proposals MUST 3658 be one more than the previous proposal (indicating an OR of the 3659 two proposals). When a proposal is accepted, the proposal number 3660 in the SA payload MUST match the number on the proposal sent that 3661 was accepted. 3663 o Protocol ID (1 octet) - Specifies the IPsec protocol identifier 3664 for the current negotiation. The values in the following table 3665 are only current as of the publication date of RFC 4306. Other 3666 values may have been added since then or will be added after the 3667 publication of this document. Readers should refer to [IKEV2IANA] 3668 for the latest values. 3670 Protocol Protocol ID 3671 ----------------------------------- 3672 IKE 1 3673 AH 2 3674 ESP 3 3676 o SPI Size (1 octet) - For an initial IKE SA negotiation, this field 3677 MUST be zero; the SPI is obtained from the outer IP header. 3678 During subsequent negotiations, it is equal to the size, in 3679 octets, of the SPI of the corresponding protocol (8 for IKE, 4 for 3680 ESP and AH). 3682 o Num Transforms (1 octet) - Specifies the number of transforms in 3683 this proposal. 3685 o SPI (variable) - The sending entity's SPI. Even if the SPI Size 3686 is not a multiple of 4 octets, there is no padding applied to the 3687 payload. When the SPI Size field is zero, this field is not 3688 present in the Security Association payload. 3690 o Transforms (variable) - One or more transform substructures. 3692 3.3.2. Transform Substructure 3694 1 2 3 3695 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 3696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3697 | 0 (last) or 3 | RESERVED | Transform Length | 3698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3699 |Transform Type | RESERVED | Transform ID | 3700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3701 | | 3702 ~ Transform Attributes ~ 3703 | | 3704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3706 Figure 8: Transform Substructure 3708 o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the 3709 last Transform Substructure in the Proposal. This syntax is 3710 inherited from ISAKMP, but is unnecessary because the last 3711 transform could be identified from the length of the proposal. 3712 The value (3) corresponds to a Payload Type of Transform in IKEv1, 3713 and the first four octets of the Transform structure are designed 3714 to look somewhat like the header of a Payload. 3716 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 3718 o Transform Length - The length (in octets) of the Transform 3719 Substructure including Header and Attributes. 3721 o Transform Type (1 octet) - The type of transform being specified 3722 in this transform. Different protocols support different 3723 transform types. For some protocols, some of the transforms may 3724 be optional. If a transform is optional and the initiator wishes 3725 to propose that the transform be omitted, no transform of the 3726 given type is included in the proposal. If the initiator wishes 3727 to make use of the transform optional to the responder, it 3728 includes a transform substructure with transform ID = 0 as one of 3729 the options. 3731 o Transform ID (2 octets) - The specific instance of the transform 3732 type being proposed. 3734 The transform type values are listed below. The values in the 3735 following table are only current as of the publication date of RFC 3736 4306. Other values may have been added since then or will be added 3737 after the publication of this document. Readers should refer to 3738 [IKEV2IANA] for the latest values. 3740 Description Trans. Used In 3741 Type 3742 ------------------------------------------------------------------ 3743 Encryption Algorithm (ENCR) 1 IKE and ESP 3744 Pseudo-random Function (PRF) 2 IKE 3745 Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP 3746 Diffie-Hellman Group (D-H) 4 IKE, optional in AH & ESP 3747 Extended Sequence Numbers (ESN) 5 AH and ESP 3749 (*) Negotiating an integrity algorithm is mandatory for the 3750 Encrypted payload format specified in this document. For example, 3751 [AEAD] specifies additional formats based on authenticated 3752 encryption, in which a separate integrity algorithm is not 3753 negotiated. 3755 For Transform Type 1 (Encryption Algorithm), the Transform IDs are 3756 listed below. The values in the following table are only current as 3757 of the publication date of RFC 4306. Other values may have been 3758 added since then or will be added after the publication of this 3759 document. Readers should refer to [IKEV2IANA] for the latest values. 3761 Name Number Defined In 3762 --------------------------------------------------- 3763 ENCR_DES_IV64 1 (UNSPECIFIED) 3764 ENCR_DES 2 (RFC2405), [DES] 3765 ENCR_3DES 3 (RFC2451) 3766 ENCR_RC5 4 (RFC2451) 3767 ENCR_IDEA 5 (RFC2451), [IDEA] 3768 ENCR_CAST 6 (RFC2451) 3769 ENCR_BLOWFISH 7 (RFC2451) 3770 ENCR_3IDEA 8 (UNSPECIFIED) 3771 ENCR_DES_IV32 9 (UNSPECIFIED) 3772 ENCR_NULL 11 (RFC2410) 3773 ENCR_AES_CBC 12 (RFC3602) 3774 ENCR_AES_CTR 13 (RFC3686) 3776 For Transform Type 2 (Pseudo-random Function), the Transform IDs are 3777 listed below. The values in the following table are only current as 3778 of the publication date of RFC 4306. Other values may have been 3779 added since then or will be added after the publication of this 3780 document. Readers should refer to [IKEV2IANA] for the latest values. 3782 Name Number Defined In 3783 ------------------------------------------------------ 3784 PRF_HMAC_MD5 1 (RFC2104), [MD5] 3785 PRF_HMAC_SHA1 2 (RFC2104), [SHA] 3786 PRF_HMAC_TIGER 3 (UNSPECIFIED) 3788 For Transform Type 3 (Integrity Algorithm), defined Transform IDs are 3789 listed below. The values in the following table are only current as 3790 of the publication date of RFC 4306. Other values may have been 3791 added since then or will be added after the publication of this 3792 document. Readers should refer to [IKEV2IANA] for the latest values. 3794 Name Number Defined In 3795 ---------------------------------------- 3796 NONE 0 3797 AUTH_HMAC_MD5_96 1 (RFC2403) 3798 AUTH_HMAC_SHA1_96 2 (RFC2404) 3799 AUTH_DES_MAC 3 (UNSPECIFIED) 3800 AUTH_KPDK_MD5 4 (UNSPECIFIED) 3801 AUTH_AES_XCBC_96 5 (RFC3566) 3803 For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs 3804 are listed below. The values in the following table are only current 3805 as of the publication date of RFC 4306. Other values may have been 3806 added since then or will be added after the publication of this 3807 document. Readers should refer to [IKEV2IANA] for the latest values. 3809 Name Number Defined in 3810 ---------------------------------------- 3811 NONE 0 3812 768 Bit MODP 1 Appendix B 3813 1024 Bit MODP 2 Appendix B 3814 1536-bit MODP 5 [ADDGROUP] 3815 2048-bit MODP 14 [ADDGROUP] 3816 3072-bit MODP 15 [ADDGROUP] 3817 4096-bit MODP 16 [ADDGROUP] 3818 6144-bit MODP 17 [ADDGROUP] 3819 8192-bit MODP 18 [ADDGROUP] 3821 Although ESP and AH do not directly include a Diffie-Hellman 3822 exchange, a Diffie-Hellman group MAY be negotiated for the Child SA. 3823 This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA 3824 exchange, providing perfect forward secrecy for the generated Child 3825 SA keys. 3827 For Transform Type 5 (Extended Sequence Numbers), defined Transform 3828 IDs are listed below. The values in the following table are only 3829 current as of the publication date of RFC 4306. Other values may 3830 have been added since then or will be added after the publication of 3831 this document. Readers should refer to [IKEV2IANA] for the latest 3832 values. 3834 Name Number 3835 -------------------------------------------- 3836 No Extended Sequence Numbers 0 3837 Extended Sequence Numbers 1 3839 Note that an initiator who supports ESNs will usually include two ESN 3840 transforms, with values "0" and "1", in its proposals. A proposal 3841 containing a single ESN transform with value "1" means that using 3842 normal (non-extended) sequence numbers is not acceptable. 3844 Numerous additional transform types have been defined since the 3845 publication of RFC 4306. Please refer to the IANA IKEv2 registry for 3846 details. 3848 3.3.3. Valid Transform Types by Protocol 3850 The number and type of transforms that accompany an SA payload are 3851 dependent on the protocol in the SA itself. An SA payload proposing 3852 the establishment of an SA has the following mandatory and optional 3853 transform types. A compliant implementation MUST understand all 3854 mandatory and optional types for each protocol it supports (though it 3855 need not accept proposals with unacceptable suites). A proposal MAY 3856 omit the optional types if the only value for them it will accept is 3857 NONE. 3859 Protocol Mandatory Types Optional Types 3860 --------------------------------------------------- 3861 IKE ENCR, PRF, INTEG*, D-H 3862 ESP ENCR, ESN INTEG, D-H 3863 AH INTEG, ESN D-H 3865 (*) Negotiating an integrity algorithm is mandatory for the 3866 Encrypted payload format specified in this document. For example, 3867 [AEAD] specifies additional formats based on authenticated 3868 encryption, in which a separate integrity algorithm is not 3869 negotiated. 3871 3.3.4. Mandatory Transform IDs 3873 The specification of suites that MUST and SHOULD be supported for 3874 interoperability has been removed from this document because they are 3875 likely to change more rapidly than this document evolves. 3877 An important lesson learned from IKEv1 is that no system should only 3878 implement the mandatory algorithms and expect them to be the best 3879 choice for all customers. 3881 It is likely that IANA will add additional transforms in the future, 3882 and some users may want to use private suites, especially for IKE 3883 where implementations should be capable of supporting different 3884 parameters, up to certain size limits. In support of this goal, all 3885 implementations of IKEv2 SHOULD include a management facility that 3886 allows specification (by a user or system administrator) of Diffie- 3887 Hellman parameters (the generator, modulus, and exponent lengths and 3888 values) for new Diffie-Hellman groups. Implementations SHOULD 3889 provide a management interface through which these parameters and the 3890 associated transform IDs may be entered (by a user or system 3891 administrator), to enable negotiating such groups. 3893 All implementations of IKEv2 MUST include a management facility that 3894 enables a user or system administrator to specify the suites that are 3895 acceptable for use with IKE. Upon receipt of a payload with a set of 3896 transform IDs, the implementation MUST compare the transmitted 3897 transform IDs against those locally configured via the management 3898 controls, to verify that the proposed suite is acceptable based on 3899 local policy. The implementation MUST reject SA proposals that are 3900 not authorized by these IKE suite controls. Note that cryptographic 3901 suites that MUST be implemented need not be configured as acceptable 3902 to local policy. 3904 3.3.5. Transform Attributes 3906 Each transform in a Security Association payload may include 3907 attributes that modify or complete the specification of the 3908 transform. The set of valid attributes depends on the transform. 3909 Currently, only a single attribute type is defined: the Key Length 3910 attribute is used by certain encryption transforms with variable- 3911 length keys (see below for details). 3913 The attributes are type/value pairs and are defined below. 3914 Attributes can have a value with a fixed two-octet length or a 3915 variable-length value. For the latter, the attribute is encoded as 3916 type/length/value. 3918 1 2 3 3919 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 3920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3921 |A| Attribute Type | AF=0 Attribute Length | 3922 |F| | AF=1 Attribute Value | 3923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3924 | AF=0 Attribute Value | 3925 | AF=1 Not Transmitted | 3926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3928 Figure 9: Data Attributes 3930 o Attribute Format (AF) (1 bit) - Indicates whether the data 3931 attribute follows the Type/Length/Value (TLV) format or a 3932 shortened Type/Value (TV) format. If the AF bit is zero (0), then 3933 the attribute uses TLV format; if the AF bit is one (1), the TV 3934 format (with two-byte value) is used. 3936 o Attribute Type (15 bits) - Unique identifier for each type of 3937 attribute (see below). 3939 o Attribute Value (variable length) - Value of the Attribute 3940 associated with the Attribute Type. If the AF bit is a zero (0), 3941 this field has a variable length defined by the Attribute Length 3942 field. If the AF bit is a one (1), the Attribute Value has a 3943 length of 2 octets. 3945 The only currently defined attribute type (Key Length) is fixed 3946 length; the variable-length encoding specification is included only 3947 for future extensions. Attributes described as fixed length MUST NOT 3948 be encoded using the variable-length encoding unless that length 3949 exceeds two bytes. Variable-length attributes MUST NOT be encoded as 3950 fixed-length even if their value can fit into two octets. NOTE: This 3951 is a change from IKEv1, where increased flexibility may have 3952 simplified the composer of messages but certainly complicated the 3953 parser. 3955 The values in the following table are only current as of the 3956 publication date of RFC 4306. Other values may have been added since 3957 then or will be added after the publication of this document. 3958 Readers should refer to [IKEV2IANA] for the latest values. 3960 Attribute Type Value Attribute Format 3961 ------------------------------------------------------------ 3962 Key Length (in bits) 14 TV 3964 Values 0-13 and 15-17 were used in a similar context in IKEv1, and 3965 should not be assigned except to matching values. 3967 The Key Length attribute specifies the key length in bits (MUST use 3968 network byte order) for certain transforms as follows: 3970 o The Key Length attribute MUST NOT be used with transforms that use 3971 a fixed length key. This includes, e.g., ENCR_DES, ENCR_IDEA, and 3972 all the Type 2 (Pseudo-random function) and Type 3 (Integrity 3973 Algorithm) transforms specified in this document. It is 3974 recommended that future Type 2 or 3 transforms do not use this 3975 attribute. 3977 o Some transforms specify that the Key Length attribute MUST be 3978 always included (omitting the attribute is not allowed, and 3979 proposals not containing it MUST be rejected). This includes, 3980 e.g., ENCR_AES_CBC and ENCR_AES_CTR. 3982 o Some transforms allow variable-length keys, but also specify a 3983 default key length if the attribute is not included. These 3984 transforms include, e.g., ENCR_RC5 and ENCR_BLOWFISH. 3986 Implementation note: To further interoperability and to support 3987 upgrading endpoints independently, implementers of this protocol 3988 SHOULD accept values that they deem to supply greater security. For 3989 instance, if a peer is configured to accept a variable-length cipher 3990 with a key length of X bits and is offered that cipher with a larger 3991 key length, the implementation SHOULD accept the offer if it supports 3992 use of the longer key. 3994 Support of this capability allows a responder to express a concept of 3995 "at least" a certain level of security -- "a key length of _at least_ 3996 X bits for cipher Y". However, as the attribute is always returned 3997 unchanged (see the next section), an initiator willing to accept 3998 multiple key lengths has to include multiple transforms with the same 3999 Transform Type, each with a different Key Length attribute. 4001 3.3.6. Attribute Negotiation 4003 During security association negotiation initiators present offers to 4004 responders. Responders MUST select a single complete set of 4005 parameters from the offers (or reject all offers if none are 4006 acceptable). If there are multiple proposals, the responder MUST 4007 choose a single proposal. If the selected proposal has multiple 4008 Transforms with the same type, the responder MUST choose a single 4009 one. Any attributes of a selected transform MUST be returned 4010 unmodified. The initiator of an exchange MUST check that the 4011 accepted offer is consistent with one of its proposals, and if not 4012 MUST terminate the exchange. 4014 If the responder receives a proposal that contains a Transform Type 4015 it does not understand, or a proposal that is missing a mandatory 4016 Transform Type, it MUST consider this proposal unacceptable; however, 4017 other proposals in the same SA payload are processed as usual. 4018 Similarly, if the responder receives a transform that it does not 4019 understand, or one that contains a Transform Attribute it does not 4020 understand, it MUST consider this transform unacceptable; other 4021 transforms with the same Transform Type are processed as usual. This 4022 allows new Transform Types and Transform Attributes to be defined in 4023 the future. 4025 Negotiating Diffie-Hellman groups presents some special challenges. 4026 SA offers include proposed attributes and a Diffie-Hellman public 4027 number (KE) in the same message. If in the initial exchange the 4028 initiator offers to use one of several Diffie-Hellman groups, it 4029 SHOULD pick the one the responder is most likely to accept and 4030 include a KE corresponding to that group. If the responder selects a 4031 proposal using a different Diffie-Hellman group (other than NONE), 4032 the responder will indicate the correct group in the response and the 4033 initiator SHOULD pick an element of that group for its KE value when 4034 retrying the first message. It SHOULD, however, continue to propose 4035 its full supported set of groups in order to prevent a man-in-the- 4036 middle downgrade attack. If one of the proposals offered is for the 4037 Diffie-Hellman group of NONE, and the responder selects that Diffie- 4038 Hellman group, then it MUST ignore the initiator's KE payload and 4039 omit the KE payload from the response. 4041 3.4. Key Exchange Payload 4043 The Key Exchange Payload, denoted KE in this document, is used to 4044 exchange Diffie-Hellman public numbers as part of a Diffie-Hellman 4045 key exchange. The Key Exchange Payload consists of the IKE generic 4046 payload header followed by the Diffie-Hellman public value itself. 4048 1 2 3 4049 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 4050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4051 | Next Payload |C| RESERVED | Payload Length | 4052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4053 | Diffie-Hellman Group Num | RESERVED | 4054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4055 | | 4056 ~ Key Exchange Data ~ 4057 | | 4058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4060 Figure 10: Key Exchange Payload Format 4062 A key exchange payload is constructed by copying one's Diffie-Hellman 4063 public value into the "Key Exchange Data" portion of the payload. 4064 The length of the Diffie-Hellman public value for MODP groups MUST be 4065 equal to the length of the prime modulus over which the 4066 exponentiation was performed, prepending zero bits to the value if 4067 necessary. 4069 The Diffie-Hellman Group Num identifies the Diffie-Hellman group in 4070 which the Key Exchange Data was computed (see Section 3.3.2). This 4071 Diffie-Hellman Group Num MUST match a Diffie-Hellman Group specified 4072 in a proposal in the SA payload that is sent in the same message, and 4073 SHOULD match the Diffie-Hellman group in the first group in the first 4074 proposal, if such exists. If none of the proposals in that SA 4075 payload specifies a Diffie-Hellman Group, the KE payload MUST NOT be 4076 present. If the selected proposal uses a different Diffie-Hellman 4077 group (other than NONE), the message MUST be rejected with a Notify 4078 payload of type INVALID_KE_PAYLOAD. See also Section 1.2 and 4079 Section 2.7. 4081 The payload type for the Key Exchange payload is thirty four (34). 4083 3.5. Identification Payloads 4085 The Identification Payloads, denoted IDi and IDr in this document, 4086 allow peers to assert an identity to one another. This identity may 4087 be used for policy lookup, but does not necessarily have to match 4088 anything in the CERT payload; both fields may be used by an 4089 implementation to perform access control decisions. When using the 4090 ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 4091 does not require this address to match the address in the IP header 4092 of IKEv2 packets, or anything in the TSi/TSr payloads. The contents 4093 of IDi/IDr is used purely to fetch the policy and authentication data 4094 related to the other party. 4096 NOTE: In IKEv1, two ID payloads were used in each direction to hold 4097 Traffic Selector (TS) information for data passing over the SA. In 4098 IKEv2, this information is carried in TS payloads (see Section 3.13). 4100 The Peer Authorization Database (PAD) as described in RFC 4301 4101 [IPSECARCH] describes the use of the ID payload in IKEv2 and provides 4102 a formal model for the binding of identity to policy in addition to 4103 providing services that deal more specifically with the details of 4104 policy enforcement. The PAD is intended to provide a link between 4105 the SPD and the IKE security association management. See Section 4106 4.4.3 of RFC 4301 for more details. 4108 The Identification Payload consists of the IKE generic payload header 4109 followed by identification fields as follows: 4111 1 2 3 4112 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 4113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4114 | Next Payload |C| RESERVED | Payload Length | 4115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4116 | ID Type | RESERVED | 4117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4118 | | 4119 ~ Identification Data ~ 4120 | | 4121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4123 Figure 11: Identification Payload Format 4125 o ID Type (1 octet) - Specifies the type of Identification being 4126 used. 4128 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 4130 o Identification Data (variable length) - Value, as indicated by the 4131 Identification Type. The length of the Identification Data is 4132 computed from the size in the ID payload header. 4134 The payload types for the Identification Payload are thirty five (35) 4135 for IDi and thirty six (36) for IDr. 4137 The following table lists the assigned semantics for the 4138 Identification Type field. The values in the following table are 4139 only current as of the publication date of RFC 4306. Other values 4140 may have been added since then or will be added after the publication 4141 of this document. Readers should refer to [IKEV2IANA] for the latest 4142 values. 4144 ID Type Value 4145 ------------------------------------------------------------------- 4146 ID_IPV4_ADDR 1 4147 A single four (4) octet IPv4 address. 4149 ID_FQDN 2 4150 A fully-qualified domain name string. An example of a ID_FQDN 4151 is, "example.com". The string MUST NOT contain any terminators 4152 (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; 4153 for an "internationalized domain name", the syntax is as defined 4154 in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net". 4156 ID_RFC822_ADDR 3 4157 A fully-qualified RFC822 email address string, An example of a 4158 ID_RFC822_ADDR is, "jsmith@example.com". The string MUST NOT 4159 contain any terminators. Because of [EAI], implementations would 4160 be wise to treat this field as UTF-8 encoded text, not as 4161 pure ASCII. 4163 ID_IPV6_ADDR 5 4164 A single sixteen (16) octet IPv6 address. 4166 ID_DER_ASN1_DN 9 4167 The binary Distinguished Encoding Rules (DER) encoding of an 4168 ASN.1 X.500 Distinguished Name [PKIX]. 4170 ID_DER_ASN1_GN 10 4171 The binary DER encoding of an ASN.1 X.509 GeneralName [PKIX]. 4173 ID_KEY_ID 11 4174 An opaque octet stream which may be used to pass vendor- 4175 specific information necessary to do certain proprietary 4176 types of identification. 4178 Two implementations will interoperate only if each can generate a 4179 type of ID acceptable to the other. To assure maximum 4180 interoperability, implementations MUST be configurable to send at 4181 least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and 4182 MUST be configurable to accept all of these four types. 4183 Implementations SHOULD be capable of generating and accepting all of 4184 these types. IPv6-capable implementations MUST additionally be 4185 configurable to accept ID_IPV6_ADDR. IPv6-only implementations MAY 4186 be configurable to send only ID_IPV6_ADDR instead of ID_IPV4_ADDR for 4187 IP addresses. 4189 EAP [EAP] does not mandate the use of any particular type of 4190 identifier, but often EAP is used with Network Access Identifiers 4191 (NAIs) defined in [NAI]. Although NAIs look a bit like email 4192 addresses (e.g., "joe@example.com"), the syntax is not exactly the 4193 same as the syntax of email address in [MAILFORMAT]. For those NAIs 4194 that include the realm component, the ID_RFC822_ADDR identification 4195 type SHOULD be used. Responder implementations should not attempt to 4196 verify that the contents actually conform to the exact syntax given 4197 in [MAILFORMAT], but instead should accept any reasonable-looking 4198 NAI. For NAIs that do not include the realm component, the ID_KEY_ID 4199 identification type SHOULD be used. 4201 3.6. Certificate Payload 4203 The Certificate Payload, denoted CERT in this document, provides a 4204 means to transport certificates or other authentication-related 4205 information via IKE. Certificate payloads SHOULD be included in an 4206 exchange if certificates are available to the sender. The Hash and 4207 URL formats of the Certificate payloads should be used in case the 4208 peer has indicated an ability to retrieve this information from 4209 elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note 4210 that the term "Certificate Payload" is somewhat misleading, because 4211 not all authentication mechanisms use certificates and data other 4212 than certificates may be passed in this payload. 4214 The Certificate Payload is defined as follows: 4216 1 2 3 4217 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 4218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4219 | Next Payload |C| RESERVED | Payload Length | 4220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4221 | Cert Encoding | | 4222 +-+-+-+-+-+-+-+-+ | 4223 ~ Certificate Data ~ 4224 | | 4225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4227 Figure 12: Certificate Payload Format 4229 o Certificate Encoding (1 octet) - This field indicates the type of 4230 certificate or certificate-related information contained in the 4231 Certificate Data field. The values in the following table are 4232 only current as of the publication date of RFC 4306. Other values 4233 may have been added since then or will be added after the 4234 publication of this document. Readers should refer to [IKEV2IANA] 4235 for the latest values. 4237 Certificate Encoding Value 4238 ---------------------------------------------------- 4239 PKCS #7 wrapped X.509 certificate 1 UNSPECIFIED 4240 PGP Certificate 2 UNSPECIFIED 4241 DNS Signed Key 3 UNSPECIFIED 4242 X.509 Certificate - Signature 4 4243 Kerberos Token 6 UNSPECIFIED 4244 Certificate Revocation List (CRL) 7 4245 Authority Revocation List (ARL) 8 UNSPECIFIED 4246 SPKI Certificate 9 UNSPECIFIED 4247 X.509 Certificate - Attribute 10 UNSPECIFIED 4248 Raw RSA Key 11 4249 Hash and URL of X.509 certificate 12 4250 Hash and URL of X.509 bundle 13 4252 o Certificate Data (variable length) - Actual encoding of 4253 certificate data. The type of certificate is indicated by the 4254 Certificate Encoding field. 4256 The payload type for the Certificate Payload is thirty seven (37). 4258 Specific syntax for some of the certificate type codes above is not 4259 defined in this document. The types whose syntax is defined in this 4260 document are: 4262 o "X.509 Certificate - Signature" contains a DER encoded X.509 4263 certificate whose public key is used to validate the sender's AUTH 4264 payload. Note that with this encoding, if a chain of certificates 4265 needs to be sent, multiple CERT payloads are used, only the first 4266 of which holds the public key used to validate the sender's AUTH 4267 payload. 4269 o "Certificate Revocation List" contains a DER encoded X.509 4270 certificate revocation list. 4272 o "Raw RSA Key" contains a PKCS #1 encoded RSA key, that is, a DER- 4273 encoded RSAPublicKey structure (see [RSA] and [PKCS1]). 4275 o Hash and URL encodings allow IKE messages to remain short by 4276 replacing long data structures with a 20 octet SHA-1 hash (see 4277 [SHA]) of the replaced value followed by a variable-length URL 4278 that resolves to the DER encoded data structure itself. This 4279 improves efficiency when the endpoints have certificate data 4280 cached and makes IKE less subject to DoS attacks that become 4281 easier to mount when IKE messages are large enough to require IP 4282 fragmentation [DOSUDPPROT]. 4284 The "Hash and URL of a bundle" type uses the following ASN.1 4285 definition for the X.509 bundle: 4287 CertBundle 4288 { iso(1) identified-organization(3) dod(6) internet(1) 4289 security(5) mechanisms(5) pkix(7) id-mod(0) 4290 id-mod-cert-bundle(34) } 4292 DEFINITIONS EXPLICIT TAGS ::= 4293 BEGIN 4295 IMPORTS 4296 Certificate, CertificateList 4297 FROM PKIX1Explicit88 4298 { iso(1) identified-organization(3) dod(6) 4299 internet(1) security(5) mechanisms(5) pkix(7) 4300 id-mod(0) id-pkix1-explicit(18) } ; 4302 CertificateOrCRL ::= CHOICE { 4303 cert [0] Certificate, 4304 crl [1] CertificateList } 4306 CertificateBundle ::= SEQUENCE OF CertificateOrCRL 4308 END 4310 Implementations MUST be capable of being configured to send and 4311 accept up to four X.509 certificates in support of authentication, 4312 and also MUST be capable of being configured to send and accept the 4313 Hash and URL format (with HTTP URLs). Implementations SHOULD be 4314 capable of being configured to send and accept Raw RSA keys. If 4315 multiple certificates are sent, the first certificate MUST contain 4316 the public key used to sign the AUTH payload. The other certificates 4317 may be sent in any order. 4319 Implementations MUST support the HTTP method for hash-and-URL lookup. 4320 The behavior of other URL methods is not currently specified, and 4321 such methods SHOULD NOT be used in the absence of a document 4322 specifying them. 4324 3.7. Certificate Request Payload 4326 The Certificate Request Payload, denoted CERTREQ in this document, 4327 provides a means to request preferred certificates via IKE and can 4328 appear in the IKE_INIT_SA response and/or the IKE_AUTH request. 4329 Certificate Request payloads MAY be included in an exchange when the 4330 sender needs to get the certificate of the receiver. 4332 The Certificate Request Payload is defined as follows: 4334 1 2 3 4335 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 4336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4337 | Next Payload |C| RESERVED | Payload Length | 4338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4339 | Cert Encoding | | 4340 +-+-+-+-+-+-+-+-+ | 4341 ~ Certification Authority ~ 4342 | | 4343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4345 Figure 13: Certificate Request Payload Format 4347 o Certificate Encoding (1 octet) - Contains an encoding of the type 4348 or format of certificate requested. Values are listed in 4349 Section 3.6. 4351 o Certification Authority (variable length) - Contains an encoding 4352 of an acceptable certification authority for the type of 4353 certificate requested. 4355 The payload type for the Certificate Request Payload is thirty eight 4356 (38). 4358 The Certificate Encoding field has the same values as those defined 4359 in Section 3.6. The Certification Authority field contains an 4360 indicator of trusted authorities for this certificate type. The 4361 Certification Authority value is a concatenated list of SHA-1 hashes 4362 of the public keys of trusted Certification Authorities (CAs). Each 4363 is encoded as the SHA-1 hash of the Subject Public Key Info element 4364 (see section 4.1.2.7 of [PKIX]) from each Trust Anchor certificate. 4365 The twenty-octet hashes are concatenated and included with no other 4366 formatting. 4368 The contents of the "Certification Authority" field are defined only 4369 for X.509 certificates, which are types 4, 12, and 13. Other values 4370 SHOULD NOT be used until standards-track specifications that specify 4371 their use are published. 4373 Note that the term "Certificate Request" is somewhat misleading, in 4374 that values other than certificates are defined in a "Certificate" 4375 payload and requests for those values can be present in a Certificate 4376 Request Payload. The syntax of the Certificate Request payload in 4377 such cases is not defined in this document. 4379 The Certificate Request Payload is processed by inspecting the "Cert 4380 Encoding" field to determine whether the processor has any 4381 certificates of this type. If so, the "Certification Authority" 4382 field is inspected to determine if the processor has any certificates 4383 that can be validated up to one of the specified certification 4384 authorities. This can be a chain of certificates. 4386 If an end-entity certificate exists that satisfies the criteria 4387 specified in the CERTREQ, a certificate or certificate chain SHOULD 4388 be sent back to the certificate requestor if the recipient of the 4389 CERTREQ: 4391 o is configured to use certificate authentication, 4393 o is allowed to send a CERT payload, 4395 o has matching CA trust policy governing the current negotiation, 4396 and 4398 o has at least one time-wise and usage appropriate end-entity 4399 certificate chaining to a CA provided in the CERTREQ. 4401 Certificate revocation checking must be considered during the 4402 chaining process used to select a certificate. Note that even if two 4403 peers are configured to use two different CAs, cross-certification 4404 relationships should be supported by appropriate selection logic. 4406 The intent is not to prevent communication through the strict 4407 adherence of selection of a certificate based on CERTREQ, when an 4408 alternate certificate could be selected by the sender that would 4409 still enable the recipient to successfully validate and trust it 4410 through trust conveyed by cross-certification, CRLs, or other out-of- 4411 band configured means. Thus, the processing of a CERTREQ should be 4412 seen as a suggestion for a certificate to select, not a mandated one. 4413 If no certificates exist, then the CERTREQ is ignored. This is not 4414 an error condition of the protocol. There may be cases where there 4415 is a preferred CA sent in the CERTREQ, but an alternate might be 4416 acceptable (perhaps after prompting a human operator). 4418 The HTTP_CERT_LOOKUP_SUPPORTED notification MAY be included in any 4419 message that can include a CERTREQ payload and indicates that the 4420 sender is capable of looking up certificates based on an HTTP-based 4421 URL (and hence presumably would prefer to receive certificate 4422 specifications in that format). 4424 3.8. Authentication Payload 4426 The Authentication Payload, denoted AUTH in this document, contains 4427 data used for authentication purposes. The syntax of the 4428 Authentication data varies according to the Auth Method as specified 4429 below. 4431 The Authentication Payload is defined as follows: 4433 1 2 3 4434 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 4435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4436 | Next Payload |C| RESERVED | Payload Length | 4437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4438 | Auth Method | RESERVED | 4439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4440 | | 4441 ~ Authentication Data ~ 4442 | | 4443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4445 Figure 14: Authentication Payload Format 4447 o Auth Method (1 octet) - Specifies the method of authentication 4448 used. The types of signatures are listed here. The values in the 4449 following table are only current as of the publication date of RFC 4450 4306. Other values may have been added since then or will be 4451 added after the publication of this document. Readers should 4452 refer to [IKEV2IANA] for the latest values. 4454 Mechanism Value 4455 ----------------------------------------------------------------- 4456 RSA Digital Signature 1 4457 Computed as specified in Section 2.15 using an RSA private key 4458 with RSASSA-PKCS1-v1_5 signature scheme specified in [PKCS1] 4459 (implementors should note that IKEv1 used a different method for 4460 RSA signatures). To promote interoperability, implementations 4461 that support this type SHOULD support signatures that use SHA-1 4462 as the hash function and SHOULD use SHA-1 as the default hash 4463 function when generating signatures. Implementations can use the 4464 certificates received from a given peer as a hint for selecting a 4465 mutually-understood hash function for the AUTH payload signature. 4466 Note, however, that the hash algorithm used in the AUTH payload 4467 signature doesn't have to be the same as any hash algorithm(s) 4468 used in the certificate(s). 4470 Shared Key Message Integrity Code 2 4471 Computed as specified in Section 2.15 using the shared key 4472 associated with the identity in the ID payload and the negotiated 4473 PRF. 4475 DSS Digital Signature 3 4476 Computed as specified in Section 2.15 using a DSS private key 4477 (see [DSS]) over a SHA-1 hash. 4479 o Authentication Data (variable length) - see Section 2.15. 4481 The payload type for the Authentication Payload is thirty nine (39). 4483 3.9. Nonce Payload 4485 The Nonce Payload, denoted Ni and Nr in this document for the 4486 initiator's and responder's nonce respectively, contains random data 4487 used to guarantee liveness during an exchange and protect against 4488 replay attacks. 4490 The Nonce Payload is defined as follows: 4492 1 2 3 4493 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 4494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4495 | Next Payload |C| RESERVED | Payload Length | 4496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4497 | | 4498 ~ Nonce Data ~ 4499 | | 4500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4502 Figure 15: Nonce Payload Format 4504 o Nonce Data (variable length) - Contains the random data generated 4505 by the transmitting entity. 4507 The payload type for the Nonce Payload is forty (40). 4509 The size of the Nonce Data MUST be between 16 and 256 octets 4510 inclusive. Nonce values MUST NOT be reused. 4512 3.10. Notify Payload 4514 The Notify Payload, denoted N in this document, is used to transmit 4515 informational data, such as error conditions and state transitions, 4516 to an IKE peer. A Notify Payload may appear in a response message 4517 (usually specifying why a request was rejected), in an INFORMATIONAL 4518 Exchange (to report an error not in an IKE request), or in any other 4519 message to indicate sender capabilities or to modify the meaning of 4520 the request. 4522 The Notify Payload is defined as follows: 4524 1 2 3 4525 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 4526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4527 | Next Payload |C| RESERVED | Payload Length | 4528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4529 | Protocol ID | SPI Size | Notify Message Type | 4530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4531 | | 4532 ~ Security Parameter Index (SPI) ~ 4533 | | 4534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4535 | | 4536 ~ Notification Data ~ 4537 | | 4538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4540 Figure 16: Notify Payload Format 4542 o Protocol ID (1 octet) - If this notification concerns an existing 4543 SA whose SPI is given in the SPI field, this field indicates the 4544 type of that SA. For notifications concerning Child SAs this 4545 field MUST contain either (2) to indicate AH or (3) to indicate 4546 ESP. Of the notifications defined in this document, the SPI is 4547 included only with INVALID_SELECTORS and REKEY_SA. If the SPI 4548 field is empty, this field MUST be sent as zero and MUST be 4549 ignored on receipt. 4551 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 4552 IPsec protocol ID or zero if no SPI is applicable. For a 4553 notification concerning the IKE SA, the SPI Size MUST be zero and 4554 the field must be empty. 4556 o Notify Message Type (2 octets) - Specifies the type of 4557 notification message. 4559 o SPI (variable length) - Security Parameter Index. 4561 o Notification Data (variable length) - Status or error data 4562 transmitted in addition to the Notify Message Type. Values for 4563 this field are type specific (see below). 4565 The payload type for the Notify Payload is forty one (41). 4567 3.10.1. Notify Message Types 4569 Notification information can be error messages specifying why an SA 4570 could not be established. It can also be status data that a process 4571 managing an SA database wishes to communicate with a peer process. 4572 The table below lists the Notification messages and their 4573 corresponding values. The number of different error statuses was 4574 greatly reduced from IKEv1 both for simplification and to avoid 4575 giving configuration information to probers. 4577 Types in the range 0 - 16383 are intended for reporting errors. An 4578 implementation receiving a Notify payload with one of these types 4579 that it does not recognize in a response MUST assume that the 4580 corresponding request has failed entirely. Unrecognized error types 4581 in a request and status types in a request or response MUST be 4582 ignored, and they should be logged. 4584 Notify payloads with status types MAY be added to any message and 4585 MUST be ignored if not recognized. They are intended to indicate 4586 capabilities, and as part of SA negotiation are used to negotiate 4587 non-cryptographic parameters. 4589 More information on error handling can be found in Section 2.21. 4591 The values in the following table are only current as of the 4592 publication date of RFC 4306, plus two error types added in this 4593 document. Other values may have been added since then or will be 4594 added after the publication of this document. Readers should refer 4595 to [IKEV2IANA] for the latest values. 4597 NOTIFY messages: error types Value 4598 ------------------------------------------------------------------- 4599 UNSUPPORTED_CRITICAL_PAYLOAD 1 4600 See Section 2.5. 4602 INVALID_IKE_SPI 4 4603 See Section 2.21. 4605 INVALID_MAJOR_VERSION 5 4606 See Section 2.5. 4608 INVALID_SYNTAX 7 4609 Indicates the IKE message that was received was invalid because 4610 some type, length, or value was out of range or because the 4611 request was rejected for policy reasons. To avoid a DoS 4612 attack using forged messages, this status may only be 4613 returned for and in an encrypted packet if the message ID and 4614 cryptographic checksum were valid. To avoid leaking information 4615 to someone probing a node, this status MUST be sent in response 4616 to any error not covered by one of the other status types. 4617 To aid debugging, more detailed error information should be 4618 written to a console or log. 4620 INVALID_MESSAGE_ID 9 4621 See Section 2.3. 4623 INVALID_SPI 11 4624 See Section 1.5. 4626 NO_PROPOSAL_CHOSEN 14 4627 None of the proposed crypto suites was acceptable. This can be 4628 sent in any case where the offered proposals (including but not 4629 limited to SA payload values, USE_TRANSPORT_MODE notify, 4630 IPCOMP_SUPPORTED notify) are not acceptable for the responder. 4631 This can also be used as "generic" Child SA error when Child SA 4632 cannot be created for some other reason. See also Section 2.7. 4634 INVALID_KE_PAYLOAD 17 4635 See Section 1.2 and 1.3. 4637 AUTHENTICATION_FAILED 24 4638 Sent in the response to an IKE_AUTH message when for some reason 4639 the authentication failed. There is no associated data. See also 4640 Section 2.21.2. 4642 SINGLE_PAIR_REQUIRED 34 4643 See Section 2.9. 4645 NO_ADDITIONAL_SAS 35 4646 See Section 1.3. 4648 INTERNAL_ADDRESS_FAILURE 36 4649 See Section 3.15.4. 4651 FAILED_CP_REQUIRED 37 4652 See Section 2.19. 4654 TS_UNACCEPTABLE 38 4655 See Section 2.9. 4657 INVALID_SELECTORS 39 4658 MAY be sent in an IKE INFORMATIONAL exchange when a node receives 4659 an ESP or AH packet whose selectors do not match those of the SA 4660 on which it was delivered (and that caused the packet to be 4661 dropped). The Notification Data contains the start of the 4662 offending packet (as in ICMP messages) and the SPI field of the 4663 notification is set to match the SPI of the Child SA. 4665 TEMPORARY_FAILURE {TBA1} 4666 See section 2.25. 4668 CHILD_SA_NOT_FOUND {TBA2} 4669 See section 2.25. 4671 NOTIFY messages: status types Value 4672 ------------------------------------------------------------------- 4673 INITIAL_CONTACT 16384 4674 See Section 2.4. 4676 SET_WINDOW_SIZE 16385 4677 See Section 2.3. 4679 ADDITIONAL_TS_POSSIBLE 16386 4680 See Section 2.9. 4682 IPCOMP_SUPPORTED 16387 4683 See Section 2.22. 4685 NAT_DETECTION_SOURCE_IP 16388 4686 See Section 2.23. 4688 NAT_DETECTION_DESTINATION_IP 16389 4689 See Section 2.23. 4691 COOKIE 16390 4692 See Section 2.6. 4694 USE_TRANSPORT_MODE 16391 4695 See Section 1.3.1. 4697 HTTP_CERT_LOOKUP_SUPPORTED 16392 4698 See Section 3.6. 4700 REKEY_SA 16393 4701 See Section 1.3.3. 4703 ESP_TFC_PADDING_NOT_SUPPORTED 16394 4704 See Section 1.3.1. 4706 NON_FIRST_FRAGMENTS_ALSO 16395 4707 See Section 1.3.1. 4709 3.11. Delete Payload 4711 The Delete Payload, denoted D in this document, contains a protocol 4712 specific security association identifier that the sender has removed 4713 from its security association database and is, therefore, no longer 4714 valid. Figure 17 shows the format of the Delete Payload. It is 4715 possible to send multiple SPIs in a Delete payload; however, each SPI 4716 MUST be for the same protocol. Mixing of protocol identifiers MUST 4717 NOT be performed in the Delete payload. It is permitted, however, to 4718 include multiple Delete payloads in a single INFORMATIONAL exchange 4719 where each Delete payload lists SPIs for a different protocol. 4721 Deletion of the IKE SA is indicated by a protocol ID of 1 (IKE) but 4722 no SPIs. Deletion of a Child SA, such as ESP or AH, will contain the 4723 IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI 4724 is the SPI the sending endpoint would expect in inbound ESP or AH 4725 packets. 4727 The Delete Payload is defined as follows: 4729 1 2 3 4730 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 4731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4732 | Next Payload |C| RESERVED | Payload Length | 4733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4734 | Protocol ID | SPI Size | Num of SPIs | 4735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4736 | | 4737 ~ Security Parameter Index(es) (SPI) ~ 4738 | | 4739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4741 Figure 17: Delete Payload Format 4743 o Protocol ID (1 octet) - Must be 1 for an IKE SA, 2 for AH, or 3 4744 for ESP. 4746 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 4747 protocol ID. It MUST be zero for IKE (SPI is in message header) 4748 or four for AH and ESP. 4750 o Num of SPIs (2 octets, unsigned integer) - The number of SPIs 4751 contained in the Delete payload. The size of each SPI is defined 4752 by the SPI Size field. 4754 o Security Parameter Index(es) (variable length) - Identifies the 4755 specific security association(s) to delete. The length of this 4756 field is determined by the SPI Size and Num of SPIs fields. 4758 The payload type for the Delete Payload is forty two (42). 4760 3.12. Vendor ID Payload 4762 The Vendor ID Payload, denoted V in this document, contains a vendor 4763 defined constant. The constant is used by vendors to identify and 4764 recognize remote instances of their implementations. This mechanism 4765 allows a vendor to experiment with new features while maintaining 4766 backward compatibility. 4768 A Vendor ID payload MAY announce that the sender is capable of 4769 accepting certain extensions to the protocol, or it MAY simply 4770 identify the implementation as an aid in debugging. A Vendor ID 4771 payload MUST NOT change the interpretation of any information defined 4772 in this specification (i.e., the critical bit MUST be set to 0). 4773 Multiple Vendor ID payloads MAY be sent. An implementation is not 4774 required to send any Vendor ID payload at all. 4776 A Vendor ID payload may be sent as part of any message. Reception of 4777 a familiar Vendor ID payload allows an implementation to make use of 4778 private use numbers described throughout this document, such as 4779 private payloads, private exchanges, private notifications, etc. 4780 Unfamiliar Vendor IDs MUST be ignored. 4782 Writers of Internet-Drafts who wish to extend this protocol MUST 4783 define a Vendor ID payload to announce the ability to implement the 4784 extension in the Internet-Draft. It is expected that Internet-Drafts 4785 that gain acceptance and are standardized will be given "magic 4786 numbers" out of the Future Use range by IANA, and the requirement to 4787 use a Vendor ID will go away. 4789 The Vendor ID Payload fields are defined as follows: 4791 1 2 3 4792 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 4793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4794 | Next Payload |C| RESERVED | Payload Length | 4795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4796 | | 4797 ~ Vendor ID (VID) ~ 4798 | | 4799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4801 Figure 18: Vendor ID Payload Format 4803 o Vendor ID (variable length) - It is the responsibility of the 4804 person choosing the Vendor ID to assure its uniqueness in spite of 4805 the absence of any central registry for IDs. Good practice is to 4806 include a company name, a person name, or some such. If you want 4807 to show off, you might include the latitude and longitude and time 4808 where you were when you chose the ID and some random input. A 4809 message digest of a long unique string is preferable to the long 4810 unique string itself. 4812 The payload type for the Vendor ID Payload is forty three (43). 4814 3.13. Traffic Selector Payload 4816 The Traffic Selector Payload, denoted TS in this document, allows 4817 peers to identify packet flows for processing by IPsec security 4818 services. The Traffic Selector Payload consists of the IKE generic 4819 payload header followed by individual traffic selectors as follows: 4821 1 2 3 4822 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 4823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4824 | Next Payload |C| RESERVED | Payload Length | 4825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4826 | Number of TSs | RESERVED | 4827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4828 | | 4829 ~ ~ 4830 | | 4831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4833 Figure 19: Traffic Selectors Payload Format 4835 o Number of TSs (1 octet) - Number of traffic selectors being 4836 provided. 4838 o RESERVED - This field MUST be sent as zero and MUST be ignored on 4839 receipt. 4841 o Traffic Selectors (variable length) - One or more individual 4842 traffic selectors. 4844 The length of the Traffic Selector payload includes the TS header and 4845 all the traffic selectors. 4847 The payload type for the Traffic Selector payload is forty four (44) 4848 for addresses at the initiator's end of the SA and forty five (45) 4849 for addresses at the responder's end. 4851 There is no requirement that TSi and TSr contain the same number of 4852 individual traffic selectors. Thus, they are interpreted as follows: 4853 a packet matches a given TSi/TSr if it matches at least one of the 4854 individual selectors in TSi, and at least one of the individual 4855 selectors in TSr. 4857 For instance, the following traffic selectors: 4859 TSi = ((17, 100, 198.51.100.66-198.51.100.66), 4860 (17, 200, 198.51.100.66-198.51.100.66)) 4861 TSr = ((17, 300, 0.0.0.0-255.255.255.255), 4862 (17, 400, 0.0.0.0-255.255.255.255)) 4864 would match UDP packets from 198.51.100.66 to anywhere, with any of 4865 the four combinations of source/destination ports (100,300), 4866 (100,400), (200,300), and (200, 400). 4868 Thus, some types of policies may require several Child SA pairs. For 4869 instance, a policy matching only source/destination ports (100,300) 4870 and (200,400), but not the other two combinations, cannot be 4871 negotiated as a single Child SA pair. 4873 3.13.1. Traffic Selector 4875 1 2 3 4876 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 4877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4878 | TS Type |IP Protocol ID*| Selector Length | 4879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4880 | Start Port* | End Port* | 4881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4882 | | 4883 ~ Starting Address* ~ 4884 | | 4885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4886 | | 4887 ~ Ending Address* ~ 4888 | | 4889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4891 Figure 20: Traffic Selector 4893 *Note: All fields other than TS Type and Selector Length depend on 4894 the TS Type. The fields shown are for TS Types 7 and 8, the only two 4895 values currently defined. 4897 o TS Type (one octet) - Specifies the type of traffic selector. 4899 o IP protocol ID (1 octet) - Value specifying an associated IP 4900 protocol ID (such as UDP, TCP, and ICMP). A value of zero means 4901 that the protocol ID is not relevant to this traffic selector-- 4902 the SA can carry all protocols. 4904 o Selector Length - Specifies the length of this Traffic Selector 4905 substructure including the header. 4907 o Start Port (2 octets, unsigned integer) - Value specifying the 4908 smallest port number allowed by this traffic selector. For 4909 protocols for which port is undefined (including protocol 0), or 4910 if all ports are allowed, this field MUST be zero. ICMP and 4911 ICMPv6 Type and Code values, as well as MIPv6 MH Type values, are 4912 represented in this field as specified in Section 4.4.1.1 of 4913 [IPSECARCH]. ICMP Type and Code values are treated as a single 4914 16-bit integer port number, with Type in the most significant 4915 eight bits and Code in the least significant eight bits. MIPv6 MH 4916 Type values are treated as a single 16-bit integer port number, 4917 with Type in the most significant eight bits and the least 4918 significant eight bits set to zero. 4920 o End Port (2 octets, unsigned integer) - Value specifying the 4921 largest port number allowed by this traffic selector. For 4922 protocols for which port is undefined (including protocol 0), or 4923 if all ports are allowed, this field MUST be 65535. ICMP and 4924 ICMPv6 Type and Code values, as well as MIPv6 MH Type values, are 4925 represented in this field as specified in Section 4.4.1.1 of 4926 [IPSECARCH]. ICMP Type and Code values are treated as a single 4927 16-bit integer port number, with Type in the most significant 4928 eight bits and Code in the least significant eight bits. MIPv6 MH 4929 Type values are treated as a single 16-bit integer port number, 4930 with Type in the most significant eight bits and the least 4931 significant eight bits set to zero. 4933 o Starting Address - The smallest address included in this Traffic 4934 Selector (length determined by TS type). 4936 o Ending Address - The largest address included in this Traffic 4937 Selector (length determined by TS type). 4939 Systems that are complying with [IPSECARCH] that wish to indicate 4940 "ANY" ports MUST set the start port to 0 and the end port to 65535; 4941 note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems 4942 working with [IPSECARCH] that wish to indicate "OPAQUE" ports, but 4943 not "ANY" ports, MUST set the start port to 65535 and the end port to 4944 0. 4946 The traffic selector types 7 and 8 can also refer to ICMP or ICMPv6 4947 type and code fields, as well as MH Type fields for the IPv6 mobility 4948 header [MIPV6]. Note, however, that neither ICMP nor MIPv6 packets 4949 have separate source and destination fields. The method for 4950 specifying the traffic selectors for ICMP and MIPv6 is shown by 4951 example in Section 4.4.1.3 of [IPSECARCH]. 4953 The following table lists values for the Traffic Selector Type field 4954 and the corresponding Address Selector Data. The values in the 4955 following table are only current as of the publication date of RFC 4956 4306. Other values may have been added since then or will be added 4957 after the publication of this document. Readers should refer to 4958 [IKEV2IANA] for the latest values. 4960 TS Type Value 4961 ------------------------------------------------------------------- 4962 TS_IPV4_ADDR_RANGE 7 4964 A range of IPv4 addresses, represented by two four-octet 4965 values. The first value is the beginning IPv4 address 4966 (inclusive) and the second value is the ending IPv4 address 4967 (inclusive). All addresses falling between the two specified 4968 addresses are considered to be within the list. 4970 TS_IPV6_ADDR_RANGE 8 4972 A range of IPv6 addresses, represented by two sixteen-octet 4973 values. The first value is the beginning IPv6 address 4974 (inclusive) and the second value is the ending IPv6 address 4975 (inclusive). All addresses falling between the two specified 4976 addresses are considered to be within the list. 4978 3.14. Encrypted Payload 4980 The Encrypted Payload, denoted SK{...} in this document, contains 4981 other payloads in encrypted form. The Encrypted Payload, if present 4982 in a message, MUST be the last payload in the message. Often, it is 4983 the only payload in the message. This payload is also called the 4984 "Encrypted and Authenticated" payload. 4986 The algorithms for encryption and integrity protection are negotiated 4987 during IKE SA setup, and the keys are computed as specified in 4988 Section 2.14 and Section 2.18. 4990 This document specifies the cryptographic processing of Encrypted 4991 payloads using a block cipher in CBC mode and an integrity check 4992 algorithm that computes a fixed-length checksum over a variable size 4993 message. The design is modeled after the ESP algorithms described in 4994 RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document 4995 completely specifies the cryptographic processing of IKE data, but 4996 those documents should be consulted for design rationale. Future 4997 documents may specify the processing of Encrypted payloads for other 4998 types of transforms, such as counter mode encryption and 4999 authenticated encryption algorithms. Peers MUST NOT negotiate 5000 transforms for which no such specification exists. 5002 When an authenticated encryption algorithm is used to protect the IKE 5003 SA, the construction of the encrypted payload is different than what 5004 is described here. See [AEAD] for more information on authenticated 5005 encryption algorithms and their use in ESP. 5007 The payload type for an Encrypted payload is forty six (46). The 5008 Encrypted Payload consists of the IKE generic payload header followed 5009 by individual fields as follows: 5011 1 2 3 5012 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 5013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5014 | Next Payload |C| RESERVED | Payload Length | 5015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5016 | Initialization Vector | 5017 | (length is block size for encryption algorithm) | 5018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5019 ~ Encrypted IKE Payloads ~ 5020 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5021 | | Padding (0-255 octets) | 5022 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 5023 | | Pad Length | 5024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5025 ~ Integrity Checksum Data ~ 5026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5028 Figure 21: Encrypted Payload Format 5030 o Next Payload - The payload type of the first embedded payload. 5031 Note that this is an exception in the standard header format, 5032 since the Encrypted payload is the last payload in the message and 5033 therefore the Next Payload field would normally be zero. But 5034 because the content of this payload is embedded payloads and there 5035 was no natural place to put the type of the first one, that type 5036 is placed here. 5038 o Payload Length - Includes the lengths of the header, IV, Encrypted 5039 IKE Payloads, Padding, Pad Length, and Integrity Checksum Data. 5041 o Initialization Vector - For CBC mode ciphers, the length of the 5042 initialization vector (IV) is equal to the block length of the 5043 underlying encryption algorithm. Senders MUST select a new 5044 unpredictable IV for every message; recipients MUST accept any 5045 value. The reader is encouraged to consult [MODES] for advice on 5046 IV generation. In particular, using the final ciphertext block of 5047 the previous message is not considered unpredictable. For modes 5048 other than CBC, the IV format and processing is specified in the 5049 document specifying the encryption algorithm and mode. 5051 o IKE Payloads are as specified earlier in this section. This field 5052 is encrypted with the negotiated cipher. 5054 o Padding MAY contain any value chosen by the sender, and MUST have 5055 a length that makes the combination of the Payloads, the Padding, 5056 and the Pad Length to be a multiple of the encryption block size. 5057 This field is encrypted with the negotiated cipher. 5059 o Pad Length is the length of the Padding field. The sender SHOULD 5060 set the Pad Length to the minimum value that makes the combination 5061 of the Payloads, the Padding, and the Pad Length a multiple of the 5062 block size, but the recipient MUST accept any length that results 5063 in proper alignment. This field is encrypted with the negotiated 5064 cipher. 5066 o Integrity Checksum Data is the cryptographic checksum of the 5067 entire message starting with the Fixed IKE Header through the Pad 5068 Length. The checksum MUST be computed over the encrypted message. 5069 Its length is determined by the integrity algorithm negotiated. 5071 3.15. Configuration Payload 5073 The Configuration payload, denoted CP in this document, is used to 5074 exchange configuration information between IKE peers. The exchange 5075 is for an IRAC to request an internal IP address from an IRAS and to 5076 exchange other information of the sort that one would acquire with 5077 Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly 5078 connected to a LAN. 5080 The Configuration Payload is defined as follows: 5082 1 2 3 5083 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 5084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5085 | Next Payload |C| RESERVED | Payload Length | 5086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5087 | CFG Type | RESERVED | 5088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5089 | | 5090 ~ Configuration Attributes ~ 5091 | | 5092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5094 Figure 22: Configuration Payload Format 5096 The payload type for the Configuration Payload is forty seven (47). 5098 o CFG Type (1 octet) - The type of exchange represented by the 5099 Configuration Attributes. The values in the following table are 5100 only current as of the publication date of RFC 4306. Other values 5101 may have been added since then or will be added after the 5102 publication of this document. Readers should refer to [IKEV2IANA] 5103 for the latest values. 5105 CFG Type Value 5106 -------------------------- 5107 CFG_REQUEST 1 5108 CFG_REPLY 2 5109 CFG_SET 3 5110 CFG_ACK 4 5112 o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on 5113 receipt. 5115 o Configuration Attributes (variable length) - These are type length 5116 value (TLV) structures specific to the Configuration Payload and 5117 are defined below. There may be zero or more Configuration 5118 Attributes in this payload. 5120 3.15.1. Configuration Attributes 5122 1 2 3 5123 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 5124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5125 |R| Attribute Type | Length | 5126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5127 | | 5128 ~ Value ~ 5129 | | 5130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5132 Figure 23: Configuration Attribute Format 5134 o Reserved (1 bit) - This bit MUST be set to zero and MUST be 5135 ignored on receipt. 5137 o Attribute Type (15 bits) - A unique identifier for each of the 5138 Configuration Attribute Types. 5140 o Length (2 octets, unsigned integer) - Length in octets of Value. 5142 o Value (0 or more octets) - The variable-length value of this 5143 Configuration Attribute. The following lists the attribute types. 5145 The values in the following table are only current as of the 5146 publication date of RFC 4306 (except INTERNAL_ADDRESS_EXPIRY and 5147 INTERNAL_IP6_NBNS which were removed by this document). Other values 5148 may have been added since then or will be added after the publication 5149 of this document. Readers should refer to [IKEV2IANA] for the latest 5150 values. 5152 Attribute Type Value Multi-Valued Length 5153 ------------------------------------------------------------ 5154 INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets 5155 INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets 5156 INTERNAL_IP4_DNS 3 YES 0 or 4 octets 5157 INTERNAL_IP4_NBNS 4 YES 0 or 4 octets 5158 INTERNAL_IP4_DHCP 6 YES 0 or 4 octets 5159 APPLICATION_VERSION 7 NO 0 or more 5160 INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets 5161 INTERNAL_IP6_DNS 10 YES 0 or 16 octets 5162 INTERNAL_IP6_DHCP 12 YES 0 or 16 octets 5163 INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets 5164 SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 5165 INTERNAL_IP6_SUBNET 15 YES 17 octets 5167 * These attributes may be multi-valued on return only if 5168 multiple values were requested. 5170 o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the 5171 internal network, sometimes called a red node address or private 5172 address and MAY be a private address on the Internet. In a 5173 request message, the address specified is a requested address (or 5174 a zero-length address if no specific address is requested). If a 5175 specific address is requested, it likely indicates that a previous 5176 connection existed with this address and the requestor would like 5177 to reuse that address. With IPv6, a requestor MAY supply the low- 5178 order address octets it wants to use. Multiple internal addresses 5179 MAY be requested by requesting multiple internal address 5180 attributes. The responder MAY only send up to the number of 5181 addresses requested. The INTERNAL_IP6_ADDRESS is made up of two 5182 fields: the first is a 16-octet IPv6 address, and the second is a 5183 one-octet prefix-length as defined in [ADDRIPV6]. The requested 5184 address is valid as long as this IKE SA (or its rekeyed 5185 successors) requesting the address is valid. This is described in 5186 more detail in Section 3.15.3. 5188 o INTERNAL_IP4_NETMASK - The internal network's netmask. Only one 5189 netmask is allowed in the request and response messages (e.g., 5190 255.255.255.0), and it MUST be used only with an 5191 INTERNAL_IP4_ADDRESS attribute. INTERNAL_IP4_NETMASK in a 5192 CFG_REPLY means roughly the same thing as INTERNAL_IP4_SUBNET 5193 containing the same information ("send traffic to these addresses 5194 through me"), but also implies a link boundary. For instance, the 5195 client could use its own address and the netmask to calculate the 5196 broadcast address of the link. An empty INTERNAL_IP4_NETMASK 5197 attribute can be included in a CFG_REQUEST to request this 5198 information (although the gateway can send the information even 5199 when not requested). Non-empty values for this attribute in a 5200 CFG_REQUEST do not make sense and thus MUST NOT be included. 5202 o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS 5203 server within the network. Multiple DNS servers MAY be requested. 5204 The responder MAY respond with zero or more DNS server attributes. 5206 o INTERNAL_IP4_NBNS - Specifies an address of a NetBios Name Server 5207 (WINS) within the network. Multiple NBNS servers MAY be 5208 requested. The responder MAY respond with zero or more NBNS 5209 server attributes. 5211 o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send 5212 any internal DHCP requests to the address contained within the 5213 attribute. Multiple DHCP servers MAY be requested. The responder 5214 MAY respond with zero or more DHCP server attributes. 5216 o APPLICATION_VERSION - The version or application information of 5217 the IPsec host. This is a string of printable ASCII characters 5218 that is NOT null terminated. 5220 o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge- 5221 device protects. This attribute is made up of two fields: the 5222 first being an IP address and the second being a netmask. 5223 Multiple sub-networks MAY be requested. The responder MAY respond 5224 with zero or more sub-network attributes. This is discussed in 5225 more detail in Section 3.15.2. 5227 o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute 5228 MUST be zero-length and specifies a query to the responder to 5229 reply back with all of the attributes that it supports. The 5230 response contains an attribute that contains a set of attribute 5231 identifiers each in 2 octets. The length divided by 2 (octets) 5232 would state the number of supported attributes contained in the 5233 response. 5235 o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge- 5236 device protects. This attribute is made up of two fields: the 5237 first is a 16-octet IPv6 address, and the second is a one-octet 5238 prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY 5239 be requested. The responder MAY respond with zero or more sub- 5240 network attributes. This is discussed in more detail in 5241 Section 3.15.2. 5243 Note that no recommendations are made in this document as to how an 5244 implementation actually figures out what information to send in a 5245 response. That is, we do not recommend any specific method of an 5246 IRAS determining which DNS server should be returned to a requesting 5247 IRAC. 5249 The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request 5250 information from its peer. If an attribute in the CFG_REQUEST 5251 Configuration Payload is not zero-length, it is taken as a suggestion 5252 for that attribute. The CFG_REPLY Configuration Payload MAY return 5253 that value, or a new one. It MAY also add new attributes and not 5254 include some requested ones. Unrecognized or unsupported attributes 5255 MUST be ignored in both requests and responses. 5257 The CFG_SET and CFG_ACK pair allows an IKE endpoint to push 5258 configuration data to its peer. In this case, the CFG_SET 5259 Configuration Payload contains attributes the initiator wants its 5260 peer to alter. The responder MUST return a Configuration Payload if 5261 it accepted any of the configuration data and it MUST contain the 5262 attributes that the responder accepted with zero-length data. Those 5263 attributes that it did not accept MUST NOT be in the CFG_ACK 5264 Configuration Payload. If no attributes were accepted, the responder 5265 MUST return either an empty CFG_ACK payload or a response message 5266 without a CFG_ACK payload. There are currently no defined uses for 5267 the CFG_SET/CFG_ACK exchange, though they may be used in connection 5268 with extensions based on Vendor IDs. An implementation of this 5269 specification MAY ignore CFG_SET payloads. 5271 3.15.2. Meaning of INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET 5273 INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets, 5274 ones that need one or more separate SAs, that can be reached through 5275 the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET 5276 attributes may also express the gateway's policy about what traffic 5277 should be sent through the gateway; the client can choose whether 5278 other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is 5279 sent through the gateway or directly to the destination. Thus, 5280 traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET 5281 attributes should be sent through the gateway that announces the 5282 attributes. If there are no existing Child SAs whose traffic 5283 selectors cover the address in question, new SAs need to be created. 5285 For instance, if there are two subnets, 198.51.100.0/26 and 5286 192.0.2.0/24, and the client's request contains the following: 5288 CP(CFG_REQUEST) = 5289 INTERNAL_IP4_ADDRESS() 5290 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) 5291 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) 5293 then a valid response could be the following (in which TSr and 5294 INTERNAL_IP4_SUBNET contain the same information): 5296 CP(CFG_REPLY) = 5297 INTERNAL_IP4_ADDRESS(198.51.100.234) 5298 INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192) 5299 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 5300 TSi = (0, 0-65535, 198.51.100.234-198.51.100.234) 5301 TSr = ((0, 0-65535, 198.51.100.0-198.51.100.63), 5302 (0, 0-65535, 192.0.2.0-192.0.2.255)) 5304 In these cases, the INTERNAL_IP4_SUBNET does not really carry any 5305 useful information. 5307 A different possible response would have been this: 5309 CP(CFG_REPLY) = 5310 INTERNAL_IP4_ADDRESS(198.51.100.234) 5311 INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192) 5312 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 5313 TSi = (0, 0-65535, 198.51.100.234-198.51.100.234) 5314 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) 5316 That response would mean that the client can send all its traffic 5317 through the gateway, but the gateway does not mind if the client 5318 sends traffic not included by INTERNAL_IP4_SUBNET directly to the 5319 destination (without going through the gateway). 5321 A different situation arises if the gateway has a policy that 5322 requires the traffic for the two subnets to be carried in separate 5323 SAs. Then a response like this would indicate to the client that if 5324 it wants access to the second subnet, it needs to create a separate 5325 SA: 5327 CP(CFG_REPLY) = 5328 INTERNAL_IP4_ADDRESS(198.51.100.234) 5329 INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192) 5330 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 5331 TSi = (0, 0-65535, 198.51.100.234-198.51.100.234) 5332 TSr = (0, 0-65535, 198.51.100.0-198.51.100.63) 5334 INTERNAL_IP4_SUBNET can also be useful if the client's TSr included 5335 only part of the address space. For instance, if the client requests 5336 the following: 5338 CP(CFG_REQUEST) = 5339 INTERNAL_IP4_ADDRESS() 5340 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) 5341 TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) 5343 then the gateway's response might be: 5345 CP(CFG_REPLY) = 5346 INTERNAL_IP4_ADDRESS(198.51.100.234) 5347 INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192) 5348 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 5349 TSi = (0, 0-65535, 198.51.100.234-198.51.100.234) 5350 TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) 5352 Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET in 5353 CFG_REQUESTs is unclear, they cannot be used reliably in 5354 CFG_REQUESTs. 5356 3.15.3. Configuration payloads for IPv6 5358 The configuration payloads for IPv6 are based on the corresponding 5359 IPv4 payloads, and do not fully follow the "normal IPv6 way of doing 5360 things". In particular, IPv6 stateless autoconfiguration or router 5361 advertisement messages are not used; neither is neighbor discovery. 5362 Note that there is an additional document that discusses IPv6 5363 configuration in IKEv2, [IPV6CONFIG]. At the present time, it is an 5364 experimental document, but there is a hope that with more 5365 implementation experience, it will gain the same standards treatment 5366 as this document. 5368 A client can be assigned an IPv6 address using the 5369 INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange might 5370 look like this: 5372 CP(CFG_REQUEST) = 5373 INTERNAL_IP6_ADDRESS() 5374 INTERNAL_IP6_DNS() 5375 TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 5376 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 5378 CP(CFG_REPLY) = 5379 INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) 5380 INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) 5381 TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) 5382 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 5384 The client MAY send a non-empty INTERNAL_IP6_ADDRESS attribute in the 5385 CFG_REQUEST to request a specific address or interface identifier. 5386 The gateway first checks if the specified address is acceptable, and 5387 if it is, returns that one. If the address was not acceptable, the 5388 gateway attempts to use the interface identifier with some other 5389 prefix; if even that fails, the gateway selects another interface 5390 identifier. 5392 The INTERNAL_IP6_ADDRESS attribute also contains a prefix length 5393 field. When used in a CFG_REPLY, this corresponds to the 5394 INTERNAL_IP4_NETMASK attribute in the IPv4 case. 5396 Although this approach to configuring IPv6 addresses is reasonably 5397 simple, it has some limitations. IPsec tunnels configured using 5398 IKEv2 are not fully-featured "interfaces" in the IPv6 addressing 5399 architecture sense [ADDRIPV6]. In particular, they do not 5400 necessarily have link-local addresses, and this may complicate the 5401 use of protocols that assume them, such as [MLDV2]. 5403 3.15.4. Address Assignment Failures 5405 If the responder encounters an error while attempting to assign an IP 5406 address to the initiator during the processing of a Configuration 5407 Payload, it responds with an INTERNAL_ADDRESS_FAILURE notification. 5408 The IKE SA is still created even if the initial Child SA cannot be 5409 created because of this failure. If this error is generated within 5410 an IKE_AUTH exchange, no Child SA will be created. However, there 5411 are some more complex error cases. 5413 If the responder does not support configuration payloads at all, it 5414 can simply ignore all configuration payloads. This type of 5415 implementation never sends INTERNAL_ADDRESS_FAILURE notifications. 5416 If the initiator requires the assignment of an IP address, it will 5417 treat a response without CFG_REPLY as an error. 5419 The initiator may request a particular type of address (IPv4 or IPv6) 5420 that the responder does not support, even though the responder 5421 supports configuration payloads. In this case, the responder simply 5422 ignores the type of address it does not support and processes the 5423 rest of the request as usual. 5425 If the initiator requests multiple addresses of a type that the 5426 responder supports, and some (but not all) of the requests fail, the 5427 responder replies with the successful addresses only. The responder 5428 sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned. 5430 If the initiator does not receive the IP address(es) required by its 5431 policy, it MAY keep the IKE SA up and retry the configuration payload 5432 as separate INFORMATIONAL exchange after suitable timeout, or it MAY 5433 tear down the IKE SA by sending a DELETE payload inside a separate 5434 INFORMATIONAL exchange and later retry IKE SA from the beginning 5435 after some timeout. Such a timeout should not be too short 5436 (especially if the IKE SA is started from the beginning) because 5437 these error situations may not be able to be fixed quickly; the 5438 timeout should likely be several minutes. For example, an address 5439 shortage problem on the responder will probably only be fixed when 5440 more entries are returned to the address pool when other clients 5441 disconnect or when responder is reconfigured with larger address 5442 pool. 5444 3.16. Extensible Authentication Protocol (EAP) Payload 5446 The Extensible Authentication Protocol Payload, denoted EAP in this 5447 document, allows IKE SAs to be authenticated using the protocol 5448 defined in RFC 3748 [EAP] and subsequent extensions to that protocol. 5449 When using EAP, an appropriate EAP method needs to be selected. Many 5450 of these methods have been defined, specifying the protocol's use 5451 with various authentication mechanisms. EAP method types are listed 5452 in [EAP-IANA]. A short summary of the EAP format is included here 5453 for clarity. 5455 1 2 3 5456 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 5457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5458 | Next Payload |C| RESERVED | Payload Length | 5459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5460 | | 5461 ~ EAP Message ~ 5462 | | 5463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5465 Figure 24: EAP Payload Format 5467 The payload type for an EAP Payload is forty eight (48). 5469 1 2 3 5470 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 5471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5472 | Code | Identifier | Length | 5473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5474 | Type | Type_Data... 5475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 5477 Figure 25: EAP Message Format 5479 o Code (1 octet) indicates whether this message is a Request (1), 5480 Response (2), Success (3), or Failure (4). 5482 o Identifier (1 octet) is used in PPP to distinguish replayed 5483 messages from repeated ones. Since in IKE, EAP runs over a 5484 reliable protocol, it serves no function here. In a response 5485 message, this octet MUST be set to match the identifier in the 5486 corresponding request. 5488 o Length (2 octets, unsigned integer) is the length of the EAP 5489 message and MUST be four less than the Payload Length of the 5490 encapsulating payload. 5492 o Type (1 octet) is present only if the Code field is Request (1) or 5493 Response (2). For other codes, the EAP message length MUST be 5494 four octets and the Type and Type_Data fields MUST NOT be present. 5495 In a Request (1) message, Type indicates the data being requested. 5496 In a Response (2) message, Type MUST either be Nak or match the 5497 type of the data requested. Note that since IKE passes an 5498 indication of initiator identity in the first message in the 5499 IKE_AUTH exchange, the responder SHOULD NOT send EAP Identity 5500 requests (type 1). The initiator MAY, however, respond to such 5501 requests if it receives them. 5503 o Type_Data (Variable Length) varies with the Type of Request and 5504 the associated Response. For the documentation of the EAP 5505 methods, see [EAP]. 5507 Note that since IKE passes an indication of initiator identity in the 5508 first message in the IKE_AUTH exchange, the responder should not send 5509 EAP Identity requests. The initiator may, however, respond to such 5510 requests if it receives them. 5512 4. Conformance Requirements 5514 In order to assure that all implementations of IKEv2 can 5515 interoperate, there are "MUST support" requirements in addition to 5516 those listed elsewhere. Of course, IKEv2 is a security protocol, and 5517 one of its major functions is to allow only authorized parties to 5518 successfully complete establishment of SAs. So a particular 5519 implementation may be configured with any of a number of restrictions 5520 concerning algorithms and trusted authorities that will prevent 5521 universal interoperability. 5523 IKEv2 is designed to permit minimal implementations that can 5524 interoperate with all compliant implementations. The following are 5525 some of the features that can be omitted in a minimal implementation: 5527 o Ability to negotiate SAs through a NAT and tunnel the resulting 5528 ESP SA over UDP. 5530 o Ability to request (and respond to a request for) a temporary IP 5531 address on the remote end of a tunnel. 5533 o Ability to support EAP-based authentication. 5535 o Ability to support window sizes greater than one. 5537 o Ability to establish multiple ESP or AH SAs within a single IKE 5538 SA. 5540 o Ability to rekey SAs. 5542 To assure interoperability, all implementations MUST be capable of 5543 parsing all payload types (if only to skip over them) and to ignore 5544 payload types that it does not support unless the critical bit is set 5545 in the payload header. If the critical bit is set in an unsupported 5546 payload header, all implementations MUST reject the messages 5547 containing those payloads. 5549 Every implementation MUST be capable of doing four-message 5550 IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, 5551 one for ESP or AH). Implementations MAY be initiate-only or respond- 5552 only if appropriate for their platform. Every implementation MUST be 5553 capable of responding to an INFORMATIONAL exchange, but a minimal 5554 implementation MAY respond to any request in the INFORMATIONAL 5555 exchange with an empty response (note that within the context of an 5556 IKE SA, an "empty" message consists of an IKE header followed by an 5557 Encrypted payload with no payloads contained in it). A minimal 5558 implementation MAY support the CREATE_CHILD_SA exchange only in so 5559 far as to recognize requests and reject them with a Notify payload of 5560 type NO_ADDITIONAL_SAS. A minimal implementation need not be able to 5561 initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA 5562 expires (based on locally configured values of either lifetime or 5563 octets passed), and implementation MAY either try to renew it with a 5564 CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and 5565 create a new one. If the responder rejects the CREATE_CHILD_SA 5566 request with a NO_ADDITIONAL_SAS notification, the implementation 5567 MUST be capable of instead deleting the old SA and creating a new 5568 one. 5570 Implementations are not required to support requesting temporary IP 5571 addresses or responding to such requests. If an implementation does 5572 support issuing such requests and its policy requires using temporary 5573 IP addresses, it MUST include a CP payload in the first message in 5574 the IKE_AUTH exchange containing at least a field of type 5575 INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. All other fields are 5576 optional. If an implementation supports responding to such requests, 5577 it MUST parse the CP payload of type CFG_REQUEST in the first message 5578 in the IKE_AUTH exchange and recognize a field of type 5579 INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports leasing 5580 an address of the appropriate type, it MUST return a CP payload of 5581 type CFG_REPLY containing an address of the requested type. The 5582 responder may include any other related attributes. 5584 For an implementation to be called conforming to this specification, 5585 it MUST be possible to configure it to accept the following: 5587 o PKIX Certificates containing and signed by RSA keys of size 1024 5588 or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, 5589 ID_RFC822_ADDR, or ID_DER_ASN1_DN. 5591 o Shared key authentication where the ID passed is any of ID_KEY_ID, 5592 ID_FQDN, or ID_RFC822_ADDR. 5594 o Authentication where the responder is authenticated using PKIX 5595 Certificates and the initiator is authenticated using shared key 5596 authentication. 5598 5. Security Considerations 5600 While this protocol is designed to minimize disclosure of 5601 configuration information to unauthenticated peers, some such 5602 disclosure is unavoidable. One peer or the other must identify 5603 itself first and prove its identity first. To avoid probing, the 5604 initiator of an exchange is required to identify itself first, and 5605 usually is required to authenticate itself first. The initiator can, 5606 however, learn that the responder supports IKE and what cryptographic 5607 protocols it supports. The responder (or someone impersonating the 5608 responder) can probe the initiator not only for its identity, but 5609 using CERTREQ payloads may be able to determine what certificates the 5610 initiator is willing to use. 5612 Use of EAP authentication changes the probing possibilities somewhat. 5613 When EAP authentication is used, the responder proves its identity 5614 before the initiator does, so an initiator that knew the name of a 5615 valid initiator could probe the responder for both its name and 5616 certificates. 5618 Repeated rekeying using CREATE_CHILD_SA without additional Diffie- 5619 Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a 5620 single key. Implementers should take note of this fact and set a 5621 limit on CREATE_CHILD_SA exchanges between exponentiations. This 5622 document does not prescribe such a limit. 5624 The strength of a key derived from a Diffie-Hellman exchange using 5625 any of the groups defined here depends on the inherent strength of 5626 the group, the size of the exponent used, and the entropy provided by 5627 the random number generator used. Due to these inputs, it is 5628 difficult to determine the strength of a key for any of the defined 5629 groups. Diffie-Hellman group number two, when used with a strong 5630 random number generator and an exponent no less than 200 bits, is 5631 common for use with 3DES. Group five provides greater security than 5632 group two. Group one is for historic purposes only and does not 5633 provide sufficient strength except for use with DES, which is also 5634 for historic use only. Implementations should make note of these 5635 estimates when establishing policy and negotiating security 5636 parameters. 5638 Note that these limitations are on the Diffie-Hellman groups 5639 themselves. There is nothing in IKE that prohibits using stronger 5640 groups nor is there anything that will dilute the strength obtained 5641 from stronger groups (limited by the strength of the other algorithms 5642 negotiated including the PRF). In fact, the extensible framework of 5643 IKE encourages the definition of more groups; use of elliptical curve 5644 groups may greatly increase strength using much smaller numbers. 5646 It is assumed that all Diffie-Hellman exponents are erased from 5647 memory after use. 5649 The IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator 5650 has been authenticated. As a result, an implementation of this 5651 protocol needs to be completely robust when deployed on any insecure 5652 network. Implementation vulnerabilities, particularly DoS attacks, 5653 can be exploited by unauthenticated peers. This issue is 5654 particularly worrisome because of the unlimited number of messages in 5655 EAP-based authentication. 5657 The strength of all keys is limited by the size of the output of the 5658 negotiated PRF. For this reason, a PRF whose output is less than 128 5659 bits (e.g., 3DES-CBC) MUST NOT be used with this protocol. 5661 The security of this protocol is critically dependent on the 5662 randomness of the randomly chosen parameters. These should be 5663 generated by a strong random or properly seeded pseudo-random source 5664 (see [RANDOMNESS]). Implementers should take care to ensure that use 5665 of random numbers for both keys and nonces is engineered in a fashion 5666 that does not undermine the security of the keys. 5668 For information on the rationale of many of the cryptographic design 5669 choices in this protocol, see [SIGMA] and [SKEME]. Though the 5670 security of negotiated Child SAs does not depend on the strength of 5671 the encryption and integrity protection negotiated in the IKE SA, 5672 implementations MUST NOT negotiate NONE as the IKE integrity 5673 protection algorithm or ENCR_NULL as the IKE encryption algorithm. 5675 When using pre-shared keys, a critical consideration is how to assure 5676 the randomness of these secrets. The strongest practice is to ensure 5677 that any pre-shared key contain as much randomness as the strongest 5678 key being negotiated. Deriving a shared secret from a password, 5679 name, or other low-entropy source is not secure. These sources are 5680 subject to dictionary and social engineering attacks, among others. 5682 The NAT_DETECTION_*_IP notifications contain a hash of the addresses 5683 and ports in an attempt to hide internal IP addresses behind a NAT. 5684 Since the IPv4 address space is only 32 bits, and it is usually very 5685 sparse, it would be possible for an attacker to find out the internal 5686 address used behind the NAT box by trying all possible IP addresses 5687 and trying to find the matching hash. The port numbers are normally 5688 fixed to 500, and the SPIs can be extracted from the packet. This 5689 reduces the number of hash calculations to 2^32. With an educated 5690 guess of the use of private address space, the number of hash 5691 calculations is much smaller. Designers should therefore not assume 5692 that use of IKE will not leak internal address information. 5694 When using an EAP authentication method that does not generate a 5695 shared key for protecting a subsequent AUTH payload, certain man-in- 5696 the-middle and server impersonation attacks are possible [EAPMITM]. 5697 These vulnerabilities occur when EAP is also used in protocols that 5698 are not protected with a secure tunnel. Since EAP is a general- 5699 purpose authentication protocol, which is often used to provide 5700 single-signon facilities, a deployed IPsec solution that relies on an 5701 EAP authentication method that does not generate a shared key (also 5702 known as a non-key-generating EAP method) can become compromised due 5703 to the deployment of an entirely unrelated application that also 5704 happens to use the same non-key-generating EAP method, but in an 5705 unprotected fashion. Note that this vulnerability is not limited to 5706 just EAP, but can occur in other scenarios where an authentication 5707 infrastructure is reused. For example, if the EAP mechanism used by 5708 IKEv2 utilizes a token authenticator, a man-in-the-middle attacker 5709 could impersonate the web server, intercept the token authentication 5710 exchange, and use it to initiate an IKEv2 connection. For this 5711 reason, use of non-key-generating EAP methods SHOULD be avoided where 5712 possible. Where they are used, it is extremely important that all 5713 usages of these EAP methods SHOULD utilize a protected tunnel, where 5714 the initiator validates the responder's certificate before initiating 5715 the EAP authentication. Implementers should describe the 5716 vulnerabilities of using non-key-generating EAP methods in the 5717 documentation of their implementations so that the administrators 5718 deploying IPsec solutions are aware of these dangers. 5720 An implementation using EAP MUST also use a public-key-based 5721 authentication of the server to the client before the EAP 5722 authentication begins, even if the EAP method offers mutual 5723 authentication. This avoids having additional IKEv2 protocol 5724 variations and protects the EAP data from active attackers. 5726 If the messages of IKEv2 are long enough that IP-level fragmentation 5727 is necessary, it is possible that attackers could prevent the 5728 exchange from completing by exhausting the reassembly buffers. The 5729 chances of this can be minimized by using the Hash and URL encodings 5730 instead of sending certificates (see Section 3.6). Additional 5731 mitigations are discussed in [DOSUDPPROT]. 5733 Admission control is critical to the security of the protocol. For 5734 example, trust anchors used for identifying IKE peers should probably 5735 be different than those used for other forms of trust, such as those 5736 used to identify public web servers. Moreover, although IKE provides 5737 a great deal of leeway in defining the security policy for a trusted 5738 peer's identity, credentials, and the correlation between them, 5739 having such security policy defined explicitly is essential to a 5740 secure implementation. 5742 5.1. Traffic selector authorization 5744 IKEv2 relies on information in the Peer Authorization Database (PAD) 5745 when determining what kind of Child SAs a peer is allowed to create. 5746 This process is described in [IPSECARCH] Section 4.4.3. When a peer 5747 requests the creation of an Child SA with some traffic selectors, the 5748 PAD must contain "Child SA Authorization Data" linking the identity 5749 authenticated by IKEv2 and the addresses permitted for traffic 5750 selectors. 5752 For example, the PAD might be configured so that authenticated 5753 identity "sgw23.example.com" is allowed to create Child SAs for 5754 192.0.2.0/24, meaning this security gateway is a valid 5755 "representative" for these addresses. Host-to-host IPsec requires 5756 similar entries, linking, for example, "fooserver4.example.com" with 5757 198.51.100.66/32, meaning this identity a valid "owner" or 5758 "representative" of the address in question. 5760 As noted in [IPSECARCH], "It is necessary to impose these constraints 5761 on creation of child SAs to prevent an authenticated peer from 5762 spoofing IDs associated with other, legitimate peers." In the 5763 example given above, a correct configuration of the PAD prevents 5764 sgw23 from creating Child SAs with address 198.51.100.66, and 5765 prevents fooserver4 from creating Child SAs with addresses from 5766 192.0.2.0/24. 5768 It is important to note that simply sending IKEv2 packets using some 5769 particular address does not imply a permission to create Child SAs 5770 with that address in the traffic selectors. For example, even if 5771 sgw23 would be able to spoof its IP address as 198.51.100.66, it 5772 could not create Child SAs matching fooserver4's traffic. 5774 The IKEv2 specification does not specify how exactly IP address 5775 assignment using configuration payloads interacts with the PAD. Our 5776 interpretation is that when a security gateway assigns an address 5777 using configuration payloads, it also creates a temporary PAD entry 5778 linking the authenticated peer identity and the newly allocated inner 5779 address. 5781 It has been recognized that configuring the PAD correctly may be 5782 difficult in some environments. For instance, if IPsec is used 5783 between a pair of hosts whose addresses are allocated dynamically 5784 using DHCP, it is extremely difficult to ensure that the PAD 5785 specifies the correct "owner" for each IP address. This would 5786 require a mechanism to securely convey address assignments from the 5787 DHCP server, and link them to identities authenticated using IKEv2. 5789 Due to this limitation, some vendors have been known to configure 5790 their PADs to allow an authenticated peer to create Child SAs with 5791 traffic selectors containing the same address that was used for the 5792 IKEv2 packets. In environments where IP spoofing is possible (i.e., 5793 almost everywhere) this essentially allows any peer to create Child 5794 SAs with any traffic selectors. This is not an appropriate or secure 5795 configuration in most circumstances. See [H2HIPSEC] for an extensive 5796 discussion about this issue, and the limitations of host-to-host 5797 IPsec in general. 5799 6. IANA Considerations 5801 [IKEV2] defined many field types and values. IANA has already 5802 registered those types and values in [IKEV2IANA], so they are not 5803 listed here again. 5805 Two items are removed from the IKEv2 Configuration Payload Attribute 5806 Types table: INTERNAL_IP6_NBNS and INTERNAL_ADDRESS_EXPIRY. 5808 Two new additions to the IKEv2 parameters "NOTIFY MESSAGES - ERROR 5809 TYPES" registry are defined here that were not defined in [IKEV2]: 5811 {TBA1} TEMPORARY_FAILURE 5812 {TBA2} CHILD_SA_NOT_FOUND 5814 IANA should change the exiting IKEv2 Payload Types table from: 5816 46 Encrypted E [RFC4306] 5818 to 5820 46 Encrypted and Authenticated SK [This document] 5822 IANA should update all references to RFC 4306 to point to this 5823 document. 5825 7. Acknowledgements 5827 Many individuals in the IPsecME Working Group were very helpful in 5828 contributing ideas and text for this document, as well as in 5829 reviewing the clarifications suggested by others. 5831 The acknowledgements from the IKEv2 document were: 5833 This document is a collaborative effort of the entire IPsec WG. If 5834 there were no limit to the number of authors that could appear on an 5835 RFC, the following, in alphabetical order, would have been listed: 5836 Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt 5837 Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John 5838 Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero 5839 Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer 5840 Reingold, and Michael Richardson. Many other people contributed to 5841 the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, 5842 each of which has its own list of authors. Hugh Daniel suggested the 5843 feature of having the initiator, in message 3, specify a name for the 5844 responder, and gave the feature the cute name "You Tarzan, Me Jane". 5845 David Faucher and Valery Smyslov helped refine the design of the 5846 traffic selector negotiation. 5848 This paragraph lists references that appear only in figures. The 5849 section is only here to keep the 'xml2rfc' program happy, and needs 5850 to be removed when the document is published. The RFC Editor will 5851 remove it before publication. [EAI] [DES] [IDEA] [MD5] [DSS] 5853 8. References 5855 8.1. Normative References 5857 [ADDGROUP] 5858 Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 5859 Diffie-Hellman groups for Internet Key Exchange (IKE)", 5860 RFC 3526, May 2003. 5862 [ADDRIPV6] 5863 Hinden, R. and S. Deering, "Internet Protocol Version 6 5864 (IPv6) Addressing Architecture", RFC 4291, February 2006. 5866 [AEAD] McGrew, D. and D. Black, "Using Authenticated Encryption 5867 Algorithms with the Encrypted Payload of the Internet Key 5868 Exchange version 2 (IKEv2) Protocol", RFC 5282, 5869 August 2008. 5871 [AESCMACPRF128] 5872 Song, J., "The Advanced Encryption Standard-Cipher-based 5873 Message Authentication Code-Pseudo-Random Function-128 5874 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange 5875 Protocol (IKE)", RFC 4615, August 2006. 5877 [AESXCBCPRF128] 5878 Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the 5879 Internet Key Exchange Protocol (IKE)", RFC 4434, 5880 February 2006. 5882 [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 5883 Levkowetz, "Extensible Authentication Protocol (EAP)", 5884 RFC 3748, June 2004. 5886 [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 5887 of Explicit Congestion Notification (ECN) to IP", 5888 RFC 3168, September 2001. 5890 [ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 5891 Algorithms", RFC 2451, November 1998. 5893 [IKEV2IANA] 5894 "Internet Key Exchange Version 2 (IKEv2) Parameters", 5895 . 5897 [IPSECARCH] 5898 Kent, S. and K. Seo, "Security Architecture for the 5899 Internet Protocol", RFC 4301, December 2005. 5901 [MUSTSHOULD] 5902 Bradner, S., "Key Words for use in RFCs to indicate 5903 Requirement Levels", BCP 14, RFC 2119, March 1997. 5905 [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 5906 Standards (PKCS) #1: RSA Cryptography Specifications 5907 Version 2.1", RFC 3447, February 2003. 5909 [PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 5910 X.509 Public Key Infrastructure Certificate and 5911 Certificate Revocation List (CRL) Profile", RFC 5280, 5912 May 2008. 5914 [UDPENCAPS] 5915 Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 5916 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 5917 RFC 3948, January 2005. 5919 8.2. Informative References 5921 [AH] Kent, S., "IP Authentication Header", RFC 4302, 5922 December 2005. 5924 [ARCHGUIDEPHIL] 5925 Bush, R. and D. Meyer, "Some Internet Architectural 5926 Guidelines and Philosophy", RFC 3439, December 2002. 5928 [ARCHPRINC] 5929 Carpenter, B., "Architectural Principles of the Internet", 5930 RFC 1958, June 1996. 5932 [Clarif] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 5933 Implementation Guidelines", RFC 4718, October 2006. 5935 [DES] American National Standards Institute, "American National 5936 Standard for Information Systems-Data Link Encryption", 5937 ANSI X3.106, 1983. 5939 [DH] Diffie, W. and M. Hellman, "New Directions in 5940 Cryptography", IEEE Transactions on Information Theory, 5941 V.IT-22 n. 6, June 1977. 5943 [DIFFSERVARCH] 5944 Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 5945 and W. Weiss, "An Architecture for Differentiated 5946 Services", RFC 2475. 5948 [DIFFSERVFIELD] 5949 Nichols, K., Blake, S., Baker, F., and D. Black, 5950 "Definition of the Differentiated Services Field (DS 5951 Field) in the IPv4 and IPv6 Headers", RFC 2474, 5952 December 1998. 5954 [DIFFTUNNEL] 5955 Black, D., "Differentiated Services and Tunnels", 5956 RFC 2983, October 2000. 5958 [DOI] Piper, D., "The Internet IP Security Domain of 5959 Interpretation for ISAKMP", RFC 2407, November 1998. 5961 [DOSUDPPROT] 5962 C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection 5963 for UDP-based protocols", ACM Conference on Computer and 5964 Communications Security , October 2003. 5966 [DSS] National Institute of Standards and Technology, U.S. 5967 Department of Commerce, "Digital Signature Standard", 5968 Draft FIPS 186-3, June 2008. 5970 [EAI] Abel, Y., "Internationalized Email Headers", RFC 5335, 5971 September 2008. 5973 [EAP-IANA] 5974 "Extensible Authentication Protocol (EAP) Registry: Method 5975 Types", . 5977 [EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, "Man-in-the-Middle in 5978 Tunneled Authentication Protocols", November 2002, 5979 . 5981 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 5982 RFC 4303, December 2005. 5984 [EXCHANGEANALYSIS] 5985 R. Perlman and C. Kaufman, "Analysis of the IPsec key 5986 exchange Standard", WET-ICE Security Conference, MIT , 5987 2001, 5988 . 5990 [H2HIPSEC] 5991 Aura, T., Roe, M., and A. Mohammed, "Experiences with 5992 Host-to-Host IPsec", 13th International Workshop on 5993 Security Protocols, Cambridge, UK, April 2005. 5995 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 5996 Hashing for Message Authentication", RFC 2104, 5997 February 1997. 5999 [IDEA] X. Lai, "On the Design and Security of Block Ciphers", ETH 6000 Series in Information Processing, v. 1, Konstanz: Hartung- 6001 Gorre Verlag, 1992. 6003 [IDNA] Faltstrom, P., Hoffman, P., and A. Costello, 6004 "Internationalizing Domain Names in Applications (IDNA)", 6005 RFC 3490, March 2003. 6007 [IKEV1] Harkins, D. and D. Carrel, "The Internet Key Exchange 6008 (IKE)", RFC 2409, November 1998. 6010 [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 6011 RFC 4306, December 2005. 6013 [IP-COMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP 6014 Payload Compression Protocol (IPComp)", RFC 3173, 6015 September 2001. 6017 [IPSECARCH-OLD] 6018 Kent, S. and R. Atkinson, "Security Architecture for the 6019 Internet Protocol", RFC 2401, November 1998. 6021 [IPV6CONFIG] 6022 Eronen, et. al., P., "IPv6 Configuration in IKEv2", 6023 RFC 5739, February 2010. 6025 [ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet 6026 Security Association and Key Management Protocol 6027 (ISAKMP)", RFC 2408, November 1998. 6029 [MAILFORMAT] 6030 Resnick, P., "Internet Message Format", RFC 5322, 6031 October 2008. 6033 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 6034 April 1992. 6036 [MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 6037 in IPv6", RFC 3775, June 2004. 6039 [MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery 6040 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 6042 [MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 6043 (MOBIKE)", RFC 4555, June 2006. 6045 [MODES] National Institute of Standards and Technology, U.S. 6046 Department of Commerce, "Recommendation for Block Cipher 6047 Modes of Operation", SP 800-38A, 2001. 6049 [NAI] Aboba, B., Beadles, M., Eronen, P., and J. Arkko, "The 6050 Network Access Identifier", RFC 4282, December 2005. 6052 [NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 6053 (NAT) Compatibility Requirements", RFC 3715, March 2004. 6055 [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", 6056 RFC 2412, November 1998. 6058 [PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 6059 Management API, Version 2", RFC 2367, July 1998. 6061 [PHOTURIS] 6062 Karn, P. and W. Simpson, "Photuris: Session-Key Management 6063 Protocol", RFC 2522, March 1999. 6065 [RANDOMNESS] 6066 Eastlake, D., Schiller, J., and S. Crocker, "Randomness 6067 Requirements for Security", BCP 106, RFC 4086, June 2005. 6069 [REAUTH] Nir, Y., "Repeated Authentication in Internet Key Exchange 6070 (IKEv2) Protocol", RFC 4478, April 2006. 6072 [REUSE] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In 6073 Diffie-Hellman Key Agreement Protocols", December 2008, 6074 . 6077 [ROHCV2] Ertekin, et. al., E., "IKEv2 Extensions to Support Robust 6078 Header Compression over IPsec (ROHCoIPsec)", 6079 draft-ietf-rohc-ikev2-extensions-hcoipsec (work in 6080 progress), August 2009. 6082 [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for 6083 Obtaining Digital Signatures and Public-Key 6084 Cryptosystems", February 1978. 6086 [SHA] National Institute of Standards and Technology, U.S. 6087 Department of Commerce, "Secure Hash Standard", 6088 FIPS 180-3, October 2008. 6090 [SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to 6091 Authenticated Diffie-Hellman and its Use in the IKE 6092 Protocols", Advances in Cryptography - CRYPTO 2003 6093 Proceedings LNCS 2729, 2003, . 6097 [SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange 6098 Mechanism for Internet", IEEE Proceedings of the 1996 6099 Symposium on Network and Distributed Systems Security , 6100 1996. 6102 [TRANSPARENCY] 6103 Carpenter, B., "Internet Transparency", RFC 2775, 6104 February 2000. 6106 Appendix A. Summary of changes from IKEv1 6108 The goals of this revision to IKE are: 6110 1. To define the entire IKE protocol in a single document, 6111 replacing RFCs 2407, 2408, and 2409 and incorporating subsequent 6112 changes to support NAT Traversal, Extensible Authentication, and 6113 Remote Address acquisition; 6115 2. To simplify IKE by replacing the eight different initial 6116 exchanges with a single four-message exchange (with changes in 6117 authentication mechanisms affecting only a single AUTH payload 6118 rather than restructuring the entire exchange) see 6119 [EXCHANGEANALYSIS]; 6121 3. To remove the Domain of Interpretation (DOI), Situation (SIT), 6122 and Labeled Domain Identifier fields, and the Commit and 6123 Authentication only bits; 6125 4. To decrease IKE's latency in the common case by making the 6126 initial exchange be 2 round trips (4 messages), and allowing the 6127 ability to piggyback setup of a Child SA on that exchange; 6129 5. To replace the cryptographic syntax for protecting the IKE 6130 messages themselves with one based closely on ESP to simplify 6131 implementation and security analysis; 6133 6. To reduce the number of possible error states by making the 6134 protocol reliable (all messages are acknowledged) and sequenced. 6135 This allows shortening CREATE_CHILD_SA exchanges from 3 messages 6136 to 2; 6138 7. To increase robustness by allowing the responder to not do 6139 significant processing until it receives a message proving that 6140 the initiator can receive messages at its claimed IP address; 6142 8. To fix cryptographic weaknesses such as the problem with 6143 symmetries in hashes used for authentication documented by Tero 6144 Kivinen; 6146 9. To specify traffic selectors in their own payloads type rather 6147 than overloading ID payloads, and making more flexible the 6148 traffic selectors that may be specified; 6150 10. To specify required behavior under certain error conditions or 6151 when data that is not understood is received in order to make it 6152 easier to make future revisions in a way that does not break 6153 backwards compatibility; 6155 11. To simplify and clarify how shared state is maintained in the 6156 presence of network failures and DoS attacks; and 6158 12. To maintain existing syntax and magic numbers to the extent 6159 possible to make it likely that implementations of IKEv1 can be 6160 enhanced to support IKEv2 with minimum effort. 6162 Appendix B. Diffie-Hellman Groups 6164 There are two Diffie-Hellman groups defined here for use in IKE. 6165 These groups were generated by Richard Schroeppel at the University 6166 of Arizona. Properties of these primes are described in [OAKLEY]. 6168 The strength supplied by group 1 may not be sufficient for typical 6169 uses and is here for historic reasons. 6171 Additional Diffie-Hellman groups have been defined in [ADDGROUP]. 6173 B.1. Group 1 - 768 Bit MODP 6175 This group is assigned id 1 (one). 6177 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 6178 Its hexadecimal value is: 6180 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 6181 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 6182 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 6183 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF 6185 The generator is 2. 6187 B.2. Group 2 - 1024 Bit MODP 6189 This group is assigned id 2 (two). 6191 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 6192 Its hexadecimal value is: 6194 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 6195 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 6196 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 6197 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 6198 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 6199 FFFFFFFF FFFFFFFF 6201 The generator is 2. 6203 Appendix C. Exchanges and Payloads 6205 This appendix contains a short summary of the IKEv2 exchanges, and 6206 what payloads can appear in which message. This appendix is purely 6207 informative; if it disagrees with the body of this document, the 6208 other text is considered correct. 6210 Vendor-ID (V) payloads may be included in any place in any message. 6211 This sequence here shows what are the most logical places for them. 6213 C.1. IKE_SA_INIT Exchange 6215 request --> [N(COOKIE)], 6216 SA, KE, Ni, 6217 [N(NAT_DETECTION_SOURCE_IP)+, 6218 N(NAT_DETECTION_DESTINATION_IP)], 6219 [V+][N+] 6221 normal response <-- SA, KE, Nr, 6222 (no cookie) [N(NAT_DETECTION_SOURCE_IP), 6223 N(NAT_DETECTION_DESTINATION_IP)], 6224 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 6225 [V+][N+] 6227 cookie response <-- N(COOKIE), 6228 [V+][N+] 6230 different Diffie- <-- N(INVALID_KE_PAYLOAD), 6231 Hellman group [V+][N+] 6232 wanted 6234 C.2. IKE_AUTH Exchange without EAP 6236 request --> IDi, [CERT+], 6237 [N(INITIAL_CONTACT)], 6238 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 6239 [IDr], 6240 AUTH, 6241 [CP(CFG_REQUEST)], 6242 [N(IPCOMP_SUPPORTED)+], 6243 [N(USE_TRANSPORT_MODE)], 6244 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 6245 [N(NON_FIRST_FRAGMENTS_ALSO)], 6246 SA, TSi, TSr, 6247 [V+][N+] 6249 response <-- IDr, [CERT+], 6250 AUTH, 6251 [CP(CFG_REPLY)], 6252 [N(IPCOMP_SUPPORTED)], 6253 [N(USE_TRANSPORT_MODE)], 6254 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 6255 [N(NON_FIRST_FRAGMENTS_ALSO)], 6256 SA, TSi, TSr, 6257 [N(ADDITIONAL_TS_POSSIBLE)], 6258 [V+][N+] 6260 error in Child SA <-- IDr, [CERT+], 6261 creation AUTH, 6262 N(error), 6263 [V+][N+] 6265 C.3. IKE_AUTH Exchange with EAP 6267 first request --> IDi, 6268 [N(INITIAL_CONTACT)], 6269 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 6270 [IDr], 6271 [CP(CFG_REQUEST)], 6272 [N(IPCOMP_SUPPORTED)+], 6273 [N(USE_TRANSPORT_MODE)], 6274 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 6275 [N(NON_FIRST_FRAGMENTS_ALSO)], 6276 SA, TSi, TSr, 6277 [V+][N+] 6279 first response <-- IDr, [CERT+], AUTH, 6280 EAP, 6281 [V+][N+] 6283 / --> EAP 6284 repeat 1..N times | 6285 \ <-- EAP 6287 last request --> AUTH 6289 last response <-- AUTH, 6290 [CP(CFG_REPLY)], 6291 [N(IPCOMP_SUPPORTED)], 6292 [N(USE_TRANSPORT_MODE)], 6293 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 6294 [N(NON_FIRST_FRAGMENTS_ALSO)], 6295 SA, TSi, TSr, 6296 [N(ADDITIONAL_TS_POSSIBLE)], 6297 [V+][N+] 6299 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying Child SAs 6301 request --> [N(REKEY_SA)], 6302 [CP(CFG_REQUEST)], 6303 [N(IPCOMP_SUPPORTED)+], 6304 [N(USE_TRANSPORT_MODE)], 6305 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 6306 [N(NON_FIRST_FRAGMENTS_ALSO)], 6307 SA, Ni, [KEi], TSi, TSr 6308 [V+][N+] 6310 normal <-- [CP(CFG_REPLY)], 6311 response [N(IPCOMP_SUPPORTED)], 6312 [N(USE_TRANSPORT_MODE)], 6313 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 6314 [N(NON_FIRST_FRAGMENTS_ALSO)], 6315 SA, Nr, [KEr], TSi, TSr, 6316 [N(ADDITIONAL_TS_POSSIBLE)] 6317 [V+][N+] 6319 error case <-- N(error) 6321 different Diffie- <-- N(INVALID_KE_PAYLOAD), 6322 Hellman group [V+][N+] 6323 wanted 6325 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA 6327 request --> SA, Ni, KEi 6328 [V+][N+] 6330 response <-- SA, Nr, KEr 6331 [V+][N+] 6333 C.6. INFORMATIONAL Exchange 6335 request --> [N+], 6336 [D+], 6337 [CP(CFG_REQUEST)] 6339 response <-- [N+], 6340 [D+], 6341 [CP(CFG_REPLY)] 6343 Appendix D. Changes Between Internet Draft Versions 6345 This section will be removed before publication as an RFC, but should 6346 be left intact until then so that reviewers can follow what has 6347 changed. 6349 D.1. Changes from IKEv2 to draft -00 6351 There were a zillion additions from RFC 4718. These are noted with 6352 "{{ Clarif-nn }}". 6354 Cleaned up many of the figures. Made the table headings consistent. 6355 Made some tables easier to read by removing blank spaces. Removed 6356 the "reserved to IANA" and "private use" text wording and moved it 6357 into the tables. 6359 Changed many SHOULD requirements to better match RFC 2119. These are 6360 also marked with comments such as "{{ Demoted the SHOULD }}". 6362 In Section 2.16, changed the MUST requirement of authenticating the 6363 responder from "public key signature based" to "strong" because that 6364 is what most current IKEv2 implementations do, and it better matches 6365 the actual security requirement. 6367 D.2. Changes from draft -00 to draft -01 6369 The most significant technical change was to make KE optional but 6370 strongly recommended in Section 1.3.2. 6372 Updated all references to the IKEv2 Clarifications document to RFC 6373 4718. 6375 Moved a lot of the protocol description out of the long tables in 6376 Section 3.10.1 into the body of the document. These are noted with 6377 "{{ 3.10.1-nnnn }}", where "nnnn" is the notification type number. 6379 Made some table changes based on suggestions from Alfred Hoenes. 6381 Changed "byte" to "octet" in many places. 6383 Removed discussion of ESP+AH bundles in many places, and added a 6384 paragraph about it in Section 1.7. 6386 Removed the discussion of INTERNAL_ADDRESS_EXPIRY in many places, and 6387 added a paragraph about it in Section 1.7. 6389 Moved Clarif-7.10 from Section 1.2 to Section 3.2. 6391 In the figure in Section 1.3.2, made KEi optional, and added text 6392 saying "The KEi payload SHOULD be included." 6394 In the figure in Section 1.3.2, maked KEr optional, and removed text 6395 saying "KEi and KEr are required for rekeying an IKE SA." 6397 In Section 1.4, clarified that the half-closed connections being 6398 discussed are AH and ESP. 6400 Rearranged the end of Section 1.7, and added the new notation for 6401 moving text out of 3.10.1. 6403 Clarified the wording in the second paragraph of Section 2.2. This 6404 allowd the removal of the fourth paragraph, which previously had 6405 Clarif-2.2 in it. 6407 In section 2.5, removed "or later" from "version 2.0". 6409 Added the question for implementers about payload order at the end of 6410 Section 2.5. 6412 Corrected Section 2.7 based on Clarif-7-13 to say that you can't do 6413 ESP and AH at one time. 6415 In Section 2.8, clarified the wording about how to replace an IKE SA. 6417 Clarified the text in the last many paragraphs in Section 2.9. Also 6418 moved some text from near the beginning of 2.9 to the beginning of 6419 2.9.1. 6421 Removed some redundant text in Section 2.9 concerning creating a 6422 Child SA pair not in response to an arriving packet. 6424 Added the following to the end of the first paragraph of Section 6425 2.14: "The lengths of SK_d, SK_pi, and SK_pr are the key length of 6426 the agreed-to PRF." 6428 Added the restriction in Section 2.15 that all PRFs used with IKEv2 6429 MUST take variable-sized keys. 6431 In Section 2.17, removed "If multiple IPsec protocols are negotiated, 6432 keying material is taken in the order in which the protocol headers 6433 will appear in the encapsulated packet" because multiple IPsec 6434 protocols cannot be negotiated at one time. 6436 Added the material from Clarif-5.12 to Section 2.18. 6438 Changed "hash of" to "expected value of" in Section 2.23. 6440 In the bulleted list in Section 2.23, replaced "this end" with a 6441 clearer description of which system is being discussed. 6443 Added the paragraph at the beginning of Section 3 about 6444 interoperability and UNSPECIFIED values ("In the tables in this 6445 section..."). 6447 Fixed Section 3.3 to not include proposal that include both AH and 6448 ESP. Ditto for the "Proposal #" bullet in Section 3.3.1. 6450 In the description of ID_FQDN in Section 3.5, added "All characters 6451 in the ID_FQDN are ASCII; this follows that for an "internationalized 6452 domain name" as defined in [IDNA]." 6454 In Section 3.8, shortened and clarified the description of "RSA 6455 Digital Signature". 6457 In Section 3.10, shortened and clarified the description of "Protocol 6458 ID". 6460 In Section 3.15, "The requested address is valid until the expiry 6461 time defined with the INTERNAL_ADDRESS_EXPIRY attribute or there are 6462 no IKE SAs between the peers" is shortened to just "The requested 6463 address is valid until there are no IKE SAs between the peers." 6465 In Section 3.15.1, changed "INTERNAL_IP6_NBNS" to unspecified. 6467 Made [ADDRIPV6] an informative reference instead of a normative 6468 reference and updated it. 6470 Made [PKCS1] a normative reference instead of an informative 6471 reference and changed the pointer to RFC 3447. 6473 D.3. Changes from draft -00 to draft -01 6475 In Section 1.5, added "request" to first sentence to make it "If an 6476 encrypted IKE request packet arrives on port 500 or 4500 with an 6477 unrecognized SPI...". 6479 In Section 3.3, fifth paragraph, upped the number of transforms for 6480 AH and ESP by one each to account for ESN, which is now mandatory. 6482 In Section 2.1, added "or equal to" in "The responder MUST remember 6483 each response until it receives a request whose sequence number is 6484 larger than or equal to the sequence number in the response plus its 6485 window size." 6487 In Section 2.18, removed " Note that this may not work if the new IKE 6488 SA's PRF has a fixed key size because the output of the PRF may not 6489 be of the correct size." because it is no longer relevant. 6491 D.4. Changes from draft -01 to draft -02 6493 Many grammatical fixes. 6495 In Section 1.2, reworded Clarif-4.3 to be clearer. 6497 In Section 1.3.3, reworded 3.10.1-16393 and Clarif-5.4 to remove 6498 redundant text. 6500 In Section 2.13, replaced text about variable length keys with 6501 clearer explanation and requirement on non-HMAC PRFs. Also added 6502 "preferred" to Section 2.14 for the key length, and removed redundant 6503 text. 6505 In Section 2.14, removed the "half and half" description and replaced 6506 it with exceptions for RFC4434 and RFC4615. 6508 Removed the now-redundant "All PRFs used with IKEv2 MUST take 6509 variable-sized keys" from Section 2.15. 6511 In Section 2.15, added "(IKE_SA_INIT response)" after "of the second 6512 message" and "(IKE_SA_INIT request)" after "the first message". 6514 In Section 2.17, simplified because there are no more bundles. "A 6515 single Child SA negotiation may result in multiple security 6516 associations. ESP and AH SAs exist in pairs (one in each 6517 direction)." becomes "For ESP and AH, a single Child SA negotiation 6518 results in two security associations (one in each direction)." 6520 In section 3.3, made the example of combinations of algorithms and 6521 the contents of the first proposal clearer. 6523 Added Clarif-4.4 to the end of Section 3.3.2. 6525 Reordered Section 3.3.5 and added Clarif-7.11. 6527 Clarified Section 3.3.6 about choosing a single proposal. Also added 6528 second paragraph about transforms not understood, and clarified third 6529 paragraph about picking D-H groups. 6531 Moved 3.10.1-16392 from Section 3.6 to 3.7. 6533 In Section 3.10, clarified 3.10.1-16394. 6535 Updated Section 6 to indicate that there is nothing new for IANA in 6536 this spec. Also removed the definition of "Expert Review" from 6537 Section 1.6 for the same reason. 6539 In Appendix A, removed "and not commit any state to an exchange until 6540 the initiator can be cryptographically authenticated" because that 6541 was only true in an earlier version of IKEv2. 6543 D.5. Changes from draft -02 to draft -03 6545 In Section 1.3, changed "If the responder rejects the Diffie-Hellman 6546 group of the KEi payload, the responder MUST reject the request and 6547 indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD 6548 Notification payload." to "If the responder selects a proposal using 6549 a different Diffie-Hellman group (other than NONE), the responder 6550 MUST reject the request and indicate its preferred Diffie-Hellman 6551 group in the INVALID_KE_PAYLOAD Notification payload. 6553 In Section 2.3, added the last two paragraphs covering why you 6554 initiator's SPI and/or IP to differentiate if this is a "half-open" 6555 IKE SA or a new request. Also removed similar text from Section 2.2. 6557 In Section 2.5, added "Payloads sent in IKE response messages MUST 6558 NOT have the critical flag set. Note that the critical flag applies 6559 only to the payload type, not the contents. If the payload type is 6560 recognized, but the payload contains something which is not (such as 6561 an unknown transform inside an SA payload, or an unknown Notify 6562 Message Type inside a Notify payload), the critical flag is ignored." 6564 In Section 2.6, moved the text about {{ 3.10.1-16390 }} later in the 6565 section. Also reworded the text to make it clearer what the COOKIE 6566 is for. 6568 Moved text from Clarif-2.1 from Section 2.6 to Section 2.7. 6570 In Section 2.13, added "(see Section 3.3.5 for the defintion of the 6571 Key Length transform attribute)". 6573 In Section 2.17, change the description of the keying material from 6574 the list with two bullets to a clearer list. 6576 In Section 2.23, added "Implementations MUST process received UDP- 6577 encapsulated ESP packets even when no NAT was detected." 6579 In Section 3.3, changed "Each proposal may contain a" to "Each 6580 proposal contains a". 6582 Added the asterisks to the transform type table in Section 3.3.2 and 6583 the types table in 3.3.3 to foreshadow future developments. 6585 In Section 3.3.2, changed the following algorithms to (UNSPECIFIED) 6586 because the RFCs listed didn't really specify how to implement them 6587 in an interoperable fashion: 6589 Encryption Algorithms 6590 ENCR_DES_IV64 1 (RFC1827) 6591 ENCR_3IDEA 8 (RFC2451) 6592 ENCR_DES_IV32 9 6593 Pseudo-random Functions 6594 PRF_HMAC_TIGER 3 (RFC2104) 6595 Integrity Algorithms 6596 AUTH_DES_MAC 3 6597 AUTH_KPDK_MD5 4 (RFC1826) 6599 In Section 3.4, added "(other than NONE)" to the second-to-last 6600 paragraph. 6602 Rewrote the third paragraph of Section 3.14 to talk about other 6603 modes, and to clarify which encryption and integrity protection we 6604 are talking about. 6606 Changed the "Initialization Vector" bullet in Section 3.14 to specify 6607 better what is needed for the IV. Upgraded the SHOULDs to MUSTs. 6608 Also added the reference for [MODES]. 6610 In Section 5, in the second-to-last paragraph, changed "a public-key- 6611 based" to "strong" to match the wording in Section 2.16. 6613 D.6. Changes from draft -03 to draft-ietf-ipsecme-ikev2bis-00 6615 Changed the document's filename to draft-ietf-ipsecme-ikev2bis-00. 6616 Added Yoav Nir as a co-author. 6618 In many places in the document, changed "and/or" to "or" when talking 6619 about combinations of ESP and AH SAs. For example, in the intro, it 6620 said "can be used to efficiently establish SAs for Encapsulating 6621 Security Payload (ESP) and/or Authentication Header (AH)". This is 6622 changed to "or" to indicate that you can only establish one type of 6623 SA at a time. 6625 In Section 1, clarified that RFC 4306 already replaced IKEv1, and 6626 that this document replaces RFC 4306. Also fixed Section 2.5 for 6627 similar issue. Also updated the Abstract to cover this. 6629 In Section 2.15, in the responder's signed octets, changed: 6631 RestOfRespIDPayload = IDType | RESERVED | InitIDData 6632 to 6633 RestOfRespIDPayload = IDType | RESERVED | RespIDData 6635 In 2.16, changed "strong" back to "public key signature based" to 6636 make it the same as 4306. 6638 In section 3.10, added "and the field must be empty" to make it clear 6639 that a zero-length SPI is really empty. 6641 D.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to 6642 draft-ietf-ipsecme-ikev2bis-01 6644 Throughout, changed "IKE_SA" to "IKE SA", and changed "CHILD_SA" to 6645 "Child SA" (except left "CREATE_CHILD_SA" alone). 6647 Added the middle sentence in the Abstract to say what IKE actually 6648 does. 6650 Added in section 1 "(unless there is failure setting up the AH or ESP 6651 Child SA, in which case the IKE SA is still established without Child 6652 SA)". 6654 Clarified the titles of 1.1.1, 1.1.2, and 1.1.3. 6656 In 1.1.2, changed "If there is an inner IP header, the inner 6657 addresses will be the same as the outer addresses." because we are 6658 talking about transport mode here. 6660 Added reference to section 2.14 to setion 1.2 and 1.3. 6662 In 1.2, clarified what is and isn't encrypted in a message. 6664 Added the following to 1.2: "If the IDr proposed by the initiator is 6665 not acceptable to the responder, the responder might use some other 6666 IDr to finish the exchange. If the initiator then does not accept 6667 that fact that responder used different IDr than the one that was 6668 requested, the initiator can close the SA after noticing the fact." 6670 Moved the paragraph beginning "All messages following..." from 1.3 up 6671 to 1.2, and reworded it to apply to all the cases it covers. 6673 At the end of section 1.3.1, clarified that the responder is the one 6674 who controls whether non-first-fragments will be sent, and reworded 6675 the paragraph. 6677 In section 1.3.3, added "The Protocol ID field of the REKEY_SA 6678 notification is set to match the protocol of the SA we are rekeying, 6679 for example, 3 for ESP and 2 for AH." [Issue #10] 6681 In 1.3.2, added "of the SA payload" to "New initiator and responder 6682 SPIs are supplied in the SPI fields." 6684 In 1.3.3, fixed the art. 6686 <-- HDR, SK {SA, Nr, [KEr], 6687 Si, TSr} 6688 becomes 6689 <-- HDR, SK {SA, Nr, [KEr], 6690 TSi, TSr} 6692 In 1.4 and 2.18, changed "replaced for the purpose of rekeying" to 6693 "rekeyed". 6695 Split out the SA deletion material from section 1.4 into its own 6696 subsection, 1.4.1. 6698 Clarified which bits are set at the end of Section 1.5. 6700 In 1.7, added "That is, the version number is *not* changed from RFC 6701 4306.". 6703 In 2.1, added wording about retransmissions needing to be identical. 6705 In 2.2, added "or rekeyed" to "In the unlikely event that Message IDs 6706 grow too large to fit in 32 bits, the IKE SA MUST be closed" 6708 In 2.2, moved the sentence "Rekeying an IKE SA resets the sequence 6709 numbers." up higher so it would be more likely to be seen. [Issue 6710 #15] 6712 Moved the definition of "original initiator" from 2.8 into 2.2 6713 because that is where it is first used. 6715 In 2.4, added "fresh (i.e., not retransmitted)" to "If a 6716 cryptographically protected message has been received from the other 6717 side recently". Also added the sentence saying that liveness checks 6718 are sometimes call dead peer detection. 6720 Removed the question to implementers about payload order in 2.5. 6722 Changed the title of 2.6 to "IKE SA SPIs and Cookies". Also, in the 6723 paragraph that describes how to implement the responder, changed the 6724 lower-case "should" to "can" to emphasize that this is a choice. 6726 Added the second paragraph in 2.6 to make it clear that the SPI is 6727 used for mapping. 6729 In section 2.6, upgraded "needs to choose them so as to be unique 6730 identifiers of an IKE_SA" to a MUST. 6732 Added sentences at the end of 2.6 eplaining wny the initiator should 6733 limit the number of responses it sends out. 6735 In 2.6.1, added the example of the shorter exchange; this is copied 6736 from RFC 4718 but was dropped in early drafts of this document. 6738 Added the paragraph to 2.7 that describes needing two proposals if 6739 you are having both normal ciphers and combined-mode ciphers. [Issue 6740 #20]. 6742 In section 2.8, added "Note that, when rekeying, the new Child SA MAY 6743 have different traffic selectors and algorithms than the old one." 6745 Added a note in 2.9 that PFKEY applies only to IKEv1. Also added 6746 that unknown traffic selector types are not returned in narrowed 6747 responses. 6749 Added note in the first paragraph of Setion 2.9.1 about decorrelated 6750 policies preventing the problem mentioned. 6752 In 2.12, removed "In particular, it MUST forget the secrets used in 6753 the Diffie-Hellman calculation and any state that may persist in the 6754 state of a pseudo-random number generator that could be used to 6755 recompute the Diffie-Hellman secrets." 6757 In 2.15, noted that the retry could happen multiple times for 6758 different reasons. 6760 In section 2.16, changed "This shared key generated during an IKE 6761 exchange" to "This key". 6763 At the end of 2.19, added statement that FAILED_CP_REQUIRED is not 6764 fatal to the IKE SA. 6766 Added the reference to ROHCV2 to the end of 2.22. 6768 In 2.23, changed "can negotiate" to "will use". for UDP 6769 encapsulation. Added "or 4500" to "...MUST be sent from and to UDP 6770 port 500". Also removed the text about why not to do NAT-traversal 6771 over port 500 because we later say you can't do that anyway. [Issue 6772 #27] Also removed the last paragraph, which obliquely pointed to 6773 MOBIKE. More will be added later on MOBIKE. 6775 In 3.1, removed "and orderings of messages" from "Exchange type". 6776 [Issue #29] 6778 In 3.1, added "This bit changes to reflect who initiated the last 6779 rekey of the IKE SA." to the description of the Initiator bit. 6781 In 3.3, added a long example of why you might use a Proposal 6782 structure because of combined-mode algorithms. [Issue #42] 6784 In 3.3.2, changed "is unnecessary because the last Proposal could be 6785 identified from the length of the SA" to "is unnecessary because the 6786 last transform could be identified from the length of the proposal." 6788 Added reference to AEAD to 3.3.2 and 3.3.3. 6790 Added the reference to RFC 2104 back for PRF_HMAC_TIGER in 3.3.2. 6791 [Issue #33] 6793 Added note at the bottom of 3.3.2 to see the IANA registry. 6795 In 3.3.4, removed all the "this could happen in the future" stuff 6796 because it already happened. 6798 Added a reference to email address internationalization to 3.5, 6799 making the address binary (not ASCII). 6801 In the table in 3.6, made "Authority Revocation List (ARL) 8" and 6802 "X.509 Certificate - Attribute 10" unspecified. 6804 In 3.7, changed the last sentence of the first paragraph to eliminate 6805 the non-protocol SHOULD. 6807 In 3.13.1, added "(including protocol 0)" for the start port and end 6808 port. 6810 In 3.14, updated the discussion of initialization modes to reflect 6811 that it is only about CBC, and that other specs have to specify their 6812 own IVs. 6814 In 3.15.1, added a pointer to 3.15.3. In the entries for 6815 INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET, added a pointer to 6816 3.15.2. 6818 In 3.15.4, added "The IKE SA is still created even if the initial 6819 Child SA cannot be created because of this failure." 6821 Changed "EAP exchange" to "EAP authentication" in 5. 6823 Removed "In particular, these exponents MUST NOT be derived from 6824 long-lived secrets like the seed to a pseudo-random generator that is 6825 not erased after use." from section 5 because it is not possible in 6826 most implementations to do so. 6828 Updated a bunch of reference to their newer versions. 6830 Added "[V+]" to the end of the exchanges in C.4 and C.5. 6832 Added two more response templates to Appendix C.1. Added another 6833 response template in Appendix C.2. Added two more responses in 6834 Appendix C.4. 6836 D.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to 6837 draft-ietf-ipsecme-ikev2bis-02 6839 In section 1.3.1, added "Failure of an attempt to create a CHILD SA 6840 SHOULD NOT tear down the IKE SA: there is no reason to lose the work 6841 done to set up the IKE SA. When an IKE SA is not created, the error 6842 message return SHOULD NOT be encrypted because the other party will 6843 not be able to authenticate that message." This may be changed again 6844 in the future. [Issue #9] 6846 In section 1.3.2, changed "The KEi payload SHOULD be included" to be 6847 "The KEi payload MUST be included". This also led to changes in 6848 section 2.18. The square brackets around "g^ir (new)" in the 6849 SKEYSEED calculation are eliminated, and the requirement language in 6850 the paragraph starting "The main rekeying" is changed from SHOULD to 6851 MUST. [Issue #50] 6853 In section 1.3.2, changed "The window size starts at 1 for any new 6854 IKE SA." to "The first IKE requests from both sides on the new IKE SA 6855 will have message ID 0. The old IKE SA retains its numbering, so any 6856 further requests (for example, to delete the IKE SA) will have 6857 consecutive numbering. The new IKE SA also has its window size reset 6858 to 1, and the initiator in this rekey exchange is the new "original 6859 initiator" of the new IKE SA." [Issue #65] 6861 Added to section 1.5: For a one-way INVALID_IKE_SPI notification for 6862 an unrecognized SPI, the responder SHOULD copy the Exchange Type from 6863 the request. [Issue #46] 6865 In 2.1, at the end of the paragraph about retransmission timers, 6866 added "In order to allow saving memory, responders are allowed to 6867 forget response after a timeout of several minutes. If the responder 6868 receives a retransmitted request for which it has already forgotten 6869 the response, it MUST ignore the request (and not, for example, 6870 attempt constructing a new response)." [Issue #14] 6872 In 2.6, added: "Also, incorporating Ni in the hash prevents an 6873 attacker from fetching one one cookie from the other end, and then 6874 initiating many IKE_SA_INIT exchanges all with different initiator 6875 SPIs (and perhaps port numbers) so that the responder thinks that 6876 there are lots of machines behind one NAT box who are all trying to 6877 connect." [Issue #19] 6879 Added text for the new 2.8.2, and bumped the section number of the 6880 old 2.8.2 to 2.8.3. [Issue #22] 6882 Added a reference to the end of 2.12 on key reuse. 6884 Added to the end of the first paragraph in 2.19: Note, however, it is 6885 usual to only assign one IP address during the IKE_AUTH exchange. 6886 That address persists at least until the deletion of the IKE SA. 6887 [Issue #79] 6889 Added the following to 2.23: An initiator can float to port 4500, 6890 regardless whether or not there is NAT, even at the beginning of IKE. 6891 When either side is using port 4500, sending with UDP encapsulation 6892 is not required, but understanding received packets with UDP 6893 encapsulation is required. UDP encapsulation MUST NOT be done on 6894 port 500. If NAT-T is supported (that is, if NAT_DETECTION_*_IP 6895 payloads were exchanged during IKE_SA_INIT), all devices MUST be able 6896 to receive and process both UDP encapsulated and non-UDP encapsulated 6897 packets at any time. Either side can decide whether or not to use 6898 UDP encapsulation irrespective of the choice made by the other side. 6899 However, if a NAT is detected, both devices MUST send UDP 6900 encapsulated packets. [Issue #40] 6902 The second-to-last paragraph in section 3.4 is changed to: The DH 6903 Group # identifies the Diffie-Hellman group in which the Key Exchange 6904 Data was computed (see Section 3.3.2. This Group # MUST match a DH 6905 Group specified in a proposal in the SA payload that is sent in the 6906 same message, and SHOULD match the DH group in the first group in the 6907 first proposal, if such exists. If none of the proposals in that SA 6908 payload specifies a DH Group, the KE payload MUST NOT be present. If 6909 the selected proposal uses a different Diffie-Hellman group (other 6910 than NONE), the message MUST be rejected with a Notify payload of 6911 type INVALID_KE_PAYLOAD. [Issue #30] 6913 In 3.10.1, changed the definition of NO_PROPOSAL_CHOSEN, 14, to: None 6914 of the proposed crypto suites was acceptable. This can be sent in 6915 any case where the offered proposal (including but not limited to SA 6916 payload values, USE_TRANSPORT_MODE notify, IPCOMP_SUPPORTED notify) 6917 are not acceptable for the responder. This can also be used as 6918 "generic" Child SA error when Child SA cannot be created for some 6919 other reason. See also Section 2.7. [Issue #81] 6921 In the description of IVs in 3.14, reorganized the text a bit to 6922 emphasize when we are and are not talking about CBC. [Issue #68] 6924 Added the following to section 5 (Security Considerations): "The 6925 IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator has 6926 been authenticated. As a result, an implementation of this protocol 6927 needs to be completely robust when deployed on any insecure network. 6928 Implementation vulnerabilities, particularly denial-of-service 6929 attacks, can be exploited by unauthenticated peers. This issue is 6930 particularly worrisome because of the unlimited number of messages in 6931 EAP-based authentication." [Issue #62] 6933 Added new Appendix D, "Significant Changes from RFC 4306", as a 6934 placeholder for now. [Issue #3] 6936 D.9. Changes from draft-ietf-ipsecme-ikev2bis-01 to 6937 draft-ietf-ipsecme-ikev2bis-02 6939 Near the end of 1.3, changed "If the guess turns out to be wrong, the 6940 responder will indicate the correct group in the response and the 6941 initiator SHOULD pick an element of that group for its KE value when 6942 retrying the first message." to "If the responder selects a proposal 6943 using a different Diffie-Hellman group (other than NONE), the 6944 responder will indicate the correct group in the response and the 6945 initiator SHOULD pick an element of that group for its KE value when 6946 retrying the first message." [Issue #6] 6948 In the figures in 1.3.2, changed the diagrams from "HDR, SK {SA, Ni, 6949 [KEi]}" to "HDR, SK {SA, Ni, KEi}", and "HDR, SK {SA, Nr,[KEr]}" to 6950 "HDR, SK {SA, Nr,KEr}". This matches the text in the section, which 6951 was updated in the last revision. [Issue #50] 6953 Reorganized the beginning of section 2.3 and clarified some of the 6954 logic. [Issue #52] 6956 Clarified the octets to be signed in setion 2.15. Changed 6958 AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), ) 6960 to 6962 For the initiator: 6963 AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"), 6964 ) 6965 For the responder: 6966 AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"), 6967 ) 6969 [Issue #72] 6971 Changed the last bullet item in section 2.23 to discuss MOBIKE in 6972 more detail. [Issue #41] 6974 In section 3.1, the bullet about bit 4, changed "must" to "MUST". 6976 In section 3.3.6, added two sentences at the end of the second 6977 paragraph to indicate that there is an exception for when the 6978 proposal is a DH group of NONE. [Issue #6] 6980 D.10. Changes from draft-ietf-ipsecme-ikev2bis-02 to 6981 draft-ietf-ipsecme-ikev2bis-03 6983 In section 2.4, change "The INITIAL_CONTACT notification, if sent, 6984 MUST be in the first IKE_AUTH request, not as a separate exchange 6985 afterwards; however, receiving parties need to deal with it in other 6986 requests." to "The INITIAL_CONTACT notification, if sent, MUST be in 6987 the first IKE_AUTH request or response, not as a separate exchange 6988 afterwards; receiving parties MAY ignore it in other messages." 6989 [Issue #53] 6991 Added to the security considerations: "Admission control is critical 6992 to the security of the protocol. For example, trust anchors used for 6993 identifying IKE peers should probably be different than those used 6994 for other forms of trust, such as those used to identify public web 6995 servers. Moreover, although IKE provides a great deal of leeway in 6996 defining the security policy for a trusted peer's identity, 6997 credentials, and the correlation between them, having such security 6998 policy defined explicitly is essential to a secure implementation." 6999 [Issue #61] 7001 Changed "[V+]" to "[V+][N+]" throughout Appendix C. [Issue #63] 7003 D.11. Changes from draft-ietf-ipsecme-ikev2bis-03 to 7004 draft-ietf-ipsecme-ikev2bis-04 7006 Throughout, removed the marks that showed where text from the 7007 Clarifications RFC was inserted, or where a "SHOULD" was demoted to 7008 weaker language. 7010 In section 1, added "IKEv2 was a change to the IKE protocol that was 7011 not backward compatible. In contrast, the current document not only 7012 provides a clarification of IKEv2, but makes minimum changes to the 7013 IKE protocol." [Issue #48] 7015 In 1.5, added "The recipient of this notification cannot tell whether 7016 the SPI is for AH or ESP, but this is not important because the SPIs 7017 are supposed to be different for the two." [Issue #35] 7019 In 1.5, added "(INVALID_MAJOR_VERSION is also a one-way message which 7020 is sent outside of an IKE SA, although it is sent as a response to 7021 the incoming IKE SA creation.)" [Issue #13] 7023 In 1.7, added "This document removes the allowance for rejecting 7024 messages where the payloads were not in the "right" order; now 7025 implementations MUST NOT reject them. This is due to the lack of 7026 clarity where the orders for th payloads are described." 7028 Added "The Message ID is reset to zero in the new IKE SA after the 7029 IKE SA is rekeyed" in the first paragraph of 2.2. [Issue #15] 7031 In 2.5, changed "implementations MUST send the payloads defined in 7032 this specification in the order shown in the figures in Section 2; 7033 implementations are explicitly allowed to reject as invalid a message 7034 with those payloads in any other order" to "implementations SHOULD 7035 send the payloads defined in this specification in the order shown in 7036 the figures in Section 2; implementations MUST NOT reject as invalid 7037 a message with those payloads in any other order". [Issue #16] 7038 [Issue #45] 7040 In 2.9, added "Maintenance of a system's SPD is outside the scope of 7041 IKE (see [PFKEY] for an example programming interface, although it 7042 only applies to IKEv1), though some implementations might update 7043 their SPD in connection with the running of IKE (for an example 7044 scenario, see Section 1.1.3)." This was actually done in -03 but not 7045 noted in the change notes. [Issue #64] [Issue #54] 7047 In 2.18, added "using SPIi, SPIr, Ni, and Nr from the new exchange" 7048 to the last sentence. 7050 In the last paragraph of 2.25, added "The SA that the initiator 7051 attempted to rekey is indicated by the SPI field in the Notify 7052 Payload, which is copied from the SPI field in the REYEY_SA 7053 notification." 7055 Removed INTERNAL_IP6_NBNS from 3.15.1. [Issue #44] 7057 Changed "The requested address is valid until there are no IKE_SAs 7058 between the peers" to "The requested address is valid as long as this 7059 IKE SA (or its rekeyed successors) requesting the address is valid." 7060 [Issue #43] 7062 D.12. Changes from draft-ietf-ipsecme-ikev2bis-04 to 7063 draft-ietf-ipsecme-ikev2bis-05 7065 Added the following near the end of 1.2: "If the failure is related 7066 to creating the IKE SA (for example, AUTHENTICATION_FAILED), the IKE 7067 SA is not created. Note that although the IKE_AUTH messages are 7068 encrypted and integrity protected, if the peer receiving this 7069 notification has not yet authenticated the other end (or if the peer 7070 fails to authenticate the other end for some reason), the information 7071 needs to be treated with caution. More precisely, assuming that the 7072 MAC verifies correctly, the sender of the error indication is known 7073 to be the responder of the IKE_SA_INIT exchange, but the sender's 7074 identity cannot be assured." [Issue #9] 7076 Added "Section 2.21 also covers error messages in great detail" near 7077 the beginning of 1.4. 7079 Added "Section 2.21 has been greatly expanded to cover the different 7080 cases where error responses are needed and the appropriate responses 7081 to them" to the end of 1.7. 7083 In 1.5, changed "There are two cases when such a one-way 7084 notification" to "There are two cases when a one-way notification". 7085 Also changed "notification" to "message" throughout this paragraph. 7087 In 2.8, changed "Note that, when rekeying, the new Child SA MAY have 7088 different traffic selectors and algorithms than the old one." to 7089 "Note that, when rekeying, the new Child SA SHOULD NOT have different 7090 traffic selectors and algorithms than the old one.". [Issue #12] 7092 Section 2.21 was replaced and significantly expanded to cover many 7093 different error situations. [Issue #26] 7095 Added 2.23.1, which covers how to handle NAT traversal when transport 7096 mode is requested. [Issue #28] 7098 In 3.3.2, after the table for tranform type 4, added "Although ESP 7099 and AH do not directly include a Diffie-Hellman exchange, a Diffie- 7100 Hellman group MAY be negotiated for the Child SA. This allows the 7101 peers to employ Diffie-Hellman in the CREATE_CHILD_SA exchange, 7102 providing perfect forward secrecy for the generated Child SA keys." 7103 [Issue #57] 7105 In 3.5, added "The Peer Authorization Database (PAD) as described in 7106 RFC 4301 [IPSECARCH] describes the use of the ID payload in IKEv2 and 7107 provides a formal model for the binding of identity to policy in 7108 addition to providing services that deal more specifically with the 7109 details of policy enforcement. The PAD is intended to provide a link 7110 between the SPD and the IKE security association management. See 7111 Section 4.4.3 of RFC 4301 for more details." [Issue #58] 7113 Added to the definition of "X.509 Certificate" in 3.6: "Note that 7114 with this encoding, if a chain of certificates needs to be sent, 7115 multiple CERT payloads are used, only the first of which holds the 7116 public key used to validate the sender's AUTH payload." [Issue 7117 #107]. 7119 In 3.14, added "When an authenticated encryption algorithm is used to 7120 protect the IKE SA, the construction of the encrypted payload is 7121 different that what is described here. See [RFC5282] for more 7122 information on authenticated encryption algorithms and their use in 7123 ESP." 7125 Added the last two paragraphs of 3.15 (on CFG_REQUEST and CFG_REPLY, 7126 and CFG_SET and CFG_ACK). Removed all of 2.19.1 which contained the 7127 same material and a lot of material that was duplicated from other 7128 parts of the document. [Issue #108] 7130 Added the following to 3.15.3: "Note that there is an additional 7131 document that discusses IPv6 configuration in IKEv2, [IPV6CONFIG]. 7132 At the present time, it is an experimental document, but there is a 7133 hope that with more implementation experience, it will gain the same 7134 standards treatment as this document." [Issue #47 and Issue #60] 7136 Reworded the acknowledgements to be more inclusive. 7138 D.13. Changes from draft-ietf-ipsecme-ikev2bis-05 to 7139 draft-ietf-ipsecme-ikev2bis-06 7141 Many small editorial nits fixed. 7143 Changed all the tables to only list the values that were defined in 7144 RFC 4306. Removed reserved and private use ranges. Also, a pointer 7145 to the IANA registry is given repeatedly. 7147 At the end of 1.3.1, added "See Section 2.21 for a list of error 7148 messages that might occur if creating a Child SA fails." 7150 In 1.3.2, made the response "HDR, SK {SA, Nr, KEr}", as it was 7151 supposed to be from earlier changes. [Issue #50] 7153 In 1.3.2, added "Once a peer receives a request to rekey an IKE SA or 7154 sends a request to rekey an IKE SA, it SHOULD NOT start any new 7155 CREATE_CHILD_SA exchanges on the IKE SA that is being rekeyed." 7156 [Issue #22] 7158 In 1.3.2, removed "[[ Note: this text may be changed in the future. 7159 ]]" 7161 Added "All of Section 2.25 was added to explain how to act when there 7162 are timing collisions when deleting and/or rekeying SAs." to 1.7. 7163 [Issue #22] 7165 In 2.8, split the third paragraph into two paragraphs to make the 7166 different types of rekeying clearer. Also, changed "The old IKE SA 7167 is then deleted" to "After the new equivalent IKE SA is created, the 7168 initiator deletes the old IKE SA". 7170 In 2.8, changed "The initiator MAY begin sending on an SA as soon as 7171 it processes the response" to "The initiator SHOULD begin sending on 7172 an SA as soon as it processes the response". 7174 Completely revised and expanded the second paragraph of 2.8.2 ("The 7175 case where both..."). [Issue #22] 7177 Changed the first parenthetical statement at the beginning of 2.15 to 7178 read "or MAC using a padded shared secret as the key, as described 7179 later in this section". Also, changed the formatting of the MAC 7180 calculation at the end of the section very slightly. 7182 Also in 2.15, in the description of the signed octets, fixed two 7183 lines. 7185 . . . 7186 InitiatorIDPayload = PayloadHeader | RestOfIDPayload 7187 RestOfInitIDPayload = IDType | RESERVED | InitIDData 7188 . . . 7190 becomes 7192 . . . 7193 InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload 7194 RestOfInitIDPayload = IDType | RESERVED | InitIDData 7195 . . . 7197 ...and the same change for the responder. 7199 In 2.23, removed the second-to-last bullet because it was 7200 accidentally left there when the last bullet was copied and expanded 7201 from it. 7203 Added 2.25 and its subsections. [Issue #22] 7205 Added to the end of 3.6: "Implementations MUST support the HTTP 7206 method for hash-and-URL lookup. The behavior of other URL methods is 7207 not currently specified, and such methods SHOULD NOT be used in the 7208 absence of a document specifying them." [Issue #117] 7210 In 3.7, removed "10" from the list of acceptable types for the 7211 "Certification Authority" field. [Issue #120] 7213 In 3.8, definition of RSA Digital Signature, added: "Implementations 7214 can use the certificates received from a given peer as a hint for 7215 selecting a mutually-understood hash function for the AUTH payload 7216 signature. Note, however, that the hash algorithm used in the AUTH 7217 payload signature doesn't have to be the same as any hash 7218 algorithm(s) used in the certificate(s)." [Isse #116] 7220 In 3.10.1, added 7222 TEMPORARY_FAILURE 7223 See section 2.25. 7225 CHILD_SA_NOT_FOUND 7226 See section 2.25. 7228 Also added these to the IANA considerations in section 6. [Issue 7229 #22] 7231 In 3.15, changed "Requestors MUST ignore returned attributes that 7232 they do not recognize" to "Unrecognized or unsupported attributes 7233 MUST be ignored in both requests and responses". This brings back 7234 some text that was removed a few iterations ago. 7236 In 4, changed "If an implementation does support issuing such 7237 requests" to "If an implementation does support issuing such requests 7238 and its policy requires using temporary IP addresses". 7240 In 8 (Refereneces), changed the reference for AEAD from RFC 5116 to 7241 RFC 5282. Also added IKEV2IANA as a normative reference. Also 7242 changed the FTP URLs to the RFC Editor to HTTP references. 7244 D.14. Changes from draft-ietf-ipsecme-ikev2bis-06 to 7245 draft-ietf-ipsecme-ikev2bis-07 7247 These changes were made during and after WG Last Call. 7249 Many small editorial nits fixed. 7251 In 1.2, added "(A man-in-the-middle who cannot complete the IKE_AUTH 7252 exchange can nonetheless see the identity of the initiator.)" 7254 In the table in 1.2, added " (not a payload)" to "IKE Header" because 7255 the other items are, in fact, payloads. Also changed "E Encrypted" 7256 to "SK Encrypted and Authenticated". 7258 Removed "When an IKE SA is not created, the error message return 7259 SHOULD NOT be encrypted because the other party will not be able to 7260 authenticate that message." from the end of 1.3.1. [Issue #127] 7262 In 1.3.1, added "An IPCOMP_SUPPORTED notification, covered in 7263 Section 2.22, can also be included in the exchange." 7265 In 1.3.2, changed "New initiator and responder SPIs are supplied in 7266 the SPI fields of the SA payload." to "A new initiator SPI is 7267 supplied in the SPI field of the SA payload." Also added "A new 7268 responder SPI is supplied in the SPI field of the SA payload." a few 7269 paragraphs down. 7271 In 1.3.3, changed the figure for the initiator from: 7273 Initiator Responder 7274 ------------------------------------------------------------------- 7275 HDR, SK {N, SA, Ni, [KEi], 7276 TSi, TSr} --> 7278 to: 7280 Initiator Responder 7281 ------------------------------------------------------------------- 7282 HDR, SK {N(REKEY_SA), SA, Ni, [KEi], 7283 TSi, TSr} --> 7285 Added to 1.4: "Note that some informational messages, not exchanges, 7286 can be sent outside the context of an IKE SA." 7288 In 1.5, changed "it MAY send an informational message" to "it MAY 7289 indicate this with a Notify payload". Made a similar change in the 7290 following paragraph. 7292 In 1.5, changed "If the receiving node has an active IKE SA to the IP 7293 address from whence the packet came, it MAY send a notification of 7294 the wayward packet over that IKE SA in an INFORMATIONAL exchange. If 7295 it does not have such an IKE SA, it MAY indicate this with a Notify 7296 payload without cryptographic protection to the source IP address." 7297 to "If the receiving node does not have an active IKE SA to the IP 7298 address from whence the packet came, it MAY send a notification of 7299 the wayward packet with a Notify payload without cryptographic 7300 protection to the source IP address." 7302 Fixed the boilerplate wording in 1.6. 7304 Added and clarified materila in 1.7. Also added "Significant" to the 7305 title of the section because it cannot list all the differences. 7306 [Issue #126] 7308 In 2.1, changed "IKE is a reliable protocol, in the sense that the 7309 initiator MUST retransmit a request until either it receives a 7310 corresponding reply OR it deems the IKE security association to have 7311 failed and it discards all state associated with the IKE SA and any 7312 Child SAs negotiated using that IKE SA." to "IKE is a reliable 7313 protocol: the initiator MUST retransmit a request until either it 7314 receives a corresponding reply, or until it deems the IKE SA to have 7315 failed. In the latter case, the initiator discards all state 7316 associated with the IKE SA and any Child SAs that were negotiated 7317 using that IKE SA." 7319 In 2.1, removed ", and the zero non-ESP marker" because it was 7320 confusing. 7322 In 2.2, rearranged the paragraphs beginning "The Message ID is a 32- 7323 bit.." and "Throughout this document, "initiator"...". 7325 In 2.5, changed "implementations SHOULD send the payloads defined in 7326 this specification in the order shown in the figures in Section 2" to 7327 "...the figures in Sections 1 and 2". 7329 In 2.6, changed "Also, incorporating Ni" to "Also, incorporating 7330 SPi". 7332 In 2.6, removed the paragraph that started "In addition to cookies" 7333 because it was redundant with information in 2.7 that was stated 7334 better. 7336 In 2.8, changed "It should do so if there has been no traffic since 7337 the last time the SA was rekeyed." to "It can also do so if ..." 7339 In 2.8.1, changed NO_PROPOSAL_CHOSEN to CHILD_SA_NOT_FOUND in the 7340 paragraph that starts "To B, it looks like A is trying to rekey" and 7341 the artwork after it. 7343 In 2.8.2, changed "In this case, when the peer that did not notice 7344 the simultaneous rekey gets the request to rekey the IKE SA that it 7345 has already successfully rekeyed, it MUST return 7346 TEMPORARY_FAILURE..." to "...it SHOULD return TEMPORARY_FAILURE...". 7347 [Issue #131] 7349 In 2.9, changed "To enable the responder to choose the appropriate 7350 range in this case, if the initiator has requested the SA due to a 7351 data packet, the initiator SHOULD include as the first traffic 7352 selector in each of TSi and TSr a very specific traffic selector 7353 including the addresses in the packet triggering the request" to "If 7354 the initiator requests an SA because it wants to sen a data packet, 7355 including the specific addresses in the packet triggering the request 7356 in the first traffic selector in both TSi and TSr enables the 7357 responder to choose the appropriate range". 7359 In 2.9, removed "Such misconfigurations should be recorded in error 7360 logs." [Issue #125] 7362 In 2.9, changed the end of the paragraph that starts "It is possible 7363 for the responder's policy..." to actually match the scenario, which 7364 is not a triggering packet. 7366 In 2.9, changed the "192.0.1" example network to "198.51.100" and 7367 removed the parenthetical comment about the old ones. Did the same 7368 change in 3.15.2 and 5.1. 7370 Rewrote parts of 2.13 to make it clearer when general functions and 7371 specific functions were being discussed. Also cleaned up 7372 inconsistent use of "prf" and "PRF" throughout the document. 7374 In 2.18, added "to generate SKEYSEED" to the end of "The old and new 7375 IKE SA...", and added "and using the new IKE SA's PRF" to the end of 7376 the last paragraph. [Issue #121] 7378 At the end of 2.19, removed some redundancy and split the final 7379 paragraph into two. 7381 In 2.21.2, removed "NOTE FOR WG DISCUSSION: Having other payloads in 7382 the message is allowed but there are none suggested. One WG member 7383 mentioned the possibility of adding a DELETE payload when the error 7384 is sent in a separate INFORMATIONAL exchange. Do we want to allow 7385 such additional payloads that have operational semantics?" 7387 In 2.23, changed "float to" to "use". 7389 In 2.23, changed "In the case of a mismatching 7390 NAT_DETECTION_SOURCE_IP hash, the recipient MAY reject the connection 7391 attempt if NAT traversal is not supported." to "In the case there is 7392 a mismatch of the NAT_DETECTION_SOURCE_IP hash with all of the 7393 NAT_DETECTION_SOURCE_IP payloads received, the recipient MAY reject 7394 the connection attempt if NAT traversal is not supported." Also 7395 removed the bullet that started "If the NAT_DETECTION_DESTINATION_IP 7396 payload received does not match the hash of the destination IP" 7397 because it was already covered above. 7399 In 2.23, removed "so this method MUST NOT be used when MOBIKE is 7400 used" but left in the reference to section 3.8 in MOBIKE so that 7401 readers can see what is and is not allowed. 7403 In 2.23.1, in the first bullet for the responder in transport mode, 7404 changed "Store the original traffic selector IP addresses as received 7405 source and destination address in case we need to undo address 7406 substitution." to "Store the original traffic selector IP addresses 7407 as received source and destination address, both in case we need to 7408 undo address substitution, and to use as the "real source and 7409 destination address" specified by [UDPENCAPS], and for TCP/UDP 7410 checksum fixup." 7412 In 2.25, changed: "A peer that receives a CHILD_SA_NOT_FOUND 7413 notification SHOULD silently delete the Child SA and send a request 7414 to create a new Child SA from scratch." to "A peer that receives a 7415 CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child SA 7416 (if it still exists) and send a request to create a new Child SA from 7417 scratch (if the Child SA does not yet exist)." 7419 In the flags description in 3.1, replaced "The bits are defined LSB 7420 first, so bit 0 would be the least significant bit of the Flags 7421 octet. " with "The bits are as follows: 7423 +-+-+-+-+-+-+-+-+ 7424 |X|X|R|V|I|X|X|X| 7425 +-+-+-+-+-+-+-+-+ 7427 Also added: ""X" bits MUST be cleared when sending and MUST be 7428 ignored on receipt." Then removed the bit positions from the 7429 description. 7431 In 3.1, added "See Section 2.5 for more information on this bit" to 7432 the end of the Critical bit description. 7434 In 3.2, changed "E Encrypted" to "SK Encrypted and Authenticated". 7436 In 3.3, fourth paragraph, changed "Combined-mode ciphers include both 7437 integrity and encryption in a single encryption algorithm, and are 7438 not allowed to be offered with a separate integrity algorithm other 7439 than "none"." to "Combined-mode ciphers include both integrity and 7440 encryption in a single encryption algorithm, and MUST either offer no 7441 integrity algorithm or a single integrity algorithm of "none", with 7442 no integrity algorithm being the RECOMMENDED method." Also, removed 7443 "If an algorithm that combines encryption and integrity protection is 7444 proposed, it MUST be proposed as an encryption algorithm and an 7445 integrity protection algorithm MUST NOT be proposed" from the 7446 following paragraph. [Issue #122] 7448 In 3.3.6, moved the last sentence from the second paragraph and moved 7449 it to third paragraph. It now reads "If one of the proposals offered 7450 is for the Diffie-Hellman group of NONE, the responder MUST ignore 7451 the initiator's KE payload and omit the KE payload from the 7452 response." 7454 In 3.4, added "See also Section 1.2 and Section 2.7." 7456 In 3.6, changed "Certificate payloads SHOULD be included in an 7457 exchange if certificates are available to the sender unless the peer 7458 has indicated an ability to retrieve this information from elsewhere 7459 using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload." to "Certificate 7460 payloads SHOULD be included in an exchange if certificates are 7461 available to the sender. The Hash and URL formats of the Certificate 7462 payloads should be used in case the peer has indicated an ability to 7463 retrieve this information from elsewhere using an 7464 HTTP_CERT_LOOKUP_SUPPORTED Notify payload." 7466 In 3.10.1, added "More information on error handling can be found in 7467 Section 2.21." 7469 Added TEMPORARY_FAILURE and CHILD_SA_NOT_FOUND to the table in 7470 3.10.1. 7472 Replaced the Start Port and End Port discussions in 3.13.1 with ones 7473 that describe the ICMP and ICMPv6 in more detail. Also replaced the 7474 two paragraphs starting "The traffic selector types 7..." and 7475 "Traffic selectors can use" with "he traffic selector types 7 and 8 7476 can also refer to ICMP or ICMPv6 type and code fields, as well as MH 7477 Type fields for the IPv6 mobility header [MIPV6]. Note, however, 7478 that neither ICMP nor MIPv6 packets have separate source and 7479 destination fields. The method for specifying the traffic selectors 7480 for ICMP and MIPv6 is shown by example in Section 4.4.1.3 of 7481 [IPSECARCH]". [Issue #129] 7483 In 3.15.1, made the table heading "Multi-Valued" instead of "Valued". 7485 In 3.15.1, added "(except INTERNAL_ADDRESS_EXPIRY and 7486 INTERNAL_IP6_NBNS which were removed by this document)" to the bullet 7487 point for "Value" because those two were removed from the table. 7489 Added new paragraph at the end of 3.15.4 to suggest what the 7490 initiator should do if they don't get enough addresses. [Issue #124] 7492 In 5, changed "An implementation using EAP MUST also use strong 7493 authentication" back to "An implementation using EAP MUST also use a 7494 public-key-based authentication" soas not to change mandatory 7495 requirements from RFC 4306. 7497 Added to section 6: "Two items are removed from the IKEv2 7498 Configuration Payload Attribute Types table: INTERNAL_IP6_NBNS and 7499 INTERNAL_ADDRESS_EXPIRY." 7501 Removed Appendix C, "Significant Changes from RFC 4306", because this 7502 information is actually going in section 1.7. 7504 In C.5, changed the figure from: 7506 request --> SA, Ni, [KEi] 7507 [V+][N+] 7509 response <-- SA, Nr, [KEr] 7510 [V+][N+] 7512 to 7514 request --> SA, Ni, KEi 7515 [V+][N+] 7517 response <-- SA, Nr, KEr 7518 [V+][N+] 7520 D.15. Changes from draft-ietf-ipsecme-ikev2bis-07 to 7521 draft-ietf-ipsecme-ikev2bis-08 7523 Lots more small editorial issues fixed. 7525 These changes were made after WG Last Call, mostly to close out open 7526 issues. 7528 In 1.2, changed "The recipients of messages 3 and 4 MUST verify that 7529 all signatures and MACs are computed correctly and that the names in 7530 the ID payloads correspond to the keys used to generate the AUTH 7531 payload." to "The recipients of messages 3 and 4 MUST verify that all 7532 signatures and MACs are computed correctly. If either side uses a 7533 shared secret for authentication, the names in the ID payload MUST 7534 correspond to the key used to generate the AUTH payload." 7536 In 1.3, added "This notify can also be used to reject IKE SA rekey" 7537 to the discussion of sending the NO_ADDITIONAL_SAS notification. 7538 [Issue #132] 7540 In 1.3.2, added a pointer to 2.18; vice versa. 7542 Added to 1.3.3: "The notifications described in Section 1.3.1 may 7543 also be sent in a rekeying exchange. Usually these will be the same 7544 notifications that were used in the original exchange; for example, 7545 when rekeying a transport mode SA, the USE_TRANSPORT_MODE 7546 notification will be used." [Issue #133] 7548 In 1.4.1, replaced the last paragraph ("Half-closed ESP or AH 7549 connections...") with two paragraphs that clarify deleting IKE SAs as 7550 compared to half-closed ESP or AH connections. 7552 In 1.5, changed "If the receiving node does not have an active IKE SA 7553 to the IP address from whence the packet came, it" to "The receiving 7554 node". 7556 In 1.5, replaced the last three paragraphs ("There are two cases...", 7557 "In case of INVALID_IKE_SPI...", and "In case of INVALID_SPI...") 7558 with a more detailed description. [Issue #143] 7560 In 1.7, added "Section 2.23 clarified that, in NAT traversal, now 7561 both UDP encapsulated IPsec packets and non-UDP encapsulated IPsec 7562 packets packets need to be understood when receiving." 7564 Added a new paragraph at the end of 2.1 ("The retransmission policy 7565 for one-way messages is somewhat different..."). [Issue #147] 7567 Replaced the first paragraph in 2.6 with a shorter one, and moved the 7568 historical material to the end of the section. [Issue #148] 7570 In 2.6.1, removed "SAi1 and" from "For instance, if the responder 7571 includes the SAi1 and KEi payloads in cookie calculation..." [Issue 7572 #134] 7574 In 2.7, moved the paragraph that begins "Because the initiator sends 7575 its Diffie-Hellman value in the IKE_SA_INIT" to 1.2. [Issue #144] 7577 In 2.8, replaced "MAY send a dummy message on a newly created SA" 7578 with "MAY send a dummy ESP message on a newly created ESP SA". 7579 [Issue #154] 7581 In 2.8, changed "...it has received a cryptographically valid message 7582 on the new SA..." to "...it has received a cryptographically valid 7583 message on the other half of the SA pair...". [Issue #149] 7585 In 2.8.2, changed "The new IKE SA containing the lowest nonce 7586 inherits the Child SAs" to "The new IKE SA containing the lowest 7587 nonce SHOULD be deleted by the node that created it, and the other 7588 suriving new IKE SA MUST inherit all the Child SAs". [Issue #135] 7590 In 2.8.2, added "In addition to normal simultaneous rekeying cases, 7591 there is a special case where one peer finishes its rekey before it 7592 even notices that other peer is doing a rekey." [Issue #171] 7594 In 2.8.2, added "Support of the TEMPORARY_FAILURE notification is not 7595 negotiated, so older peers may receive these notifications. In that 7596 case, they will treat it the same as any other unknown error 7597 notification, and will stop the exchange. Because the other peer has 7598 already rekeyed the exchange, doing so does not have any ill 7599 effects." [Issue #150] 7601 In 2.9, reverted to using a SHOULD for trigger packets. Replaced "If 7602 the initiator requests an SA because it wants to send a data packet, 7603 including the specific addresses in the packet triggering the request 7604 in the first traffic selector in both TSi and TSr enables the 7605 responder to choose the appropriate range" with "To enable the 7606 responder to choose the appropriate range in this case, if the 7607 initiator has requested the SA due to a data packet, the initiator 7608 SHOULD include as the first traffic selector in each of TSi and TSr a 7609 very specific traffic selector including the addresses in the packet 7610 triggering the request." [Issue #155] 7612 In 2.14, changed "only the first 64 bits of Ni and the first 64 bits 7613 of Nr are used in the calculation" to "only the first 64 bits of Ni 7614 and the first 64 bits of Nr are used in calculating SKEYSEED, but all 7615 the bits are used for input to the prf+ function". [Issue #138] 7617 Added to the end of 2.15: "There are two types of EAP authentication 7618 (described in Section 2.16), and each type uses different values in 7619 the AUTH computations shown above. If the EAP method is key- 7620 generating, substitute MSK for the Shared Secret in the computation. 7621 For non-key-generating methods, substitute SK_pi and SK_pr, 7622 respectively, for the Shared Secret in the two AUTH computations." 7623 [Issue #151] 7625 In 2.16, changed "the authenticated identity has to be sent" to "the 7626 authenticated identity, if different from that in the IDi payload, 7627 has to be sent". [Issue #174] 7629 In 2.17, significantly changed the discussion of the order in which 7630 keying material is taken from KEYMAT. The result is the same, but 7631 the description is quite different, and now also refers to ROHC. 7632 [Issue #139] 7634 In 2.21, changed "Only authentication failures 7635 (AUTHENTICATION_FAILED)..." to "Only authentication failures 7636 (AUTHENTICATION_FAILED and EAP failure)...". Also added "If the 7637 exchange is terminated with EAP Failure, an AUTHENTICATION_FAILED 7638 notification is not sent." [Issue #152 and #160] 7640 In 2.21.2, removed INVALID_SELECTORS from the list of things that are 7641 returned from the piggybacked exchanges. [Issue #166] 7643 In 2.23, changed "In the case of NAT traversal, the Traffic Selectors 7644 MUST contain exactly one IP address, which is then used as the 7645 original IP address" to "In the case of transport mode NAT traversal, 7646 the traffic selectors MUST contain exactly one IP address, which is 7647 then used as the original IP address". [Issue #136] 7649 In 2.23, completely replaced the paragraph that begins "An initiator 7650 can use port 4500". [Issue #146] 7652 In 2.23, changed "In addition, firewalls may be configured to pass 7653 IPsec traffic over UDP but not ESP/AH or vice versa." to "In 7654 addition, firewalls may be configured to pass UDP-encapsulated IPsec 7655 traffic but not plain, unencapsulated ESP/AH or vice versa". 7657 In 2.23, changed "SPIs, source IP address, and port" to "SPIs, source 7658 or recipient IP address respectively, and port". [Issue #162]. 7660 In 2.23, completely replaced the last paragraph ("There are cases 7661 where a NAT box..."). [Issue #175] 7663 In 2.23.1, changed "When the client starts creating the IKEv2 SA and 7664 Child SA for sending traffic to the server, it has a triggering 7665 packet with source IP address of IP1, and a destination IP address of 7666 IPN2" to "...it may have a triggering packet...". Changed "The first 7667 traffic selector of TSi and TSr SHOULD have very specific traffic 7668 selectors including protocol and port numbers from the packet 7669 triggering the request" to "...SHOULD have very specific traffic 7670 selectors including protocol and port numbers, such as from the 7671 packet...". The same change is made in the third bullet of the 7672 client list near the end of the section. [Issue #173] 7674 At the beginning of the second paragraph of 3.1, changed "The 7675 Recipient SPI" to the "The responder's SPI". 7677 In 3.1, changed "Payloads are processed in the order in which they 7678 appear in an IKE message by invoking the appropriate processing 7679 routine according to the "Next Payload" field in the IKE header and 7680 subsequently according to the "Next Payload" field in the IKE payload 7681 itself until a "Next Payload" field of zero indicates that no 7682 payloads follow" to "Payloads are identified in the order in which 7683 they appear in an IKE message by looking in the "Next Payload" field 7684 in the IKE header, and subsequently according to the "Next Payload" 7685 field in the IKE payload itself until a "Next Payload" field of zero 7686 indicates that no payloads follow". [Issue #159] 7688 In 3.1, added "including multiple sessions per peer" to the end of 7689 the second paragraph. 7691 In 3.2, changed "In the header of an Encrypted payload, the Next 7692 Payload field is set to the payload type of the first contained 7693 payload (instead of 0)" to "In the header of an Encrypted payload, 7694 the Next Payload field is set to the payload type of the first 7695 contained payload (instead of 0); conversely, the Next Payload field 7696 of the last contained payload is set to zero." [Issue #164] 7698 In 3.3, changed the example of the two proposals and added a worked- 7699 out figure for them. [Issue #157] 7701 In 3.3.2, changed PRF_HMAC_TIGER to UNSPECIFIED. 7703 In 3.3.5, added "unless that length exceeds two bytes" to the end of 7704 "Attributes described as fixed length MUST NOT be encoded using the 7705 variable-length encoding". [Issue #167] 7707 In 3.3.6, changed "The initiator of an exchange MUST check that the 7708 accepted offer is consistent with one of its proposals, and if not 7709 that response MUST be rejected" to "The initiator of an exchange MUST 7710 check that the accepted offer is consistent with one of its 7711 proposals, and if not MUST terminate the exchange". 7713 In 3.3.6, changed "Similarly, if the responder receives a transform 7714 that contains a Transform Attribute it does not understand..." to 7715 "Similarly, if the responder receives a transform that it does not 7716 understand, or one that contains a Transform Attribute it does not 7717 understand...". 7719 In 3.4, changed "The length of the Diffie-Hellman public value MUST 7720 be equal to the length of the prime modulus over which the 7721 exponentiation was performed, prepending zero bits to the value if 7722 necessary" to "The length of the the Diffie-Hellman public value for 7723 MODP groups..." (because it is not true for elliptic curve groups). 7725 In 3.5, changed "IPv6-only implementations MAY be configurable to 7726 send only ID_IPV6_ADDR" to "IPv6-only implementations MAY be 7727 configurable to send ID_IPV6_ADDR instead of ID_IPV6_ADDR for IP 7728 addresses." 7730 In 3.6, replaced "Use the following ASN.1 definition for an X.509 7731 bundle" by "The "Hash and URL of a bundle" type uses the following 7732 ASN.1 definition for the X.509 bundle". 7734 In 3.7, removed "If multiple CAs are trusted and the certificate 7735 encoding does not allow a list, then multiple Certificate Request 7736 payloads would need to be transmitted". 7738 In 3.14, added "This payload is also called the "Encrypted and 7739 Authenticated" payload." 7741 In 3.16, removed the table of EAP types and replaced it with "Note 7742 that since IKE passes an indication of initiator identity in message 7743 3 of the protocol, the responder SHOULD NOT send EAP Identity 7744 requests (type 1). The initiator MAY, however, respond to such 7745 requests if it receives them." [Issue #153] 7747 In 3.16, removed "In other messages, this field MAY be set to any 7748 value" from the bullet defining Identifier. [Issue #168] 7750 In 4, changed "Ability to support various types of legacy 7751 authentication" to "Ability to support EAP-based authentication". 7753 In section 4, removed two sentences ("A minimal IPv4 responder 7754 implementation..." and "A minimal IPv4 initiator...") because they 7755 were redundant with the preceding text but also used new terms that 7756 were not defined. [Issue #172] 7758 In 5, removed "or overrun of either endpoint". [Issue #169] 7760 In 6, added that IANA should change "46 Encrypted E" to "46 Encrypted 7761 SK". 7763 In 8.2, updated the pointer for IPV6CONFIG to RFC 5739. 7765 D.16. Changes from draft-ietf-ipsecme-ikev2bis-08 to 7766 draft-ietf-ipsecme-ikev2bis-09 7768 These changes came during IETF Last Call. 7770 Fixed more minor editorial nits. 7772 Throughout, changed "#" in the name of variables to "Num" or "Number" 7773 because "#" is US-centric and confusing. 7775 Throughout, changed "denial of service" to "DoS" after the first 7776 definition to be consistent. 7778 In many places, changed "message 3" to "the first message in the 7779 IKE_AUTH exchange". 7781 In 1, changed 'The pair is called an "exchange"' to 'The pair is 7782 called an "exchange", and is sometimes called "request/response"'. 7783 Then changed most of the rest of "request/response" to "exchange" 7784 throughout the document. 7786 In 1, changed "We call the first messages establishing an IKE SA 7787 IKE_SA_INIT and IKE_AUTH exchanges and subsequent IKE exchanges 7788 CREATE_CHILD_SA or INFORMATIONAL exchanges" to "The first exchange of 7789 messages establishing an IKE SA are called the IKE_SA_INIT and 7790 IKE_AUTH exchanges; subsequent IKE exchanges are called the 7791 CREATE_CHILD_SA or INFORMATIONAL exchanges". 7793 In 1.2, added "see Section 2.13 and Section 2.14 for details on the 7794 key derivation". 7796 In 1.2, copied text from 2.2 to describe what a Message ID is before 7797 we start talking about it. 7799 In 1.2, added "The traffic selectors (TSi and TSr) are discussed in 7800 Section 2.9" because it was ignored in the section. 7802 In 1.2, changed "The recipients of messages 3 and 4 MUST verify..." 7803 to "Both parties in the IKE_SA_INIT exchange MUST verify...". 7805 In 1.2, changed "The list of responses..." to "Notify message 7806 types...". 7808 In 1.2, changed "If the failure is related to creating the IKE SA 7809 (for example, AUTHENTICATION_FAILED)" to "If the failure is related 7810 to creating the IKE SA (for example, an AUTHENTICATION_FAILED Notify 7811 error message is returned)". 7813 In 1.2, changed "the sender of the error indication" to "the sender 7814 of the error Notify message". 7816 In 1.3, removed the paragraph starting "All messages following..." 7817 because it is a duplicate from 1.2. 7819 In 1.3, changed "this notify" to "this notification". 7821 In 1.3, removed "The CREATE_CHILD_SA is also used for rekeying IKE 7822 SAs and Child SAs" because it is redundant with the first sentence of 7823 the section. 7825 In 1.3.1, changed "Failure of an attempt" to "A failed attempt". 7827 In 1.5, added "these flags are described in Section 3.1" because they 7828 had not beed defined yet. 7830 In 2.2, added "Retransmission of a message MUST use the same Message 7831 ID as the original message." 7833 At the end of 2.3, changed "is optional" to "is OPTIONAL". 7835 In 2.4, changed "Every implementation MUST be capable of responding 7836 to an INFORMATIONAL exchange, but a minimal implementation MAY 7837 respond to any INFORMATIONAL message with an empty INFORMATIONAL 7838 response" to "Every implementation MUST be capable of responding to 7839 an INFORMATIONAL exchange, but a minimal implementation MAY respond 7840 to any request in the INFORMATIONAL exchange with an empty response". 7842 In 2.4, changed "An implementation MUST NOT continue sending on any 7843 SA if some failure prevents it from receiving on all of the 7844 associated SAs" to "An implementation needs to stop sending on any 7845 SA..." because there is no way for the implementation to know if 7846 "some failure" has occured. 7848 In 2.4, changed "If Child SAs can fail independently from one another 7849 without the associated IKE SA being able to send a delete message, 7850 then they MUST be negotiated by separate IKE SAs" to "If a system 7851 creates Child SAs that can fail independently from one another 7852 without the associated IKE SA being able to send a delete message, 7853 then the system MUST negotiate such Child SAs using separate IKE 7854 SAs". [Issue #181] 7856 In 2.6, changed "will cause two packets:" to "will cause two packets 7857 to be sent:". 7859 In 2.6, added "possibly using exponential back-off" to the discussion 7860 of limiting the number of cookies it sends. 7862 Moved the paragraph that starts "When the IKE_SA_INIT exchange does 7863 not result" from 2.7 to 2.6. Also changed"the responder's SPI will 7864 be zero" to "the responder's SPI will be zero also in the response 7865 message". 7867 In 2.8.1, removed "lexicographical" because it was undefined and 7868 unnecessary. 7870 In 2.8.2, last paragraph: Change the beginning of the sentence and 7871 changed "older peers may receive these notifications" to "older peers 7872 that implement RFC 4306 but not this document may receive these 7873 notifications". 7875 Fixed the first two paragraphs of 2.9 to talk about PFKEY in the 7876 correct context. 7878 In 2.9, changed "reject the request with a status of 7879 SINGLE_PAIR_REQUIRED" with "reject the request with a 7880 SINGLE_PAIR_REQUIRED Notify message". 7882 In 2.13, changed "The preferred key size is used as the length of 7883 SK_d, SK_pi, and SK_pr" to "The preferred key size MUST be used as 7884 the length of SK_d, SK_pi, and SK_pr". 7886 In 2.14, changed "The lengths of SK_d, SK_pi, and SK_pr are the 7887 preferred key length of the agreed-to PRF" to "The lengths of SK_d, 7888 SK_pi, and SK_pr MUST be the preferred key length of the agreed-to 7889 PRF". 7891 In 2.15, moved "In the above calculation, IDi' and IDr' are the 7892 entire ID payloads excluding the fixed header" earlier and removed 7893 redundant definitions. 7895 In 2.16, added "(Note that the AUTH payload is required for non-EAP 7896 authentication, and is thus not marked as optional in the rest of 7897 this document.)" 7899 In 2.17, added a reference to [ROHCV2]. 7901 In 2.20, removed "to prevent trolling" because it is not a widely- 7902 known term. 7904 In 2.21.2, added "using the Vendor ID payload" to the last sentence. 7906 In 2.23, clarified the paragraph that starts "An initiator can 7907 use..." in many places, saying that it is UDP encapsulated ESP. 7909 In the bulleted list in 2.23 that lists what implementations that 7910 support NAT traversal must do, removed "IKE MUST listen on port 4500 7911 as well as port 500. IKE MUST respond to the IP address and port 7912 from which packets arrived". That requirement applies to all IKE 7913 implementations. 7915 In 2.23, changed "these payloads" to "the NAT_DETECTION_SOURCE_IP or 7916 NAT_DETECTION_DESTINATION_IP payloads". 7918 Throughout subsections of 3, added ", unsigned integer" in 7919 definitions of multi-octet items such as Message ID and Payload 7920 Length. 7922 In 3.1, added "(with one exception; see Section 2.21.2)" to the 7923 discussion of the Response flag. 7925 In 3.3.1, changed "the SPI is obtained from outer header" to "the SPI 7926 is obtained from outer IP header". 7928 In 3.3.6, changed "If one of the proposals offered is for the Diffie- 7929 Hellman group of NONE, the responder MUST ignore the initiator's KE 7930 payload and omit the KE payload from the response" to "If one of the 7931 proposals offered is for the Diffie-Hellman group of NONE, and the 7932 responder selects that Diffie-Hellman group, then it MUST ignore the 7933 initiator's KE payload and omit the KE payload from the response". 7934 [Issue #176] 7936 In 3.5, changed "[X.501]" and "[X.509]" to "[PKIX]". Also removed 7937 those two now-unneeded references. [Issue #183] 7939 In 3.5, changed "IPv6-only implementations MAY be configurable to 7940 send only ID_IPV6_ADDR instead of ID_IPV6_ADDR for IP addresses" to 7941 "IPv6-only implementations MAY be configurable to send only 7942 ID_IPV6_ADDR instead of ID_IPV4_ADDR for IP addresses". 7944 In 3.5, changed "and MUST be configurable to accept all of these 7945 types" to "and MUST be configurable to accept all of these four 7946 types". [Issue #186] 7948 In 3.6, changed "MUST be capable of being configured to send and 7949 accept the two Hash and URL formats (with HTTP URLs)" to "MUST be 7950 capable of being configured to send and accept the Hash and URL 7951 format (with HTTP URLs)" because there is only one format. 7953 At the beginning of 3.16, changed "The full set of acceptable values 7954 for the payload is defined elsewhere, but a short summary of RFC 3748 7955 is included here to make this document stand alone in the common 7956 cases" to "When using EAP, an appropriate EAP method needs to be 7957 selected. Many of these methods have been defined, specifying the 7958 protocol's use with various authentication mechanisms. EAP method 7959 types are listed in [EAP-IANA]. A short summary of the EAP format is 7960 included here for clarity.". Also added the reference to [EAP-IANA] 7961 to the informative references. [Issue #187] 7963 In 4, changed "There are a series of optional features that can 7964 easily be ignored by a particular implementation if it does not 7965 support that feature. Those features include:" to "The following are 7966 some of the features that can be omitted in a minimal 7967 implementation:". 7969 In the references, moved [AEAD] from informative to normative. 7971 In Appendix B, changed "The strength supplied by group one may not be 7972 sufficient for the mandatory-to-implement encryption algorithm and is 7973 here for historic reasons" to "The strength supplied by group 1 may 7974 not be sufficient for typical uses and is here for historic reasons". 7976 Authors' Addresses 7978 Charlie Kaufman 7979 Microsoft 7980 1 Microsoft Way 7981 Redmond, WA 98052 7982 US 7984 Phone: 1-425-707-3335 7985 Email: charliek@microsoft.com 7987 Paul Hoffman 7988 VPN Consortium 7989 127 Segre Place 7990 Santa Cruz, CA 95060 7991 US 7993 Phone: 1-831-426-9827 7994 Email: paul.hoffman@vpnc.org 7996 Yoav Nir 7997 Check Point Software Technologies Ltd. 7998 5 Hasolelim St. 7999 Tel Aviv 67897 8000 Israel 8002 Email: ynir@checkpoint.com 8004 Pasi Eronen 8005 Nokia Research Center 8006 P.O. Box 407 8007 FIN-00045 Nokia Group 8008 Finland 8010 Email: pasi.eronen@nokia.com