idnits 2.17.1 draft-ietf-ipsecme-ikev2bis-11.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 8080 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 (May 17, 2010) is 5093 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 2369, but not defined == Missing Reference: 'KEi' is mentioned on line 7526, but not defined == Missing Reference: 'KEr' is mentioned on line 7529, but not defined == Missing Reference: 'CP' is mentioned on line 805, but not defined -- Looks like a reference, but probably isn't: '0' on line 4314 -- Looks like a reference, but probably isn't: '1' on line 4315 == Missing Reference: 'IKEv2' is mentioned on line 5827, but not defined == Missing Reference: 'IDr' is mentioned on line 6290, but not defined == Missing Reference: 'RFC5282' is mentioned on line 7141, but not defined ** Obsolete normative reference: RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEV2IANA' ** Obsolete normative reference: RFC 3447 (ref. 'PKCS1') (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 4307 (Obsoleted by RFC 8247) -- 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: 3 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: November 18, 2010 Check Point 8 P. Eronen 9 Nokia 10 May 17, 2010 12 Internet Key Exchange Protocol: IKEv2 13 draft-ietf-ipsecme-ikev2bis-11 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 November 18, 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 D.17. Changes from draft-ietf-ipsecme-ikev2bis-09 to 205 draft-ietf-ipsecme-ikev2bis-10 206 D.18. Changes from draft-ietf-ipsecme-ikev2bis-10 to 207 draft-ietf-ipsecme-ikev2bis-11 208 Authors' Addresses 210 1. Introduction 212 IP Security (IPsec) provides confidentiality, data integrity, access 213 control, and data source authentication to IP datagrams. These 214 services are provided by maintaining shared state between the source 215 and the sink of an IP datagram. This state defines, among other 216 things, the specific services provided to the datagram, which 217 cryptographic algorithms will be used to provide the services, and 218 the keys used as input to the cryptographic algorithms. 220 Establishing this shared state in a manual fashion does not scale 221 well. Therefore, a protocol to establish this state dynamically is 222 needed. This document describes such a protocol -- the Internet Key 223 Exchange (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI], 224 2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 replaced all of those RFCs. 225 IKEv2 was defined in [IKEV2] (RFC 4306) and was clarified in [Clarif] 226 (RFC 4718). This document replaces and updates RFC 4306 and RFC 227 4718. IKEv2 was a change to the IKE protocol that was not backward 228 compatible. In contrast, the current document not only provides a 229 clarification of IKEv2, but makes minimum changes to the IKE 230 protocol. A list of the significant differences between RFC 4306 and 231 this document is given in Section 1.7. 233 IKE performs mutual authentication between two parties and 234 establishes an IKE security association (SA) that includes shared 235 secret information that can be used to efficiently establish SAs for 236 Encapsulating Security Payload (ESP) [ESP] or Authentication Header 237 (AH) [AH] and a set of cryptographic algorithms to be used by the SAs 238 to protect the traffic that they carry. In this document, the term 239 "suite" or "cryptographic suite" refers to a complete set of 240 algorithms used to protect an SA. An initiator proposes one or more 241 suites by listing supported algorithms that can be combined into 242 suites in a mix-and-match fashion. IKE can also negotiate use of IP 243 Compression (IPComp) [IP-COMP] in connection with an ESP or AH SA. 244 The SAs for ESP or AH that get set up through that IKE SA we call 245 "Child SAs". 247 All IKE communications consist of pairs of messages: a request and a 248 response. The pair is called an "exchange", and is sometimes called 249 "request/response pair". The first exchange of messages establishing 250 an IKE SA are called the IKE_SA_INIT and IKE_AUTH exchanges; 251 subsequent IKE exchanges are called the CREATE_CHILD_SA or 252 INFORMATIONAL exchanges. In the common case, there is a single 253 IKE_SA_INIT exchange and a single IKE_AUTH exchange (a total of four 254 messages) to establish the IKE SA and the first Child SA. In 255 exceptional cases, there may be more than one of each of these 256 exchanges. In all cases, all IKE_SA_INIT exchanges MUST complete 257 before any other exchange type, then all IKE_AUTH exchanges MUST 258 complete, and following that any number of CREATE_CHILD_SA and 259 INFORMATIONAL exchanges may occur in any order. In some scenarios, 260 only a single Child SA is needed between the IPsec endpoints, and 261 therefore there would be no additional exchanges. Subsequent 262 exchanges MAY be used to establish additional Child SAs between the 263 same authenticated pair of endpoints and to perform housekeeping 264 functions. 266 An IKE message flow always consists of a request followed by a 267 response. It is the responsibility of the requester to ensure 268 reliability. If the response is not received within a timeout 269 interval, the requester needs to retransmit the request (or abandon 270 the connection). 272 The first exchange of an IKE session, IKE_SA_INIT, negotiates 273 security parameters for the IKE SA, sends nonces, and sends Diffie- 274 Hellman values. 276 The second exchange, IKE_AUTH, transmits identities, proves knowledge 277 of the secrets corresponding to the two identities, and sets up an SA 278 for the first (and often only) AH or ESP Child SA (unless there is 279 failure setting up the AH or ESP Child SA, in which case the IKE SA 280 is still established without the Child SA). 282 The types of subsequent exchanges are CREATE_CHILD_SA (which creates 283 a Child SA) and INFORMATIONAL (which deletes an SA, reports error 284 conditions, or does other housekeeping). Every request requires a 285 response. An INFORMATIONAL request with no payloads (other than the 286 empty Encrypted payload required by the syntax) is commonly used as a 287 check for liveness. These subsequent exchanges cannot be used until 288 the initial exchanges have completed. 290 In the description that follows, we assume that no errors occur. 291 Modifications to the flow when errors occur are described in 292 Section 2.21. 294 1.1. Usage Scenarios 296 IKE is used to negotiate ESP or AH SAs in a number of different 297 scenarios, each with its own special requirements. 299 1.1.1. Security Gateway to Security Gateway Tunnel Mode 301 +-+-+-+-+-+ +-+-+-+-+-+ 302 | | IPsec | | 303 Protected |Tunnel | tunnel |Tunnel | Protected 304 Subnet <-->|Endpoint |<---------->|Endpoint |<--> Subnet 305 | | | | 306 +-+-+-+-+-+ +-+-+-+-+-+ 308 Figure 1: Security Gateway to Security Gateway Tunnel 310 In this scenario, neither endpoint of the IP connection implements 311 IPsec, but network nodes between them protect traffic for part of the 312 way. Protection is transparent to the endpoints, and depends on 313 ordinary routing to send packets through the tunnel endpoints for 314 processing. Each endpoint would announce the set of addresses 315 "behind" it, and packets would be sent in tunnel mode where the inner 316 IP header would contain the IP addresses of the actual endpoints. 318 1.1.2. Endpoint-to-Endpoint Transport Mode 320 +-+-+-+-+-+ +-+-+-+-+-+ 321 | | IPsec transport | | 322 |Protected| or tunnel mode SA |Protected| 323 |Endpoint |<---------------------------------------->|Endpoint | 324 | | | | 325 +-+-+-+-+-+ +-+-+-+-+-+ 327 Figure 2: Endpoint to Endpoint 329 In this scenario, both endpoints of the IP connection implement 330 IPsec, as required of hosts in [IPSECARCH]. Transport mode will 331 commonly be used with no inner IP header. A single pair of addresses 332 will be negotiated for packets to be protected by this SA. These 333 endpoints MAY implement application layer access controls based on 334 the IPsec authenticated identities of the participants. This 335 scenario enables the end-to-end security that has been a guiding 336 principle for the Internet since [ARCHPRINC], [TRANSPARENCY], and a 337 method of limiting the inherent problems with complexity in networks 338 noted by [ARCHGUIDEPHIL]. Although this scenario may not be fully 339 applicable to the IPv4 Internet, it has been deployed successfully in 340 specific scenarios within intranets using IKEv1. It should be more 341 broadly enabled during the transition to IPv6 and with the adoption 342 of IKEv2. 344 It is possible in this scenario that one or both of the protected 345 endpoints will be behind a network address translation (NAT) node, in 346 which case the tunneled packets will have to be UDP encapsulated so 347 that port numbers in the UDP headers can be used to identify 348 individual endpoints "behind" the NAT (see Section 2.23). 350 1.1.3. Endpoint to Security Gateway Tunnel Mode 352 +-+-+-+-+-+ +-+-+-+-+-+ 353 | | IPsec | | Protected 354 |Protected| tunnel |Tunnel | Subnet 355 |Endpoint |<------------------------>|Endpoint |<--- and/or 356 | | | | Internet 357 +-+-+-+-+-+ +-+-+-+-+-+ 359 Figure 3: Endpoint to Security Gateway Tunnel 361 In this scenario, a protected endpoint (typically a portable roaming 362 computer) connects back to its corporate network through an IPsec- 363 protected tunnel. It might use this tunnel only to access 364 information on the corporate network, or it might tunnel all of its 365 traffic back through the corporate network in order to take advantage 366 of protection provided by a corporate firewall against Internet-based 367 attacks. In either case, the protected endpoint will want an IP 368 address associated with the security gateway so that packets returned 369 to it will go to the security gateway and be tunneled back. This IP 370 address may be static or may be dynamically allocated by the security 371 gateway. In support of the latter case, IKEv2 includes a mechanism 372 (namely, configuration payloads) for the initiator to request an IP 373 address owned by the security gateway for use for the duration of its 374 SA. 376 In this scenario, packets will use tunnel mode. On each packet from 377 the protected endpoint, the outer IP header will contain the source 378 IP address associated with its current location (i.e., the address 379 that will get traffic routed to the endpoint directly), while the 380 inner IP header will contain the source IP address assigned by the 381 security gateway (i.e., the address that will get traffic routed to 382 the security gateway for forwarding to the endpoint). The outer 383 destination address will always be that of the security gateway, 384 while the inner destination address will be the ultimate destination 385 for the packet. 387 In this scenario, it is possible that the protected endpoint will be 388 behind a NAT. In that case, the IP address as seen by the security 389 gateway will not be the same as the IP address sent by the protected 390 endpoint, and packets will have to be UDP encapsulated in order to be 391 routed properly. Interaction with NATs is covered in detail in 392 Section 2.23. 394 1.1.4. Other Scenarios 396 Other scenarios are possible, as are nested combinations of the 397 above. One notable example combines aspects of 1.1.1 and 1.1.3. A 398 subnet may make all external accesses through a remote security 399 gateway using an IPsec tunnel, where the addresses on the subnet are 400 routed to the security gateway by the rest of the Internet. An 401 example would be someone's home network being virtually on the 402 Internet with static IP addresses even though connectivity is 403 provided by an ISP that assigns a single dynamically assigned IP 404 address to the user's security gateway (where the static IP addresses 405 and an IPsec relay are provided by a third party located elsewhere). 407 1.2. The Initial Exchanges 409 Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH 410 exchanges (known in IKEv1 as Phase 1). These initial exchanges 411 normally consist of four messages, though in some scenarios that 412 number can grow. All communications using IKE consist of request/ 413 response pairs. We'll describe the base exchange first, followed by 414 variations. The first pair of messages (IKE_SA_INIT) negotiate 415 cryptographic algorithms, exchange nonces, and do a Diffie-Hellman 416 exchange [DH]. 418 The second pair of messages (IKE_AUTH) authenticate the previous 419 messages, exchange identities and certificates, and establish the 420 first Child SA. Parts of these messages are encrypted and integrity 421 protected with keys established through the IKE_SA_INIT exchange, so 422 the identities are hidden from eavesdroppers and all fields in all 423 the messages are authenticated. See Section 2.14 for information on 424 how the encryption keys are generated. (A man-in-the-middle who 425 cannot complete the IKE_AUTH exchange can nonetheless see the 426 identity of the initiator.) 428 All messages following the initial exchange are cryptographically 429 protected using the cryptographic algorithms and keys negotiated in 430 the IKE_SA_INIT exchange. These subsequent messages use the syntax 431 of the Encrypted Payload described in Section 3.14, encrypted with 432 keys that are derived as described in Section 2.14. All subsequent 433 messages include an Encrypted Payload, even if they are referred to 434 in the text as "empty". For the CREATE_CHILD_SA, IKE_AUTH, or 435 INFORMATIONAL exchanges, the message following the header is 436 encrypted and the message including the header is integrity protected 437 using the cryptographic algorithms negotiated for the IKE SA. 439 Every IKE message contains a Message ID as part of its fixed header. 440 This Message ID is used to match up requests and responses, and to 441 identify retransmissions of messages. 443 In the following descriptions, the payloads contained in the message 444 are indicated by names as listed below. 446 Notation Payload 447 ----------------------------------------- 448 AUTH Authentication 449 CERT Certificate 450 CERTREQ Certificate Request 451 CP Configuration 452 D Delete 453 EAP Extensible Authentication 454 HDR IKE Header (not a payload) 455 IDi Identification - Initiator 456 IDr Identification - Responder 457 KE Key Exchange 458 Ni, Nr Nonce 459 N Notify 460 SA Security Association 461 SK Encrypted and Authenticated 462 TSi Traffic Selector - Initiator 463 TSr Traffic Selector - Responder 464 V Vendor ID 466 The details of the contents of each payload are described in section 467 3. Payloads that may optionally appear will be shown in brackets, 468 such as [CERTREQ]; this indicates that a certificate request payload 469 can optionally be included. 471 The initial exchanges are as follows: 473 Initiator Responder 474 ------------------------------------------------------------------- 475 HDR, SAi1, KEi, Ni --> 477 HDR contains the Security Parameter Indexes (SPIs), version numbers, 478 and flags of various sorts. The SAi1 payload states the 479 cryptographic algorithms the initiator supports for the IKE SA. The 480 KE payload sends the initiator's Diffie-Hellman value. Ni is the 481 initiator's nonce. 483 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 485 The responder chooses a cryptographic suite from the initiator's 486 offered choices and expresses that choice in the SAr1 payload, 487 completes the Diffie-Hellman exchange with the KEr payload, and sends 488 its nonce in the Nr payload. 490 At this point in the negotiation, each party can generate SKEYSEED, 491 from which all keys are derived for that IKE SA. The messages that 492 follow are encrypted and integrity protected in their entirety, with 493 the exception of the message headers. The keys used for the 494 encryption and integrity protection are derived from SKEYSEED and are 495 known as SK_e (encryption) and SK_a (authentication, a.k.a. integrity 496 protection); see Section 2.13 and Section 2.14 for details on the key 497 derivation. A separate SK_e and SK_a is computed for each direction. 498 In addition to the keys SK_e and SK_a derived from the Diffie-Hellman 499 value for protection of the IKE SA, another quantity SK_d is derived 500 and used for derivation of further keying material for Child SAs. 501 The notation SK { ... } indicates that these payloads are encrypted 502 and integrity protected using that direction's SK_e and SK_a. 504 HDR, SK {IDi, [CERT,] [CERTREQ,] 505 [IDr,] AUTH, SAi2, 506 TSi, TSr} --> 508 The initiator asserts its identity with the IDi payload, proves 509 knowledge of the secret corresponding to IDi and integrity protects 510 the contents of the first message using the AUTH payload (see 511 Section 2.15). It might also send its certificate(s) in CERT 512 payload(s) and a list of its trust anchors in CERTREQ payload(s). If 513 any CERT payloads are included, the first certificate provided MUST 514 contain the public key used to verify the AUTH field. 516 The optional payload IDr enables the initiator to specify which of 517 the responder's identities it wants to talk to. This is useful when 518 the machine on which the responder is running is hosting multiple 519 identities at the same IP address. If the IDr proposed by the 520 initiator is not acceptable to the responder, the responder might use 521 some other IDr to finish the exchange. If the initiator then does 522 not accept the fact that responder used an IDr different than the one 523 that was requested, the initiator can close the SA after noticing the 524 fact. 526 The traffic selectors (TSi and TSr) are discussed in Section 2.9. 528 The initiator begins negotiation of a Child SA using the SAi2 529 payload. The final fields (starting with SAi2) are described in the 530 description of the CREATE_CHILD_SA exchange. 532 <-- HDR, SK {IDr, [CERT,] AUTH, 533 SAr2, TSi, TSr} 535 The responder asserts its identity with the IDr payload, optionally 536 sends one or more certificates (again with the certificate containing 537 the public key used to verify AUTH listed first), authenticates its 538 identity and protects the integrity of the second message with the 539 AUTH payload, and completes negotiation of a Child SA with the 540 additional fields described below in the CREATE_CHILD_SA exchange. 542 Both parties in the IKE_AUTH exchange MUST verify that all signatures 543 and MACs are computed correctly. If either side uses a shared secret 544 for authentication, the names in the ID payload MUST correspond to 545 the key used to generate the AUTH payload. 547 Because the initiator sends its Diffie-Hellman value in the 548 IKE_SA_INIT, it must guess the Diffie-Hellman group that the 549 responder will select from its list of supported groups. If the 550 initiator guesses wrong, the responder will respond with a Notify 551 payload of type INVALID_KE_PAYLOAD indicating the selected group. In 552 this case, the initiator MUST retry the IKE_SA_INIT with the 553 corrected Diffie-Hellman group. The initiator MUST again propose its 554 full set of acceptable cryptographic suites because the rejection 555 message was unauthenticated and otherwise an active attacker could 556 trick the endpoints into negotiating a weaker suite than a stronger 557 one that they both prefer. 559 If creating the Child SA during the IKE_AUTH exchange fails for some 560 reason, the IKE SA is still created as usual. The list of Notify 561 message types in the IKE_AUTH exchange that do not prevent an IKE SA 562 from being set up include at least the following: NO_PROPOSAL_CHOSEN, 563 TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and 564 FAILED_CP_REQUIRED. 566 If the failure is related to creating the IKE SA (for example, an 567 AUTHENTICATION_FAILED Notify error message is returned), the IKE SA 568 is not created. Note that although the IKE_AUTH messages are 569 encrypted and integrity protected, if the peer receiving this Notify 570 error message has not yet authenticated the other end (or if the peer 571 fails to authenticate the other end for some reason), the information 572 needs to be treated with caution. More precisely, assuming that the 573 MAC verifies correctly, the sender of the error Notify message is 574 known to be the responder of the IKE_SA_INIT exchange, but the 575 sender's identity cannot be assured. 577 Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads. 578 Thus, the SA payloads in the IKE_AUTH exchange cannot contain 579 Transform Type 4 (Diffie-Hellman Group) with any value other than 580 NONE. Implementations SHOULD omit the whole transform substructure 581 instead of sending value NONE. 583 1.3. The CREATE_CHILD_SA Exchange 585 The CREATE_CHILD_SA exchange is used to create new Child SAs and to 586 rekey both IKE SAs and Child SAs. This exchange consists of a single 587 request/response pair, and some of its function was referred to as a 588 phase 2 exchange in IKEv1. It MAY be initiated by either end of the 589 IKE SA after the initial exchanges are completed. 591 An SA is rekeyed by creating a new SA and then deleting the old one. 592 This section describes the first part of rekeying, the creation of 593 new SAs; Section 2.8 covers the mechanics of rekeying, including 594 moving traffic from old to new SAs and the deletion of the old SAs. 595 The two sections must be read together to understand the entire 596 process of rekeying. 598 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this 599 section the term initiator refers to the endpoint initiating this 600 exchange. An implementation MAY refuse all CREATE_CHILD_SA requests 601 within an IKE SA. 603 The CREATE_CHILD_SA request MAY optionally contain a KE payload for 604 an additional Diffie-Hellman exchange to enable stronger guarantees 605 of forward secrecy for the Child SA. The keying material for the 606 Child SA is a function of SK_d established during the establishment 607 of the IKE SA, the nonces exchanged during the CREATE_CHILD_SA 608 exchange, and the Diffie-Hellman value (if KE payloads are included 609 in the CREATE_CHILD_SA exchange). 611 If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of 612 the SA offers MUST include the Diffie-Hellman group of the KEi. The 613 Diffie-Hellman group of the KEi MUST be an element of the group the 614 initiator expects the responder to accept (additional Diffie-Hellman 615 groups can be proposed). If the responder selects a proposal using a 616 different Diffie-Hellman group (other than NONE), the responder MUST 617 reject the request and indicate its preferred Diffie-Hellman group in 618 the INVALID_KE_PAYLOAD Notify payload. There are two octets of data 619 associated with this notification: the accepted Diffie-Hellman Group 620 number in big endian order. In the case of such a rejection, the 621 CREATE_CHILD_SA exchange fails, and the initiator will probably retry 622 the exchange with a Diffie-Hellman proposal and KEi in the group that 623 the responder gave in the INVALID_KE_PAYLOAD Notify payload. 625 The responder sends a NO_ADDITIONAL_SAS notification to indicate that 626 a CREATE_CHILD_SA request is unacceptable because the responder is 627 unwilling to accept any more Child SAs on this IKE SA. This 628 notification can also be used to reject IKE SA rekey. Some minimal 629 implementations may only accept a single Child SA setup in the 630 context of an initial IKE exchange and reject any subsequent attempts 631 to add more. 633 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA Exchange 635 A Child SA may be created by sending a CREATE_CHILD_SA request. The 636 CREATE_CHILD_SA request for creating a new Child SA is: 638 Initiator Responder 639 ------------------------------------------------------------------- 640 HDR, SK {SA, Ni, [KEi], 641 TSi, TSr} --> 643 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 644 payload, optionally a Diffie-Hellman value in the KEi payload, and 645 the proposed traffic selectors for the proposed Child SA in the TSi 646 and TSr payloads. 648 The CREATE_CHILD_SA response for creating a new Child SA is: 650 <-- HDR, SK {SA, Nr, [KEr], 651 TSi, TSr} 653 The responder replies (using the same Message ID to respond) with the 654 accepted offer in an SA payload, and a Diffie-Hellman value in the 655 KEr payload if KEi was included in the request and the selected 656 cryptographic suite includes that group. 658 The traffic selectors for traffic to be sent on that SA are specified 659 in the TS payloads in the response, which may be a subset of what the 660 initiator of the Child SA proposed. 662 The USE_TRANSPORT_MODE notification MAY be included in a request 663 message that also includes an SA payload requesting a Child SA. It 664 requests that the Child SA use transport mode rather than tunnel mode 665 for the SA created. If the request is accepted, the response MUST 666 also include a notification of type USE_TRANSPORT_MODE. If the 667 responder declines the request, the Child SA will be established in 668 tunnel mode. If this is unacceptable to the initiator, the initiator 669 MUST delete the SA. Note: Except when using this option to negotiate 670 transport mode, all Child SAs will use tunnel mode. 672 The ESP_TFC_PADDING_NOT_SUPPORTED notification asserts that the 673 sending endpoint will not accept packets that contain Traffic Flow 674 Confidentiality (TFC) padding over the Child SA being negotiated. If 675 neither endpoint accepts TFC padding, this notification is included 676 in both the request and the response. If this notification is 677 included in only one of the messages, TFC padding can still be sent 678 in the other direction. 680 The NON_FIRST_FRAGMENTS_ALSO notification is used for fragmentation 681 control. See [IPSECARCH] for a fuller explanation. Both parties 682 need to agree to sending non-first fragments before either party does 683 so. It is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is 684 included in both the request proposing an SA and the response 685 accepting it. If the responder does not want to send or receive non- 686 first fragments, it only omits NON_FIRST_FRAGMENTS_ALSO notification 687 from its response, but does not reject the whole Child SA creation. 689 An IPCOMP_SUPPORTED notification, covered in Section 2.22, can also 690 be included in the exchange. 692 A failed attempt to create a Child SA SHOULD NOT tear down the IKE 693 SA: there is no reason to lose the work done to set up the IKE SA. 694 See Section 2.21 for a list of error messages that might occur if 695 creating a Child SA fails. 697 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange 699 The CREATE_CHILD_SA request for rekeying an IKE SA is: 701 Initiator Responder 702 ------------------------------------------------------------------- 703 HDR, SK {SA, Ni, KEi} --> 705 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 706 payload, and a Diffie-Hellman value in the KEi payload. The KEi 707 payload MUST be included. A new initiator SPI is supplied in the SPI 708 field of the SA payload. Once a peer receives a request to rekey an 709 IKE SA or sends a request to rekey an IKE SA, it SHOULD NOT start any 710 new CREATE_CHILD_SA exchanges on the IKE SA that is being rekeyed. 712 The CREATE_CHILD_SA response for rekeying an IKE SA is: 714 <-- HDR, SK {SA, Nr, KEr} 716 The responder replies (using the same Message ID to respond) with the 717 accepted offer in an SA payload, and a Diffie-Hellman value in the 718 KEr payload if the selected cryptographic suite includes that group. 719 A new responder SPI is supplied in the SPI field of the SA payload. 721 The new IKE SA has its message counters set to 0, regardless of what 722 they were in the earlier IKE SA. The first IKE requests from both 723 sides on the new IKE SA will have message ID 0. The old IKE SA 724 retains its numbering, so any further requests (for example, to 725 delete the IKE SA) will have consecutive numbering. The new IKE SA 726 also has its window size reset to 1, and the initiator in this rekey 727 exchange is the new "original initiator" of the new IKE SA. 729 Section 2.18 also covers IKE SA rekeying in detail. 731 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange 733 The CREATE_CHILD_SA request for rekeying a Child SA is: 735 Initiator Responder 736 ------------------------------------------------------------------- 737 HDR, SK {N(REKEY_SA), SA, Ni, [KEi], 738 TSi, TSr} --> 740 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 741 payload, optionally a Diffie-Hellman value in the KEi payload, and 742 the proposed traffic selectors for the proposed Child SA in the TSi 743 and TSr payloads. 745 The notifications described in Section 1.3.1 may also be sent in a 746 rekeying exchange. Usually these will be the same notifications that 747 were used in the original exchange; for example, when rekeying a 748 transport mode SA, the USE_TRANSPORT_MODE notification will be used. 750 The REKEY_SA notification MUST be included in a CREATE_CHILD_SA 751 exchange if the purpose of the exchange is to replace an existing ESP 752 or AH SA. The SA being rekeyed is identified by the SPI field in the 753 Notify payload; this is the SPI the exchange initiator would expect 754 in inbound ESP or AH packets. There is no data associated with this 755 Notify message type. The Protocol ID field of the REKEY_SA 756 notification is set to match the protocol of the SA we are rekeying, 757 for example, 3 for ESP and 2 for AH. 759 The CREATE_CHILD_SA response for rekeying a Child SA is: 761 <-- HDR, SK {SA, Nr, [KEr], 762 TSi, TSr} 764 The responder replies (using the same Message ID to respond) with the 765 accepted offer in an SA payload, and a Diffie-Hellman value in the 766 KEr payload if KEi was included in the request and the selected 767 cryptographic suite includes that group. 769 The traffic selectors for traffic to be sent on that SA are specified 770 in the TS payloads in the response, which may be a subset of what the 771 initiator of the Child SA proposed. 773 1.4. The INFORMATIONAL Exchange 775 At various points during the operation of an IKE SA, peers may desire 776 to convey control messages to each other regarding errors or 777 notifications of certain events. To accomplish this, IKE defines an 778 INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur 779 after the initial exchanges and are cryptographically protected with 780 the negotiated keys. Note that some informational messages, not 781 exchanges, can be sent outside the context of an IKE SA. Section 782 2.21 also covers error messages in great detail. 784 Control messages that pertain to an IKE SA MUST be sent under that 785 IKE SA. Control messages that pertain to Child SAs MUST be sent 786 under the protection of the IKE SA which generated them (or its 787 successor if the IKE SA was rekeyed). 789 Messages in an INFORMATIONAL exchange contain zero or more 790 Notification, Delete, and Configuration payloads. The recipient of 791 an INFORMATIONAL exchange request MUST send some response; otherwise, 792 the sender will assume the message was lost in the network and will 793 retransmit it. That response MAY be an empty message. The request 794 message in an INFORMATIONAL exchange MAY also contain no payloads. 795 This is the expected way an endpoint can ask the other endpoint to 796 verify that it is alive. 798 The INFORMATIONAL exchange is defined as: 800 Initiator Responder 801 ------------------------------------------------------------------- 802 HDR, SK {[N,] [D,] 803 [CP,] ...} --> 804 <-- HDR, SK {[N,] [D,] 805 [CP], ...} 807 The processing of an INFORMATIONAL exchange is determined by its 808 component payloads. 810 1.4.1. Deleting an SA with INFORMATIONAL Exchanges 812 ESP and AH SAs always exist in pairs, with one SA in each direction. 813 When an SA is closed, both members of the pair MUST be closed (that 814 is, deleted). Each endpoint MUST close its incoming SAs and allow 815 the other endpoint to close the other SA in each pair. To delete an 816 SA, an INFORMATIONAL exchange with one or more Delete payloads is 817 sent listing the SPIs (as they would be expected in the headers of 818 inbound packets) of the SAs to be deleted. The recipient MUST close 819 the designated SAs. Note that one never sends delete payloads for 820 the two sides of an SA in a single message. If there are many SAs to 821 delete at the same time, one includes Delete payloads for the inbound 822 half of each SA pair in the INFORMATIONAL exchange. 824 Normally, the response in the INFORMATIONAL exchange will contain 825 delete payloads for the paired SAs going in the other direction. 826 There is one exception. If by chance both ends of a set of SAs 827 independently decide to close them, each may send a delete payload 828 and the two requests may cross in the network. If a node receives a 829 delete request for SAs for which it has already issued a delete 830 request, it MUST delete the outgoing SAs while processing the request 831 and the incoming SAs while processing the response. In that case, 832 the responses MUST NOT include delete payloads for the deleted SAs, 833 since that would result in duplicate deletion and could in theory 834 delete the wrong SA. 836 Similar to ESP and AH SAs, IKE SAs are also deleted by sending an 837 Informational exchange. Deleting an IKE SA implicitly closes any 838 remaining Child SAs negotiated under it. The response to a request 839 that deletes the IKE SA is an empty INFORMATIONAL response. 841 Half-closed ESP or AH connections are anomalous, and a node with 842 auditing capability should probably audit their existence if they 843 persist. Note that this specification does not specify time periods, 844 so it is up to individual endpoints to decide how long to wait. A 845 node MAY refuse to accept incoming data on half-closed connections 846 but MUST NOT unilaterally close them and reuse the SPIs. If 847 connection state becomes sufficiently messed up, a node MAY close the 848 IKE SA, as described above. It can then rebuild the SAs it needs on 849 a clean base under a new IKE SA. 851 1.5. Informational Messages outside of an IKE SA 853 There are some cases in which a node receives a packet that it cannot 854 process, but it may want to notify the sender about this situation. 856 o If an ESP or AH packet arrives with an unrecognized SPI. This 857 might be due to the receiving node having recently crashed and 858 lost state, or because of some other system malfunction or attack. 860 o If an encrypted IKE request packet arrives on port 500 or 4500 861 with an unrecognized IKE SPI. This might be due to the receiving 862 node having recently crashed and lost state, or because of some 863 other system malfunction or attack. 865 o If an IKE request packet arrives with a higher major version 866 number than the implementation supports. 868 In the first case, if the receiving node has an active IKE SA to the 869 IP address from whence the packet came, it MAY send an INVALID_SPI 870 notification of the wayward packet over that IKE SA in an 871 INFORMATIONAL exchange. The Notification Data contains the SPI of 872 the invalid packet. The recipient of this notification cannot tell 873 whether the SPI is for AH or ESP, but this is not important because 874 the SPIs are supposed to be different for the two. If no suitable 875 IKE SA exists, the node MAY send an informational message without 876 cryptographic protection to the source IP address, using the source 877 UDP port as the destination port if the packet was UDP (UDP- 878 encapsulated ESP or AH). In this case, it should only be used by the 879 recipient as a hint that something might be wrong (because it could 880 easily be forged). This message is not part of an INFORMATIONAL 881 exchange, and the receiving node MUST NOT respond to it because doing 882 so could cause a message loop. The message is constructed as 883 follows: there are no IKE SPI values that would be meaningful to the 884 recipient of such a notification; using zero values or random values 885 are both acceptable, this being the exception to the rule in 886 Section 3.1 that prohibits zero IKE Initiator SPIs. The Initiator 887 flag is set to 1, the Response flag is set to 0, and the version 888 flags are set in the normal fashion; these flags are described in 889 Section 3.1. 891 In the second and third cases, the message is always sent without 892 cryptographic protection (outside of an IKE SA), and includes either 893 an INVALID_IKE_SPI or an INVALID_MAJOR_VERSION notification (with no 894 notification data). The message is a response message, and thus it 895 is sent to the IP address and port from whence it came with the same 896 IKE SPIs and the Message ID and Exchange Type are copied from the 897 request. The Response flag is set to 1, and the version flags are 898 set in the normal fashion. 900 1.6. Requirements Terminology 902 Definitions of the primitive terms in this document (such as Security 903 Association or SA) can be found in [IPSECARCH]. It should be noted 904 that parts of IKEv2 rely on some of the processing rules in 905 [IPSECARCH], as described in various sections of this document. 907 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 908 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 909 document are to be interpreted as described in [MUSTSHOULD]. 911 1.7. Significant Differences Between RFC 4306 and This Document 913 This document contains clarifications and amplifications to IKEv2 914 [IKEV2]. Many of the clarifications are based on [Clarif]. The 915 changes listed in that document were discussed in the IPsec Working 916 Group and, after the Working Group was disbanded, on the IPsec 917 mailing list. That document contains detailed explanations of areas 918 that were unclear in IKEv2, and is thus useful to implementers of 919 IKEv2. 921 The protocol described in this document retains the same major 922 version number (2) and minor version number (0) as was used in RFC 923 4306. That is, the version number is *not* changed from RFC 4306. 924 The small number of technical changes listed here are not expected to 925 affect RFC 4306 implementations that have already been deployed at 926 the time of publication of this document. 928 This document makes the figures and references a bit more consistent 929 than they were in [IKEV2]. 931 IKEv2 developers have noted that the SHOULD-level requirements in RFC 932 4306 are often unclear in that they don't say when it is OK to not 933 obey the requirements. They also have noted that there are MUST- 934 level requirements that are not related to interoperability. This 935 document has more explanation of some of these requirements. All 936 non-capitalized uses of the words SHOULD and MUST now mean their 937 normal English sense, not the interoperability sense of [MUSTSHOULD]. 939 IKEv2 (and IKEv1) developers have noted that there is a great deal of 940 material in the tables of codes in Section 3.10.1 in RFC 4306. This 941 leads to implementers not having all the needed information in the 942 main body of the document. Much of the material from those tables 943 has been moved into the associated parts of the main body of the 944 document. 946 This document removes discussion of nesting AH and ESP. This was a 947 mistake in RFC 4306 caused by the lag between finishing RFC 4306 and 948 RFC 4301. Basically, IKEv2 is based on RFC 4301, which does not 949 include "SA bundles" that were part of RFC 2401. While a single 950 packet can go through IPsec processing multiple times, each of these 951 passes uses a separate SA, and the passes are coordinated by the 952 forwarding tables. In IKEv2, each of these SAs has to be created 953 using a separate CREATE_CHILD_SA exchange. 955 This document removes discussion of the INTERNAL_ADDRESS_EXPIRY 956 configuration attribute because its implementation was very 957 problematic. Implementations that conform to this document MUST 958 ignore proposals that have configuration attribute type 5, the old 959 value for INTERNAL_ADDRESS_EXPIRY. This document also removed 960 INTERNAL_IP6_NBNS as a configuration attribute. 962 This document removes the allowance for rejecting messages where the 963 payloads were not in the "right" order; now implementations MUST NOT 964 reject them. This is due to the lack of clarity where the orders for 965 the payloads are described. 967 The lists of items from RFC 4306 that ended up in the IANA registry 968 were trimmed to only include items that were actually defined in RFC 969 4306. Also, many of those lists are now preceded with the very 970 important instruction to developers that they really should look at 971 the IANA registry at the time of development because new items have 972 been added since RFC 4306. 974 This document adds clarification on when notifications are and are 975 not sent encrypted, depending on the state of the negotiation at the 976 time. 978 This document discusses more about how to negotiate combined-mode 979 ciphers. 981 In section 1.3.2, changed "The KEi payload SHOULD be included" to be 982 "The KEi payload MUST be included". This also led to changes in 983 section 2.18. 985 In Section 2.1, there is new material covering how the initiator's 986 SPI and/or IP is used to differentiate if this is a "half-open" IKE 987 SA or a new request. 989 This document clarifies the use of the critical flag in Section 2.5. 991 In 2.8, changed "Note that, when rekeying, the new Child SA MAY have 992 different traffic selectors and algorithms than the old one" to "Note 993 that, when rekeying, the new Child SA SHOULD NOT have different 994 traffic selectors and algorithms than the old one". 996 The new Section 2.8.2 covers simultaneous IKE SA rekeying. 998 The new Section 2.9.2 covers traffic selectors in rekeying. 1000 This document adds the restriction in Section 2.13 that all pseudo- 1001 random functions (PRFs) used with IKEv2 MUST take variable-sized 1002 keys. This should not affect any implementations because there were 1003 no standardized PRFs that have fixed-size keys. 1005 Section 2.18 requires doing a Diffie-Hellman exchange when rekeying 1006 the IKE_SA. In theory, RFC 4306 allowed a policy where the Diffie- 1007 Hellman exchange was optional, but this was not useful (or 1008 appropriate) when rekeying the IKE_SA. 1010 Section 2.21 has been greatly expanded to cover the different cases 1011 where error responses are needed and the appropriate responses to 1012 them. 1014 Section 2.23 clarified that, in NAT traversal, now both UDP 1015 encapsulated IPsec packets and non-UDP encapsulated IPsec packets 1016 packets need to be understood when receiving. 1018 Added Section 2.23.1 to describe NAT traversal when transport mode is 1019 requested. 1021 Added Section 2.25 to explain how to act when there are timing 1022 collisions when deleting and/or rekeying SAs, and two new error 1023 notifications (TEMPORARY_FAILURE and CHILD_SA_NOT_FOUND) were 1024 defined. 1026 In Section 3.6, added "Implementations MUST support the HTTP method 1027 for hash-and-URL lookup. The behavior of other URL methods is not 1028 currently specified, and such methods SHOULD NOT be used in the 1029 absence of a document specifying them." 1031 In Section 3.15.3, added a pointer to a new document that is related 1032 to configuration of IPv6 addresses. 1034 Appendix C was expanded and clarified. 1036 2. IKE Protocol Details and Variations 1038 IKE normally listens and sends on UDP port 500, though IKE messages 1039 may also be received on UDP port 4500 with a slightly different 1040 format (see Section 2.23). Since UDP is a datagram (unreliable) 1041 protocol, IKE includes in its definition recovery from transmission 1042 errors, including packet loss, packet replay, and packet forgery. 1043 IKE is designed to function so long as (1) at least one of a series 1044 of retransmitted packets reaches its destination before timing out; 1045 and (2) the channel is not so full of forged and replayed packets so 1046 as to exhaust the network or CPU capacities of either endpoint. Even 1047 in the absence of those minimum performance requirements, IKE is 1048 designed to fail cleanly (as though the network were broken). 1050 Although IKEv2 messages are intended to be short, they contain 1051 structures with no hard upper bound on size (in particular, digital 1052 certificates), and IKEv2 itself does not have a mechanism for 1053 fragmenting large messages. IP defines a mechanism for fragmentation 1054 of oversized UDP messages, but implementations vary in the maximum 1055 message size supported. Furthermore, use of IP fragmentation opens 1056 an implementation to denial of service (DoS) attacks [DOSUDPPROT]. 1057 Finally, some NAT and/or firewall implementations may block IP 1058 fragments. 1060 All IKEv2 implementations MUST be able to send, receive, and process 1061 IKE messages that are up to 1280 octets long, and they SHOULD be able 1062 to send, receive, and process messages that are up to 3000 octets 1063 long. IKEv2 implementations need to be aware of the maximum UDP 1064 message size supported and MAY shorten messages by leaving out some 1065 certificates or cryptographic suite proposals if that will keep 1066 messages below the maximum. Use of the "Hash and URL" formats rather 1067 than including certificates in exchanges where possible can avoid 1068 most problems. Implementations and configuration need to keep in 1069 mind, however, that if the URL lookups are possible only after the 1070 Child SA is established, recursion issues could prevent this 1071 technique from working. 1073 The UDP payload of all packets containing IKE messages sent on port 1074 4500 MUST begin with the prefix of four zeros; otherwise, the 1075 receiver won't know how to handle them. 1077 2.1. Use of Retransmission Timers 1079 All messages in IKE exist in pairs: a request and a response. The 1080 setup of an IKE SA normally consists of two exchanges. Once the IKE 1081 SA is set up, either end of the security association may initiate 1082 requests at any time, and there can be many requests and responses 1083 "in flight" at any given moment. But each message is labeled as 1084 either a request or a response, and for each exchange, one end of the 1085 security association is the initiator and the other is the responder. 1087 For every pair of IKE messages, the initiator is responsible for 1088 retransmission in the event of a timeout. The responder MUST never 1089 retransmit a response unless it receives a retransmission of the 1090 request. In that event, the responder MUST ignore the retransmitted 1091 request except insofar as it causes a retransmission of the response. 1092 The initiator MUST remember each request until it receives the 1093 corresponding response. The responder MUST remember each response 1094 until it receives a request whose sequence number is larger than or 1095 equal to the sequence number in the response plus its window size 1096 (see Section 2.3). In order to allow saving memory, responders are 1097 allowed to forget the response after a timeout of several minutes. 1098 If the responder receives a retransmitted request for which it has 1099 already forgotten the response, it MUST ignore the request (and not, 1100 for example, attempt constructing a new response). 1102 IKE is a reliable protocol: the initiator MUST retransmit a request 1103 until either it receives a corresponding response, or until it deems 1104 the IKE SA to have failed. In the latter case, the initiator 1105 discards all state associated with the IKE SA and any Child SAs that 1106 were negotiated using that IKE SA. A retransmission from the 1107 initiator MUST be bitwise identical to the original request. That 1108 is, everything starting from the IKE Header (the IKE SA initiator's 1109 SPI onwards) must be bitwise identical; items before it (such as the 1110 IP and UDP headers) do not have to be identical. 1112 Retransmissions of the IKE_SA_INIT request require some special 1113 handling. When a responder receives an IKE_SA_INIT request, it has 1114 to determine whether the packet is a retransmission belonging to an 1115 existing "half-open" IKE SA (in which case the responder retransmits 1116 the same response), or a new request (in which case the responder 1117 creates a new IKE SA and sends a fresh response), or it belongs to an 1118 existing IKE SA where the IKE_AUTH request has been already received 1119 (in which case the responder ignores it). 1121 It is not sufficient to use the initiator's SPI and/or IP address to 1122 differentiate between these three cases because two different peers 1123 behind a single NAT could choose the same initiator SPI. Instead, a 1124 robust responder will do the IKE SA lookup using the whole packet, 1125 its hash, or the Ni payload. 1127 The retransmission policy for one-way messages is somewhat different 1128 from that for regular messages. Because no acknowledgement is ever 1129 sent, there is no reason to gratuitously retransmit one-way messages. 1130 Given that all these messages are errors, it makes sense to send them 1131 only once per "offending" packet, and only retransmit if further 1132 offending packets are received. Still, it also makes sense to limit 1133 retransmissions of such error messages. 1135 2.2. Use of Sequence Numbers for Message ID 1137 Every IKE message contains a Message ID as part of its fixed header. 1138 This Message ID is used to match up requests and responses, and to 1139 identify retransmissions of messages. Retransmission of a message 1140 MUST use the same Message ID as the original message. 1142 The Message ID is a 32-bit quantity, which is zero for the 1143 IKE_SA_INIT messages (including retries of the message due to 1144 responses such as COOKIE and INVALID_KE_PAYLOAD), and incremented for 1145 each subsequent exchange. Thus, the first pair of IKE_AUTH messages 1146 will have ID of 1, the second (when EAP is used) will be 2, and so 1147 on. The Message ID is reset to zero in the new IKE SA after the IKE 1148 SA is rekeyed. 1150 Each endpoint in the IKE Security Association maintains two "current" 1151 Message IDs: the next one to be used for a request it initiates and 1152 the next one it expects to see in a request from the other end. 1153 These counters increment as requests are generated and received. 1154 Responses always contain the same message ID as the corresponding 1155 request. That means that after the initial exchange, each integer n 1156 may appear as the message ID in four distinct messages: the nth 1157 request from the original IKE initiator, the corresponding response, 1158 the nth request from the original IKE responder, and the 1159 corresponding response. If the two ends make very different numbers 1160 of requests, the Message IDs in the two directions can be very 1161 different. There is no ambiguity in the messages, however, because 1162 the Initiator and Response flags in the message header specify which 1163 of the four messages a particular one is. 1165 Throughout this document, "initiator" refers to the party who 1166 initiated the exchange being described. The "original initiator" 1167 always refers to the party who initiated the exchange which resulted 1168 in the current IKE SA. In other words, if the "original responder" 1169 starts rekeying the IKE SA, that party becomes the "original 1170 initiator" of the new IKE SA. 1172 Note that Message IDs are cryptographically protected and provide 1173 protection against message replays. In the unlikely event that 1174 Message IDs grow too large to fit in 32 bits, the IKE SA MUST be 1175 closed or rekeyed. 1177 2.3. Window Size for Overlapping Requests 1179 The SET_WINDOW_SIZE notification asserts that the sending endpoint is 1180 capable of keeping state for multiple outstanding exchanges, 1181 permitting the recipient to send multiple requests before getting a 1182 response to the first. The data associated with a SET_WINDOW_SIZE 1183 notification MUST be 4 octets long and contain the big endian 1184 representation of the number of messages the sender promises to keep. 1185 The window size is always one until the initial exchanges complete. 1187 An IKE endpoint MUST wait for a response to each of its messages 1188 before sending a subsequent message unless it has received a 1189 SET_WINDOW_SIZE Notify message from its peer informing it that the 1190 peer is prepared to maintain state for multiple outstanding messages 1191 in order to allow greater throughput. 1193 After an IKE SA is set up, in order to maximize IKE throughput, an 1194 IKE endpoint MAY issue multiple requests before getting a response to 1195 any of them, up to the limit set by its peer's SET_WINDOW_SIZE. 1196 These requests may pass one another over the network. An IKE 1197 endpoint MUST be prepared to accept and process a request while it 1198 has a request outstanding in order to avoid a deadlock in this 1199 situation. An IKE endpoint may also accept and process multiple 1200 requests while it has a request outstanding. 1202 An IKE endpoint MUST NOT exceed the peer's stated window size for 1203 transmitted IKE requests. In other words, if the responder stated 1204 its window size is N, then when the initiator needs to make a request 1205 X, it MUST wait until it has received responses to all requests up 1206 through request X-N. An IKE endpoint MUST keep a copy of (or be able 1207 to regenerate exactly) each request it has sent until it receives the 1208 corresponding response. An IKE endpoint MUST keep a copy of (or be 1209 able to regenerate exactly) the number of previous responses equal to 1210 its declared window size in case its response was lost and the 1211 initiator requests its retransmission by retransmitting the request. 1213 An IKE endpoint supporting a window size greater than one ought to be 1214 capable of processing incoming requests out of order to maximize 1215 performance in the event of network failures or packet reordering. 1217 The window size is normally a (possibly configurable) property of a 1218 particular implementation, and is not related to congestion control 1219 (unlike the window size in TCP, for example). In particular, it is 1220 not defined what the responder should do when it receives a 1221 SET_WINDOW_SIZE notification containing a smaller value than is 1222 currently in effect. Thus, there is currently no way to reduce the 1223 window size of an existing IKE SA; you can only increase it. When 1224 rekeying an IKE SA, the new IKE SA starts with window size 1 until it 1225 is explicitly increased by sending a new SET_WINDOW_SIZE 1226 notification. 1228 The INVALID_MESSAGE_ID notification is sent when an IKE message ID 1229 outside the supported window is received. This Notify message MUST 1230 NOT be sent in a response; the invalid request MUST NOT be 1231 acknowledged. Instead, inform the other side by initiating an 1232 INFORMATIONAL exchange with Notification data containing the four 1233 octet invalid message ID. Sending this notification is OPTIONAL, and 1234 notifications of this type MUST be rate limited. 1236 2.4. State Synchronization and Connection Timeouts 1238 An IKE endpoint is allowed to forget all of its state associated with 1239 an IKE SA and the collection of corresponding Child SAs at any time. 1240 This is the anticipated behavior in the event of an endpoint crash 1241 and restart. It is important when an endpoint either fails or 1242 reinitializes its state that the other endpoint detect those 1243 conditions and not continue to waste network bandwidth by sending 1244 packets over discarded SAs and having them fall into a black hole. 1246 The INITIAL_CONTACT notification asserts that this IKE SA is the only 1247 IKE SA currently active between the authenticated identities. It MAY 1248 be sent when an IKE SA is established after a crash, and the 1249 recipient MAY use this information to delete any other IKE SAs it has 1250 to the same authenticated identity without waiting for a timeout. 1251 This notification MUST NOT be sent by an entity that may be 1252 replicated (e.g., a roaming user's credentials where the user is 1253 allowed to connect to the corporate firewall from two remote systems 1254 at the same time). The INITIAL_CONTACT notification, if sent, MUST 1255 be in the first IKE_AUTH request or response, not as a separate 1256 exchange afterwards; receiving parties MAY ignore it in other 1257 messages. 1259 Since IKE is designed to operate in spite of DoS attacks from the 1260 network, an endpoint MUST NOT conclude that the other endpoint has 1261 failed based on any routing information (e.g., ICMP messages) or IKE 1262 messages that arrive without cryptographic protection (e.g., Notify 1263 messages complaining about unknown SPIs). An endpoint MUST conclude 1264 that the other endpoint has failed only when repeated attempts to 1265 contact it have gone unanswered for a timeout period or when a 1266 cryptographically protected INITIAL_CONTACT notification is received 1267 on a different IKE SA to the same authenticated identity. An 1268 endpoint should suspect that the other endpoint has failed based on 1269 routing information and initiate a request to see whether the other 1270 endpoint is alive. To check whether the other side is alive, IKE 1271 specifies an empty INFORMATIONAL message that (like all IKE requests) 1272 requires an acknowledgement (note that within the context of an IKE 1273 SA, an "empty" message consists of an IKE header followed by an 1274 Encrypted payload that contains no payloads). If a cryptographically 1275 protected (fresh, i.e. not retransmitted) message has been received 1276 from the other side recently, unprotected Notify messages MAY be 1277 ignored. Implementations MUST limit the rate at which they take 1278 actions based on unprotected messages. 1280 Numbers of retries and lengths of timeouts are not covered in this 1281 specification because they do not affect interoperability. It is 1282 suggested that messages be retransmitted at least a dozen times over 1283 a period of at least several minutes before giving up on an SA, but 1284 different environments may require different rules. To be a good 1285 network citizen, retransmission times MUST increase exponentially to 1286 avoid flooding the network and making an existing congestion 1287 situation worse. If there has only been outgoing traffic on all of 1288 the SAs associated with an IKE SA, it is essential to confirm 1289 liveness of the other endpoint to avoid black holes. If no 1290 cryptographically protected messages have been received on an IKE SA 1291 or any of its Child SAs recently, the system needs to perform a 1292 liveness check in order to prevent sending messages to a dead peer. 1293 (This is sometimes called "dead peer detection" or "DPD", although it 1294 is really detecting live peers, not dead ones.) Receipt of a fresh 1295 cryptographically protected message on an IKE SA or any of its Child 1296 SAs ensures liveness of the IKE SA and all of its Child SAs. Note 1297 that this places requirements on the failure modes of an IKE 1298 endpoint. An implementation needs to stop sending on any SA if some 1299 failure prevents it from receiving on all of the associated SAs. If 1300 a system creates Child SAs that can fail independently from one 1301 another without the associated IKE SA being able to send a delete 1302 message, then the system MUST negotiate such Child SAs using separate 1303 IKE SAs. 1305 There is a DoS attack on the initiator of an IKE SA that can be 1306 avoided if the initiator takes the proper care. Since the first two 1307 messages of an SA setup are not cryptographically protected, an 1308 attacker could respond to the initiator's message before the genuine 1309 responder and poison the connection setup attempt. To prevent this, 1310 the initiator MAY be willing to accept multiple responses to its 1311 first message, treat each as potentially legitimate, respond to it, 1312 and then discard all the invalid half-open connections when it 1313 receives a valid cryptographically protected response to any one of 1314 its requests. Once a cryptographically valid response is received, 1315 all subsequent responses should be ignored whether or not they are 1316 cryptographically valid. 1318 Note that with these rules, there is no reason to negotiate and agree 1319 upon an SA lifetime. If IKE presumes the partner is dead, based on 1320 repeated lack of acknowledgement to an IKE message, then the IKE SA 1321 and all Child SAs set up through that IKE SA are deleted. 1323 An IKE endpoint may at any time delete inactive Child SAs to recover 1324 resources used to hold their state. If an IKE endpoint chooses to 1325 delete Child SAs, it MUST send Delete payloads to the other end 1326 notifying it of the deletion. It MAY similarly time out the IKE SA. 1327 Closing the IKE SA implicitly closes all associated Child SAs. In 1328 this case, an IKE endpoint SHOULD send a Delete payload indicating 1329 that it has closed the IKE SA unless the other endpoint is no longer 1330 responding. 1332 2.5. Version Numbers and Forward Compatibility 1334 This document describes version 2.0 of IKE, meaning the major version 1335 number is 2 and the minor version number is 0. This document is a 1336 replacement for [IKEV2]. It is likely that some implementations will 1337 want to support version 1.0 and version 2.0, and in the future, other 1338 versions. 1340 The major version number should be incremented only if the packet 1341 formats or required actions have changed so dramatically that an 1342 older version node would not be able to interoperate with a newer 1343 version node if it simply ignored the fields it did not understand 1344 and took the actions specified in the older specification. The minor 1345 version number indicates new capabilities, and MUST be ignored by a 1346 node with a smaller minor version number, but used for informational 1347 purposes by the node with the larger minor version number. For 1348 example, it might indicate the ability to process a newly defined 1349 Notify message type. The node with the larger minor version number 1350 would simply note that its correspondent would not be able to 1351 understand that message and therefore would not send it. 1353 If an endpoint receives a message with a higher major version number, 1354 it MUST drop the message and SHOULD send an unauthenticated Notify 1355 message of type INVALID_MAJOR_VERSION containing the highest 1356 (closest) version number it supports. If an endpoint supports major 1357 version n, and major version m, it MUST support all versions between 1358 n and m. If it receives a message with a major version that it 1359 supports, it MUST respond with that version number. In order to 1360 prevent two nodes from being tricked into corresponding with a lower 1361 major version number than the maximum that they both support, IKE has 1362 a flag that indicates that the node is capable of speaking a higher 1363 major version number. 1365 Thus, the major version number in the IKE header indicates the 1366 version number of the message, not the highest version number that 1367 the transmitter supports. If the initiator is capable of speaking 1368 versions n, n+1, and n+2, and the responder is capable of speaking 1369 versions n and n+1, then they will negotiate speaking n+1, where the 1370 initiator will set a flag indicating its ability to speak a higher 1371 version. If they mistakenly (perhaps through an active attacker 1372 sending error messages) negotiate to version n, then both will notice 1373 that the other side can support a higher version number, and they 1374 MUST break the connection and reconnect using version n+1. 1376 Note that IKEv1 does not follow these rules, because there is no way 1377 in v1 of noting that you are capable of speaking a higher version 1378 number. So an active attacker can trick two v2-capable nodes into 1379 speaking v1. When a v2-capable node negotiates down to v1, it should 1380 note that fact in its logs. 1382 Also for forward compatibility, all fields marked RESERVED MUST be 1383 set to zero by an implementation running version 2.0, and their 1384 content MUST be ignored by an implementation running version 2.0 ("Be 1385 conservative in what you send and liberal in what you receive"). In 1386 this way, future versions of the protocol can use those fields in a 1387 way that is guaranteed to be ignored by implementations that do not 1388 understand them. Similarly, payload types that are not defined are 1389 reserved for future use; implementations of a version where they are 1390 undefined MUST skip over those payloads and ignore their contents. 1392 IKEv2 adds a "critical" flag to each payload header for further 1393 flexibility for forward compatibility. If the critical flag is set 1394 and the payload type is unrecognized, the message MUST be rejected 1395 and the response to the IKE request containing that payload MUST 1396 include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an 1397 unsupported critical payload was included. In that Notify payload, 1398 the notification data contains the one-octet payload type. If the 1399 critical flag is not set and the payload type is unsupported, that 1400 payload MUST be ignored. Payloads sent in IKE response messages MUST 1401 NOT have the critical flag set. Note that the critical flag applies 1402 only to the payload type, not the contents. If the payload type is 1403 recognized, but the payload contains something which is not (such as 1404 an unknown transform inside an SA payload, or an unknown Notify 1405 Message Type inside a Notify payload), the critical flag is ignored. 1407 Although new payload types may be added in the future and may appear 1408 interleaved with the fields defined in this specification, 1409 implementations SHOULD send the payloads defined in this 1410 specification in the order shown in the figures in Sections 1 and 2; 1411 implementations MUST NOT reject as invalid a message with those 1412 payloads in any other order. 1414 2.6. IKE SA SPIs and Cookies 1416 The initial two eight-octet fields in the header, called the "IKE 1417 SPIs", are used as a connection identifier at the beginning of IKE 1418 packets. Each endpoint chooses one of the two SPIs and MUST choose 1419 them so as to be unique identifiers of an IKE SA. An SPI value of 1420 zero is special: it indicates that the remote SPI value is not yet 1421 known by the sender. 1423 Incoming IKE packets are mapped to an IKE SA only using the packet's 1424 SPI, not using (for example) the source IP address of the packet. 1426 Unlike ESP and AH where only the recipient's SPI appears in the 1427 header of a message, in IKE the sender's SPI is also sent in every 1428 message. Since the SPI chosen by the original initiator of the IKE 1429 SA is always sent first, an endpoint with multiple IKE SAs open that 1430 wants to find the appropriate IKE SA using the SPI it assigned must 1431 look at the Initiator flag in the header to determine whether it 1432 assigned the first or the second eight octets. 1434 In the first message of an initial IKE exchange, the initiator will 1435 not know the responder's SPI value and will therefore set that field 1436 to zero. When the IKE_SA_INIT exchange does not result in the 1437 creation of an IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, 1438 or COOKIE (see Section 2.6), the responder's SPI will be zero also in 1439 the response message. However, if the responder sends a non-zero 1440 responder SPI, the initiator should not reject the response for only 1441 that reason. 1443 Two expected attacks against IKE are state and CPU exhaustion, where 1444 the target is flooded with session initiation requests from forged IP 1445 addresses. These attack can be made less effective if a responder 1446 uses minimal CPU and commits no state to an SA until it knows the 1447 initiator can receive packets at the address from which it claims to 1448 be sending them. 1450 When a responder detects a large number of half-open IKE SAs, it 1451 SHOULD reply to IKE_SA_INIT requests with a response containing the 1452 COOKIE notification. The data associated with this notification MUST 1453 be between 1 and 64 octets in length (inclusive), and its generation 1454 is described later in this section. If the IKE_SA_INIT response 1455 includes the COOKIE notification, the initiator MUST then retry the 1456 IKE_SA_INIT request, and include the COOKIE notification containing 1457 the received data as the first payload, and all other payloads 1458 unchanged. The initial exchange will then be as follows: 1460 Initiator Responder 1461 ------------------------------------------------------------------- 1462 HDR(A,0), SAi1, KEi, Ni --> 1463 <-- HDR(A,0), N(COOKIE) 1464 HDR(A,0), N(COOKIE), SAi1, 1465 KEi, Ni --> 1466 <-- HDR(A,B), SAr1, KEr, 1467 Nr, [CERTREQ] 1468 HDR(A,B), SK {IDi, [CERT,] 1469 [CERTREQ,] [IDr,] AUTH, 1470 SAi2, TSi, TSr} --> 1471 <-- HDR(A,B), SK {IDr, [CERT,] 1472 AUTH, SAr2, TSi, TSr} 1474 The first two messages do not affect any initiator or responder state 1475 except for communicating the cookie. In particular, the message 1476 sequence numbers in the first four messages will all be zero and the 1477 message sequence numbers in the last two messages will be one. 'A' 1478 is the SPI assigned by the initiator, while 'B' is the SPI assigned 1479 by the responder. 1481 An IKE implementation can implement its responder cookie generation 1482 in such a way as to not require any saved state to recognize its 1483 valid cookie when the second IKE_SA_INIT message arrives. The exact 1484 algorithms and syntax used to generate cookies do not affect 1485 interoperability and hence are not specified here. The following is 1486 an example of how an endpoint could use cookies to implement limited 1487 DoS protection. 1489 A good way to do this is to set the responder cookie to be: 1491 Cookie = | Hash(Ni | IPi | SPIi | ) 1493 where is a randomly generated secret known only to the 1494 responder and periodically changed and | indicates concatenation. 1495 should be changed whenever is 1496 regenerated. The cookie can be recomputed when the IKE_SA_INIT 1497 arrives the second time and compared to the cookie in the received 1498 message. If it matches, the responder knows that the cookie was 1499 generated since the last change to and that IPi must be the 1500 same as the source address it saw the first time. Incorporating SPIi 1501 into the calculation ensures that if multiple IKE SAs are being set 1502 up in parallel they will all get different cookies (assuming the 1503 initiator chooses unique SPIi's). Incorporating Ni in the hash 1504 ensures that an attacker who sees only message 2 can't successfully 1505 forge a message 3. Also, incorporating SPIi in the hash prevents an 1506 attacker from fetching one cookie from the other end, and then 1507 initiating many IKE_SA_INIT exchanges all with different initiator 1508 SPIs (and perhaps port numbers) so that the responder thinks that 1509 there are lots of machines behind one NAT box who are all trying to 1510 connect. 1512 If a new value for is chosen while there are connections in 1513 the process of being initialized, an IKE_SA_INIT might be returned 1514 with other than the current . The responder in 1515 that case MAY reject the message by sending another response with a 1516 new cookie or it MAY keep the old value of around for a 1517 short time and accept cookies computed from either one. The 1518 responder should not accept cookies indefinitely after is 1519 changed, since that would defeat part of the DoS protection. The 1520 responder should change the value of frequently, especially 1521 if under attack. 1523 When one party receives an IKE_SA_INIT request containing a cookie 1524 whose contents do not match the value expected, that party MUST 1525 ignore the cookie and process the message as if no cookie had been 1526 included; usually this means sending a response containing a new 1527 cookie. The initiator should limit the number of cookie exchanges it 1528 tries before giving up, possibly using exponential back-off. An 1529 attacker can forge multiple cookie responses to the initiator's 1530 IKE_SA_INIT message, and each of those forged cookie replies will 1531 cause two packets to be sent: one packet from the initiator to the 1532 responder (which will reject those cookies), and one response from 1533 responder to initiator that includes the correct cookie. 1535 A note on terminology: the term "cookies" originates with Karn and 1536 Simpson [PHOTURIS] in Photuris, an early proposal for key management 1537 with IPsec, and it has persisted. The Internet Security Association 1538 and Key Management Protocol (ISAKMP) [ISAKMP] fixed message header 1539 includes two eight-octet fields called "cookies", and that syntax is 1540 used by both IKEv1 and IKEv2, although in IKEv2 they are referred to 1541 as the "IKE SPI" and there is a new separate field in a Notify 1542 payload holding the cookie. 1544 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD 1546 There are two common reasons why the initiator may have to retry the 1547 IKE_SA_INIT exchange: the responder requests a cookie or wants a 1548 different Diffie-Hellman group than was included in the KEi payload. 1549 If the initiator receives a cookie from the responder, the initiator 1550 needs to decide whether or not to include the cookie in only the next 1551 retry of the IKE_SA_INIT request, or in all subsequent retries as 1552 well. 1554 If the initiator includes the cookie only in the next retry, one 1555 additional roundtrip may be needed in some cases. An additional 1556 roundtrip is needed also if the initiator includes the cookie in all 1557 retries, but the responder does not support this. For instance, if 1558 the responder includes the KEi payloads in cookie calculation, it 1559 will reject the request by sending a new cookie. 1561 If both peers support including the cookie in all retries, a slightly 1562 shorter exchange can happen. 1564 Initiator Responder 1565 ----------------------------------------------------------- 1566 HDR(A,0), SAi1, KEi, Ni --> 1567 <-- HDR(A,0), N(COOKIE) 1568 HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> 1569 <-- HDR(A,0), N(INVALID_KE_PAYLOAD) 1570 HDR(A,0), N(COOKIE), SAi1, KEi', Ni --> 1571 <-- HDR(A,B), SAr1, KEr, Nr 1573 Implementations SHOULD support this shorter exchange, but MUST NOT 1574 fail if other implementations do not support this shorter exchange. 1576 2.7. Cryptographic Algorithm Negotiation 1578 The payload type known as "SA" indicates a proposal for a set of 1579 choices of IPsec protocols (IKE, ESP, or AH) for the SA as well as 1580 cryptographic algorithms associated with each protocol. 1582 An SA payload consists of one or more proposals. Each proposal 1583 includes one protocol. Each protocol contains one or more transforms 1584 -- each specifying a cryptographic algorithm. Each transform 1585 contains zero or more attributes (attributes are needed only if the 1586 transform identifier does not completely specify the cryptographic 1587 algorithm). 1589 This hierarchical structure was designed to efficiently encode 1590 proposals for cryptographic suites when the number of supported 1591 suites is large because multiple values are acceptable for multiple 1592 transforms. The responder MUST choose a single suite, which may be 1593 any subset of the SA proposal following the rules below: 1595 Each proposal contains one protocol. If a proposal is accepted, the 1596 SA response MUST contain the same protocol. The responder MUST 1597 accept a single proposal or reject them all and return an error. The 1598 error is given in a notification of type NO_PROPOSAL_CHOSEN. 1600 Each IPsec protocol proposal contains one or more transforms. Each 1601 transform contains a transform type. The accepted cryptographic 1602 suite MUST contain exactly one transform of each type included in the 1603 proposal. For example: if an ESP proposal includes transforms 1604 ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, 1605 AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one 1606 of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six 1607 combinations are acceptable. 1609 If an initiator proposes both normal ciphers with integrity 1610 protection as well as combined-mode ciphers, then two proposals are 1611 needed. One of the proposals includes the normal ciphers with the 1612 integrity algoritms for them, and the other proposal includes all the 1613 combined mode ciphers without the integrity algorithms (because 1614 combined mode ciphers are not allowed to have any integrity algorithm 1615 other than "none"). 1617 2.8. Rekeying 1619 IKE, ESP, and AH security associations use secret keys that should be 1620 used only for a limited amount of time and to protect a limited 1621 amount of data. This limits the lifetime of the entire security 1622 association. When the lifetime of a security association expires, 1623 the security association MUST NOT be used. If there is demand, new 1624 security associations MAY be established. Reestablishment of 1625 security associations to take the place of ones that expire is 1626 referred to as "rekeying". 1628 To allow for minimal IPsec implementations, the ability to rekey SAs 1629 without restarting the entire IKE SA is optional. An implementation 1630 MAY refuse all CREATE_CHILD_SA requests within an IKE SA. If an SA 1631 has expired or is about to expire and rekeying attempts using the 1632 mechanisms described here fail, an implementation MUST close the IKE 1633 SA and any associated Child SAs and then MAY start new ones. 1634 Implementations may wish to support in-place rekeying of SAs, since 1635 doing so offers better performance and is likely to reduce the number 1636 of packets lost during the transition. 1638 To rekey a Child SA within an existing IKE SA, create a new, 1639 equivalent SA (see Section 2.17 below), and when the new one is 1640 established, delete the old one. Note that, when rekeying, the new 1641 Child SA SHOULD NOT have different traffic selectors and algorithms 1642 than the old one. 1644 To rekey an IKE SA, establish a new equivalent IKE SA (see 1645 Section 2.18 below) with the peer to whom the old IKE SA is shared 1646 using a CREATE_CHILD_SA within the existing IKE SA. An IKE SA so 1647 created inherits all of the original IKE SA's Child SAs, and the new 1648 IKE SA is used for all control messages needed to maintain those 1649 Child SAs. After the new equivalent IKE SA is created, the initiator 1650 deletes the old IKE SA, and the Delete payload to delete itself MUST 1651 be the last request sent over the old IKE SA. 1653 SAs should be rekeyed proactively, i.e., the new SA should be 1654 established before the old one expires and becomes unusable. Enough 1655 time should elapse between the time the new SA is established and the 1656 old one becomes unusable so that traffic can be switched over to the 1657 new SA. 1659 A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes 1660 were negotiated. In IKEv2, each end of the SA is responsible for 1661 enforcing its own lifetime policy on the SA and rekeying the SA when 1662 necessary. If the two ends have different lifetime policies, the end 1663 with the shorter lifetime will end up always being the one to request 1664 the rekeying. If an SA has been inactive for a long time and if an 1665 endpoint would not initiate the SA in the absence of traffic, the 1666 endpoint MAY choose to close the SA instead of rekeying it when its 1667 lifetime expires. It can also do so if there has been no traffic 1668 since the last time the SA was rekeyed. 1670 Note that IKEv2 deliberately allows parallel SAs with the same 1671 traffic selectors between common endpoints. One of the purposes of 1672 this is to support traffic quality of service (QoS) differences among 1673 the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and section 4.1 of 1674 [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints 1675 and the traffic selectors may not uniquely identify an SA between 1676 those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on 1677 the basis of duplicate traffic selectors SHOULD NOT be used. 1679 There are timing windows -- particularly in the presence of lost 1680 packets -- where endpoints may not agree on the state of an SA. The 1681 responder to a CREATE_CHILD_SA MUST be prepared to accept messages on 1682 an SA before sending its response to the creation request, so there 1683 is no ambiguity for the initiator. The initiator MAY begin sending 1684 on an SA as soon as it processes the response. The initiator, 1685 however, cannot receive on a newly created SA until it receives and 1686 processes the response to its CREATE_CHILD_SA request. How, then, is 1687 the responder to know when it is OK to send on the newly created SA? 1689 From a technical correctness and interoperability perspective, the 1690 responder MAY begin sending on an SA as soon as it sends its response 1691 to the CREATE_CHILD_SA request. In some situations, however, this 1692 could result in packets unnecessarily being dropped, so an 1693 implementation MAY defer such sending. 1695 The responder can be assured that the initiator is prepared to 1696 receive messages on an SA if either (1) it has received a 1697 cryptographically valid message on the other half of the SA pair, or 1698 (2) the new SA rekeys an existing SA and it receives an IKE request 1699 to close the replaced SA. When rekeying an SA, the responder 1700 continues to send traffic on the old SA until one of those events 1701 occurs. When establishing a new SA, the responder MAY defer sending 1702 messages on a new SA until either it receives one or a timeout has 1703 occurred. If an initiator receives a message on an SA for which it 1704 has not received a response to its CREATE_CHILD_SA request, it 1705 interprets that as a likely packet loss and retransmits the 1706 CREATE_CHILD_SA request. An initiator MAY send a dummy ESP message 1707 on a newly created ESP SA if it has no messages queued in order to 1708 assure the responder that the initiator is ready to receive messages. 1710 2.8.1. Simultaneous Child SA rekeying 1712 If the two ends have the same lifetime policies, it is possible that 1713 both will initiate a rekeying at the same time (which will result in 1714 redundant SAs). To reduce the probability of this happening, the 1715 timing of rekeying requests SHOULD be jittered (delayed by a random 1716 amount of time after the need for rekeying is noticed). 1718 This form of rekeying may temporarily result in multiple similar SAs 1719 between the same pairs of nodes. When there are two SAs eligible to 1720 receive packets, a node MUST accept incoming packets through either 1721 SA. If redundant SAs are created though such a collision, the SA 1722 created with the lowest of the four nonces used in the two exchanges 1723 SHOULD be closed by the endpoint that created it. "Lowest" means an 1724 octet-by-octet comparison (instead of, for instance, comparing the 1725 nonces as large integers). In other words, start by comparing the 1726 first octet; if they're equal, move to the next octet, and so on. If 1727 you reach the end of one nonce, that nonce is the lower one. The 1728 node that initiated the surviving rekeyed SA should delete the 1729 replaced SA after the new one is established. 1731 The following is an explanation on the impact this has on 1732 implementations. Assume that hosts A and B have an existing Child SA 1733 pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same 1734 time: 1736 Host A Host B 1737 ------------------------------------------------------------------- 1738 send req1: N(REKEY_SA,SPIa1), 1739 SA(..,SPIa2,..),Ni1,.. --> 1740 <-- send req2: N(REKEY_SA,SPIb1), 1741 SA(..,SPIb2,..),Ni2 1742 recv req2 <-- 1744 At this point, A knows there is a simultaneous rekeying going on. 1745 However, it cannot yet know which of the exchanges will have the 1746 lowest nonce, so it will just note the situation and respond as 1747 usual. 1749 send resp2: SA(..,SPIa3,..), 1750 Nr1,.. --> 1751 --> recv req1 1753 Now B also knows that simultaneous rekeying is going on. It responds 1754 as usual. 1756 <-- send resp1: SA(..,SPIb3,..), 1757 Nr2,.. 1758 recv resp1 <-- 1759 --> recv resp2 1761 At this point, there are three Child SA pairs between A and B (the 1762 old one and two new ones). A and B can now compare the nonces. 1763 Suppose that the lowest nonce was Nr1 in message resp2; in this case, 1764 B (the sender of req2) deletes the redundant new SA, and A (the node 1765 that initiated the surviving rekeyed SA), deletes the old one. 1767 send req3: D(SPIa1) --> 1768 <-- send req4: D(SPIb2) 1769 --> recv req3 1770 <-- send resp3: D(SPIb1) 1771 recv req4 <-- 1772 send resp4: D(SPIa3) --> 1774 The rekeying is now finished. 1776 However, there is a second possible sequence of events that can 1777 happen if some packets are lost in the network, resulting in 1778 retransmissions. The rekeying begins as usual, but A's first packet 1779 (req1) is lost. 1781 Host A Host B 1782 ------------------------------------------------------------------- 1783 send req1: N(REKEY_SA,SPIa1), 1784 SA(..,SPIa2,..), 1785 Ni1,.. --> (lost) 1786 <-- send req2: N(REKEY_SA,SPIb1), 1787 SA(..,SPIb2,..),Ni2 1788 recv req2 <-- 1789 send resp2: SA(..,SPIa3,..), 1790 Nr1,.. --> 1791 --> recv resp2 1792 <-- send req3: D(SPIb1) 1793 recv req3 <-- 1794 send resp3: D(SPIa1) --> 1795 --> recv resp3 1797 From B's point of view, the rekeying is now completed, and since it 1798 has not yet received A's req1, it does not even know that there was 1799 simultaneous rekeying. However, A will continue retransmitting the 1800 message, and eventually it will reach B. 1802 resend req1 --> 1803 --> recv req1 1805 To B, it looks like A is trying to rekey an SA that no longer exists; 1806 thus, B responds to the request with something non-fatal such as 1807 CHILD_SA_NOT_FOUND. 1809 <-- send resp1: N(CHILD_SA_NOT_FOUND) 1810 recv resp1 <-- 1812 When A receives this error, it already knows there was simultaneous 1813 rekeying, so it can ignore the error message. 1815 2.8.2. Simultaneous IKE SA Rekeying 1817 Probably the most complex case occurs when both peers try to rekey 1818 the IKE_SA at the same time. Basically, the text in Section 2.8 1819 applies to this case as well; however, it is important to ensure that 1820 the Child SAs are inherited by the correct IKE_SA. 1822 The case where both endpoints notice the simultaneous rekeying works 1823 the same way as with Child SAs. After the CREATE_CHILD_SA exchanges, 1824 three IKE SAs exist between A and B: the old IKE SA and two new IKE 1825 SAs. The new IKE SA containing the lowest nonce SHOULD be deleted by 1826 the node that created it, and the other suriving new IKE SA MUST 1827 inherit all the Child SAs. 1829 In addition to normal simultaneous rekeying cases, there is a special 1830 case where one peer finishes its rekey before it even notices that 1831 other peer is doing a rekey. If only one peer detects a simultaneous 1832 rekey, redundant SAs are not created. In this case, when the peer 1833 that did not notice the simultaneous rekey gets the request to rekey 1834 the IKE SA that it has already successfully rekeyed, it SHOULD return 1835 TEMPORARY_FAILURE because it is an IKE SA that it is currently trying 1836 to close (whether or not it has already sent the delete notification 1837 for the SA). If the peer that did notice the simultaneous rekey gets 1838 the delete request from the other peer for the old IKE SA, it knows 1839 that the other peer did not detect the simultaneous rekey, and the 1840 first peer can forget its own rekey attempt. 1842 Host A Host B 1843 ------------------------------------------------------------------- 1844 send req1: 1845 SA(..,SPIa1,..),Ni1,.. --> 1846 <-- send req2: SA(..,SPIb1,..),Ni2,.. 1847 --> recv req1 1848 <-- send resp1: SA(..,SPIb2,..),Nr2,.. 1849 recv resp1 <-- 1850 send req3: D() --> 1851 --> recv req3 1853 At this point, host B sees a request to close the IKE_SA. There's 1854 not much more to do than to reply as usual. However, at this point 1855 host B should stop retransmitting req2, since once host A receives 1856 resp3, it will delete all the state associated with the old IKE_SA 1857 and will not be able to reply to it. 1859 <-- send resp3: () 1861 The TEMPORARY_FAILURE notification was not included in RFC 4306, and 1862 support of the TEMPORARY_FAILURE notification is not negotiated. 1863 Thus, older peers that implement RFC 4306 but not this document may 1864 receive these notifications. In that case, they will treat it the 1865 same as any other unknown error notification, and will stop the 1866 exchange. Because the other peer has already rekeyed the exchange, 1867 doing so does not have any ill effects. 1869 2.8.3. Rekeying the IKE SA Versus Reauthentication 1871 Rekeying the IKE SA and reauthentication are different concepts in 1872 IKEv2. Rekeying the IKE SA establishes new keys for the IKE SA and 1873 resets the Message ID counters, but it does not authenticate the 1874 parties again (no AUTH or EAP payloads are involved). 1876 Although rekeying the IKE SA may be important in some environments, 1877 reauthentication (the verification that the parties still have access 1878 to the long-term credentials) is often more important. 1880 IKEv2 does not have any special support for reauthentication. 1881 Reauthentication is done by creating a new IKE SA from scratch (using 1882 IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify 1883 payloads), creating new Child SAs within the new IKE SA (without 1884 REKEY_SA Notify payloads), and finally deleting the old IKE SA (which 1885 deletes the old Child SAs as well). 1887 This means that reauthentication also establishes new keys for the 1888 IKE SA and Child SAs. Therefore, while rekeying can be performed 1889 more often than reauthentication, the situation where "authentication 1890 lifetime" is shorter than "key lifetime" does not make sense. 1892 While creation of a new IKE SA can be initiated by either party 1893 (initiator or responder in the original IKE SA), the use of EAP 1894 authentication and/or configuration payloads means in practice that 1895 reauthentication has to be initiated by the same party as the 1896 original IKE SA. IKEv2 does not currently allow the responder to 1897 request reauthentication in this case; however, there are extensions 1898 that add this functionality such as [REAUTH]. 1900 2.9. Traffic Selector Negotiation 1902 When an RFC4301-compliant IPsec subsystem receives an IP packet that 1903 matches a "protect" selector in its Security Policy Database (SPD), 1904 the subsystem protects that packet with IPsec. When no SA exists 1905 yet, it is the task of IKE to create it. Maintenance of a system's 1906 SPD is outside the scope of IKE, although some implementations might 1907 update their SPD in connection with the running of IKE (for an 1908 example scenario, see Section 1.1.3). 1910 Traffic Selector (TS) payloads allow endpoints to communicate some of 1911 the information from their SPD to their peers. These must be 1912 communicated to IKE from the SPD (for example, the PF_KEY API [PFKEY] 1913 uses the SADB_ACQUIRE message). TS payloads specify the selection 1914 criteria for packets that will be forwarded over the newly set up SA. 1915 This can serve as a consistency check in some scenarios to assure 1916 that the SPDs are consistent. In others, it guides the dynamic 1917 update of the SPD. 1919 Two TS payloads appear in each of the messages in the exchange that 1920 creates a Child SA pair. Each TS payload contains one or more 1921 Traffic Selectors. Each traffic selector consists of an address 1922 range (IPv4 or IPv6), a port range, and an IP protocol ID. 1924 The first of the two TS payloads is known as TSi (Traffic Selector- 1925 initiator). The second is known as TSr (Traffic Selector-responder). 1926 TSi specifies the source address of traffic forwarded from (or the 1927 destination address of traffic forwarded to) the initiator of the 1928 Child SA pair. TSr specifies the destination address of the traffic 1929 forwarded to (or the source address of the traffic forwarded from) 1930 the responder of the Child SA pair. For example, if the original 1931 initiator requests the creation of a Child SA pair, and wishes to 1932 tunnel all traffic from subnet 198.51.100.* on the initiator's side 1933 to subnet 192.0.2.* on the responder's side, the initiator would 1934 include a single traffic selector in each TS payload. TSi would 1935 specify the address range (198.51.100.0 - 198.51.100.255) and TSr 1936 would specify the address range (192.0.2.0 - 192.0.2.255). Assuming 1937 that proposal was acceptable to the responder, it would send 1938 identical TS payloads back. 1940 IKEv2 allows the responder to choose a subset of the traffic proposed 1941 by the initiator. This could happen when the configurations of the 1942 two endpoints are being updated but only one end has received the new 1943 information. Since the two endpoints may be configured by different 1944 people, the incompatibility may persist for an extended period even 1945 in the absence of errors. It also allows for intentionally different 1946 configurations, as when one end is configured to tunnel all addresses 1947 and depends on the other end to have the up-to-date list. 1949 When the responder chooses a subset of the traffic proposed by the 1950 initiator, it narrows the traffic selectors to some subset of the 1951 initiator's proposal (provided the set does not become the null set). 1952 If the type of traffic selector proposed is unknown, the responder 1953 ignores that traffic selector, so that the unknown type is not 1954 returned in the narrowed set. 1956 To enable the responder to choose the appropriate range in this case, 1957 if the initiator has requested the SA due to a data packet, the 1958 initiator SHOULD include as the first traffic selector in each of TSi 1959 and TSr a very specific traffic selector including the addresses in 1960 the packet triggering the request. In the example, the initiator 1961 would include in TSi two traffic selectors: the first containing the 1962 address range (198.51.100.43 - 198.51.100.43) and the source port and 1963 IP protocol from the packet and the second containing (198.51.100.0 - 1964 198.51.100.255) with all ports and IP protocols. The initiator would 1965 similarly include two traffic selectors in TSr. If the initiator 1966 creates the Child SA pair not in response to an arriving packet, but 1967 rather, say, upon startup, then there may be no specific addresses 1968 the initiator prefers for the initial tunnel over any other. In that 1969 case, the first values in TSi and TSr can be ranges rather than 1970 specific values. 1972 The responder performs the narrowing as follows: 1974 o If the responder's policy does not allow it to accept any part of 1975 the proposed traffic selectors, it responds with a TS_UNACCEPTABLE 1976 Notify message. 1978 o If the responder's policy allows the entire set of traffic covered 1979 by TSi and TSr, no narrowing is necessary, and the responder can 1980 return the same TSi and TSr values. 1982 o If the responder's policy allows it to accept the first selector 1983 of TSi and TSr, then the responder MUST narrow the traffic 1984 selectors to a subset that includes the initiator's first choices. 1985 In this example above, the responder might respond with TSi being 1986 (198.51.100.43 - 198.51.100.43) with all ports and IP protocols. 1988 o If the responder's policy does not allow it to accept the first 1989 selector of TSi and TSr, the responder narrows to an acceptable 1990 subset of TSi and TSr. 1992 When narrowing is done, there may be several subsets that are 1993 acceptable but their union is not. In this case, the responder 1994 arbitrarily chooses one of them, and MAY include an 1995 ADDITIONAL_TS_POSSIBLE notification in the response. The 1996 ADDITIONAL_TS_POSSIBLE notification asserts that the responder 1997 narrowed the proposed traffic selectors but that other traffic 1998 selectors would also have been acceptable, though only in a separate 1999 SA. There is no data associated with this Notify type. This case 2000 will occur only when the initiator and responder are configured 2001 differently from one another. If the initiator and responder agree 2002 on the granularity of tunnels, the initiator will never request a 2003 tunnel wider than the responder will accept. 2005 It is possible for the responder's policy to contain multiple smaller 2006 ranges, all encompassed by the initiator's traffic selector, and with 2007 the responder's policy being that each of those ranges should be sent 2008 over a different SA. Continuing the example above, the responder 2009 might have a policy of being willing to tunnel those addresses to and 2010 from the initiator, but might require that each address pair be on a 2011 separately negotiated Child SA. If the initiator didn't generate its 2012 request based on the packet, but (for example) upon startup, there 2013 would not be the very specific first traffic selectors helping the 2014 responder to select the correct range. There would be no way for the 2015 responder to determine which pair of addresses should be included in 2016 this tunnel, and it would have to make a guess or reject the request 2017 with a SINGLE_PAIR_REQUIRED Notify message. 2019 The SINGLE_PAIR_REQUIRED error indicates that a CREATE_CHILD_SA 2020 request is unacceptable because its sender is only willing to accept 2021 traffic selectors specifying a single pair of addresses. The 2022 requestor is expected to respond by requesting an SA for only the 2023 specific traffic it is trying to forward. 2025 Few implementations will have policies that require separate SAs for 2026 each address pair. Because of this, if only some parts of the TSi 2027 and TSr proposed by the initiator are acceptable to the responder, 2028 responders SHOULD narrow the selectors to an acceptable subset rather 2029 than use SINGLE_PAIR_REQUIRED. 2031 2.9.1. Traffic Selectors Violating Own Policy 2033 When creating a new SA, the initiator needs to avoid proposing 2034 traffic selectors that violate its own policy. If this rule is not 2035 followed, valid traffic may be dropped. If you use decorrelated 2036 policies from [IPSECARCH], this kind of policy violations cannot 2037 happen. 2039 This is best illustrated by an example. Suppose that host A has a 2040 policy whose effect is that traffic to 198.51.100.66 is sent via host 2041 B encrypted using AES, and traffic to all other hosts in 2042 198.51.100.0/24 is also sent via B, but must use 3DES. Suppose also 2043 that host B accepts any combination of AES and 3DES. 2045 If host A now proposes an SA that uses 3DES, and includes TSr 2046 containing (198.51.100.0-198.51.100.255), this will be accepted by 2047 host B. Now, host B can also use this SA to send traffic from 2048 198.51.100.66, but those packets will be dropped by A since it 2049 requires the use of AES for this traffic. Even if host A creates a 2050 new SA only for 198.51.100.66 that uses AES, host B may freely 2051 continue to use the first SA for the traffic. In this situation, 2052 when proposing the SA, host A should have followed its own policy, 2053 and included a TSr containing ((198.51.100.0- 2054 198.51.100.65),(198.51.100.67-198.51.100.255)) instead. 2056 In general, if (1) the initiator makes a proposal "for traffic X 2057 (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator 2058 does not actually accept traffic X' with SA, and (3) the initiator 2059 would be willing to accept traffic X' with some SA' (!=SA), valid 2060 traffic can be unnecessarily dropped since the responder can apply 2061 either SA or SA' to traffic X'. 2063 2.10. Nonces 2065 The IKE_SA_INIT messages each contain a nonce. These nonces are used 2066 as inputs to cryptographic functions. The CREATE_CHILD_SA request 2067 and the CREATE_CHILD_SA response also contain nonces. These nonces 2068 are used to add freshness to the key derivation technique used to 2069 obtain keys for Child SA, and to ensure creation of strong pseudo- 2070 random bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST 2071 be randomly chosen, MUST be at least 128 bits in size, and MUST be at 2072 least half the key size of the negotiated pseudo-random function 2073 (PRF). However, the initiator chooses the nonce before the outcome 2074 of the negotiation is known. Because of that, the nonce has to be 2075 long enough for all the PRFs being proposed. If the same random 2076 number source is used for both keys and nonces, care must be taken to 2077 ensure that the latter use does not compromise the former. 2079 2.11. Address and Port Agility 2081 IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and 2082 AH associations for the same IP addresses it runs over. The IP 2083 addresses and ports in the outer header are, however, not themselves 2084 cryptographically protected, and IKE is designed to work even through 2085 Network Address Translation (NAT) boxes. An implementation MUST 2086 accept incoming requests even if the source port is not 500 or 4500, 2087 and MUST respond to the address and port from which the request was 2088 received. It MUST specify the address and port at which the request 2089 was received as the source address and port in the response. IKE 2090 functions identically over IPv4 or IPv6. 2092 2.12. Reuse of Diffie-Hellman Exponentials 2094 IKE generates keying material using an ephemeral Diffie-Hellman 2095 exchange in order to gain the property of "perfect forward secrecy". 2096 This means that once a connection is closed and its corresponding 2097 keys are forgotten, even someone who has recorded all of the data 2098 from the connection and gets access to all of the long-term keys of 2099 the two endpoints cannot reconstruct the keys used to protect the 2100 conversation without doing a brute force search of the session key 2101 space. 2103 Achieving perfect forward secrecy requires that when a connection is 2104 closed, each endpoint MUST forget not only the keys used by the 2105 connection but also any information that could be used to recompute 2106 those keys. 2108 Because computing Diffie-Hellman exponentials is computationally 2109 expensive, an endpoint may find it advantageous to reuse those 2110 exponentials for multiple connection setups. There are several 2111 reasonable strategies for doing this. An endpoint could choose a new 2112 exponential only periodically though this could result in less-than- 2113 perfect forward secrecy if some connection lasts for less than the 2114 lifetime of the exponential. Or it could keep track of which 2115 exponential was used for each connection and delete the information 2116 associated with the exponential only when some corresponding 2117 connection was closed. This would allow the exponential to be reused 2118 without losing perfect forward secrecy at the cost of maintaining 2119 more state. 2121 Whether and when to reuse Diffie-Hellman exponentials are private 2122 decisions in the sense that they will not affect interoperability. 2123 An implementation that reuses exponentials MAY choose to remember the 2124 exponential used by the other endpoint on past exchanges and if one 2125 is reused to avoid the second half of the calculation. See [REUSE] 2126 for a security analysis of this practice and for additional security 2127 considerations when reusing ephemeral Diffie-Hellman keys. 2129 2.13. Generating Keying Material 2131 In the context of the IKE SA, four cryptographic algorithms are 2132 negotiated: an encryption algorithm, an integrity protection 2133 algorithm, a Diffie-Hellman group, and a pseudo-random function 2134 (PRF). The PRF is used for the construction of keying material for 2135 all of the cryptographic algorithms used in both the IKE SA and the 2136 Child SAs. 2138 We assume that each encryption algorithm and integrity protection 2139 algorithm uses a fixed-size key and that any randomly chosen value of 2140 that fixed size can serve as an appropriate key. For algorithms that 2141 accept a variable length key, a fixed key size MUST be specified as 2142 part of the cryptographic transform negotiated (see Section 3.3.5 for 2143 the definition of the Key Length transform attribute). For 2144 algorithms for which not all values are valid keys (such as DES or 2145 3DES with key parity), the algorithm by which keys are derived from 2146 arbitrary values MUST be specified by the cryptographic transform. 2147 For integrity protection functions based on Hashed Message 2148 Authentication Code (HMAC), the fixed key size is the size of the 2149 output of the underlying hash function. 2151 It is assumed that PRFs accept keys of any length, but have a 2152 preferred key size. The preferred key size MUST be used as the 2153 length of SK_d, SK_pi, and SK_pr (see Section 2.14). For PRFs based 2154 on the HMAC construction, the preferred key size is equal to the 2155 length of the output of the underlying hash function. Other types of 2156 PRFs MUST specify their preferred key size. 2158 Keying material will always be derived as the output of the 2159 negotiated PRF algorithm. Since the amount of keying material needed 2160 may be greater than the size of the output of the PRF, the PRF is 2161 used iteratively. The term "prf+" describes a function that outputs 2162 a pseudo-random stream based on the inputs to a pseudo-random 2163 function called "prf". 2165 In the following, | indicates concatenation. prf+ is defined as: 2167 prf+ (K,S) = T1 | T2 | T3 | T4 | ... 2169 where: 2170 T1 = prf (K, S | 0x01) 2171 T2 = prf (K, T1 | S | 0x02) 2172 T3 = prf (K, T2 | S | 0x03) 2173 T4 = prf (K, T3 | S | 0x04) 2174 ... 2176 This continues until all the material needed to compute all required 2177 keys has been output from prf+. The keys are taken from the output 2178 string without regard to boundaries (e.g., if the required keys are a 2179 256-bit Advanced Encryption Standard (AES) key and a 160-bit HMAC 2180 key, and the prf function generates 160 bits, the AES key will come 2181 from T1 and the beginning of T2, while the HMAC key will come from 2182 the rest of T2 and the beginning of T3). 2184 The constant concatenated to the end of each prf function is a single 2185 octet. The prf+ function is not defined beyond 255 times the size of 2186 the prf function output. 2188 2.14. Generating Keying Material for the IKE SA 2190 The shared keys are computed as follows. A quantity called SKEYSEED 2191 is calculated from the nonces exchanged during the IKE_SA_INIT 2192 exchange and the Diffie-Hellman shared secret established during that 2193 exchange. SKEYSEED is used to calculate seven other secrets: SK_d 2194 used for deriving new keys for the Child SAs established with this 2195 IKE SA; SK_ai and SK_ar used as a key to the integrity protection 2196 algorithm for authenticating the component messages of subsequent 2197 exchanges; SK_ei and SK_er used for encrypting (and of course 2198 decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are 2199 used when generating an AUTH payload. The lengths of SK_d, SK_pi, 2200 and SK_pr MUST be the preferred key length of the agreed-to PRF. 2202 SKEYSEED and its derivatives are computed as follows: 2204 SKEYSEED = prf(Ni | Nr, g^ir) 2206 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } 2207 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) 2209 (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, 2210 SK_pi, and SK_pr are taken in order from the generated bits of the 2211 prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman 2212 exchange. g^ir is represented as a string of octets in big endian 2213 order padded with zeros if necessary to make it the length of the 2214 modulus. Ni and Nr are the nonces, stripped of any headers. For 2215 historical backwards-compatibility reasons, there are two PRFs that 2216 are treated specially in this calculation. If the negotiated PRF is 2217 AES-XCBC-PRF-128 [AESXCBCPRF128] or AES-CMAC-PRF-128 [AESCMACPRF128], 2218 only the first 64 bits of Ni and the first 64 bits of Nr are used in 2219 calculating SKEYSEED, but all the bits are used for input to the prf+ 2220 function. 2222 The two directions of traffic flow use different keys. The keys used 2223 to protect messages from the original initiator are SK_ai and SK_ei. 2224 The keys used to protect messages in the other direction are SK_ar 2225 and SK_er. 2227 2.15. Authentication of the IKE SA 2229 When not using extensible authentication (see Section 2.16), the 2230 peers are authenticated by having each sign (or MAC using a padded 2231 shared secret as the key, as described later in this section) a block 2232 of data. In these calculations, IDi' and IDr' are the entire ID 2233 payloads excluding the fixed header. For the responder, the octets 2234 to be signed start with the first octet of the first SPI in the 2235 header of the second message (IKE_SA_INIT response) and end with the 2236 last octet of the last payload in the second message. Appended to 2237 this (for purposes of computing the signature) are the initiator's 2238 nonce Ni (just the value, not the payload containing it), and the 2239 value prf(SK_pr, IDr'). Note that neither the nonce Ni nor the value 2240 prf(SK_pr, IDr') are transmitted. Similarly, the initiator signs the 2241 first message (IKE_SA_INIT request), starting with the first octet of 2242 the first SPI in the header and ending with the last octet of the 2243 last payload. Appended to this (for purposes of computing the 2244 signature) are the responder's nonce Nr, and the value prf(SK_pi, 2245 IDi'). It is critical to the security of the exchange that each side 2246 sign the other side's nonce. 2248 The initiator's signed octets can be described as: 2250 InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI 2251 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 2252 RealIKEHDR = SPIi | SPIr | . . . | Length 2253 RealMessage1 = RealIKEHDR | RestOfMessage1 2254 NonceRPayload = PayloadHeader | NonceRData 2255 InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload 2256 RestOfInitIDPayload = IDType | RESERVED | InitIDData 2257 MACedIDForI = prf(SK_pi, RestOfInitIDPayload) 2259 The responder's signed octets can be described as: 2261 ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR 2262 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 2263 RealIKEHDR = SPIi | SPIr | . . . | Length 2264 RealMessage2 = RealIKEHDR | RestOfMessage2 2265 NonceIPayload = PayloadHeader | NonceIData 2266 ResponderIDPayload = PayloadHeader | RestOfRespIDPayload 2267 RestOfRespIDPayload = IDType | RESERVED | RespIDData 2268 MACedIDForR = prf(SK_pr, RestOfRespIDPayload) 2270 Note that all of the payloads are included under the signature, 2271 including any payload types not defined in this document. If the 2272 first message of the exchange is sent multiple times (such as with a 2273 responder cookie and/or a different Diffie-Hellman group), it is the 2274 latest version of the message that is signed. 2276 Optionally, messages 3 and 4 MAY include a certificate, or 2277 certificate chain providing evidence that the key used to compute a 2278 digital signature belongs to the name in the ID payload. The 2279 signature or MAC will be computed using algorithms dictated by the 2280 type of key used by the signer, and specified by the Auth Method 2281 field in the Authentication payload. There is no requirement that 2282 the initiator and responder sign with the same cryptographic 2283 algorithms. The choice of cryptographic algorithms depends on the 2284 type of key each has. In particular, the initiator may be using a 2285 shared key while the responder may have a public signature key and 2286 certificate. It will commonly be the case (but it is not required) 2287 that if a shared secret is used for authentication that the same key 2288 is used in both directions. 2290 Note that it is a common but typically insecure practice to have a 2291 shared key derived solely from a user-chosen password without 2292 incorporating another source of randomness. This is typically 2293 insecure because user-chosen passwords are unlikely to have 2294 sufficient unpredictability to resist dictionary attacks and these 2295 attacks are not prevented in this authentication method. 2296 (Applications using password-based authentication for bootstrapping 2297 and IKE SA should use the authentication method in Section 2.16, 2298 which is designed to prevent off-line dictionary attacks.) The pre- 2299 shared key needs to contain as much unpredictability as the strongest 2300 key being negotiated. In the case of a pre-shared key, the AUTH 2301 value is computed as: 2303 For the initiator: 2304 AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), 2305 ) 2306 For the responder: 2307 AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), 2308 ) 2310 where the string "Key Pad for IKEv2" is 17 ASCII characters without 2311 null termination. The shared secret can be variable length. The pad 2312 string is added so that if the shared secret is derived from a 2313 password, the IKE implementation need not store the password in 2314 cleartext, but rather can store the value prf(Shared Secret,"Key Pad 2315 for IKEv2"), which could not be used as a password equivalent for 2316 protocols other than IKEv2. As noted above, deriving the shared 2317 secret from a password is not secure. This construction is used 2318 because it is anticipated that people will do it anyway. The 2319 management interface by which the Shared Secret is provided MUST 2320 accept ASCII strings of at least 64 octets and MUST NOT add a null 2321 terminator before using them as shared secrets. It MUST also accept 2322 a hex encoding of the Shared Secret. The management interface MAY 2323 accept other encodings if the algorithm for translating the encoding 2324 to a binary string is specified. 2326 There are two types of EAP authentication (described in 2327 Section 2.16), and each type uses different values in the AUTH 2328 computations shown above. If the EAP method is key-generating, 2329 substitute MSK for the Shared Secret in the computation. For non- 2330 key-generating methods, substitute SK_pi and SK_pr, respectively, for 2331 the Shared Secret in the two AUTH computations. 2333 2.16. Extensible Authentication Protocol Methods 2335 In addition to authentication using public key signatures and shared 2336 secrets, IKE supports authentication using methods defined in RFC 2337 3748 [EAP]. Typically, these methods are asymmetric (designed for a 2338 user authenticating to a server), and they may not be mutual. For 2339 this reason, these protocols are typically used to authenticate the 2340 initiator to the responder and MUST be used in conjunction with a 2341 public key signature based authentication of the responder to the 2342 initiator. These methods are often associated with mechanisms 2343 referred to as "Legacy Authentication" mechanisms. 2345 While this document references [EAP] with the intent that new methods 2346 can be added in the future without updating this specification, some 2347 simpler variations are documented here. [EAP] defines an 2348 authentication protocol requiring a variable number of messages. 2349 Extensible Authentication is implemented in IKE as additional 2350 IKE_AUTH exchanges that MUST be completed in order to initialize the 2351 IKE SA. 2353 An initiator indicates a desire to use extensible authentication by 2354 leaving out the AUTH payload from the first message in the IKE_AUTH 2355 exchange. (Note that the AUTH payload is required for non-EAP 2356 authentication, and is thus not marked as optional in the rest of 2357 this document.) By including an IDi payload but not an AUTH payload, 2358 the initiator has declared an identity but has not proven it. If the 2359 responder is willing to use an extensible authentication method, it 2360 will place an Extensible Authentication Protocol (EAP) payload in the 2361 response of the IKE_AUTH exchange and defer sending SAr2, TSi, and 2362 TSr until initiator authentication is complete in a subsequent 2363 IKE_AUTH exchange. In the case of a minimal extensible 2364 authentication, the initial SA establishment will appear as follows: 2366 Initiator Responder 2367 ------------------------------------------------------------------- 2368 HDR, SAi1, KEi, Ni --> 2369 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 2370 HDR, SK {IDi, [CERTREQ,] 2371 [IDr,] SAi2, 2372 TSi, TSr} --> 2373 <-- HDR, SK {IDr, [CERT,] AUTH, 2374 EAP } 2375 HDR, SK {EAP} --> 2376 <-- HDR, SK {EAP (success)} 2377 HDR, SK {AUTH} --> 2378 <-- HDR, SK {AUTH, SAr2, TSi, TSr } 2380 As described in Section 2.2, when EAP is used, each pair of IKE SA 2381 initial setup messages will have their message numbers incremented; 2382 the first pair of AUTH messages will have an ID of 1, the second will 2383 be 2, and so on. 2385 For EAP methods that create a shared key as a side effect of 2386 authentication, that shared key MUST be used by both the initiator 2387 and responder to generate AUTH payloads in messages 7 and 8 using the 2388 syntax for shared secrets specified in Section 2.15. The shared key 2389 from EAP is the field from the EAP specification named MSK. This 2390 shared key generated during an IKE exchange MUST NOT be used for any 2391 other purpose. 2393 EAP methods that do not establish a shared key SHOULD NOT be used, as 2394 they are subject to a number of man-in-the-middle attacks [EAPMITM] 2395 if these EAP methods are used in other protocols that do not use a 2396 server-authenticated tunnel. Please see the Security Considerations 2397 section for more details. If EAP methods that do not generate a 2398 shared key are used, the AUTH payloads in messages 7 and 8 MUST be 2399 generated using SK_pi and SK_pr, respectively. 2401 The initiator of an IKE SA using EAP needs to be capable of extending 2402 the initial protocol exchange to at least ten IKE_AUTH exchanges in 2403 the event the responder sends notification messages and/or retries 2404 the authentication prompt. Once the protocol exchange defined by the 2405 chosen EAP authentication method has successfully terminated, the 2406 responder MUST send an EAP payload containing the Success message. 2407 Similarly, if the authentication method has failed, the responder 2408 MUST send an EAP payload containing the Failure message. The 2409 responder MAY at any time terminate the IKE exchange by sending an 2410 EAP payload containing the Failure message. 2412 Following such an extended exchange, the EAP AUTH payloads MUST be 2413 included in the two messages following the one containing the EAP 2414 Success message. 2416 When the initiator authentication uses EAP, it is possible that the 2417 contents of the IDi payload is used only for AAA routing purposes and 2418 selecting which EAP method to use. This value may be different from 2419 the identity authenticated by the EAP method. It is important that 2420 policy lookups and access control decisions use the actual 2421 authenticated identity. Often the EAP server is implemented in a 2422 separate AAA server that communicates with the IKEv2 responder. In 2423 this case, the authenticated identity, if different from that in the 2424 IDi payload, has to be sent from the AAA server to the IKEv2 2425 responder. 2427 2.17. Generating Keying Material for Child SAs 2429 A single Child SA is created by the IKE_AUTH exchange, and additional 2430 Child SAs can optionally be created in CREATE_CHILD_SA exchanges. 2431 Keying material for them is generated as follows: 2433 KEYMAT = prf+(SK_d, Ni | Nr) 2435 Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this 2436 request is the first Child SA created or the fresh Ni and Nr from the 2437 CREATE_CHILD_SA exchange if this is a subsequent creation. 2439 For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman 2440 exchange, the keying material is defined as: 2442 KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) 2444 where g^ir (new) is the shared secret from the ephemeral Diffie- 2445 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 2446 octet string in big endian order padded with zeros in the high-order 2447 bits if necessary to make it the length of the modulus). 2449 A single CHILD_SA negotiation may result in multiple security 2450 associations. ESP and AH SAs exist in pairs (one in each direction), 2451 so two SAs are created in a single Child SA negotiation for them. 2452 Furthermore, Child SA negotiation may include some future IPsec 2453 protocol(s) in addition to, or instead of, ESP or AH (for example, 2454 ROHC_INTEG as described in [ROHCV2]). In any case, keying material 2455 for each child SA MUST be taken from the expanded KEYMAT using the 2456 following rules: 2458 o All keys for SAs carrying data from the initiator to the responder 2459 are taken before SAs going from the responder to the initiator. 2461 o If multiple IPsec protocols are negotiated, keying material for 2462 each Child SA is taken in the order in which the protocol headers 2463 will appear in the encapsulated packet. 2465 o If an IPsec protocol requires multiple keys, the order in which 2466 they are taken from the SA's keying material needs to be described 2467 in the protocol's specification. For ESP and AH, [IPSECARCH] 2468 defines the order, namely: the encryption key (if any) MUST be 2469 taken from the first bits and the integrity key (if any) MUST be 2470 taken from the remaining bits. 2472 Each cryptographic algorithm takes a fixed number of bits of keying 2473 material specified as part of the algorithm, or negotiated in SA 2474 payloads (see Section 2.13 for description of key lengths, and 2475 Section 3.3.5 for the definition of the Key Length transform 2476 attribute). 2478 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange 2480 The CREATE_CHILD_SA exchange can be used to rekey an existing IKE SA 2481 (see Section 1.3.2 and Section 2.8). New initiator and responder 2482 SPIs are supplied in the SPI fields in the Proposal structures inside 2483 the Security Association (SA) payloads (not the SPI fields in the IKE 2484 header). The TS payloads are omitted when rekeying an IKE SA. 2485 SKEYSEED for the new IKE SA is computed using SK_d from the existing 2486 IKE SA as follows: 2488 SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr) 2490 where g^ir (new) is the shared secret from the ephemeral Diffie- 2491 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 2492 octet string in big endian order padded with zeros if necessary to 2493 make it the length of the modulus) and Ni and Nr are the two nonces 2494 stripped of any headers. 2496 The old and new IKE SA may have selected a different PRF. Because 2497 the rekeying exchange belongs to the old IKE SA, it is the old IKE 2498 SA's PRF that is used to generate SKEYSEED. 2500 The main reason for rekeying the IKE SA is to ensure that the 2501 compromise of old keying material does not provide information about 2502 the current keys, or vice versa. Therefore, implementations MUST 2503 perform a new Diffie-Hellman exchange when rekeying the IKE SA. In 2504 other words, an initiator MUST NOT propose the value "NONE" for the 2505 Diffie-Hellman transform, and a responder MUST NOT accept such a 2506 proposal. This means that a successful exchange rekeying the IKE SA 2507 always includes the KEi/KEr payloads. 2509 The new IKE SA MUST reset its message counters to 0. 2511 SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as 2512 specified in Section 2.14, using SPIi, SPIr, Ni, and Nr from the new 2513 exchange, and using the new IKE SA's PRF. 2515 2.19. Requesting an Internal Address on a Remote Network 2517 Most commonly occurring in the endpoint-to-security-gateway scenario, 2518 an endpoint may need an IP address in the network protected by the 2519 security gateway and may need to have that address dynamically 2520 assigned. A request for such a temporary address can be included in 2521 any request to create a Child SA (including the implicit request in 2522 message 3) by including a CP payload. Note, however, it is usual to 2523 only assign one IP address during the IKE_AUTH exchange. That 2524 address persists at least until the deletion of the IKE SA. 2526 This function provides address allocation to an IPsec Remote Access 2527 Client (IRAC) trying to tunnel into a network protected by an IPsec 2528 Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an 2529 IKE SA and a Child SA, the IRAC MUST request the IRAS-controlled 2530 address (and optionally other information concerning the protected 2531 network) in the IKE_AUTH exchange. The IRAS may procure an address 2532 for the IRAC from any number of sources such as a DHCP/BOOTP server 2533 or its own address pool. 2535 Initiator Responder 2536 ------------------------------------------------------------------- 2537 HDR, SK {IDi, [CERT,] 2538 [CERTREQ,] [IDr,] AUTH, 2539 CP(CFG_REQUEST), SAi2, 2540 TSi, TSr} --> 2541 <-- HDR, SK {IDr, [CERT,] AUTH, 2542 CP(CFG_REPLY), SAr2, 2543 TSi, TSr} 2545 In all cases, the CP payload MUST be inserted before the SA payload. 2546 In variations of the protocol where there are multiple IKE_AUTH 2547 exchanges, the CP payloads MUST be inserted in the messages 2548 containing the SA payloads. 2550 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute 2551 (either IPv4 or IPv6) but MAY contain any number of additional 2552 attributes the initiator wants returned in the response. 2554 For example, message from initiator to responder: 2556 CP(CFG_REQUEST)= 2557 INTERNAL_ADDRESS() 2558 TSi = (0, 0-65535,0.0.0.0-255.255.255.255) 2559 TSr = (0, 0-65535,0.0.0.0-255.255.255.255) 2561 NOTE: Traffic selectors contain (protocol, port range, address 2562 range). 2564 Message from responder to initiator: 2566 CP(CFG_REPLY)= 2567 INTERNAL_ADDRESS(192.0.2.202) 2568 INTERNAL_NETMASK(255.255.255.0) 2569 INTERNAL_SUBNET(192.0.2.0/255.255.255.0) 2570 TSi = (0, 0-65535,192.0.2.202-192.0.2.202) 2571 TSr = (0, 0-65535,192.0.2.0-192.0.2.255) 2573 All returned values will be implementation dependent. As can be seen 2574 in the above example, the IRAS MAY also send other attributes that 2575 were not included in CP(CFG_REQUEST) and MAY ignore the non- 2576 mandatory attributes that it does not support. 2578 The responder MUST NOT send a CFG_REPLY without having first received 2579 a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS 2580 to perform an unnecessary configuration lookup if the IRAC cannot 2581 process the REPLY. 2583 In the case where the IRAS's configuration requires that CP be used 2584 for a given identity IDi, but IRAC has failed to send a 2585 CP(CFG_REQUEST), IRAS MUST fail the request, and terminate the Child 2586 SA creation with a FAILED_CP_REQUIRED error. The FAILED_CP_REQUIRED 2587 is not fatal to the IKE SA; it simply causes the Child SA creation to 2588 fail. The initiator can fix this by later starting a new 2589 configuration payload request. There is no associated data in the 2590 FAILED_CP_REQUIRED error. 2592 2.20. Requesting the Peer's Version 2594 An IKE peer wishing to inquire about the other peer's IKE software 2595 version information MAY use the method below. This is an example of 2596 a configuration request within an INFORMATIONAL exchange, after the 2597 IKE SA and first Child SA have been created. 2599 An IKE implementation MAY decline to give out version information 2600 prior to authentication or even after authentication in case some 2601 implementation is known to have some security weakness. In that 2602 case, it MUST either return an empty string or no CP payload if CP is 2603 not supported. 2605 Initiator Responder 2606 ------------------------------------------------------------------- 2607 HDR, SK{CP(CFG_REQUEST)} --> 2608 <-- HDR, SK{CP(CFG_REPLY)} 2610 CP(CFG_REQUEST)= 2611 APPLICATION_VERSION("") 2613 CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar 2614 Inc.") 2616 2.21. Error Handling 2618 There are many kinds of errors that can occur during IKE processing. 2619 The general rule is that if a request is received that is badly 2620 formatted, or unacceptable for reasons of policy (such as no matching 2621 cryptographic algorithms), the response contains a Notify payload 2622 indicating the error. The decision whether or not to send such a 2623 response depends whether or not there is an authenticated IKE SA. 2625 If there is an error parsing or processing a response packet, the 2626 general rule is to not send back any error message because responses 2627 should not generate new requests (and a new request would be the only 2628 way to send back an error message). Such errors in parsing or 2629 processing response packets should still cause the recipient to clean 2630 up the IKE state (for example, by sending a DELETE for a bad SA). 2632 Only authentication failures (AUTHENTICATION_FAILED and EAP failure) 2633 and malformed messages (INVALID_SYNTAX) lead to a deletion of the IKE 2634 SA without requiring an explicit INFORMATIONAL exchange carrying a 2635 DELETE payload. Other error conditions MAY require such an exchange 2636 if policy dictates that this is needed. If the exchange is 2637 terminated with EAP Failure, an AUTHENTICATION_FAILED notification is 2638 not sent. 2640 2.21.1. Error Handling in IKE_SA_INIT 2642 Errors that occur before a cryptographically protected IKE SA is 2643 established need to be handled very carefully. There is a trade-off 2644 between wanting to help the peer to diagnose a problem and thus 2645 responding to the error, and wanting to avoid being part of a DoS 2646 attack based on forged messages. 2648 In an IKE_SA_INIT exchange, any error notification causes the 2649 exchange to fail. Note that some error notifications such as COOKIE, 2650 INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent 2651 successful exchange. Because all error notifications are completely 2652 unauthenticated, the recipient should continue trying for some time 2653 before giving up. The recipient should not immediately act based on 2654 the error notification unless corrective actions are defined in this 2655 specification, such as for COOKIE, INVALID_KE_PAYLOAD, and 2656 INVALID_MAJOR_VERSION. 2658 2.21.2. Error Handling in IKE_AUTH 2660 All errors that occur in an IKE_AUTH exchange, causing the 2661 authentication to fail for whatever reason (invalid shared secret, 2662 invalid ID, untrusted certificate issuer, revoked or expired 2663 certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED 2664 notification. If the error occurred on the responder, the 2665 notification is returned in the protected response, and is usually 2666 the only payload in that response. Although the IKE_AUTH messages 2667 are encrypted and integrity protected, if the peer receiving this 2668 notification has not authenticated the other end yet, that peer needs 2669 to treat the information with caution. 2671 If the error occurs on the initiator, the notification MAY be 2672 returned in a separate INFORMATIONAL exchange, usually with no other 2673 payloads. This is an exception for the general rule of not starting 2674 new exchanges based on errors in responses. 2676 Note, however, that request messages that contain an unsupported 2677 critical payload, or where the whole message is malformed (rather 2678 than just bad payload contents), MUST be rejected in their entirety, 2679 and MUST only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or 2680 INVALID_SYNTAX Notification sent as a response. The receiver should 2681 not verify the payloads related to authentication in this case. 2683 If authentication has succeeded in the IKE_AUTH exchange, the IKE SA 2684 is established; however, establishing the Child SA or requesting 2685 configuration information may still fail. This failure does not 2686 automatically cause the IKE SA to be deleted. Specifically, a 2687 responder may include all the payloads associated with authentication 2688 (IDr, Cert and AUTH) while sending error notifications for the 2689 piggybacked exchanges (FAILED_CP_REQUIRED, NO_PROPOSAL_CHOSEN, and so 2690 on), and the initiator MUST NOT fail the authentication because of 2691 this. The initiator MAY, of course, for reasons of policy later 2692 delete such an IKE SA. 2694 In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately 2695 following it (in case an error happened when processing a response to 2696 IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and 2697 AUTHENTICATION_FAILED notifications are the only ones to cause the 2698 IKE SA to be deleted or not created, without a DELETE payload. 2699 Extension documents may define new error notifications with these 2700 semantics, but MUST NOT use them unless the peer has been shown to 2701 understand them, such as by using the Vendor ID payload. 2703 2.21.3. Error Handling after IKE SA is Authenticated 2705 After the IKE SA is authenticated all requests having errors MUST 2706 result in a response notifying about the error. 2708 In normal situations, there should not be cases where a valid 2709 response from one peer results in an error situation in the other 2710 peer, so there should not be any reason for a peer to send error 2711 messages to the other end except as a response. Because sending such 2712 error messages as an INFORMATIONAL exchange might lead to further 2713 errors that could cause loops, such errors SHOULD NOT be sent. If 2714 errors are seen that indicate that the peers do not have the same 2715 state, it might be good to delete the IKE SA to clean up state and 2716 start over. 2718 If a peer parsing a request notices that it is badly formatted (after 2719 it has passed the message authentication code checks and window 2720 checks) and it returns an INVALID_SYNTAX notification, then this 2721 error notification is considered fatal in both peers, meaning that 2722 the IKE SA is deleted without needing an explicit DELETE payload. 2724 2.21.4. Error Handling Outside IKE SA 2726 A node needs to limit the rate at which it will send messages in 2727 response to unprotected messages. 2729 If a node receives a message on UDP port 500 or 4500 outside the 2730 context of an IKE SA known to it (and the message is not a request to 2731 start an IKE SA), this may be the result of a recent crash of the 2732 node. If the message is marked as a response, the node can audit the 2733 suspicious event but MUST NOT respond. If the message is marked as a 2734 request, the node can audit the suspicious event and MAY send a 2735 response. If a response is sent, the response MUST be sent to the IP 2736 address and port from where it came with the same IKE SPIs and the 2737 Message ID copied. The response MUST NOT be cryptographically 2738 protected and MUST contain an INVALID_IKE_SPI Notify payload. The 2739 INVALID_IKE_SPI notification indicates an IKE message was received 2740 with an unrecognized destination SPI; this usually indicates that the 2741 recipient has rebooted and forgotten the existence of an IKE SA. 2743 A peer receiving such an unprotected Notify payload MUST NOT respond 2744 and MUST NOT change the state of any existing SAs. The message might 2745 be a forgery or might be a response that a genuine correspondent was 2746 tricked into sending. A node should treat such a message (and also a 2747 network message like ICMP destination unreachable) as a hint that 2748 there might be problems with SAs to that IP address and should 2749 initiate a liveness check for any such IKE SA. An implementation 2750 SHOULD limit the frequency of such tests to avoid being tricked into 2751 participating in a DoS attack. 2753 If an error occurs outside the context of an IKE request (e.g., the 2754 node is getting ESP messages on a nonexistent SPI), the node SHOULD 2755 initiate an INFORMATIONAL exchange with a Notify payload describing 2756 the problem. 2758 A node receiving a suspicious message from an IP address (and port, 2759 if NAT traversal is used) with which it has an IKE SA SHOULD send an 2760 IKE Notify payload in an IKE INFORMATIONAL exchange over that SA. 2761 The recipient MUST NOT change the state of any SAs as a result, but 2762 may wish to audit the event to aid in diagnosing malfunctions. 2764 2.22. IPComp 2766 Use of IP compression [IP-COMP] can be negotiated as part of the 2767 setup of a Child SA. While IP compression involves an extra header 2768 in each packet and a compression parameter index (CPI), the virtual 2769 "compression association" has no life outside the ESP or AH SA that 2770 contains it. Compression associations disappear when the 2771 corresponding ESP or AH SA goes away. It is not explicitly mentioned 2772 in any DELETE payload. 2774 Negotiation of IP compression is separate from the negotiation of 2775 cryptographic parameters associated with a Child SA. A node 2776 requesting a Child SA MAY advertise its support for one or more 2777 compression algorithms through one or more Notify payloads of type 2778 IPCOMP_SUPPORTED. This Notify message may be included only in a 2779 message containing an SA payload negotiating a Child SA and indicates 2780 a willingness by its sender to use IPComp on this SA. The response 2781 MAY indicate acceptance of a single compression algorithm with a 2782 Notify payload of type IPCOMP_SUPPORTED. These payloads MUST NOT 2783 occur in messages that do not contain SA payloads. 2785 The data associated with this Notify message includes a two-octet 2786 IPComp CPI followed by a one-octet transform ID optionally followed 2787 by attributes whose length and format are defined by that transform 2788 ID. A message proposing an SA may contain multiple IPCOMP_SUPPORTED 2789 notifications to indicate multiple supported algorithms. A message 2790 accepting an SA may contain at most one. 2792 The transform IDs are listed here. The values in the following table 2793 are only current as of the publication date of RFC 4306. Other 2794 values may have been added since then or will be added after the 2795 publication of this document. Readers should refer to [IKEV2IANA] 2796 for the latest values. 2798 Name Number Defined In 2799 ------------------------------------- 2800 IPCOMP_OUI 1 2801 IPCOMP_DEFLATE 2 RFC 2394 2802 IPCOMP_LZS 3 RFC 2395 2803 IPCOMP_LZJH 4 RFC 3051 2805 Although there has been discussion of allowing multiple compression 2806 algorithms to be accepted and to have different compression 2807 algorithms available for the two directions of a Child SA, 2808 implementations of this specification MUST NOT accept an IPComp 2809 algorithm that was not proposed, MUST NOT accept more than one, and 2810 MUST NOT compress using an algorithm other than one proposed and 2811 accepted in the setup of the Child SA. 2813 A side effect of separating the negotiation of IPComp from 2814 cryptographic parameters is that it is not possible to propose 2815 multiple cryptographic suites and propose IP compression with some of 2816 them but not others. 2818 In some cases, Robust Header Compression (ROHC) may be more 2819 appropriate than IP Compression. [ROHCV2] defines the use of ROHC 2820 with IKEv2 and IPsec. 2822 2.23. NAT Traversal 2824 Network Address Translation (NAT) gateways are a controversial 2825 subject. This section briefly describes what they are and how they 2826 are likely to act on IKE traffic. Many people believe that NATs are 2827 evil and that we should not design our protocols so as to make them 2828 work better. IKEv2 does specify some unintuitive processing rules in 2829 order that NATs are more likely to work. 2831 NATs exist primarily because of the shortage of IPv4 addresses, 2832 though there are other rationales. IP nodes that are "behind" a NAT 2833 have IP addresses that are not globally unique, but rather are 2834 assigned from some space that is unique within the network behind the 2835 NAT but that are likely to be reused by nodes behind other NATs. 2836 Generally, nodes behind NATs can communicate with other nodes behind 2837 the same NAT and with nodes with globally unique addresses, but not 2838 with nodes behind other NATs. There are exceptions to that rule. 2839 When those nodes make connections to nodes on the real Internet, the 2840 NAT gateway "translates" the IP source address to an address that 2841 will be routed back to the gateway. Messages to the gateway from the 2842 Internet have their destination addresses "translated" to the 2843 internal address that will route the packet to the correct endnode. 2845 NATs are designed to be "transparent" to endnodes. Neither software 2846 on the node behind the NAT nor the node on the Internet requires 2847 modification to communicate through the NAT. Achieving this 2848 transparency is more difficult with some protocols than with others. 2849 Protocols that include IP addresses of the endpoints within the 2850 payloads of the packet will fail unless the NAT gateway understands 2851 the protocol and modifies the internal references as well as those in 2852 the headers. Such knowledge is inherently unreliable, is a network 2853 layer violation, and often results in subtle problems. 2855 Opening an IPsec connection through a NAT introduces special 2856 problems. If the connection runs in transport mode, changing the IP 2857 addresses on packets will cause the checksums to fail and the NAT 2858 cannot correct the checksums because they are cryptographically 2859 protected. Even in tunnel mode, there are routing problems because 2860 transparently translating the addresses of AH and ESP packets 2861 requires special logic in the NAT and that logic is heuristic and 2862 unreliable in nature. For that reason, IKEv2 will use UDP 2863 encapsulation of IKE and ESP packets. This encoding is slightly less 2864 efficient but is easier for NATs to process. In addition, firewalls 2865 may be configured to pass UDP-encapsulated IPsec traffic but not 2866 plain, unencapsulated ESP/AH or vice versa. 2868 It is a common practice of NATs to translate TCP and UDP port numbers 2869 as well as addresses and use the port numbers of inbound packets to 2870 decide which internal node should get a given packet. For this 2871 reason, even though IKE packets MUST be sent from and to UDP port 500 2872 or 4500, they MUST be accepted coming from any port and responses 2873 MUST be sent to the port from whence they came. This is because the 2874 ports may be modified as the packets pass through NATs. Similarly, 2875 IP addresses of the IKE endpoints are generally not included in the 2876 IKE payloads because the payloads are cryptographically protected and 2877 could not be transparently modified by NATs. 2879 Port 4500 is reserved for UDP-encapsulated ESP and IKE. An IPsec 2880 endpoint that discovers a NAT between it and its correspondent (as 2881 described below) MUST send all subsequent traffic from port 4500, 2882 which NATs should not treat specially (as they might with port 500). 2884 An initiator can use port 4500 for both IKE and ESP, regardless of 2885 whether or not there is a NAT, even at the beginning of IKE. When 2886 either side is using port 4500, sending ESP with UDP encapsulation is 2887 not required, but understanding received UDP encapsulated ESP packets 2888 is required. UDP encapsulation MUST NOT be done on port 500. If 2889 NAT-T is supported (that is, if NAT_DETECTION_*_IP payloads were 2890 exchanged during IKE_SA_INIT), all devices MUST be able to receive 2891 and process both UDP encapsulated ESP and non-UDP encapsulated ESP 2892 packets at any time. Either side can decide whether or not to use 2893 UDP encapsulation for ESP irrespective of the choice made by the 2894 other side. However, if a NAT is detected, both devices MUST use UDP 2895 encapsulation for ESP. 2897 The specific requirements for supporting NAT traversal [NATREQ] are 2898 listed below. Support for NAT traversal is optional. In this 2899 section only, requirements listed as MUST apply only to 2900 implementations supporting NAT traversal. 2902 o Both IKE initiator and responder MUST include in their IKE_SA_INIT 2903 packets Notify payloads of type NAT_DETECTION_SOURCE_IP and 2904 NAT_DETECTION_DESTINATION_IP. Those payloads can be used to 2905 detect if there is NAT between the hosts, and which end is behind 2906 the NAT. The location of the payloads in the IKE_SA_INIT packets 2907 is just after the Ni and Nr payloads (before the optional CERTREQ 2908 payload). 2910 o The data associated with the NAT_DETECTION_SOURCE_IP notification 2911 is a SHA-1 digest of the SPIs (in the order they appear in the 2912 header), IP address, and port from which this packet was sent. 2913 There MAY be multiple NAT_DETECTION_SOURCE_IP payloads in a 2914 message if the sender does not know which of several network 2915 attachments will be used to send the packet. 2917 o The data associated with the NAT_DETECTION_DESTINATION_IP 2918 notification is a SHA-1 digest of the SPIs (in the order they 2919 appear in the header), IP address, and port to which this packet 2920 was sent. 2922 o The recipient of either the NAT_DETECTION_SOURCE_IP or 2923 NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied 2924 value to a SHA-1 hash of the SPIs, source or recipient IP address 2925 (respectively), address, and port, and if they don't match it 2926 SHOULD enable NAT traversal. In the case there is a mismatch of 2927 the NAT_DETECTION_SOURCE_IP hash with all of the 2928 NAT_DETECTION_SOURCE_IP payloads received, the recipient MAY 2929 reject the connection attempt if NAT traversal is not supported. 2930 In the case of a mismatching NAT_DETECTION_DESTINATION_IP hash, it 2931 means that the system receiving the NAT_DETECTION_DESTINATION_IP 2932 payload is behind a NAT and that system SHOULD start sending 2933 keepalive packets as defined in [UDPENCAPS]; alternately, it MAY 2934 reject the connection attempt if NAT traversal is not supported. 2936 o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches 2937 the expected value of the source IP and port found from the IP 2938 header of the packet containing the payload, it means that the 2939 system sending those payloads is behind NAT (i.e., someone along 2940 the route changed the source address of the original packet to 2941 match the address of the NAT box). In this case, the system 2942 receiving the payloads should allow dynamic update of the other 2943 systems' IP address, as described later. 2945 o The IKE initiator MUST check the NAT_DETECTION_SOURCE_IP or 2946 NAT_DETECTION_DESTINATION_IP payloads if present and if they do 2947 not match the addresses in the outer packet MUST tunnel all future 2948 IKE and ESP packets associated with this IKE SA over UDP port 2949 4500. 2951 o To tunnel IKE packets over UDP port 4500, the IKE header has four 2952 octets of zero prepended and the result immediately follows the 2953 UDP header. To tunnel ESP packets over UDP port 4500, the ESP 2954 header immediately follows the UDP header. Since the first four 2955 octets of the ESP header contain the SPI, and the SPI cannot 2956 validly be zero, it is always possible to distinguish ESP and IKE 2957 messages. 2959 o Implementations MUST process received UDP-encapsulated ESP packets 2960 even when no NAT was detected. 2962 o The original source and destination IP address required for the 2963 transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) 2964 are obtained from the traffic selectors associated with the 2965 exchange. In the case of transport mode NAT traversal, the 2966 traffic selectors MUST contain exactly one IP address, which is 2967 then used as the original IP address. This is covered in greater 2968 detail in Section 2.23.1. 2970 o There are cases where a NAT box decides to remove mappings that 2971 are still alive (for example, the keepalive interval is too long, 2972 or the NAT box is rebooted). This will be apparent to a host if 2973 it receives a packet whose integrity protection validates, but has 2974 a different port, address, or both from the one that was 2975 associated with the SA in the validated packet. When such a 2976 validated packet is found, a host that does not support other 2977 methods of recovery such as MOBIKE [MOBIKE], and that is not 2978 behind a NAT, SHOULD send all packets (including retransmission 2979 packets) to the IP address and port in the validated packet, and 2980 SHOULD store this as the new address and port combination for the 2981 SA (that is, they SHOULD dynamically update the address). A host 2982 behind a NAT SHOULD NOT do this type of dynamic address update if 2983 a validated packet has different port and/or address values 2984 because it opens a possible DoS attack (such as allowing an 2985 attacker to break the connection with a single packet). Also, 2986 dynamic address update should only be done in response to a new 2987 packet; otherwise, an attacker can revert the addresses with old 2988 replayed packets. Because of this, dynamic update can only be 2989 done safely if replay protection is enabled. When IKEv2 is used 2990 with MOBIKE, dynamically updating the addresses described above 2991 interferes with MOBIKE's way of recovering from the same 2992 situation. See Section 3.8 of [MOBIKE] for more information. 2994 2.23.1. Transport Mode NAT Traversal 2996 Transport mode used with NAT Traversal requires special handling of 2997 the traffic selectors used in the IKEv2. The complete scenario looks 2998 like: 3000 +------+ +------+ +------+ +------+ 3001 |Client| IP1 | NAT | IPN1 IPN2 | NAT | IP2 |Server| 3002 |node |<------>| A |<---------->| B |<------->| | 3003 +------+ +------+ +------+ +------+ 3005 (Other scenarios are simplifications of this complex case, so this 3006 discussion uses the complete scenario.) 3008 In this scenario, there are two address translating NATs: NAT A and 3009 NAT B. NAT A is dynamic NAT that maps the clients source address IP1 3010 to IPN1. NAT B is static NAT configured so that connections coming 3011 to IPN2 address are mapped to the gateways address IP2, that is, IPN2 3012 destination address is mapped to IP2. This allows the client to 3013 connect to a server by connecting to the IPN2. NAT B does not 3014 necessarily need to be a static NAT, but the client needs to know how 3015 to connect to the server, and it can only do that if it somehow knows 3016 the outer address of the NAT B, that is, the IPN2 address. If NAT B 3017 is a static NAT, then its address can be configured to the client's 3018 configuration. Other options would be find it using some other 3019 protocol (like DNS), but those are outside of scope of IKEv2. 3021 In this scenario, both client and server are configured to use 3022 transport mode for the traffic originating from the client node and 3023 destined to the server. 3025 When the client starts creating the IKEv2 SA and Child SA for sending 3026 traffic to the server, it may have a triggering packet with source IP 3027 address of IP1, and a destination IP address of IPN2. Its PAD and 3028 SPD needs to have configuration matching those addresses (or wildcard 3029 entries covering them). Because this is transport mode, it uses 3030 exactly same addresses as the traffic selectors and outer IP address 3031 of the IKE packets. For transport mode, it MUST use exactly one IP 3032 address in the TSi and TSr payloads. It can have multiple traffic 3033 selectors if it has, for example, multiple port ranges that it wants 3034 to negotiate, but all TSi entries must use IP1-IP1 range as the IP 3035 addresses, and all TSr entries must have the IPN2-IPN2 range as IP 3036 addresses. The first traffic selector of TSi and TSr SHOULD have 3037 very specific traffic selectors including protocol and port numbers, 3038 such as from the packet triggering the request. 3040 NAT A will then replace the source address of the IKE packet from IP1 3041 to IPN1, and NAT B will replace the destination address of the IKE 3042 packet from IPN2 to IP2, so when the packet arrives to the server it 3043 will still have the exactly same traffic selectors which were sent by 3044 the client, but the IP address of the IKE packet has been replaced to 3045 IPN1 and IP2. 3047 When the server receives this packet, it normally looks in the Peer 3048 Authorization Database (PAD) described in RFC 4301 [IPSECARCH] based 3049 on the ID and then searches the SPD based on the traffic selectors. 3050 Because IP1 does not really mean anything to the server (it is the 3051 address client has behind the NAT), it is useless to do a lookup 3052 based on that if transport mode is used. On the other hand, the 3053 server cannot know whether transport mode is allowed by its policy 3054 before it finds the matching SPD entry. 3056 In this case, the server should first check that the initiator 3057 requested transport mode, and then do address substitution on the 3058 traffic selectors. It needs to first store the old traffic selector 3059 IP addresses to be used later for the incremental checksum fixup (the 3060 IP address in the TSi can be stored as the original source address 3061 and the IP address in the TSr can be stored as the original 3062 destination address). After that, if the other end was detected as 3063 being behind a NAT, the server replaces the IP address in TSi 3064 payloads with the IP address obtained from the source address of the 3065 IKE packet received (that is, it replaces IP1 in TSi with IPN1). If 3066 the server's end was detected to be behind NAT, it replaces the IP 3067 address in the TSr payloads with the IP address obtained from the 3068 destination address of the IKE packet received (that is, it replaces 3069 IPN2 in TSr with IP2). 3071 After this address substitution, both the traffic selectors and the 3072 IKE UDP source/destination addresses look the same, and the server 3073 does SPD lookup based on those new traffic selectors. If an entry is 3074 found and it allows transport mode, then that entry is used. If an 3075 entry is found but it does not allow transport mode, then the server 3076 MAY undo the address substitution and redo the SPD lookup using the 3077 original traffic selectors. If the second lookup succeeds, the 3078 server will create an SA in tunnel mode using real traffic selectors 3079 sent by the other end. 3081 This address substitution in transport mode is needed because the SPD 3082 is looked up using the addresses that will be seen by the local host. 3083 This also will make sure the SAD entries for the tunnel exit checks 3084 and return packets is added using the addresses as seen by the local 3085 operating system stack. 3087 The most common case is that the server's SPD will contain wildcard 3088 entries matching any addresses, but this allows also making different 3089 SPD entries, for example, for different known NATs' outer addresses. 3091 After the SPD lookup, the server will do traffic selector narrowing 3092 based on the SPD entry it found. It will again use the already- 3093 substituted traffic selectors, and it will thus send back traffic 3094 selectors having IPN1 and IP2 as their IP addresses; it can still 3095 narrow down the protocol number or port ranges used by the traffic 3096 selectors. The SAD entry created for the Child SA will have the 3097 addresses as seen by the server, namely IPN1 and IP2. 3099 When the client receives the server's response to the Child SA, it 3100 will do similar processing. If the transport mode SA was created, 3101 the client can store the original returned traffic selectors as 3102 original source and destination addresses. It will replace the IP 3103 addresses in the traffic selectors with the ones from the IP header 3104 of the IKE packet: it will replace IPN1 with IP1 and IP2 with IPN2. 3105 Then it will use those traffic selectors when verifying the SA 3106 against sent traffic selectors, and when installing the SAD entry. 3108 A summary of the rules for NAT-traversal in transport mode is: 3110 For the client proposing transport mode: 3112 - The TSi entries MUST have exactly one IP address, and that MUST 3113 match the source address of the IKE SA. 3115 - The TSr entries MUST have exactly one IP address, and that MUST 3116 match the destination address of the IKE SA. 3118 - The first TSi and TSr traffic selectors SHOULD have very specific 3119 traffic selectors including protocol and port numbers, such as 3120 from the packet triggering the request. 3122 - There MAY be multiple TSi and TSr entries. 3124 - If transport mode for the SA was selected (that is, if the server 3125 included USE_TRANSPORT_MODE notification in its response): 3127 - Store the original traffic selectors as the received source and 3128 destination address. 3130 - If the server is behind a NAT, substitute the IP address in the 3131 TSr entries with the remote address of the IKE SA. 3133 - If the client is behind a NAT, substitute the IP address in the 3134 TSi entries with the local address of the IKE SA. 3136 - Do address substitution before using those traffic selectors 3137 for anything else other than storing original content of them. 3138 This includes verification that traffic selectors were narrowed 3139 correctly by other end, creation of the SAD entry, and so on. 3141 For the responder, when transport mode is proposed by client: 3143 - Store the original traffic selector IP addresses as received source 3144 and destination address, both in case we need to undo address 3145 substitution, and to use as the "real source and destination 3146 address" specified by [UDPENCAPS], and for TCP/UDP checksum fixup. 3148 - If the client is behind a NAT, substitute the IP address in the 3149 TSi entries with the remote address of the IKE SA. 3151 - If the server is behind a NAT substitute the IP address in the 3152 TSr entries with the local address of the IKE SA. 3154 - Do PAD and SPD lookup using the ID and substituted traffic 3155 selectors. 3157 - If no SPD entry was found, or if found SPD entry does not 3158 allow transport mode, undo the traffic selector substitutions. 3159 Do PAD and SPD lookup again using the ID and original traffic 3160 selectors, but also searching for tunnel mode SPD entry (that 3161 is, fall back to tunnel mode). 3163 - However, if a transport mode SPD entry was found, do normal 3164 traffic selection narrowing based on the substituted traffic 3165 selectors and SPD entry. Use the resulting traffic selectors when 3166 creating SAD entries, and when sending traffic selectors back to 3167 the client. 3169 2.24. Explicit Congestion Notification (ECN) 3171 When IPsec tunnels behave as originally specified in [IPSECARCH-OLD], 3172 ECN usage is not appropriate for the outer IP headers because tunnel 3173 decapsulation processing discards ECN congestion indications to the 3174 detriment of the network. ECN support for IPsec tunnels for IKEv1- 3175 based IPsec requires multiple operating modes and negotiation (see 3176 [ECN]). IKEv2 simplifies this situation by requiring that ECN be 3177 usable in the outer IP headers of all tunnel-mode Child SAs created 3178 by IKEv2. Specifically, tunnel encapsulators and decapsulators for 3179 all tunnel-mode SAs created by IKEv2 MUST support the ECN full- 3180 functionality option for tunnels specified in [ECN] and MUST 3181 implement the tunnel encapsulation and decapsulation processing 3182 specified in [IPSECARCH] to prevent discarding of ECN congestion 3183 indications. 3185 2.25. Exchange Collisions 3187 Because IKEv2 exchanges can be initiated by either peer, it is 3188 possible that two exchanges affecting the same SA partly overlap. 3189 This can lead to a situation where the SA state information is 3190 temporarily not synchronized, and a peer can receive a request that 3191 it cannot process in a normal fashion. 3193 Obviously, using a window size greater than 1 leads to more complex 3194 situations, especially if requests are processed out of order. This 3195 section concentrates on problems that can arise even with a window 3196 size of 1, and recommends solutions. 3198 A TEMPORARY_FAILURE notification SHOULD be sent when a peer receives 3199 a request that cannot be completed due to a temporary condition such 3200 as a rekeying operation. When a peer receives a TEMPORARY_FAILURE 3201 notification, it MUST NOT immediately retry the operation; it MUST 3202 wait so that the sender may complete whatever operation caused the 3203 temporary condition. The recipient MAY retry the request one or more 3204 times over a period of several minutes. If a peer continues to 3205 receive TEMPORARY_FAILURE on the same IKE SA after several minutes, 3206 it SHOULD conclude that the state information is out-of-sync and 3207 close the IKE SA. 3209 A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives 3210 a request to rekey a Child SA that does not exist. The SA that the 3211 initiator attempted to rekey is indicated by the SPI field in the 3212 Notify Payload, which is copied from the SPI field in the REKEY_SA 3213 notification. A peer that receives a CHILD_SA_NOT_FOUND notification 3214 SHOULD silently delete the Child SA (if it still exists) and send a 3215 request to create a new Child SA from scratch (if the Child SA does 3216 not yet exist). 3218 2.25.1. Collisions While Rekeying or Closing Child SAs 3220 If a peer receives a request to rekey a Child SA that it is currently 3221 trying to close, it SHOULD reply with TEMPORARY_FAILURE. If a peer 3222 receives a request to rekey a Child SA that it is currently rekeying, 3223 it SHOULD reply as usual, and SHOULD prepare to close redundant SAs 3224 later based on the nonces (see Section 2.8.1). If a peer receives a 3225 request to rekey a Child SA that does not exist, it SHOULD reply with 3226 CHILD_SA_NOT_FOUND. 3228 If a peer receives a request to close a Child SA that it is currently 3229 trying to close, it SHOULD reply without Delete payloads (see 3230 Section 1.4.1). If a peer receives a request to close a Child SA 3231 that it is currently rekeying, it SHOULD reply as usual, with a 3232 Delete payload. If a peer receives a request to close a Child SA 3233 that does not exist, it SHOULD reply without Delete payloads. 3235 If a peer receives a request to rekey the IKE SA, and it is currently 3236 creating, rekeying, or closing a Child SA of that IKE SA, it SHOULD 3237 reply with TEMPORARY_FAILURE. 3239 2.25.2. Collisions While Rekeying or Closing IKE SAs 3241 If a peer receives a request to rekey an IKE SA that it is currently 3242 rekeying, it SHOULD reply as usual, and SHOULD prepare to close 3243 redundant SAs and move inherited Child SAs later based on the nonces 3244 (see Section 2.8.2). If a peer receives a request to rekey an IKE SA 3245 that it is currently trying to close, it SHOULD reply with 3246 TEMPORARY_FAILURE. 3248 If a peer receives a request to close an IKE SA that it is currently 3249 rekeying, it SHOULD reply as usual, and forget about its own rekeying 3250 request. If a peer receives a request to close an IKE SA that it is 3251 currently trying to close, it SHOULD reply as usual, and forget about 3252 its own close request. 3254 If a peer receives a request to create or rekey a Child SA when it is 3255 currently rekeying the IKE SA, it SHOULD reply with 3256 TEMPORARY_FAILURE. If a peer receives a request to delete a Child SA 3257 when it is currently rekeying the IKE SA, it SHOULD reply as usual, 3258 with a Delete payload. 3260 3. Header and Payload Formats 3262 In the tables in this section, some cryptographic primitives and 3263 configuration attributes are marked as "UNSPECIFIED". These are 3264 items for which there are no known specifications and therefore 3265 interoperability is currently impossible. A future specification may 3266 describe their use, but until such specification is made, 3267 implementations SHOULD NOT attempt to use items marked as 3268 "UNSPECIFIED" in implementations that are meant to be interoperable. 3270 3.1. The IKE Header 3272 IKE messages use UDP ports 500 and/or 4500, with one IKE message per 3273 UDP datagram. Information from the beginning of the packet through 3274 the UDP header is largely ignored except that the IP addresses and 3275 UDP ports from the headers are reversed and used for return packets. 3276 When sent on UDP port 500, IKE messages begin immediately following 3277 the UDP header. When sent on UDP port 4500, IKE messages have 3278 prepended four octets of zero. These four octets of zero are not 3279 part of the IKE message and are not included in any of the length 3280 fields or checksums defined by IKE. Each IKE message begins with the 3281 IKE header, denoted HDR in this document. Following the header are 3282 one or more IKE payloads each identified by a "Next Payload" field in 3283 the preceding payload. Payloads are identified in the order in which 3284 they appear in an IKE message by looking in the "Next Payload" field 3285 in the IKE header, and subsequently according to the "Next Payload" 3286 field in the IKE payload itself until a "Next Payload" field of zero 3287 indicates that no payloads follow. If a payload of type "Encrypted" 3288 is found, that payload is decrypted and its contents parsed as 3289 additional payloads. An Encrypted payload MUST be the last payload 3290 in a packet and an Encrypted payload MUST NOT contain another 3291 Encrypted payload. 3293 The responder's SPI in the header identifies an instance of an IKE 3294 security association. It is therefore possible for a single instance 3295 of IKE to multiplex distinct sessions with multiple peers, including 3296 multiple sessions per peer. 3298 All multi-octet fields representing integers are laid out in big 3299 endian order (also known as "most significant byte first", or 3300 "network byte order"). 3302 The format of the IKE header is shown in Figure 4. 3304 1 2 3 3305 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 3306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3307 | IKE SA Initiator's SPI | 3308 | | 3309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3310 | IKE SA Responder's SPI | 3311 | | 3312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3313 | Next Payload | MjVer | MnVer | Exchange Type | Flags | 3314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3315 | Message ID | 3316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3317 | Length | 3318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3320 Figure 4: IKE Header Format 3322 o Initiator's SPI (8 octets) - A value chosen by the initiator to 3323 identify a unique IKE security association. This value MUST NOT 3324 be zero. 3326 o Responder's SPI (8 octets) - A value chosen by the responder to 3327 identify a unique IKE security association. This value MUST be 3328 zero in the first message of an IKE Initial Exchange (including 3329 repeats of that message including a cookie). 3331 o Next Payload (1 octet) - Indicates the type of payload that 3332 immediately follows the header. The format and value of each 3333 payload are defined below. 3335 o Major Version (4 bits) - Indicates the major version of the IKE 3336 protocol in use. Implementations based on this version of IKE 3337 MUST set the Major Version to 2. Implementations based on 3338 previous versions of IKE and ISAKMP MUST set the Major Version to 3339 1. Implementations based on this version of IKE MUST reject or 3340 ignore messages containing a version number greater than 2 with an 3341 INVALID_MAJOR_VERSION notification message as described in Section 3342 2.5. 3344 o Minor Version (4 bits) - Indicates the minor version of the IKE 3345 protocol in use. Implementations based on this version of IKE 3346 MUST set the Minor Version to 0. They MUST ignore the minor 3347 version number of received messages. 3349 o Exchange Type (1 octet) - Indicates the type of exchange being 3350 used. This constrains the payloads sent in each message in an 3351 exchange. The values in the following table are only current as 3352 of the publication date of RFC 4306. Other values may have been 3353 added since then or will be added after the publication of this 3354 document. Readers should refer to [IKEV2IANA] for the latest 3355 values. 3357 Exchange Type Value 3358 ---------------------------------- 3359 IKE_SA_INIT 34 3360 IKE_AUTH 35 3361 CREATE_CHILD_SA 36 3362 INFORMATIONAL 37 3364 o Flags (1 octet) - Indicates specific options that are set for the 3365 message. Presence of options is indicated by the appropriate bit 3366 in the flags field being set. The bits are as follows: 3368 +-+-+-+-+-+-+-+-+ 3369 |X|X|R|V|I|X|X|X| 3370 +-+-+-+-+-+-+-+-+ 3372 In the description below, a bit being 'set' means its value is 3373 '1', while 'cleared' means its value is '0'. "X" bits MUST be 3374 cleared when sending and MUST be ignored on receipt. 3376 * R (Response) - This bit indicates that this message is a 3377 response to a message containing the same message ID. This bit 3378 MUST be cleared in all request messages and MUST be set in all 3379 responses. An IKE endpoint MUST NOT generate a response to a 3380 message that is marked as being a response (with one exception; 3381 see Section 2.21.2). 3383 * V (Version) - This bit indicates that the transmitter is 3384 capable of speaking a higher major version number of the 3385 protocol than the one indicated in the major version number 3386 field. Implementations of IKEv2 MUST clear this bit when 3387 sending and MUST ignore it in incoming messages. 3389 * I (Initiator) - This bit MUST be set in messages sent by the 3390 original initiator of the IKE SA and MUST be cleared in 3391 messages sent by the original responder. It is used by the 3392 recipient to determine which eight octets of the SPI were 3393 generated by the recipient. This bit changes to reflect who 3394 initiated the last rekey of the IKE SA. 3396 o Message ID (4 octets, unsigned integer) - Message identifier used 3397 to control retransmission of lost packets and matching of requests 3398 and responses. It is essential to the security of the protocol 3399 because it is used to prevent message replay attacks. See 3400 Section 2.1 and Section 2.2. 3402 o Length (4 octets, unsigned integer) - Length of total message 3403 (header + payloads) in octets. 3405 3.2. Generic Payload Header 3407 Each IKE payload defined in Section 3.3 through Section 3.16 begins 3408 with a generic payload header, shown in Figure 5. Figures for each 3409 payload below will include the generic payload header, but for 3410 brevity the description of each field will be omitted. 3412 1 2 3 3413 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 3414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3415 | Next Payload |C| RESERVED | Payload Length | 3416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3418 Figure 5: Generic Payload Header 3420 The Generic Payload Header fields are defined as follows: 3422 o Next Payload (1 octet) - Identifier for the payload type of the 3423 next payload in the message. If the current payload is the last 3424 in the message, then this field will be 0. This field provides a 3425 "chaining" capability whereby additional payloads can be added to 3426 a message by appending each one to the end of the message and 3427 setting the "Next Payload" field of the preceding payload to 3428 indicate the new payload's type. An Encrypted payload, which must 3429 always be the last payload of a message, is an exception. It 3430 contains data structures in the format of additional payloads. In 3431 the header of an Encrypted payload, the Next Payload field is set 3432 to the payload type of the first contained payload (instead of 0); 3433 conversely, the Next Payload field of the last contained payload 3434 is set to zero). The payload type values are listed here. The 3435 values in the following table are only current as of the 3436 publication date of RFC 4306. Other values may have been added 3437 since then or will be added after the publication of this 3438 document. Readers should refer to [IKEV2IANA] for the latest 3439 values. 3441 Next Payload Type Notation Value 3442 -------------------------------------------------- 3443 No Next Payload 0 3444 Security Association SA 33 3445 Key Exchange KE 34 3446 Identification - Initiator IDi 35 3447 Identification - Responder IDr 36 3448 Certificate CERT 37 3449 Certificate Request CERTREQ 38 3450 Authentication AUTH 39 3451 Nonce Ni, Nr 40 3452 Notify N 41 3453 Delete D 42 3454 Vendor ID V 43 3455 Traffic Selector - Initiator TSi 44 3456 Traffic Selector - Responder TSr 45 3457 Encrypted and Authenticated SK 46 3458 Configuration CP 47 3459 Extensible Authentication EAP 48 3461 (Payload type values 1-32 should not be assigned in the 3462 future so that there is no overlap with the code assignments 3463 for IKEv1.) 3465 o Critical (1 bit) - MUST be set to zero if the sender wants the 3466 recipient to skip this payload if it does not understand the 3467 payload type code in the Next Payload field of the previous 3468 payload. MUST be set to one if the sender wants the recipient to 3469 reject this entire message if it does not understand the payload 3470 type. MUST be ignored by the recipient if the recipient 3471 understands the payload type code. MUST be set to zero for 3472 payload types defined in this document. Note that the critical 3473 bit applies to the current payload rather than the "next" payload 3474 whose type code appears in the first octet. The reasoning behind 3475 not setting the critical bit for payloads defined in this document 3476 is that all implementations MUST understand all payload types 3477 defined in this document and therefore must ignore the Critical 3478 bit's value. Skipped payloads are expected to have valid Next 3479 Payload and Payload Length fields. See Section 2.5 for more 3480 information on this bit. 3482 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on 3483 receipt. 3485 o Payload Length (2 octets, unsigned integer) - Length in octets of 3486 the current payload, including the generic payload header. 3488 Many payloads contain fields marked as "RESERVED". Some payloads in 3489 IKEv2 (and historically in IKEv1) are not aligned to 4-octet 3490 boundaries. 3492 3.3. Security Association Payload 3494 The Security Association Payload, denoted SA in this document, is 3495 used to negotiate attributes of a security association. Assembly of 3496 Security Association Payloads requires great peace of mind. An SA 3497 payload MAY contain multiple proposals. If there is more than one, 3498 they MUST be ordered from most preferred to least preferred. Each 3499 proposal contains a single IPsec protocol (where a protocol is IKE, 3500 ESP, or AH), each protocol MAY contain multiple transforms, and each 3501 transform MAY contain multiple attributes. When parsing an SA, an 3502 implementation MUST check that the total Payload Length is consistent 3503 with the payload's internal lengths and counts. Proposals, 3504 Transforms, and Attributes each have their own variable length 3505 encodings. They are nested such that the Payload Length of an SA 3506 includes the combined contents of the SA, Proposal, Transform, and 3507 Attribute information. The length of a Proposal includes the lengths 3508 of all Transforms and Attributes it contains. The length of a 3509 Transform includes the lengths of all Attributes it contains. 3511 The syntax of Security Associations, Proposals, Transforms, and 3512 Attributes is based on ISAKMP; however the semantics are somewhat 3513 different. The reason for the complexity and the hierarchy is to 3514 allow for multiple possible combinations of algorithms to be encoded 3515 in a single SA. Sometimes there is a choice of multiple algorithms, 3516 whereas other times there is a combination of algorithms. For 3517 example, an initiator might want to propose using ESP with either 3518 (3DES and HMAC_MD5) or (AES and HMAC_SHA1). 3520 One of the reasons the semantics of the SA payload has changed from 3521 ISAKMP and IKEv1 is to make the encodings more compact in common 3522 cases. 3524 The Proposal structure contains within it a Proposal Num and an IPsec 3525 protocol ID. Each structure MUST have a proposal number one (1) 3526 greater than the previous structure. The first Proposal in the 3527 initiator's SA payload MUST have a Proposal Num of one (1). One 3528 reason to use multiple proposals is to propose both standard crypto 3529 ciphers and combined-mode ciphers. Combined-mode ciphers include 3530 both integrity and encryption in a single encryption algorithm, and 3531 MUST either offer no integrity algorithm or a single integrity 3532 algorithm of "none", with no integrity algorithm being the 3533 RECOMMENDED method. If an initiator wants to propose both combined- 3534 mode ciphers and normal ciphers, it must include two proposals: one 3535 will have all the combined-mode ciphers, and the other will have all 3536 the normal ciphers with the integrity algorithms. For example, one 3537 such proposal would have two proposal structures. Proposal 1 is ESP 3538 with AES-128, AES-192, and AES-256 bits in CBC mode, with either 3539 HMAC-SHA1-96 or XCBC-96 as the integrity algorithm; Proposal 2 is 3540 AES-128 or AES-256 in GCM mode with an 8-octet ICV. Both proposals 3541 allow but do not require the use of ESN (extended sequence numbers). 3542 This can be illustrated as: 3544 SA Payload 3545 | 3546 +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4, 3547 | | 7 transforms, SPI = 0x052357bb ) 3548 | | 3549 | +-- Transform ENCR ( Name = ENCR_AES_CBC ) 3550 | | +-- Attribute ( Key Length = 128 ) 3551 | | 3552 | +-- Transform ENCR ( Name = ENCR_AES_CBC ) 3553 | | +-- Attribute ( Key Length = 192 ) 3554 | | 3555 | +-- Transform ENCR ( Name = ENCR_AES_CBC ) 3556 | | +-- Attribute ( Key Length = 256 ) 3557 | | 3558 | +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 ) 3559 | +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 ) 3560 | +-- Transform ESN ( Name = ESNs ) 3561 | +-- Transform ESN ( Name = No ESNs ) 3562 | 3563 +--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4, 3564 | 4 transforms, SPI = 0x35a1d6f2 ) 3565 | 3566 +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) 3567 | +-- Attribute ( Key Length = 128 ) 3568 | 3569 +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) 3570 | +-- Attribute ( Key Length = 256 ) 3571 | 3572 +-- Transform ESN ( Name = ESNs ) 3573 +-- Transform ESN ( Name = No ESNs ) 3575 Each Proposal/Protocol structure is followed by one or more transform 3576 structures. The number of different transforms is generally 3577 determined by the Protocol. AH generally has two transforms: 3578 Extended Sequence Numbers (ESN) and an integrity check algorithm. 3579 ESP generally has three: ESN, an encryption algorithm and an 3580 integrity check algorithm. IKE generally has four transforms: a 3581 Diffie-Hellman group, an integrity check algorithm, a PRF algorithm, 3582 and an encryption algorithm. For each Protocol, the set of 3583 permissible transforms is assigned transform ID numbers, which appear 3584 in the header of each transform. 3586 If there are multiple transforms with the same Transform Type, the 3587 proposal is an OR of those transforms. If there are multiple 3588 Transforms with different Transform Types, the proposal is an AND of 3589 the different groups. For example, to propose ESP with (3DES or AES- 3590 CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two 3591 Transform Type 1 candidates (one for 3DES and one for AEC-CBC) and 3592 two Transform Type 3 candidates (one for HMAC_MD5 and one for 3593 HMAC_SHA). This effectively proposes four combinations of 3594 algorithms. If the initiator wanted to propose only a subset of 3595 those, for example (3DES and HMAC_MD5) or (IDEA and HMAC_SHA), there 3596 is no way to encode that as multiple transforms within a single 3597 Proposal. Instead, the initiator would have to construct two 3598 different Proposals, each with two transforms. 3600 A given transform MAY have one or more Attributes. Attributes are 3601 necessary when the transform can be used in more than one way, as 3602 when an encryption algorithm has a variable key size. The transform 3603 would specify the algorithm and the attribute would specify the key 3604 size. Most transforms do not have attributes. A transform MUST NOT 3605 have multiple attributes of the same type. To propose alternate 3606 values for an attribute (for example, multiple key sizes for the AES 3607 encryption algorithm), an implementation MUST include multiple 3608 Transforms with the same Transform Type each with a single Attribute. 3610 Note that the semantics of Transforms and Attributes are quite 3611 different from those in IKEv1. In IKEv1, a single Transform carried 3612 multiple algorithms for a protocol with one carried in the Transform 3613 and the others carried in the Attributes. 3615 1 2 3 3616 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 3617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3618 | Next Payload |C| RESERVED | Payload Length | 3619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3620 | | 3621 ~ ~ 3622 | | 3623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3625 Figure 6: Security Association Payload 3627 o Proposals (variable) - One or more proposal substructures. 3629 The payload type for the Security Association Payload is thirty three 3630 (33). 3632 3.3.1. Proposal Substructure 3634 1 2 3 3635 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 3636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3637 | 0 (last) or 2 | RESERVED | Proposal Length | 3638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3639 | Proposal Num | Protocol ID | SPI Size |Num Transforms| 3640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3641 ~ SPI (variable) ~ 3642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3643 | | 3644 ~ ~ 3645 | | 3646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3648 Figure 7: Proposal Substructure 3650 o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the 3651 last Proposal Substructure in the SA. This syntax is inherited 3652 from ISAKMP, but is unnecessary because the last Proposal could be 3653 identified from the length of the SA. The value (2) corresponds 3654 to a Payload Type of Proposal in IKEv1, and the first four octets 3655 of the Proposal structure are designed to look somewhat like the 3656 header of a Payload. 3658 o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on 3659 receipt. 3661 o Proposal Length (2 octets, unsigned integer) - Length of this 3662 proposal, including all transforms and attributes that follow. 3664 o Proposal Num (1 octet) - When a proposal is made, the first 3665 proposal in an SA payload MUST be 1, and subsequent proposals MUST 3666 be one more than the previous proposal (indicating an OR of the 3667 two proposals). When a proposal is accepted, the proposal number 3668 in the SA payload MUST match the number on the proposal sent that 3669 was accepted. 3671 o Protocol ID (1 octet) - Specifies the IPsec protocol identifier 3672 for the current negotiation. The values in the following table 3673 are only current as of the publication date of RFC 4306. Other 3674 values may have been added since then or will be added after the 3675 publication of this document. Readers should refer to [IKEV2IANA] 3676 for the latest values. 3678 Protocol Protocol ID 3679 ----------------------------------- 3680 IKE 1 3681 AH 2 3682 ESP 3 3684 o SPI Size (1 octet) - For an initial IKE SA negotiation, this field 3685 MUST be zero; the SPI is obtained from the outer header. During 3686 subsequent negotiations, it is equal to the size, in octets, of 3687 the SPI of the corresponding protocol (8 for IKE, 4 for ESP and 3688 AH). 3690 o Num Transforms (1 octet) - Specifies the number of transforms in 3691 this proposal. 3693 o SPI (variable) - The sending entity's SPI. Even if the SPI Size 3694 is not a multiple of 4 octets, there is no padding applied to the 3695 payload. When the SPI Size field is zero, this field is not 3696 present in the Security Association payload. 3698 o Transforms (variable) - One or more transform substructures. 3700 3.3.2. Transform Substructure 3702 1 2 3 3703 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 3704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3705 | 0 (last) or 3 | RESERVED | Transform Length | 3706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3707 |Transform Type | RESERVED | Transform ID | 3708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3709 | | 3710 ~ Transform Attributes ~ 3711 | | 3712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3714 Figure 8: Transform Substructure 3716 o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the 3717 last Transform Substructure in the Proposal. This syntax is 3718 inherited from ISAKMP, but is unnecessary because the last 3719 transform could be identified from the length of the proposal. 3720 The value (3) corresponds to a Payload Type of Transform in IKEv1, 3721 and the first four octets of the Transform structure are designed 3722 to look somewhat like the header of a Payload. 3724 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 3726 o Transform Length - The length (in octets) of the Transform 3727 Substructure including Header and Attributes. 3729 o Transform Type (1 octet) - The type of transform being specified 3730 in this transform. Different protocols support different 3731 transform types. For some protocols, some of the transforms may 3732 be optional. If a transform is optional and the initiator wishes 3733 to propose that the transform be omitted, no transform of the 3734 given type is included in the proposal. If the initiator wishes 3735 to make use of the transform optional to the responder, it 3736 includes a transform substructure with transform ID = 0 as one of 3737 the options. 3739 o Transform ID (2 octets) - The specific instance of the transform 3740 type being proposed. 3742 The transform type values are listed below. The values in the 3743 following table are only current as of the publication date of RFC 3744 4306. Other values may have been added since then or will be added 3745 after the publication of this document. Readers should refer to 3746 [IKEV2IANA] for the latest values. 3748 Description Trans. Used In 3749 Type 3750 ------------------------------------------------------------------ 3751 Encryption Algorithm (ENCR) 1 IKE and ESP 3752 Pseudo-random Function (PRF) 2 IKE 3753 Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP 3754 Diffie-Hellman Group (D-H) 4 IKE, optional in AH & ESP 3755 Extended Sequence Numbers (ESN) 5 AH and ESP 3757 (*) Negotiating an integrity algorithm is mandatory for the 3758 Encrypted payload format specified in this document. For example, 3759 [AEAD] specifies additional formats based on authenticated 3760 encryption, in which a separate integrity algorithm is not 3761 negotiated. 3763 For Transform Type 1 (Encryption Algorithm), the Transform IDs are 3764 listed below. The values in the following table are only current as 3765 of the publication date of RFC 4306. Other values may have been 3766 added since then or will be added after the publication of this 3767 document. Readers should refer to [IKEV2IANA] for the latest values. 3769 Name Number Defined In 3770 --------------------------------------------------- 3771 ENCR_DES_IV64 1 (UNSPECIFIED) 3772 ENCR_DES 2 (RFC2405), [DES] 3773 ENCR_3DES 3 (RFC2451) 3774 ENCR_RC5 4 (RFC2451) 3775 ENCR_IDEA 5 (RFC2451), [IDEA] 3776 ENCR_CAST 6 (RFC2451) 3777 ENCR_BLOWFISH 7 (RFC2451) 3778 ENCR_3IDEA 8 (UNSPECIFIED) 3779 ENCR_DES_IV32 9 (UNSPECIFIED) 3780 ENCR_NULL 11 (RFC2410) 3781 ENCR_AES_CBC 12 (RFC3602) 3782 ENCR_AES_CTR 13 (RFC3686) 3784 For Transform Type 2 (Pseudo-random Function), the Transform IDs are 3785 listed below. The values in the following table are only current as 3786 of the publication date of RFC 4306. Other values may have been 3787 added since then or will be added after the publication of this 3788 document. Readers should refer to [IKEV2IANA] for the latest values. 3790 Name Number Defined In 3791 ------------------------------------------------------ 3792 PRF_HMAC_MD5 1 (RFC2104), [MD5] 3793 PRF_HMAC_SHA1 2 (RFC2104), [SHA] 3794 PRF_HMAC_TIGER 3 (UNSPECIFIED) 3796 For Transform Type 3 (Integrity Algorithm), defined Transform IDs are 3797 listed below. The values in the following table are only current as 3798 of the publication date of RFC 4306. Other values may have been 3799 added since then or will be added after the publication of this 3800 document. Readers should refer to [IKEV2IANA] for the latest values. 3802 Name Number Defined In 3803 ---------------------------------------- 3804 NONE 0 3805 AUTH_HMAC_MD5_96 1 (RFC2403) 3806 AUTH_HMAC_SHA1_96 2 (RFC2404) 3807 AUTH_DES_MAC 3 (UNSPECIFIED) 3808 AUTH_KPDK_MD5 4 (UNSPECIFIED) 3809 AUTH_AES_XCBC_96 5 (RFC3566) 3811 For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs 3812 are listed below. The values in the following table are only current 3813 as of the publication date of RFC 4306. Other values may have been 3814 added since then or will be added after the publication of this 3815 document. Readers should refer to [IKEV2IANA] for the latest values. 3817 Name Number Defined in 3818 ---------------------------------------- 3819 NONE 0 3820 768 Bit MODP 1 Appendix B 3821 1024 Bit MODP 2 Appendix B 3822 1536-bit MODP 5 [ADDGROUP] 3823 2048-bit MODP 14 [ADDGROUP] 3824 3072-bit MODP 15 [ADDGROUP] 3825 4096-bit MODP 16 [ADDGROUP] 3826 6144-bit MODP 17 [ADDGROUP] 3827 8192-bit MODP 18 [ADDGROUP] 3829 Although ESP and AH do not directly include a Diffie-Hellman 3830 exchange, a Diffie-Hellman group MAY be negotiated for the Child SA. 3831 This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA 3832 exchange, providing perfect forward secrecy for the generated Child 3833 SA keys. 3835 For Transform Type 5 (Extended Sequence Numbers), defined Transform 3836 IDs are listed below. The values in the following table are only 3837 current as of the publication date of RFC 4306. Other values may 3838 have been added since then or will be added after the publication of 3839 this document. Readers should refer to [IKEV2IANA] for the latest 3840 values. 3842 Name Number 3843 -------------------------------------------- 3844 No Extended Sequence Numbers 0 3845 Extended Sequence Numbers 1 3847 Note that an initiator who supports ESNs will usually include two ESN 3848 transforms, with values "0" and "1", in its proposals. A proposal 3849 containing a single ESN transform with value "1" means that using 3850 normal (non-extended) sequence numbers is not acceptable. 3852 Numerous additional transform types have been defined since the 3853 publication of RFC 4306. Please refer to the IANA IKEv2 registry for 3854 details. 3856 3.3.3. Valid Transform Types by Protocol 3858 The number and type of transforms that accompany an SA payload are 3859 dependent on the protocol in the SA itself. An SA payload proposing 3860 the establishment of an SA has the following mandatory and optional 3861 transform types. A compliant implementation MUST understand all 3862 mandatory and optional types for each protocol it supports (though it 3863 need not accept proposals with unacceptable suites). A proposal MAY 3864 omit the optional types if the only value for them it will accept is 3865 NONE. 3867 Protocol Mandatory Types Optional Types 3868 --------------------------------------------------- 3869 IKE ENCR, PRF, INTEG*, D-H 3870 ESP ENCR, ESN INTEG, D-H 3871 AH INTEG, ESN D-H 3873 (*) Negotiating an integrity algorithm is mandatory for the 3874 Encrypted payload format specified in this document. For example, 3875 [AEAD] specifies additional formats based on authenticated 3876 encryption, in which a separate integrity algorithm is not 3877 negotiated. 3879 3.3.4. Mandatory Transform IDs 3881 The specification of suites that MUST and SHOULD be supported for 3882 interoperability has been removed from this document because they are 3883 likely to change more rapidly than this document evolves. At the 3884 time of publication of this document, [RFC4307] specifies these 3885 suites, but note that it might be updated in the future, and other 3886 RFCs might specify different sets of suites. 3888 An important lesson learned from IKEv1 is that no system should only 3889 implement the mandatory algorithms and expect them to be the best 3890 choice for all customers. 3892 It is likely that IANA will add additional transforms in the future, 3893 and some users may want to use private suites, especially for IKE 3894 where implementations should be capable of supporting different 3895 parameters, up to certain size limits. In support of this goal, all 3896 implementations of IKEv2 SHOULD include a management facility that 3897 allows specification (by a user or system administrator) of Diffie- 3898 Hellman parameters (the generator, modulus, and exponent lengths and 3899 values) for new Diffie-Hellman groups. Implementations SHOULD 3900 provide a management interface through which these parameters and the 3901 associated transform IDs may be entered (by a user or system 3902 administrator), to enable negotiating such groups. 3904 All implementations of IKEv2 MUST include a management facility that 3905 enables a user or system administrator to specify the suites that are 3906 acceptable for use with IKE. Upon receipt of a payload with a set of 3907 transform IDs, the implementation MUST compare the transmitted 3908 transform IDs against those locally configured via the management 3909 controls, to verify that the proposed suite is acceptable based on 3910 local policy. The implementation MUST reject SA proposals that are 3911 not authorized by these IKE suite controls. Note that cryptographic 3912 suites that MUST be implemented need not be configured as acceptable 3913 to local policy. 3915 3.3.5. Transform Attributes 3917 Each transform in a Security Association payload may include 3918 attributes that modify or complete the specification of the 3919 transform. The set of valid attributes depends on the transform. 3920 Currently, only a single attribute type is defined: the Key Length 3921 attribute is used by certain encryption transforms with variable- 3922 length keys (see below for details). 3924 The attributes are type/value pairs and are defined below. 3925 Attributes can have a value with a fixed two-octet length or a 3926 variable-length value. For the latter, the attribute is encoded as 3927 type/length/value. 3929 1 2 3 3930 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 3931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3932 |A| Attribute Type | AF=0 Attribute Length | 3933 |F| | AF=1 Attribute Value | 3934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3935 | AF=0 Attribute Value | 3936 | AF=1 Not Transmitted | 3937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3939 Figure 9: Data Attributes 3941 o Attribute Format (AF) (1 bit) - Indicates whether the data 3942 attribute follows the Type/Length/Value (TLV) format or a 3943 shortened Type/Value (TV) format. If the AF bit is zero (0), then 3944 the attribute uses TLV format; if the AF bit is one (1), the TV 3945 format (with two-byte value) is used. 3947 o Attribute Type (15 bits) - Unique identifier for each type of 3948 attribute (see below). 3950 o Attribute Value (variable length) - Value of the Attribute 3951 associated with the Attribute Type. If the AF bit is a zero (0), 3952 this field has a variable length defined by the Attribute Length 3953 field. If the AF bit is a one (1), the Attribute Value has a 3954 length of 2 octets. 3956 The only currently defined attribute type (Key Length) is fixed 3957 length; the variable-length encoding specification is included only 3958 for future extensions. Attributes described as fixed length MUST NOT 3959 be encoded using the variable-length encoding unless that length 3960 exceeds two bytes. Variable-length attributes MUST NOT be encoded as 3961 fixed-length even if their value can fit into two octets. NOTE: This 3962 is a change from IKEv1, where increased flexibility may have 3963 simplified the composer of messages but certainly complicated the 3964 parser. 3966 The values in the following table are only current as of the 3967 publication date of RFC 4306. Other values may have been added since 3968 then or will be added after the publication of this document. 3969 Readers should refer to [IKEV2IANA] for the latest values. 3971 Attribute Type Value Attribute Format 3972 ------------------------------------------------------------ 3973 Key Length (in bits) 14 TV 3975 Values 0-13 and 15-17 were used in a similar context in IKEv1, and 3976 should not be assigned except to matching values. 3978 The Key Length attribute specifies the key length in bits (MUST use 3979 network byte order) for certain transforms as follows: 3981 o The Key Length attribute MUST NOT be used with transforms that use 3982 a fixed length key. This includes, e.g., ENCR_DES, ENCR_IDEA, and 3983 all the Type 2 (Pseudo-random function) and Type 3 (Integrity 3984 Algorithm) transforms specified in this document. It is 3985 recommended that future Type 2 or 3 transforms do not use this 3986 attribute. 3988 o Some transforms specify that the Key Length attribute MUST be 3989 always included (omitting the attribute is not allowed, and 3990 proposals not containing it MUST be rejected). This includes, 3991 e.g., ENCR_AES_CBC and ENCR_AES_CTR. 3993 o Some transforms allow variable-length keys, but also specify a 3994 default key length if the attribute is not included. These 3995 transforms include, e.g., ENCR_RC5 and ENCR_BLOWFISH. 3997 Implementation note: To further interoperability and to support 3998 upgrading endpoints independently, implementers of this protocol 3999 SHOULD accept values that they deem to supply greater security. For 4000 instance, if a peer is configured to accept a variable-length cipher 4001 with a key length of X bits and is offered that cipher with a larger 4002 key length, the implementation SHOULD accept the offer if it supports 4003 use of the longer key. 4005 Support of this capability allows a responder to express a concept of 4006 "at least" a certain level of security -- "a key length of _at least_ 4007 X bits for cipher Y". However, as the attribute is always returned 4008 unchanged (see the next section), an initiator willing to accept 4009 multiple key lengths has to include multiple transforms with the same 4010 Transform Type, each with a different Key Length attribute. 4012 3.3.6. Attribute Negotiation 4014 During security association negotiation initiators present offers to 4015 responders. Responders MUST select a single complete set of 4016 parameters from the offers (or reject all offers if none are 4017 acceptable). If there are multiple proposals, the responder MUST 4018 choose a single proposal. If the selected proposal has multiple 4019 Transforms with the same type, the responder MUST choose a single 4020 one. Any attributes of a selected transform MUST be returned 4021 unmodified. The initiator of an exchange MUST check that the 4022 accepted offer is consistent with one of its proposals, and if not 4023 MUST terminate the exchange. 4025 If the responder receives a proposal that contains a Transform Type 4026 it does not understand, or a proposal that is missing a mandatory 4027 Transform Type, it MUST consider this proposal unacceptable; however, 4028 other proposals in the same SA payload are processed as usual. 4029 Similarly, if the responder receives a transform that it does not 4030 understand, or one that contains a Transform Attribute it does not 4031 understand, it MUST consider this transform unacceptable; other 4032 transforms with the same Transform Type are processed as usual. This 4033 allows new Transform Types and Transform Attributes to be defined in 4034 the future. 4036 Negotiating Diffie-Hellman groups presents some special challenges. 4037 SA offers include proposed attributes and a Diffie-Hellman public 4038 number (KE) in the same message. If in the initial exchange the 4039 initiator offers to use one of several Diffie-Hellman groups, it 4040 SHOULD pick the one the responder is most likely to accept and 4041 include a KE corresponding to that group. If the responder selects a 4042 proposal using a different Diffie-Hellman group (other than NONE), 4043 the responder will indicate the correct group in the response and the 4044 initiator SHOULD pick an element of that group for its KE value when 4045 retrying the first message. It SHOULD, however, continue to propose 4046 its full supported set of groups in order to prevent a man-in-the- 4047 middle downgrade attack. If one of the proposals offered is for the 4048 Diffie-Hellman group of NONE, and the responder selects that Diffie- 4049 Hellman group, then it MUST ignore the initiator's KE payload and 4050 omit the KE payload from the response. 4052 3.4. Key Exchange Payload 4054 The Key Exchange Payload, denoted KE in this document, is used to 4055 exchange Diffie-Hellman public numbers as part of a Diffie-Hellman 4056 key exchange. The Key Exchange Payload consists of the IKE generic 4057 payload header followed by the Diffie-Hellman public value itself. 4059 1 2 3 4060 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 4061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4062 | Next Payload |C| RESERVED | Payload Length | 4063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4064 | Diffie-Hellman Group Num | RESERVED | 4065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4066 | | 4067 ~ Key Exchange Data ~ 4068 | | 4069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4071 Figure 10: Key Exchange Payload Format 4073 A key exchange payload is constructed by copying one's Diffie-Hellman 4074 public value into the "Key Exchange Data" portion of the payload. 4075 The length of the Diffie-Hellman public value for MODP groups MUST be 4076 equal to the length of the prime modulus over which the 4077 exponentiation was performed, prepending zero bits to the value if 4078 necessary. 4080 The Diffie-Hellman Group Num identifies the Diffie-Hellman group in 4081 which the Key Exchange Data was computed (see Section 3.3.2). This 4082 Diffie-Hellman Group Num MUST match a Diffie-Hellman Group specified 4083 in a proposal in the SA payload that is sent in the same message, and 4084 SHOULD match the Diffie-Hellman group in the first group in the first 4085 proposal, if such exists. If none of the proposals in that SA 4086 payload specifies a Diffie-Hellman Group, the KE payload MUST NOT be 4087 present. If the selected proposal uses a different Diffie-Hellman 4088 group (other than NONE), the message MUST be rejected with a Notify 4089 payload of type INVALID_KE_PAYLOAD. See also Section 1.2 and 4090 Section 2.7. 4092 The payload type for the Key Exchange payload is thirty four (34). 4094 3.5. Identification Payloads 4096 The Identification Payloads, denoted IDi and IDr in this document, 4097 allow peers to assert an identity to one another. This identity may 4098 be used for policy lookup, but does not necessarily have to match 4099 anything in the CERT payload; both fields may be used by an 4100 implementation to perform access control decisions. When using the 4101 ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 4102 does not require this address to match the address in the IP header 4103 of IKEv2 packets, or anything in the TSi/TSr payloads. The contents 4104 of IDi/IDr is used purely to fetch the policy and authentication data 4105 related to the other party. 4107 NOTE: In IKEv1, two ID payloads were used in each direction to hold 4108 Traffic Selector (TS) information for data passing over the SA. In 4109 IKEv2, this information is carried in TS payloads (see Section 3.13). 4111 The Peer Authorization Database (PAD) as described in RFC 4301 4112 [IPSECARCH] describes the use of the ID payload in IKEv2 and provides 4113 a formal model for the binding of identity to policy in addition to 4114 providing services that deal more specifically with the details of 4115 policy enforcement. The PAD is intended to provide a link between 4116 the SPD and the IKE security association management. See Section 4117 4.4.3 of RFC 4301 for more details. 4119 The Identification Payload consists of the IKE generic payload header 4120 followed by identification fields as follows: 4122 1 2 3 4123 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 4124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4125 | Next Payload |C| RESERVED | Payload Length | 4126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4127 | ID Type | RESERVED | 4128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4129 | | 4130 ~ Identification Data ~ 4131 | | 4132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4134 Figure 11: Identification Payload Format 4136 o ID Type (1 octet) - Specifies the type of Identification being 4137 used. 4139 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 4141 o Identification Data (variable length) - Value, as indicated by the 4142 Identification Type. The length of the Identification Data is 4143 computed from the size in the ID payload header. 4145 The payload types for the Identification Payload are thirty five (35) 4146 for IDi and thirty six (36) for IDr. 4148 The following table lists the assigned semantics for the 4149 Identification Type field. The values in the following table are 4150 only current as of the publication date of RFC 4306. Other values 4151 may have been added since then or will be added after the publication 4152 of this document. Readers should refer to [IKEV2IANA] for the latest 4153 values. 4155 ID Type Value 4156 ------------------------------------------------------------------- 4157 ID_IPV4_ADDR 1 4158 A single four (4) octet IPv4 address. 4160 ID_FQDN 2 4161 A fully-qualified domain name string. An example of a ID_FQDN 4162 is, "example.com". The string MUST NOT contain any terminators 4163 (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; 4164 for an "internationalized domain name", the syntax is as defined 4165 in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net". 4167 ID_RFC822_ADDR 3 4168 A fully-qualified RFC822 email address string, An example of a 4169 ID_RFC822_ADDR is, "jsmith@example.com". The string MUST NOT 4170 contain any terminators. Because of [EAI], implementations would 4171 be wise to treat this field as UTF-8 encoded text, not as 4172 pure ASCII. 4174 ID_IPV6_ADDR 5 4175 A single sixteen (16) octet IPv6 address. 4177 ID_DER_ASN1_DN 9 4178 The binary Distinguished Encoding Rules (DER) encoding of an 4179 ASN.1 X.500 Distinguished Name [PKIX]. 4181 ID_DER_ASN1_GN 10 4182 The binary DER encoding of an ASN.1 X.509 GeneralName [PKIX]. 4184 ID_KEY_ID 11 4185 An opaque octet stream which may be used to pass vendor- 4186 specific information necessary to do certain proprietary 4187 types of identification. 4189 Two implementations will interoperate only if each can generate a 4190 type of ID acceptable to the other. To assure maximum 4191 interoperability, implementations MUST be configurable to send at 4192 least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and 4193 MUST be configurable to accept all of these four types. 4194 Implementations SHOULD be capable of generating and accepting all of 4195 these types. IPv6-capable implementations MUST additionally be 4196 configurable to accept ID_IPV6_ADDR. IPv6-only implementations MAY 4197 be configurable to send only ID_IPV6_ADDR instead of ID_IPV4_ADDR for 4198 IP addresses. 4200 EAP [EAP] does not mandate the use of any particular type of 4201 identifier, but often EAP is used with Network Access Identifiers 4202 (NAIs) defined in [NAI]. Although NAIs look a bit like email 4203 addresses (e.g., "joe@example.com"), the syntax is not exactly the 4204 same as the syntax of email address in [MAILFORMAT]. For those NAIs 4205 that include the realm component, the ID_RFC822_ADDR identification 4206 type SHOULD be used. Responder implementations should not attempt to 4207 verify that the contents actually conform to the exact syntax given 4208 in [MAILFORMAT], but instead should accept any reasonable-looking 4209 NAI. For NAIs that do not include the realm component, the ID_KEY_ID 4210 identification type SHOULD be used. 4212 3.6. Certificate Payload 4214 The Certificate Payload, denoted CERT in this document, provides a 4215 means to transport certificates or other authentication-related 4216 information via IKE. Certificate payloads SHOULD be included in an 4217 exchange if certificates are available to the sender. The Hash and 4218 URL formats of the Certificate payloads should be used in case the 4219 peer has indicated an ability to retrieve this information from 4220 elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note 4221 that the term "Certificate Payload" is somewhat misleading, because 4222 not all authentication mechanisms use certificates and data other 4223 than certificates may be passed in this payload. 4225 The Certificate Payload is defined as follows: 4227 1 2 3 4228 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 4229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4230 | Next Payload |C| RESERVED | Payload Length | 4231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4232 | Cert Encoding | | 4233 +-+-+-+-+-+-+-+-+ | 4234 ~ Certificate Data ~ 4235 | | 4236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4238 Figure 12: Certificate Payload Format 4240 o Certificate Encoding (1 octet) - This field indicates the type of 4241 certificate or certificate-related information contained in the 4242 Certificate Data field. The values in the following table are 4243 only current as of the publication date of RFC 4306. Other values 4244 may have been added since then or will be added after the 4245 publication of this document. Readers should refer to [IKEV2IANA] 4246 for the latest values. 4248 Certificate Encoding Value 4249 ---------------------------------------------------- 4250 PKCS #7 wrapped X.509 certificate 1 UNSPECIFIED 4251 PGP Certificate 2 UNSPECIFIED 4252 DNS Signed Key 3 UNSPECIFIED 4253 X.509 Certificate - Signature 4 4254 Kerberos Token 6 UNSPECIFIED 4255 Certificate Revocation List (CRL) 7 4256 Authority Revocation List (ARL) 8 UNSPECIFIED 4257 SPKI Certificate 9 UNSPECIFIED 4258 X.509 Certificate - Attribute 10 UNSPECIFIED 4259 Raw RSA Key 11 4260 Hash and URL of X.509 certificate 12 4261 Hash and URL of X.509 bundle 13 4263 o Certificate Data (variable length) - Actual encoding of 4264 certificate data. The type of certificate is indicated by the 4265 Certificate Encoding field. 4267 The payload type for the Certificate Payload is thirty seven (37). 4269 Specific syntax for some of the certificate type codes above is not 4270 defined in this document. The types whose syntax is defined in this 4271 document are: 4273 o "X.509 Certificate - Signature" contains a DER encoded X.509 4274 certificate whose public key is used to validate the sender's AUTH 4275 payload. Note that with this encoding, if a chain of certificates 4276 needs to be sent, multiple CERT payloads are used, only the first 4277 of which holds the public key used to validate the sender's AUTH 4278 payload. 4280 o "Certificate Revocation List" contains a DER encoded X.509 4281 certificate revocation list. 4283 o "Raw RSA Key" contains a PKCS #1 encoded RSA key, that is, a DER- 4284 encoded RSAPublicKey structure (see [RSA] and [PKCS1]). 4286 o Hash and URL encodings allow IKE messages to remain short by 4287 replacing long data structures with a 20 octet SHA-1 hash (see 4288 [SHA]) of the replaced value followed by a variable-length URL 4289 that resolves to the DER encoded data structure itself. This 4290 improves efficiency when the endpoints have certificate data 4291 cached and makes IKE less subject to DoS attacks that become 4292 easier to mount when IKE messages are large enough to require IP 4293 fragmentation [DOSUDPPROT]. 4295 The "Hash and URL of a bundle" type uses the following ASN.1 4296 definition for the X.509 bundle: 4298 CertBundle 4299 { iso(1) identified-organization(3) dod(6) internet(1) 4300 security(5) mechanisms(5) pkix(7) id-mod(0) 4301 id-mod-cert-bundle(34) } 4303 DEFINITIONS EXPLICIT TAGS ::= 4304 BEGIN 4306 IMPORTS 4307 Certificate, CertificateList 4308 FROM PKIX1Explicit88 4309 { iso(1) identified-organization(3) dod(6) 4310 internet(1) security(5) mechanisms(5) pkix(7) 4311 id-mod(0) id-pkix1-explicit(18) } ; 4313 CertificateOrCRL ::= CHOICE { 4314 cert [0] Certificate, 4315 crl [1] CertificateList } 4317 CertificateBundle ::= SEQUENCE OF CertificateOrCRL 4319 END 4321 Implementations MUST be capable of being configured to send and 4322 accept up to four X.509 certificates in support of authentication, 4323 and also MUST be capable of being configured to send and accept the 4324 Hash and URL format (with HTTP URLs). Implementations SHOULD be 4325 capable of being configured to send and accept Raw RSA keys. If 4326 multiple certificates are sent, the first certificate MUST contain 4327 the public key used to sign the AUTH payload. The other certificates 4328 may be sent in any order. 4330 Implementations MUST support the HTTP [HTTP] method for hash-and-URL 4331 lookup. The behavior of other URL methods [URLS] is not currently 4332 specified, and such methods SHOULD NOT be used in the absence of a 4333 document specifying them. 4335 3.7. Certificate Request Payload 4337 The Certificate Request Payload, denoted CERTREQ in this document, 4338 provides a means to request preferred certificates via IKE and can 4339 appear in the IKE_INIT_SA response and/or the IKE_AUTH request. 4340 Certificate Request payloads MAY be included in an exchange when the 4341 sender needs to get the certificate of the receiver. 4343 The Certificate Request Payload is defined as follows: 4345 1 2 3 4346 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 4347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4348 | Next Payload |C| RESERVED | Payload Length | 4349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4350 | Cert Encoding | | 4351 +-+-+-+-+-+-+-+-+ | 4352 ~ Certification Authority ~ 4353 | | 4354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4356 Figure 13: Certificate Request Payload Format 4358 o Certificate Encoding (1 octet) - Contains an encoding of the type 4359 or format of certificate requested. Values are listed in 4360 Section 3.6. 4362 o Certification Authority (variable length) - Contains an encoding 4363 of an acceptable certification authority for the type of 4364 certificate requested. 4366 The payload type for the Certificate Request Payload is thirty eight 4367 (38). 4369 The Certificate Encoding field has the same values as those defined 4370 in Section 3.6. The Certification Authority field contains an 4371 indicator of trusted authorities for this certificate type. The 4372 Certification Authority value is a concatenated list of SHA-1 hashes 4373 of the public keys of trusted Certification Authorities (CAs). Each 4374 is encoded as the SHA-1 hash of the Subject Public Key Info element 4375 (see section 4.1.2.7 of [PKIX]) from each Trust Anchor certificate. 4376 The twenty-octet hashes are concatenated and included with no other 4377 formatting. 4379 The contents of the "Certification Authority" field are defined only 4380 for X.509 certificates, which are types 4, 12, and 13. Other values 4381 SHOULD NOT be used until standards-track specifications that specify 4382 their use are published. 4384 Note that the term "Certificate Request" is somewhat misleading, in 4385 that values other than certificates are defined in a "Certificate" 4386 payload and requests for those values can be present in a Certificate 4387 Request Payload. The syntax of the Certificate Request payload in 4388 such cases is not defined in this document. 4390 The Certificate Request Payload is processed by inspecting the "Cert 4391 Encoding" field to determine whether the processor has any 4392 certificates of this type. If so, the "Certification Authority" 4393 field is inspected to determine if the processor has any certificates 4394 that can be validated up to one of the specified certification 4395 authorities. This can be a chain of certificates. 4397 If an end-entity certificate exists that satisfies the criteria 4398 specified in the CERTREQ, a certificate or certificate chain SHOULD 4399 be sent back to the certificate requestor if the recipient of the 4400 CERTREQ: 4402 o is configured to use certificate authentication, 4404 o is allowed to send a CERT payload, 4406 o has matching CA trust policy governing the current negotiation, 4407 and 4409 o has at least one time-wise and usage appropriate end-entity 4410 certificate chaining to a CA provided in the CERTREQ. 4412 Certificate revocation checking must be considered during the 4413 chaining process used to select a certificate. Note that even if two 4414 peers are configured to use two different CAs, cross-certification 4415 relationships should be supported by appropriate selection logic. 4417 The intent is not to prevent communication through the strict 4418 adherence of selection of a certificate based on CERTREQ, when an 4419 alternate certificate could be selected by the sender that would 4420 still enable the recipient to successfully validate and trust it 4421 through trust conveyed by cross-certification, CRLs, or other out-of- 4422 band configured means. Thus, the processing of a CERTREQ should be 4423 seen as a suggestion for a certificate to select, not a mandated one. 4424 If no certificates exist, then the CERTREQ is ignored. This is not 4425 an error condition of the protocol. There may be cases where there 4426 is a preferred CA sent in the CERTREQ, but an alternate might be 4427 acceptable (perhaps after prompting a human operator). 4429 The HTTP_CERT_LOOKUP_SUPPORTED notification MAY be included in any 4430 message that can include a CERTREQ payload and indicates that the 4431 sender is capable of looking up certificates based on an HTTP-based 4432 URL (and hence presumably would prefer to receive certificate 4433 specifications in that format). 4435 3.8. Authentication Payload 4437 The Authentication Payload, denoted AUTH in this document, contains 4438 data used for authentication purposes. The syntax of the 4439 Authentication data varies according to the Auth Method as specified 4440 below. 4442 The Authentication Payload is defined as follows: 4444 1 2 3 4445 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 4446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4447 | Next Payload |C| RESERVED | Payload Length | 4448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4449 | Auth Method | RESERVED | 4450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4451 | | 4452 ~ Authentication Data ~ 4453 | | 4454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4456 Figure 14: Authentication Payload Format 4458 o Auth Method (1 octet) - Specifies the method of authentication 4459 used. The types of signatures are listed here. The values in the 4460 following table are only current as of the publication date of RFC 4461 4306. Other values may have been added since then or will be 4462 added after the publication of this document. Readers should 4463 refer to [IKEV2IANA] for the latest values. 4465 Mechanism Value 4466 ----------------------------------------------------------------- 4467 RSA Digital Signature 1 4468 Computed as specified in Section 2.15 using an RSA private key 4469 with RSASSA-PKCS1-v1_5 signature scheme specified in [PKCS1] 4470 (implementors should note that IKEv1 used a different method for 4471 RSA signatures). To promote interoperability, implementations 4472 that support this type SHOULD support signatures that use SHA-1 4473 as the hash function and SHOULD use SHA-1 as the default hash 4474 function when generating signatures. Implementations can use the 4475 certificates received from a given peer as a hint for selecting a 4476 mutually-understood hash function for the AUTH payload signature. 4477 Note, however, that the hash algorithm used in the AUTH payload 4478 signature doesn't have to be the same as any hash algorithm(s) 4479 used in the certificate(s). 4481 Shared Key Message Integrity Code 2 4482 Computed as specified in Section 2.15 using the shared key 4483 associated with the identity in the ID payload and the negotiated 4484 PRF. 4486 DSS Digital Signature 3 4487 Computed as specified in Section 2.15 using a DSS private key 4488 (see [DSS]) over a SHA-1 hash. 4490 o Authentication Data (variable length) - see Section 2.15. 4492 The payload type for the Authentication Payload is thirty nine (39). 4494 3.9. Nonce Payload 4496 The Nonce Payload, denoted Ni and Nr in this document for the 4497 initiator's and responder's nonce respectively, contains random data 4498 used to guarantee liveness during an exchange and protect against 4499 replay attacks. 4501 The Nonce Payload is defined as follows: 4503 1 2 3 4504 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 4505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4506 | Next Payload |C| RESERVED | Payload Length | 4507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4508 | | 4509 ~ Nonce Data ~ 4510 | | 4511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4513 Figure 15: Nonce Payload Format 4515 o Nonce Data (variable length) - Contains the random data generated 4516 by the transmitting entity. 4518 The payload type for the Nonce Payload is forty (40). 4520 The size of the Nonce Data MUST be between 16 and 256 octets 4521 inclusive. Nonce values MUST NOT be reused. 4523 3.10. Notify Payload 4525 The Notify Payload, denoted N in this document, is used to transmit 4526 informational data, such as error conditions and state transitions, 4527 to an IKE peer. A Notify Payload may appear in a response message 4528 (usually specifying why a request was rejected), in an INFORMATIONAL 4529 Exchange (to report an error not in an IKE request), or in any other 4530 message to indicate sender capabilities or to modify the meaning of 4531 the request. 4533 The Notify Payload is defined as follows: 4535 1 2 3 4536 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 4537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4538 | Next Payload |C| RESERVED | Payload Length | 4539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4540 | Protocol ID | SPI Size | Notify Message Type | 4541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4542 | | 4543 ~ Security Parameter Index (SPI) ~ 4544 | | 4545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4546 | | 4547 ~ Notification Data ~ 4548 | | 4549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4551 Figure 16: Notify Payload Format 4553 o Protocol ID (1 octet) - If this notification concerns an existing 4554 SA whose SPI is given in the SPI field, this field indicates the 4555 type of that SA. For notifications concerning Child SAs this 4556 field MUST contain either (2) to indicate AH or (3) to indicate 4557 ESP. Of the notifications defined in this document, the SPI is 4558 included only with INVALID_SELECTORS and REKEY_SA. If the SPI 4559 field is empty, this field MUST be sent as zero and MUST be 4560 ignored on receipt. 4562 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 4563 IPsec protocol ID or zero if no SPI is applicable. For a 4564 notification concerning the IKE SA, the SPI Size MUST be zero and 4565 the field must be empty. 4567 o Notify Message Type (2 octets) - Specifies the type of 4568 notification message. 4570 o SPI (variable length) - Security Parameter Index. 4572 o Notification Data (variable length) - Status or error data 4573 transmitted in addition to the Notify Message Type. Values for 4574 this field are type specific (see below). 4576 The payload type for the Notify Payload is forty one (41). 4578 3.10.1. Notify Message Types 4580 Notification information can be error messages specifying why an SA 4581 could not be established. It can also be status data that a process 4582 managing an SA database wishes to communicate with a peer process. 4583 The table below lists the Notification messages and their 4584 corresponding values. The number of different error statuses was 4585 greatly reduced from IKEv1 both for simplification and to avoid 4586 giving configuration information to probers. 4588 Types in the range 0 - 16383 are intended for reporting errors. An 4589 implementation receiving a Notify payload with one of these types 4590 that it does not recognize in a response MUST assume that the 4591 corresponding request has failed entirely. Unrecognized error types 4592 in a request and status types in a request or response MUST be 4593 ignored, and they should be logged. 4595 Notify payloads with status types MAY be added to any message and 4596 MUST be ignored if not recognized. They are intended to indicate 4597 capabilities, and as part of SA negotiation are used to negotiate 4598 non-cryptographic parameters. 4600 More information on error handling can be found in Section 2.21. 4602 The values in the following table are only current as of the 4603 publication date of RFC 4306, plus two error types added in this 4604 document. Other values may have been added since then or will be 4605 added after the publication of this document. Readers should refer 4606 to [IKEV2IANA] for the latest values. 4608 NOTIFY messages: error types Value 4609 ------------------------------------------------------------------- 4610 UNSUPPORTED_CRITICAL_PAYLOAD 1 4611 See Section 2.5. 4613 INVALID_IKE_SPI 4 4614 See Section 2.21. 4616 INVALID_MAJOR_VERSION 5 4617 See Section 2.5. 4619 INVALID_SYNTAX 7 4620 Indicates the IKE message that was received was invalid because 4621 some type, length, or value was out of range or because the 4622 request was rejected for policy reasons. To avoid a DoS 4623 attack using forged messages, this status may only be 4624 returned for and in an encrypted packet if the message ID and 4625 cryptographic checksum were valid. To avoid leaking information 4626 to someone probing a node, this status MUST be sent in response 4627 to any error not covered by one of the other status types. 4628 To aid debugging, more detailed error information should be 4629 written to a console or log. 4631 INVALID_MESSAGE_ID 9 4632 See Section 2.3. 4634 INVALID_SPI 11 4635 See Section 1.5. 4637 NO_PROPOSAL_CHOSEN 14 4638 None of the proposed crypto suites was acceptable. This can be 4639 sent in any case where the offered proposals (including but not 4640 limited to SA payload values, USE_TRANSPORT_MODE notify, 4641 IPCOMP_SUPPORTED notify) are not acceptable for the responder. 4642 This can also be used as "generic" Child SA error when Child SA 4643 cannot be created for some other reason. See also Section 2.7. 4645 INVALID_KE_PAYLOAD 17 4646 See Section 1.2 and 1.3. 4648 AUTHENTICATION_FAILED 24 4649 Sent in the response to an IKE_AUTH message when for some reason 4650 the authentication failed. There is no associated data. See also 4651 Section 2.21.2. 4653 SINGLE_PAIR_REQUIRED 34 4654 See Section 2.9. 4656 NO_ADDITIONAL_SAS 35 4657 See Section 1.3. 4659 INTERNAL_ADDRESS_FAILURE 36 4660 See Section 3.15.4. 4662 FAILED_CP_REQUIRED 37 4663 See Section 2.19. 4665 TS_UNACCEPTABLE 38 4666 See Section 2.9. 4668 INVALID_SELECTORS 39 4669 MAY be sent in an IKE INFORMATIONAL exchange when a node receives 4670 an ESP or AH packet whose selectors do not match those of the SA 4671 on which it was delivered (and that caused the packet to be 4672 dropped). The Notification Data contains the start of the 4673 offending packet (as in ICMP messages) and the SPI field of the 4674 notification is set to match the SPI of the Child SA. 4676 TEMPORARY_FAILURE {TBA1} 4677 See section 2.25. 4679 CHILD_SA_NOT_FOUND {TBA2} 4680 See section 2.25. 4682 NOTIFY messages: status types Value 4683 ------------------------------------------------------------------- 4684 INITIAL_CONTACT 16384 4685 See Section 2.4. 4687 SET_WINDOW_SIZE 16385 4688 See Section 2.3. 4690 ADDITIONAL_TS_POSSIBLE 16386 4691 See Section 2.9. 4693 IPCOMP_SUPPORTED 16387 4694 See Section 2.22. 4696 NAT_DETECTION_SOURCE_IP 16388 4697 See Section 2.23. 4699 NAT_DETECTION_DESTINATION_IP 16389 4700 See Section 2.23. 4702 COOKIE 16390 4703 See Section 2.6. 4705 USE_TRANSPORT_MODE 16391 4706 See Section 1.3.1. 4708 HTTP_CERT_LOOKUP_SUPPORTED 16392 4709 See Section 3.6. 4711 REKEY_SA 16393 4712 See Section 1.3.3. 4714 ESP_TFC_PADDING_NOT_SUPPORTED 16394 4715 See Section 1.3.1. 4717 NON_FIRST_FRAGMENTS_ALSO 16395 4718 See Section 1.3.1. 4720 3.11. Delete Payload 4722 The Delete Payload, denoted D in this document, contains a protocol 4723 specific security association identifier that the sender has removed 4724 from its security association database and is, therefore, no longer 4725 valid. Figure 17 shows the format of the Delete Payload. It is 4726 possible to send multiple SPIs in a Delete payload; however, each SPI 4727 MUST be for the same protocol. Mixing of protocol identifiers MUST 4728 NOT be performed in the Delete payload. It is permitted, however, to 4729 include multiple Delete payloads in a single INFORMATIONAL exchange 4730 where each Delete payload lists SPIs for a different protocol. 4732 Deletion of the IKE SA is indicated by a protocol ID of 1 (IKE) but 4733 no SPIs. Deletion of a Child SA, such as ESP or AH, will contain the 4734 IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI 4735 is the SPI the sending endpoint would expect in inbound ESP or AH 4736 packets. 4738 The Delete Payload is defined as follows: 4740 1 2 3 4741 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 4742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4743 | Next Payload |C| RESERVED | Payload Length | 4744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4745 | Protocol ID | SPI Size | Num of SPIs | 4746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4747 | | 4748 ~ Security Parameter Index(es) (SPI) ~ 4749 | | 4750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4752 Figure 17: Delete Payload Format 4754 o Protocol ID (1 octet) - Must be 1 for an IKE SA, 2 for AH, or 3 4755 for ESP. 4757 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 4758 protocol ID. It MUST be zero for IKE (SPI is in message header) 4759 or four for AH and ESP. 4761 o Num of SPIs (2 octets, unsigned integer) - The number of SPIs 4762 contained in the Delete payload. The size of each SPI is defined 4763 by the SPI Size field. 4765 o Security Parameter Index(es) (variable length) - Identifies the 4766 specific security association(s) to delete. The length of this 4767 field is determined by the SPI Size and Num of SPIs fields. 4769 The payload type for the Delete Payload is forty two (42). 4771 3.12. Vendor ID Payload 4773 The Vendor ID Payload, denoted V in this document, contains a vendor 4774 defined constant. The constant is used by vendors to identify and 4775 recognize remote instances of their implementations. This mechanism 4776 allows a vendor to experiment with new features while maintaining 4777 backward compatibility. 4779 A Vendor ID payload MAY announce that the sender is capable of 4780 accepting certain extensions to the protocol, or it MAY simply 4781 identify the implementation as an aid in debugging. A Vendor ID 4782 payload MUST NOT change the interpretation of any information defined 4783 in this specification (i.e., the critical bit MUST be set to 0). 4784 Multiple Vendor ID payloads MAY be sent. An implementation is not 4785 required to send any Vendor ID payload at all. 4787 A Vendor ID payload may be sent as part of any message. Reception of 4788 a familiar Vendor ID payload allows an implementation to make use of 4789 private use numbers described throughout this document, such as 4790 private payloads, private exchanges, private notifications, etc. 4791 Unfamiliar Vendor IDs MUST be ignored. 4793 Writers of Internet-Drafts who wish to extend this protocol MUST 4794 define a Vendor ID payload to announce the ability to implement the 4795 extension in the Internet-Draft. It is expected that Internet-Drafts 4796 that gain acceptance and are standardized will be given "magic 4797 numbers" out of the Future Use range by IANA, and the requirement to 4798 use a Vendor ID will go away. 4800 The Vendor ID Payload fields are defined as follows: 4802 1 2 3 4803 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 4804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4805 | Next Payload |C| RESERVED | Payload Length | 4806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4807 | | 4808 ~ Vendor ID (VID) ~ 4809 | | 4810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4812 Figure 18: Vendor ID Payload Format 4814 o Vendor ID (variable length) - It is the responsibility of the 4815 person choosing the Vendor ID to assure its uniqueness in spite of 4816 the absence of any central registry for IDs. Good practice is to 4817 include a company name, a person name, or some such. If you want 4818 to show off, you might include the latitude and longitude and time 4819 where you were when you chose the ID and some random input. A 4820 message digest of a long unique string is preferable to the long 4821 unique string itself. 4823 The payload type for the Vendor ID Payload is forty three (43). 4825 3.13. Traffic Selector Payload 4827 The Traffic Selector Payload, denoted TS in this document, allows 4828 peers to identify packet flows for processing by IPsec security 4829 services. The Traffic Selector Payload consists of the IKE generic 4830 payload header followed by individual traffic selectors as follows: 4832 1 2 3 4833 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 4834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4835 | Next Payload |C| RESERVED | Payload Length | 4836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4837 | Number of TSs | RESERVED | 4838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4839 | | 4840 ~ ~ 4841 | | 4842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4844 Figure 19: Traffic Selectors Payload Format 4846 o Number of TSs (1 octet) - Number of traffic selectors being 4847 provided. 4849 o RESERVED - This field MUST be sent as zero and MUST be ignored on 4850 receipt. 4852 o Traffic Selectors (variable length) - One or more individual 4853 traffic selectors. 4855 The length of the Traffic Selector payload includes the TS header and 4856 all the traffic selectors. 4858 The payload type for the Traffic Selector payload is forty four (44) 4859 for addresses at the initiator's end of the SA and forty five (45) 4860 for addresses at the responder's end. 4862 There is no requirement that TSi and TSr contain the same number of 4863 individual traffic selectors. Thus, they are interpreted as follows: 4864 a packet matches a given TSi/TSr if it matches at least one of the 4865 individual selectors in TSi, and at least one of the individual 4866 selectors in TSr. 4868 For instance, the following traffic selectors: 4870 TSi = ((17, 100, 198.51.100.66-198.51.100.66), 4871 (17, 200, 198.51.100.66-198.51.100.66)) 4872 TSr = ((17, 300, 0.0.0.0-255.255.255.255), 4873 (17, 400, 0.0.0.0-255.255.255.255)) 4875 would match UDP packets from 198.51.100.66 to anywhere, with any of 4876 the four combinations of source/destination ports (100,300), 4877 (100,400), (200,300), and (200, 400). 4879 Thus, some types of policies may require several Child SA pairs. For 4880 instance, a policy matching only source/destination ports (100,300) 4881 and (200,400), but not the other two combinations, cannot be 4882 negotiated as a single Child SA pair. 4884 3.13.1. Traffic Selector 4886 1 2 3 4887 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 4888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4889 | TS Type |IP Protocol ID*| Selector Length | 4890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4891 | Start Port* | End Port* | 4892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4893 | | 4894 ~ Starting Address* ~ 4895 | | 4896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4897 | | 4898 ~ Ending Address* ~ 4899 | | 4900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4902 Figure 20: Traffic Selector 4904 *Note: All fields other than TS Type and Selector Length depend on 4905 the TS Type. The fields shown are for TS Types 7 and 8, the only two 4906 values currently defined. 4908 o TS Type (one octet) - Specifies the type of traffic selector. 4910 o IP protocol ID (1 octet) - Value specifying an associated IP 4911 protocol ID (such as UDP, TCP, and ICMP). A value of zero means 4912 that the protocol ID is not relevant to this traffic selector-- 4913 the SA can carry all protocols. 4915 o Selector Length - Specifies the length of this Traffic Selector 4916 substructure including the header. 4918 o Start Port (2 octets, unsigned integer) - Value specifying the 4919 smallest port number allowed by this traffic selector. For 4920 protocols for which port is undefined (including protocol 0), or 4921 if all ports are allowed, this field MUST be zero. ICMP and 4922 ICMPv6 Type and Code values, as well as MIPv6 MH Type values, are 4923 represented in this field as specified in Section 4.4.1.1 of 4924 [IPSECARCH]. ICMP Type and Code values are treated as a single 4925 16-bit integer port number, with Type in the most significant 4926 eight bits and Code in the least significant eight bits. MIPv6 MH 4927 Type values are treated as a single 16-bit integer port number, 4928 with Type in the most significant eight bits and the least 4929 significant eight bits set to zero. 4931 o End Port (2 octets, unsigned integer) - Value specifying the 4932 largest port number allowed by this traffic selector. For 4933 protocols for which port is undefined (including protocol 0), or 4934 if all ports are allowed, this field MUST be 65535. ICMP and 4935 ICMPv6 Type and Code values, as well as MIPv6 MH Type values, are 4936 represented in this field as specified in Section 4.4.1.1 of 4937 [IPSECARCH]. ICMP Type and Code values are treated as a single 4938 16-bit integer port number, with Type in the most significant 4939 eight bits and Code in the least significant eight bits. MIPv6 MH 4940 Type values are treated as a single 16-bit integer port number, 4941 with Type in the most significant eight bits and the least 4942 significant eight bits set to zero. 4944 o Starting Address - The smallest address included in this Traffic 4945 Selector (length determined by TS type). 4947 o Ending Address - The largest address included in this Traffic 4948 Selector (length determined by TS type). 4950 Systems that are complying with [IPSECARCH] that wish to indicate 4951 "ANY" ports MUST set the start port to 0 and the end port to 65535; 4952 note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems 4953 working with [IPSECARCH] that wish to indicate "OPAQUE" ports, but 4954 not "ANY" ports, MUST set the start port to 65535 and the end port to 4955 0. 4957 The traffic selector types 7 and 8 can also refer to ICMP or ICMPv6 4958 type and code fields, as well as MH Type fields for the IPv6 mobility 4959 header [MIPV6]. Note, however, that neither ICMP nor MIPv6 packets 4960 have separate source and destination fields. The method for 4961 specifying the traffic selectors for ICMP and MIPv6 is shown by 4962 example in Section 4.4.1.3 of [IPSECARCH]. 4964 The following table lists values for the Traffic Selector Type field 4965 and the corresponding Address Selector Data. The values in the 4966 following table are only current as of the publication date of RFC 4967 4306. Other values may have been added since then or will be added 4968 after the publication of this document. Readers should refer to 4969 [IKEV2IANA] for the latest values. 4971 TS Type Value 4972 ------------------------------------------------------------------- 4973 TS_IPV4_ADDR_RANGE 7 4975 A range of IPv4 addresses, represented by two four-octet 4976 values. The first value is the beginning IPv4 address 4977 (inclusive) and the second value is the ending IPv4 address 4978 (inclusive). All addresses falling between the two specified 4979 addresses are considered to be within the list. 4981 TS_IPV6_ADDR_RANGE 8 4983 A range of IPv6 addresses, represented by two sixteen-octet 4984 values. The first value is the beginning IPv6 address 4985 (inclusive) and the second value is the ending IPv6 address 4986 (inclusive). All addresses falling between the two specified 4987 addresses are considered to be within the list. 4989 3.14. Encrypted Payload 4991 The Encrypted Payload, denoted SK{...} in this document, contains 4992 other payloads in encrypted form. The Encrypted Payload, if present 4993 in a message, MUST be the last payload in the message. Often, it is 4994 the only payload in the message. This payload is also called the 4995 "Encrypted and Authenticated" payload. 4997 The algorithms for encryption and integrity protection are negotiated 4998 during IKE SA setup, and the keys are computed as specified in 4999 Section 2.14 and Section 2.18. 5001 This document specifies the cryptographic processing of Encrypted 5002 payloads using a block cipher in CBC mode and an integrity check 5003 algorithm that computes a fixed-length checksum over a variable size 5004 message. The design is modeled after the ESP algorithms described in 5005 RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document 5006 completely specifies the cryptographic processing of IKE data, but 5007 those documents should be consulted for design rationale. Future 5008 documents may specify the processing of Encrypted payloads for other 5009 types of transforms, such as counter mode encryption and 5010 authenticated encryption algorithms. Peers MUST NOT negotiate 5011 transforms for which no such specification exists. 5013 When an authenticated encryption algorithm is used to protect the IKE 5014 SA, the construction of the encrypted payload is different than what 5015 is described here. See [AEAD] for more information on authenticated 5016 encryption algorithms and their use in ESP. 5018 The payload type for an Encrypted payload is forty six (46). The 5019 Encrypted Payload consists of the IKE generic payload header followed 5020 by individual fields as follows: 5022 1 2 3 5023 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 5024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5025 | Next Payload |C| RESERVED | Payload Length | 5026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5027 | Initialization Vector | 5028 | (length is block size for encryption algorithm) | 5029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5030 ~ Encrypted IKE Payloads ~ 5031 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5032 | | Padding (0-255 octets) | 5033 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 5034 | | Pad Length | 5035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5036 ~ Integrity Checksum Data ~ 5037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5039 Figure 21: Encrypted Payload Format 5041 o Next Payload - The payload type of the first embedded payload. 5042 Note that this is an exception in the standard header format, 5043 since the Encrypted payload is the last payload in the message and 5044 therefore the Next Payload field would normally be zero. But 5045 because the content of this payload is embedded payloads and there 5046 was no natural place to put the type of the first one, that type 5047 is placed here. 5049 o Payload Length - Includes the lengths of the header, IV, Encrypted 5050 IKE Payloads, Padding, Pad Length, and Integrity Checksum Data. 5052 o Initialization Vector - For CBC mode ciphers, the length of the 5053 initialization vector (IV) is equal to the block length of the 5054 underlying encryption algorithm. Senders MUST select a new 5055 unpredictable IV for every message; recipients MUST accept any 5056 value. The reader is encouraged to consult [MODES] for advice on 5057 IV generation. In particular, using the final ciphertext block of 5058 the previous message is not considered unpredictable. For modes 5059 other than CBC, the IV format and processing is specified in the 5060 document specifying the encryption algorithm and mode. 5062 o IKE Payloads are as specified earlier in this section. This field 5063 is encrypted with the negotiated cipher. 5065 o Padding MAY contain any value chosen by the sender, and MUST have 5066 a length that makes the combination of the Payloads, the Padding, 5067 and the Pad Length to be a multiple of the encryption block size. 5068 This field is encrypted with the negotiated cipher. 5070 o Pad Length is the length of the Padding field. The sender SHOULD 5071 set the Pad Length to the minimum value that makes the combination 5072 of the Payloads, the Padding, and the Pad Length a multiple of the 5073 block size, but the recipient MUST accept any length that results 5074 in proper alignment. This field is encrypted with the negotiated 5075 cipher. 5077 o Integrity Checksum Data is the cryptographic checksum of the 5078 entire message starting with the Fixed IKE Header through the Pad 5079 Length. The checksum MUST be computed over the encrypted message. 5080 Its length is determined by the integrity algorithm negotiated. 5082 3.15. Configuration Payload 5084 The Configuration payload, denoted CP in this document, is used to 5085 exchange configuration information between IKE peers. The exchange 5086 is for an IRAC to request an internal IP address from an IRAS and to 5087 exchange other information of the sort that one would acquire with 5088 Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly 5089 connected to a LAN. 5091 The Configuration Payload is defined as follows: 5093 1 2 3 5094 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 5095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5096 | Next Payload |C| RESERVED | Payload Length | 5097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5098 | CFG Type | RESERVED | 5099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5100 | | 5101 ~ Configuration Attributes ~ 5102 | | 5103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5105 Figure 22: Configuration Payload Format 5107 The payload type for the Configuration Payload is forty seven (47). 5109 o CFG Type (1 octet) - The type of exchange represented by the 5110 Configuration Attributes. The values in the following table are 5111 only current as of the publication date of RFC 4306. Other values 5112 may have been added since then or will be added after the 5113 publication of this document. Readers should refer to [IKEV2IANA] 5114 for the latest values. 5116 CFG Type Value 5117 -------------------------- 5118 CFG_REQUEST 1 5119 CFG_REPLY 2 5120 CFG_SET 3 5121 CFG_ACK 4 5123 o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on 5124 receipt. 5126 o Configuration Attributes (variable length) - These are type length 5127 value (TLV) structures specific to the Configuration Payload and 5128 are defined below. There may be zero or more Configuration 5129 Attributes in this payload. 5131 3.15.1. Configuration Attributes 5133 1 2 3 5134 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 5135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5136 |R| Attribute Type | Length | 5137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5138 | | 5139 ~ Value ~ 5140 | | 5141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5143 Figure 23: Configuration Attribute Format 5145 o Reserved (1 bit) - This bit MUST be set to zero and MUST be 5146 ignored on receipt. 5148 o Attribute Type (15 bits) - A unique identifier for each of the 5149 Configuration Attribute Types. 5151 o Length (2 octets, unsigned integer) - Length in octets of Value. 5153 o Value (0 or more octets) - The variable-length value of this 5154 Configuration Attribute. The following lists the attribute types. 5156 The values in the following table are only current as of the 5157 publication date of RFC 4306 (except INTERNAL_ADDRESS_EXPIRY and 5158 INTERNAL_IP6_NBNS which were removed by this document). Other values 5159 may have been added since then or will be added after the publication 5160 of this document. Readers should refer to [IKEV2IANA] for the latest 5161 values. 5163 Attribute Type Value Multi-Valued Length 5164 ------------------------------------------------------------ 5165 INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets 5166 INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets 5167 INTERNAL_IP4_DNS 3 YES 0 or 4 octets 5168 INTERNAL_IP4_NBNS 4 YES 0 or 4 octets 5169 INTERNAL_IP4_DHCP 6 YES 0 or 4 octets 5170 APPLICATION_VERSION 7 NO 0 or more 5171 INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets 5172 INTERNAL_IP6_DNS 10 YES 0 or 16 octets 5173 INTERNAL_IP6_DHCP 12 YES 0 or 16 octets 5174 INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets 5175 SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 5176 INTERNAL_IP6_SUBNET 15 YES 17 octets 5178 * These attributes may be multi-valued on return only if 5179 multiple values were requested. 5181 o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the 5182 internal network, sometimes called a red node address or private 5183 address and MAY be a private address on the Internet. In a 5184 request message, the address specified is a requested address (or 5185 a zero-length address if no specific address is requested). If a 5186 specific address is requested, it likely indicates that a previous 5187 connection existed with this address and the requestor would like 5188 to reuse that address. With IPv6, a requestor MAY supply the low- 5189 order address octets it wants to use. Multiple internal addresses 5190 MAY be requested by requesting multiple internal address 5191 attributes. The responder MAY only send up to the number of 5192 addresses requested. The INTERNAL_IP6_ADDRESS is made up of two 5193 fields: the first is a 16-octet IPv6 address, and the second is a 5194 one-octet prefix-length as defined in [ADDRIPV6]. The requested 5195 address is valid as long as this IKE SA (or its rekeyed 5196 successors) requesting the address is valid. This is described in 5197 more detail in Section 3.15.3. 5199 o INTERNAL_IP4_NETMASK - The internal network's netmask. Only one 5200 netmask is allowed in the request and response messages (e.g., 5201 255.255.255.0), and it MUST be used only with an 5202 INTERNAL_IP4_ADDRESS attribute. INTERNAL_IP4_NETMASK in a 5203 CFG_REPLY means roughly the same thing as INTERNAL_IP4_SUBNET 5204 containing the same information ("send traffic to these addresses 5205 through me"), but also implies a link boundary. For instance, the 5206 client could use its own address and the netmask to calculate the 5207 broadcast address of the link. An empty INTERNAL_IP4_NETMASK 5208 attribute can be included in a CFG_REQUEST to request this 5209 information (although the gateway can send the information even 5210 when not requested). Non-empty values for this attribute in a 5211 CFG_REQUEST do not make sense and thus MUST NOT be included. 5213 o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS 5214 server within the network. Multiple DNS servers MAY be requested. 5215 The responder MAY respond with zero or more DNS server attributes. 5217 o INTERNAL_IP4_NBNS - Specifies an address of a NetBios Name Server 5218 (WINS) within the network. Multiple NBNS servers MAY be 5219 requested. The responder MAY respond with zero or more NBNS 5220 server attributes. 5222 o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send 5223 any internal DHCP requests to the address contained within the 5224 attribute. Multiple DHCP servers MAY be requested. The responder 5225 MAY respond with zero or more DHCP server attributes. 5227 o APPLICATION_VERSION - The version or application information of 5228 the IPsec host. This is a string of printable ASCII characters 5229 that is NOT null terminated. 5231 o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge- 5232 device protects. This attribute is made up of two fields: the 5233 first being an IP address and the second being a netmask. 5234 Multiple sub-networks MAY be requested. The responder MAY respond 5235 with zero or more sub-network attributes. This is discussed in 5236 more detail in Section 3.15.2. 5238 o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute 5239 MUST be zero-length and specifies a query to the responder to 5240 reply back with all of the attributes that it supports. The 5241 response contains an attribute that contains a set of attribute 5242 identifiers each in 2 octets. The length divided by 2 (octets) 5243 would state the number of supported attributes contained in the 5244 response. 5246 o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge- 5247 device protects. This attribute is made up of two fields: the 5248 first is a 16-octet IPv6 address, and the second is a one-octet 5249 prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY 5250 be requested. The responder MAY respond with zero or more sub- 5251 network attributes. This is discussed in more detail in 5252 Section 3.15.2. 5254 Note that no recommendations are made in this document as to how an 5255 implementation actually figures out what information to send in a 5256 response. That is, we do not recommend any specific method of an 5257 IRAS determining which DNS server should be returned to a requesting 5258 IRAC. 5260 The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request 5261 information from its peer. If an attribute in the CFG_REQUEST 5262 Configuration Payload is not zero-length, it is taken as a suggestion 5263 for that attribute. The CFG_REPLY Configuration Payload MAY return 5264 that value, or a new one. It MAY also add new attributes and not 5265 include some requested ones. Unrecognized or unsupported attributes 5266 MUST be ignored in both requests and responses. 5268 The CFG_SET and CFG_ACK pair allows an IKE endpoint to push 5269 configuration data to its peer. In this case, the CFG_SET 5270 Configuration Payload contains attributes the initiator wants its 5271 peer to alter. The responder MUST return a Configuration Payload if 5272 it accepted any of the configuration data and it MUST contain the 5273 attributes that the responder accepted with zero-length data. Those 5274 attributes that it did not accept MUST NOT be in the CFG_ACK 5275 Configuration Payload. If no attributes were accepted, the responder 5276 MUST return either an empty CFG_ACK payload or a response message 5277 without a CFG_ACK payload. There are currently no defined uses for 5278 the CFG_SET/CFG_ACK exchange, though they may be used in connection 5279 with extensions based on Vendor IDs. An implementation of this 5280 specification MAY ignore CFG_SET payloads. 5282 3.15.2. Meaning of INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET 5284 INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets, 5285 ones that need one or more separate SAs, that can be reached through 5286 the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET 5287 attributes may also express the gateway's policy about what traffic 5288 should be sent through the gateway; the client can choose whether 5289 other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is 5290 sent through the gateway or directly to the destination. Thus, 5291 traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET 5292 attributes should be sent through the gateway that announces the 5293 attributes. If there are no existing Child SAs whose traffic 5294 selectors cover the address in question, new SAs need to be created. 5296 For instance, if there are two subnets, 198.51.100.0/26 and 5297 192.0.2.0/24, and the client's request contains the following: 5299 CP(CFG_REQUEST) = 5300 INTERNAL_IP4_ADDRESS() 5301 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) 5302 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) 5304 then a valid response could be the following (in which TSr and 5305 INTERNAL_IP4_SUBNET contain the same information): 5307 CP(CFG_REPLY) = 5308 INTERNAL_IP4_ADDRESS(198.51.100.234) 5309 INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192) 5310 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 5311 TSi = (0, 0-65535, 198.51.100.234-198.51.100.234) 5312 TSr = ((0, 0-65535, 198.51.100.0-198.51.100.63), 5313 (0, 0-65535, 192.0.2.0-192.0.2.255)) 5315 In these cases, the INTERNAL_IP4_SUBNET does not really carry any 5316 useful information. 5318 A different possible response would have been this: 5320 CP(CFG_REPLY) = 5321 INTERNAL_IP4_ADDRESS(198.51.100.234) 5322 INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192) 5323 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 5324 TSi = (0, 0-65535, 198.51.100.234-198.51.100.234) 5325 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) 5327 That response would mean that the client can send all its traffic 5328 through the gateway, but the gateway does not mind if the client 5329 sends traffic not included by INTERNAL_IP4_SUBNET directly to the 5330 destination (without going through the gateway). 5332 A different situation arises if the gateway has a policy that 5333 requires the traffic for the two subnets to be carried in separate 5334 SAs. Then a response like this would indicate to the client that if 5335 it wants access to the second subnet, it needs to create a separate 5336 SA: 5338 CP(CFG_REPLY) = 5339 INTERNAL_IP4_ADDRESS(198.51.100.234) 5340 INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192) 5341 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 5342 TSi = (0, 0-65535, 198.51.100.234-198.51.100.234) 5343 TSr = (0, 0-65535, 198.51.100.0-198.51.100.63) 5345 INTERNAL_IP4_SUBNET can also be useful if the client's TSr included 5346 only part of the address space. For instance, if the client requests 5347 the following: 5349 CP(CFG_REQUEST) = 5350 INTERNAL_IP4_ADDRESS() 5351 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) 5352 TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) 5354 then the gateway's response might be: 5356 CP(CFG_REPLY) = 5357 INTERNAL_IP4_ADDRESS(198.51.100.234) 5358 INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192) 5359 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 5360 TSi = (0, 0-65535, 198.51.100.234-198.51.100.234) 5361 TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) 5363 Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET in 5364 CFG_REQUESTs is unclear, they cannot be used reliably in 5365 CFG_REQUESTs. 5367 3.15.3. Configuration payloads for IPv6 5369 The configuration payloads for IPv6 are based on the corresponding 5370 IPv4 payloads, and do not fully follow the "normal IPv6 way of doing 5371 things". In particular, IPv6 stateless autoconfiguration or router 5372 advertisement messages are not used; neither is neighbor discovery. 5373 Note that there is an additional document that discusses IPv6 5374 configuration in IKEv2, [IPV6CONFIG]. At the present time, it is an 5375 experimental document, but there is a hope that with more 5376 implementation experience, it will gain the same standards treatment 5377 as this document. 5379 A client can be assigned an IPv6 address using the 5380 INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange might 5381 look like this: 5383 CP(CFG_REQUEST) = 5384 INTERNAL_IP6_ADDRESS() 5385 INTERNAL_IP6_DNS() 5386 TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 5387 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 5389 CP(CFG_REPLY) = 5390 INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) 5391 INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) 5392 TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) 5393 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 5395 The client MAY send a non-empty INTERNAL_IP6_ADDRESS attribute in the 5396 CFG_REQUEST to request a specific address or interface identifier. 5397 The gateway first checks if the specified address is acceptable, and 5398 if it is, returns that one. If the address was not acceptable, the 5399 gateway attempts to use the interface identifier with some other 5400 prefix; if even that fails, the gateway selects another interface 5401 identifier. 5403 The INTERNAL_IP6_ADDRESS attribute also contains a prefix length 5404 field. When used in a CFG_REPLY, this corresponds to the 5405 INTERNAL_IP4_NETMASK attribute in the IPv4 case. 5407 Although this approach to configuring IPv6 addresses is reasonably 5408 simple, it has some limitations. IPsec tunnels configured using 5409 IKEv2 are not fully-featured "interfaces" in the IPv6 addressing 5410 architecture sense [ADDRIPV6]. In particular, they do not 5411 necessarily have link-local addresses, and this may complicate the 5412 use of protocols that assume them, such as [MLDV2]. 5414 3.15.4. Address Assignment Failures 5416 If the responder encounters an error while attempting to assign an IP 5417 address to the initiator during the processing of a Configuration 5418 Payload, it responds with an INTERNAL_ADDRESS_FAILURE notification. 5419 The IKE SA is still created even if the initial Child SA cannot be 5420 created because of this failure. If this error is generated within 5421 an IKE_AUTH exchange, no Child SA will be created. However, there 5422 are some more complex error cases. 5424 If the responder does not support configuration payloads at all, it 5425 can simply ignore all configuration payloads. This type of 5426 implementation never sends INTERNAL_ADDRESS_FAILURE notifications. 5427 If the initiator requires the assignment of an IP address, it will 5428 treat a response without CFG_REPLY as an error. 5430 The initiator may request a particular type of address (IPv4 or IPv6) 5431 that the responder does not support, even though the responder 5432 supports configuration payloads. In this case, the responder simply 5433 ignores the type of address it does not support and processes the 5434 rest of the request as usual. 5436 If the initiator requests multiple addresses of a type that the 5437 responder supports, and some (but not all) of the requests fail, the 5438 responder replies with the successful addresses only. The responder 5439 sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned. 5441 If the initiator does not receive the IP address(es) required by its 5442 policy, it MAY keep the IKE SA up and retry the configuration payload 5443 as separate INFORMATIONAL exchange after suitable timeout, or it MAY 5444 tear down the IKE SA by sending a DELETE payload inside a separate 5445 INFORMATIONAL exchange and later retry IKE SA from the beginning 5446 after some timeout. Such a timeout should not be too short 5447 (especially if the IKE SA is started from the beginning) because 5448 these error situations may not be able to be fixed quickly; the 5449 timeout should likely be several minutes. For example, an address 5450 shortage problem on the responder will probably only be fixed when 5451 more entries are returned to the address pool when other clients 5452 disconnect or when responder is reconfigured with larger address 5453 pool. 5455 3.16. Extensible Authentication Protocol (EAP) Payload 5457 The Extensible Authentication Protocol Payload, denoted EAP in this 5458 document, allows IKE SAs to be authenticated using the protocol 5459 defined in RFC 3748 [EAP] and subsequent extensions to that protocol. 5460 When using EAP, an appropriate EAP method needs to be selected. Many 5461 of these methods have been defined, specifying the protocol's use 5462 with various authentication mechanisms. EAP method types are listed 5463 in [EAP-IANA]. A short summary of the EAP format is included here 5464 for clarity. 5466 1 2 3 5467 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 5468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5469 | Next Payload |C| RESERVED | Payload Length | 5470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5471 | | 5472 ~ EAP Message ~ 5473 | | 5474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5476 Figure 24: EAP Payload Format 5478 The payload type for an EAP Payload is forty eight (48). 5480 1 2 3 5481 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 5482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5483 | Code | Identifier | Length | 5484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5485 | Type | Type_Data... 5486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 5488 Figure 25: EAP Message Format 5490 o Code (1 octet) indicates whether this message is a Request (1), 5491 Response (2), Success (3), or Failure (4). 5493 o Identifier (1 octet) is used in PPP to distinguish replayed 5494 messages from repeated ones. Since in IKE, EAP runs over a 5495 reliable protocol, it serves no function here. In a response 5496 message, this octet MUST be set to match the identifier in the 5497 corresponding request. 5499 o Length (2 octets, unsigned integer) is the length of the EAP 5500 message and MUST be four less than the Payload Length of the 5501 encapsulating payload. 5503 o Type (1 octet) is present only if the Code field is Request (1) or 5504 Response (2). For other codes, the EAP message length MUST be 5505 four octets and the Type and Type_Data fields MUST NOT be present. 5506 In a Request (1) message, Type indicates the data being requested. 5507 In a Response (2) message, Type MUST either be Nak or match the 5508 type of the data requested. Note that since IKE passes an 5509 indication of initiator identity in the first message in the 5510 IKE_AUTH exchange, the responder SHOULD NOT send EAP Identity 5511 requests (type 1). The initiator MAY, however, respond to such 5512 requests if it receives them. 5514 o Type_Data (Variable Length) varies with the Type of Request and 5515 the associated Response. For the documentation of the EAP 5516 methods, see [EAP]. 5518 Note that since IKE passes an indication of initiator identity in the 5519 first message in the IKE_AUTH exchange, the responder should not send 5520 EAP Identity requests. The initiator may, however, respond to such 5521 requests if it receives them. 5523 4. Conformance Requirements 5525 In order to assure that all implementations of IKEv2 can 5526 interoperate, there are "MUST support" requirements in addition to 5527 those listed elsewhere. Of course, IKEv2 is a security protocol, and 5528 one of its major functions is to allow only authorized parties to 5529 successfully complete establishment of SAs. So a particular 5530 implementation may be configured with any of a number of restrictions 5531 concerning algorithms and trusted authorities that will prevent 5532 universal interoperability. 5534 IKEv2 is designed to permit minimal implementations that can 5535 interoperate with all compliant implementations. The following are 5536 features that can be omitted in a minimal implementation: 5538 o Ability to negotiate SAs through a NAT and tunnel the resulting 5539 ESP SA over UDP. 5541 o Ability to request (and respond to a request for) a temporary IP 5542 address on the remote end of a tunnel. 5544 o Ability to support EAP-based authentication. 5546 o Ability to support window sizes greater than one. 5548 o Ability to establish multiple ESP or AH SAs within a single IKE 5549 SA. 5551 o Ability to rekey SAs. 5553 To assure interoperability, all implementations MUST be capable of 5554 parsing all payload types (if only to skip over them) and to ignore 5555 payload types that it does not support unless the critical bit is set 5556 in the payload header. If the critical bit is set in an unsupported 5557 payload header, all implementations MUST reject the messages 5558 containing those payloads. 5560 Every implementation MUST be capable of doing four-message 5561 IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, 5562 one for ESP or AH). Implementations MAY be initiate-only or respond- 5563 only if appropriate for their platform. Every implementation MUST be 5564 capable of responding to an INFORMATIONAL exchange, but a minimal 5565 implementation MAY respond to any request in the INFORMATIONAL 5566 exchange with an empty response (note that within the context of an 5567 IKE SA, an "empty" message consists of an IKE header followed by an 5568 Encrypted payload with no payloads contained in it). A minimal 5569 implementation MAY support the CREATE_CHILD_SA exchange only in so 5570 far as to recognize requests and reject them with a Notify payload of 5571 type NO_ADDITIONAL_SAS. A minimal implementation need not be able to 5572 initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA 5573 expires (based on locally configured values of either lifetime or 5574 octets passed), and implementation MAY either try to renew it with a 5575 CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and 5576 create a new one. If the responder rejects the CREATE_CHILD_SA 5577 request with a NO_ADDITIONAL_SAS notification, the implementation 5578 MUST be capable of instead deleting the old SA and creating a new 5579 one. 5581 Implementations are not required to support requesting temporary IP 5582 addresses or responding to such requests. If an implementation does 5583 support issuing such requests and its policy requires using temporary 5584 IP addresses, it MUST include a CP payload in the first message in 5585 the IKE_AUTH exchange containing at least a field of type 5586 INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. All other fields are 5587 optional. If an implementation supports responding to such requests, 5588 it MUST parse the CP payload of type CFG_REQUEST in the first message 5589 in the IKE_AUTH exchange and recognize a field of type 5590 INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports leasing 5591 an address of the appropriate type, it MUST return a CP payload of 5592 type CFG_REPLY containing an address of the requested type. The 5593 responder may include any other related attributes. 5595 For an implementation to be called conforming to this specification, 5596 it MUST be possible to configure it to accept the following: 5598 o PKIX Certificates containing and signed by RSA keys of size 1024 5599 or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, 5600 ID_RFC822_ADDR, or ID_DER_ASN1_DN. 5602 o Shared key authentication where the ID passed is any of ID_KEY_ID, 5603 ID_FQDN, or ID_RFC822_ADDR. 5605 o Authentication where the responder is authenticated using PKIX 5606 Certificates and the initiator is authenticated using shared key 5607 authentication. 5609 5. Security Considerations 5611 While this protocol is designed to minimize disclosure of 5612 configuration information to unauthenticated peers, some such 5613 disclosure is unavoidable. One peer or the other must identify 5614 itself first and prove its identity first. To avoid probing, the 5615 initiator of an exchange is required to identify itself first, and 5616 usually is required to authenticate itself first. The initiator can, 5617 however, learn that the responder supports IKE and what cryptographic 5618 protocols it supports. The responder (or someone impersonating the 5619 responder) can probe the initiator not only for its identity, but 5620 using CERTREQ payloads may be able to determine what certificates the 5621 initiator is willing to use. 5623 Use of EAP authentication changes the probing possibilities somewhat. 5624 When EAP authentication is used, the responder proves its identity 5625 before the initiator does, so an initiator that knew the name of a 5626 valid initiator could probe the responder for both its name and 5627 certificates. 5629 Repeated rekeying using CREATE_CHILD_SA without additional Diffie- 5630 Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a 5631 single key. Implementers should take note of this fact and set a 5632 limit on CREATE_CHILD_SA exchanges between exponentiations. This 5633 document does not prescribe such a limit. 5635 The strength of a key derived from a Diffie-Hellman exchange using 5636 any of the groups defined here depends on the inherent strength of 5637 the group, the size of the exponent used, and the entropy provided by 5638 the random number generator used. Due to these inputs, it is 5639 difficult to determine the strength of a key for any of the defined 5640 groups. Diffie-Hellman group number two, when used with a strong 5641 random number generator and an exponent no less than 200 bits, is 5642 common for use with 3DES. Group five provides greater security than 5643 group two. Group one is for historic purposes only and does not 5644 provide sufficient strength except for use with DES, which is also 5645 for historic use only. Implementations should make note of these 5646 estimates when establishing policy and negotiating security 5647 parameters. 5649 Note that these limitations are on the Diffie-Hellman groups 5650 themselves. There is nothing in IKE that prohibits using stronger 5651 groups nor is there anything that will dilute the strength obtained 5652 from stronger groups (limited by the strength of the other algorithms 5653 negotiated including the PRF). In fact, the extensible framework of 5654 IKE encourages the definition of more groups; use of elliptic curve 5655 groups may greatly increase strength using much smaller numbers. 5657 It is assumed that all Diffie-Hellman exponents are erased from 5658 memory after use. 5660 The IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator 5661 has been authenticated. As a result, an implementation of this 5662 protocol needs to be completely robust when deployed on any insecure 5663 network. Implementation vulnerabilities, particularly DoS attacks, 5664 can be exploited by unauthenticated peers. This issue is 5665 particularly worrisome because of the unlimited number of messages in 5666 EAP-based authentication. 5668 The strength of all keys is limited by the size of the output of the 5669 negotiated PRF. For this reason, a PRF whose output is less than 128 5670 bits (e.g., 3DES-CBC) MUST NOT be used with this protocol. 5672 The security of this protocol is critically dependent on the 5673 randomness of the randomly chosen parameters. These should be 5674 generated by a strong random or properly seeded pseudo-random source 5675 (see [RANDOMNESS]). Implementers should take care to ensure that use 5676 of random numbers for both keys and nonces is engineered in a fashion 5677 that does not undermine the security of the keys. 5679 For information on the rationale of many of the cryptographic design 5680 choices in this protocol, see [SIGMA] and [SKEME]. Though the 5681 security of negotiated Child SAs does not depend on the strength of 5682 the encryption and integrity protection negotiated in the IKE SA, 5683 implementations MUST NOT negotiate NONE as the IKE integrity 5684 protection algorithm or ENCR_NULL as the IKE encryption algorithm. 5686 When using pre-shared keys, a critical consideration is how to assure 5687 the randomness of these secrets. The strongest practice is to ensure 5688 that any pre-shared key contain as much randomness as the strongest 5689 key being negotiated. Deriving a shared secret from a password, 5690 name, or other low-entropy source is not secure. These sources are 5691 subject to dictionary and social engineering attacks, among others. 5693 The NAT_DETECTION_*_IP notifications contain a hash of the addresses 5694 and ports in an attempt to hide internal IP addresses behind a NAT. 5695 Since the IPv4 address space is only 32 bits, and it is usually very 5696 sparse, it would be possible for an attacker to find out the internal 5697 address used behind the NAT box by trying all possible IP addresses 5698 and trying to find the matching hash. The port numbers are normally 5699 fixed to 500, and the SPIs can be extracted from the packet. This 5700 reduces the number of hash calculations to 2^32. With an educated 5701 guess of the use of private address space, the number of hash 5702 calculations is much smaller. Designers should therefore not assume 5703 that use of IKE will not leak internal address information. 5705 When using an EAP authentication method that does not generate a 5706 shared key for protecting a subsequent AUTH payload, certain man-in- 5707 the-middle and server impersonation attacks are possible [EAPMITM]. 5708 These vulnerabilities occur when EAP is also used in protocols that 5709 are not protected with a secure tunnel. Since EAP is a general- 5710 purpose authentication protocol, which is often used to provide 5711 single-signon facilities, a deployed IPsec solution that relies on an 5712 EAP authentication method that does not generate a shared key (also 5713 known as a non-key-generating EAP method) can become compromised due 5714 to the deployment of an entirely unrelated application that also 5715 happens to use the same non-key-generating EAP method, but in an 5716 unprotected fashion. Note that this vulnerability is not limited to 5717 just EAP, but can occur in other scenarios where an authentication 5718 infrastructure is reused. For example, if the EAP mechanism used by 5719 IKEv2 utilizes a token authenticator, a man-in-the-middle attacker 5720 could impersonate the web server, intercept the token authentication 5721 exchange, and use it to initiate an IKEv2 connection. For this 5722 reason, use of non-key-generating EAP methods SHOULD be avoided where 5723 possible. Where they are used, it is extremely important that all 5724 usages of these EAP methods SHOULD utilize a protected tunnel, where 5725 the initiator validates the responder's certificate before initiating 5726 the EAP authentication. Implementers should describe the 5727 vulnerabilities of using non-key-generating EAP methods in the 5728 documentation of their implementations so that the administrators 5729 deploying IPsec solutions are aware of these dangers. 5731 An implementation using EAP MUST also use a public-key-based 5732 authentication of the server to the client before the EAP 5733 authentication begins, even if the EAP method offers mutual 5734 authentication. This avoids having additional IKEv2 protocol 5735 variations and protects the EAP data from active attackers. 5737 If the messages of IKEv2 are long enough that IP-level fragmentation 5738 is necessary, it is possible that attackers could prevent the 5739 exchange from completing by exhausting the reassembly buffers. The 5740 chances of this can be minimized by using the Hash and URL encodings 5741 instead of sending certificates (see Section 3.6). Additional 5742 mitigations are discussed in [DOSUDPPROT]. 5744 Admission control is critical to the security of the protocol. For 5745 example, trust anchors used for identifying IKE peers should probably 5746 be different than those used for other forms of trust, such as those 5747 used to identify public web servers. Moreover, although IKE provides 5748 a great deal of leeway in defining the security policy for a trusted 5749 peer's identity, credentials, and the correlation between them, 5750 having such security policy defined explicitly is essential to a 5751 secure implementation. 5753 5.1. Traffic selector authorization 5755 IKEv2 relies on information in the Peer Authorization Database (PAD) 5756 when determining what kind of Child SAs a peer is allowed to create. 5757 This process is described in [IPSECARCH] Section 4.4.3. When a peer 5758 requests the creation of an Child SA with some traffic selectors, the 5759 PAD must contain "Child SA Authorization Data" linking the identity 5760 authenticated by IKEv2 and the addresses permitted for traffic 5761 selectors. 5763 For example, the PAD might be configured so that authenticated 5764 identity "sgw23.example.com" is allowed to create Child SAs for 5765 192.0.2.0/24, meaning this security gateway is a valid 5766 "representative" for these addresses. Host-to-host IPsec requires 5767 similar entries, linking, for example, "fooserver4.example.com" with 5768 198.51.100.66/32, meaning this identity a valid "owner" or 5769 "representative" of the address in question. 5771 As noted in [IPSECARCH], "It is necessary to impose these constraints 5772 on creation of child SAs to prevent an authenticated peer from 5773 spoofing IDs associated with other, legitimate peers." In the 5774 example given above, a correct configuration of the PAD prevents 5775 sgw23 from creating Child SAs with address 198.51.100.66, and 5776 prevents fooserver4 from creating Child SAs with addresses from 5777 192.0.2.0/24. 5779 It is important to note that simply sending IKEv2 packets using some 5780 particular address does not imply a permission to create Child SAs 5781 with that address in the traffic selectors. For example, even if 5782 sgw23 would be able to spoof its IP address as 198.51.100.66, it 5783 could not create Child SAs matching fooserver4's traffic. 5785 The IKEv2 specification does not specify how exactly IP address 5786 assignment using configuration payloads interacts with the PAD. Our 5787 interpretation is that when a security gateway assigns an address 5788 using configuration payloads, it also creates a temporary PAD entry 5789 linking the authenticated peer identity and the newly allocated inner 5790 address. 5792 It has been recognized that configuring the PAD correctly may be 5793 difficult in some environments. For instance, if IPsec is used 5794 between a pair of hosts whose addresses are allocated dynamically 5795 using DHCP, it is extremely difficult to ensure that the PAD 5796 specifies the correct "owner" for each IP address. This would 5797 require a mechanism to securely convey address assignments from the 5798 DHCP server, and link them to identities authenticated using IKEv2. 5800 Due to this limitation, some vendors have been known to configure 5801 their PADs to allow an authenticated peer to create Child SAs with 5802 traffic selectors containing the same address that was used for the 5803 IKEv2 packets. In environments where IP spoofing is possible (i.e., 5804 almost everywhere) this essentially allows any peer to create Child 5805 SAs with any traffic selectors. This is not an appropriate or secure 5806 configuration in most circumstances. See [H2HIPSEC] for an extensive 5807 discussion about this issue, and the limitations of host-to-host 5808 IPsec in general. 5810 6. IANA Considerations 5812 [IKEV2] defined many field types and values. IANA has already 5813 registered those types and values in [IKEV2IANA], so they are not 5814 listed here again. 5816 Two items are removed from the IKEv2 Configuration Payload Attribute 5817 Types table: INTERNAL_IP6_NBNS and INTERNAL_ADDRESS_EXPIRY. 5819 Two new additions to the IKEv2 parameters "NOTIFY MESSAGES - ERROR 5820 TYPES" registry are defined here that were not defined in [IKEV2]: 5822 {TBA1} TEMPORARY_FAILURE 5823 {TBA2} CHILD_SA_NOT_FOUND 5825 IANA should change the exiting IKEv2 Payload Types table from: 5827 46 Encrypted E [IKEv2] 5829 to 5831 46 Encrypted and Authenticated SK [This document] 5833 IANA should update all references to RFC 4306 to point to this 5834 document. 5836 7. Acknowledgements 5838 Many individuals in the IPsecME Working Group were very helpful in 5839 contributing ideas and text for this document, as well as in 5840 reviewing the clarifications suggested by others. 5842 The acknowledgements from the IKEv2 document were: 5844 This document is a collaborative effort of the entire IPsec WG. If 5845 there were no limit to the number of authors that could appear on an 5846 RFC, the following, in alphabetical order, would have been listed: 5847 Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt 5848 Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John 5849 Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero 5850 Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer 5851 Reingold, and Michael Richardson. Many other people contributed to 5852 the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, 5853 each of which has its own list of authors. Hugh Daniel suggested the 5854 feature of having the initiator, in message 3, specify a name for the 5855 responder, and gave the feature the cute name "You Tarzan, Me Jane". 5856 David Faucher and Valery Smyslov helped refine the design of the 5857 traffic selector negotiation. 5859 This paragraph lists references that appear only in figures. The 5860 section is only here to keep the 'xml2rfc' program happy, and needs 5861 to be removed when the document is published. The RFC Editor will 5862 remove it before publication. [EAI] [DES] [IDEA] [MD5] [DSS] 5864 8. References 5866 8.1. Normative References 5868 [ADDGROUP] 5869 Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 5870 Diffie-Hellman groups for Internet Key Exchange (IKE)", 5871 RFC 3526, May 2003. 5873 [ADDRIPV6] 5874 Hinden, R. and S. Deering, "Internet Protocol Version 6 5875 (IPv6) Addressing Architecture", RFC 4291, February 2006. 5877 [AEAD] McGrew, D. and D. Black, "Using Authenticated Encryption 5878 Algorithms with the Encrypted Payload of the Internet Key 5879 Exchange version 2 (IKEv2) Protocol", RFC 5282, 5880 August 2008. 5882 [AESCMACPRF128] 5883 Song, J., "The Advanced Encryption Standard-Cipher-based 5884 Message Authentication Code-Pseudo-Random Function-128 5885 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange 5886 Protocol (IKE)", RFC 4615, August 2006. 5888 [AESXCBCPRF128] 5889 Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the 5890 Internet Key Exchange Protocol (IKE)", RFC 4434, 5891 February 2006. 5893 [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 5894 Levkowetz, "Extensible Authentication Protocol (EAP)", 5895 RFC 3748, June 2004. 5897 [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 5898 of Explicit Congestion Notification (ECN) to IP", 5899 RFC 3168, September 2001. 5901 [ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 5902 Algorithms", RFC 2451, November 1998. 5904 [HTTP] Fielding, et. al., R., "Hypertext Transfer Protocol -- 5905 HTTP/1.1", RFC 2616, June 1999. 5907 [IKEV2IANA] 5908 "Internet Key Exchange Version 2 (IKEv2) Parameters", 5909 . 5911 [IPSECARCH] 5912 Kent, S. and K. Seo, "Security Architecture for the 5913 Internet Protocol", RFC 4301, December 2005. 5915 [MUSTSHOULD] 5916 Bradner, S., "Key Words for use in RFCs to indicate 5917 Requirement Levels", BCP 14, RFC 2119, March 1997. 5919 [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 5920 Standards (PKCS) #1: RSA Cryptography Specifications 5921 Version 2.1", RFC 3447, February 2003. 5923 [PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 5924 X.509 Public Key Infrastructure Certificate and 5925 Certificate Revocation List (CRL) Profile", RFC 5280, 5926 May 2008. 5928 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in IKEv2", 5929 RFC 4307, December 2005. 5931 [UDPENCAPS] 5932 Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 5933 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 5934 RFC 3948, January 2005. 5936 [URLS] Fielding, et. al., R., "Uniform Resource Identifier (URI): 5937 Generic Syntax", RFC 3986, January 2005. 5939 8.2. Informative References 5941 [AH] Kent, S., "IP Authentication Header", RFC 4302, 5942 December 2005. 5944 [ARCHGUIDEPHIL] 5945 Bush, R. and D. Meyer, "Some Internet Architectural 5946 Guidelines and Philosophy", RFC 3439, December 2002. 5948 [ARCHPRINC] 5949 Carpenter, B., "Architectural Principles of the Internet", 5950 RFC 1958, June 1996. 5952 [Clarif] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 5953 Implementation Guidelines", RFC 4718, October 2006. 5955 [DES] American National Standards Institute, "American National 5956 Standard for Information Systems-Data Link Encryption", 5957 ANSI X3.106, 1983. 5959 [DH] Diffie, W. and M. Hellman, "New Directions in 5960 Cryptography", IEEE Transactions on Information Theory, 5961 V.IT-22 n. 6, June 1977. 5963 [DIFFSERVARCH] 5964 Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 5965 and W. Weiss, "An Architecture for Differentiated 5966 Services", RFC 2475. 5968 [DIFFSERVFIELD] 5969 Nichols, K., Blake, S., Baker, F., and D. Black, 5970 "Definition of the Differentiated Services Field (DS 5971 Field) in the IPv4 and IPv6 Headers", RFC 2474, 5972 December 1998. 5974 [DIFFTUNNEL] 5975 Black, D., "Differentiated Services and Tunnels", 5976 RFC 2983, October 2000. 5978 [DOI] Piper, D., "The Internet IP Security Domain of 5979 Interpretation for ISAKMP", RFC 2407, November 1998. 5981 [DOSUDPPROT] 5982 C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection 5983 for UDP-based protocols", ACM Conference on Computer and 5984 Communications Security , October 2003. 5986 [DSS] National Institute of Standards and Technology, U.S. 5987 Department of Commerce, "Digital Signature Standard", 5988 Draft FIPS 186-3, June 2008. 5990 [EAI] Abel, Y., "Internationalized Email Headers", RFC 5335, 5991 September 2008. 5993 [EAP-IANA] 5994 "Extensible Authentication Protocol (EAP) Registry: Method 5995 Types", . 5997 [EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, "Man-in-the-Middle in 5998 Tunneled Authentication Protocols", November 2002, 5999 . 6001 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 6002 RFC 4303, December 2005. 6004 [EXCHANGEANALYSIS] 6005 R. Perlman and C. Kaufman, "Analysis of the IPsec key 6006 exchange Standard", WET-ICE Security Conference, MIT , 6007 2001, 6008 . 6010 [H2HIPSEC] 6011 Aura, T., Roe, M., and A. Mohammed, "Experiences with 6012 Host-to-Host IPsec", 13th International Workshop on 6013 Security Protocols, Cambridge, UK, April 2005. 6015 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 6016 Hashing for Message Authentication", RFC 2104, 6017 February 1997. 6019 [IDEA] X. Lai, "On the Design and Security of Block Ciphers", ETH 6020 Series in Information Processing, v. 1, Konstanz: Hartung- 6021 Gorre Verlag, 1992. 6023 [IDNA] Faltstrom, P., Hoffman, P., and A. Costello, 6024 "Internationalizing Domain Names in Applications (IDNA)", 6025 RFC 3490, March 2003. 6027 [IKEV1] Harkins, D. and D. Carrel, "The Internet Key Exchange 6028 (IKE)", RFC 2409, November 1998. 6030 [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 6031 RFC 4306, December 2005. 6033 [IP-COMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP 6034 Payload Compression Protocol (IPComp)", RFC 3173, 6035 September 2001. 6037 [IPSECARCH-OLD] 6038 Kent, S. and R. Atkinson, "Security Architecture for the 6039 Internet Protocol", RFC 2401, November 1998. 6041 [IPV6CONFIG] 6042 Eronen, et. al., P., "IPv6 Configuration in IKEv2", 6043 RFC 5739, February 2010. 6045 [ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet 6046 Security Association and Key Management Protocol 6047 (ISAKMP)", RFC 2408, November 1998. 6049 [MAILFORMAT] 6050 Resnick, P., "Internet Message Format", RFC 5322, 6051 October 2008. 6053 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 6054 April 1992. 6056 [MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 6057 in IPv6", RFC 3775, June 2004. 6059 [MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery 6060 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 6062 [MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 6063 (MOBIKE)", RFC 4555, June 2006. 6065 [MODES] National Institute of Standards and Technology, U.S. 6066 Department of Commerce, "Recommendation for Block Cipher 6067 Modes of Operation", SP 800-38A, 2001. 6069 [NAI] Aboba, B., Beadles, M., Eronen, P., and J. Arkko, "The 6070 Network Access Identifier", RFC 4282, December 2005. 6072 [NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 6073 (NAT) Compatibility Requirements", RFC 3715, March 2004. 6075 [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", 6076 RFC 2412, November 1998. 6078 [PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 6079 Management API, Version 2", RFC 2367, July 1998. 6081 [PHOTURIS] 6082 Karn, P. and W. Simpson, "Photuris: Session-Key Management 6083 Protocol", RFC 2522, March 1999. 6085 [RANDOMNESS] 6086 Eastlake, D., Schiller, J., and S. Crocker, "Randomness 6087 Requirements for Security", BCP 106, RFC 4086, June 2005. 6089 [REAUTH] Nir, Y., "Repeated Authentication in Internet Key Exchange 6090 (IKEv2) Protocol", RFC 4478, April 2006. 6092 [REUSE] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In 6093 Diffie-Hellman Key Agreement Protocols", December 2008, 6094 . 6097 [ROHCV2] Ertekin, et. al., E., "IKEv2 Extensions to Support Robust 6098 Header Compression over IPsec (ROHCoIPsec)", 6099 draft-ietf-rohc-ikev2-extensions-hcoipsec (work in 6100 progress), August 2009. 6102 [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for 6103 Obtaining Digital Signatures and Public-Key 6104 Cryptosystems", February 1978. 6106 [SHA] National Institute of Standards and Technology, U.S. 6107 Department of Commerce, "Secure Hash Standard", 6108 FIPS 180-3, October 2008. 6110 [SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to 6111 Authenticated Diffie-Hellman and its Use in the IKE 6112 Protocols", Advances in Cryptography - CRYPTO 2003 6113 Proceedings LNCS 2729, 2003, . 6117 [SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange 6118 Mechanism for Internet", IEEE Proceedings of the 1996 6119 Symposium on Network and Distributed Systems Security , 6120 1996. 6122 [TRANSPARENCY] 6123 Carpenter, B., "Internet Transparency", RFC 2775, 6124 February 2000. 6126 Appendix A. Summary of changes from IKEv1 6128 The goals of this revision to IKE are: 6130 1. To define the entire IKE protocol in a single document, 6131 replacing RFCs 2407, 2408, and 2409 and incorporating subsequent 6132 changes to support NAT Traversal, Extensible Authentication, and 6133 Remote Address acquisition; 6135 2. To simplify IKE by replacing the eight different initial 6136 exchanges with a single four-message exchange (with changes in 6137 authentication mechanisms affecting only a single AUTH payload 6138 rather than restructuring the entire exchange) see 6139 [EXCHANGEANALYSIS]; 6141 3. To remove the Domain of Interpretation (DOI), Situation (SIT), 6142 and Labeled Domain Identifier fields, and the Commit and 6143 Authentication only bits; 6145 4. To decrease IKE's latency in the common case by making the 6146 initial exchange be 2 round trips (4 messages), and allowing the 6147 ability to piggyback setup of a Child SA on that exchange; 6149 5. To replace the cryptographic syntax for protecting the IKE 6150 messages themselves with one based closely on ESP to simplify 6151 implementation and security analysis; 6153 6. To reduce the number of possible error states by making the 6154 protocol reliable (all messages are acknowledged) and sequenced. 6155 This allows shortening CREATE_CHILD_SA exchanges from 3 messages 6156 to 2; 6158 7. To increase robustness by allowing the responder to not do 6159 significant processing until it receives a message proving that 6160 the initiator can receive messages at its claimed IP address; 6162 8. To fix cryptographic weaknesses such as the problem with 6163 symmetries in hashes used for authentication documented by Tero 6164 Kivinen; 6166 9. To specify traffic selectors in their own payloads type rather 6167 than overloading ID payloads, and making more flexible the 6168 traffic selectors that may be specified; 6170 10. To specify required behavior under certain error conditions or 6171 when data that is not understood is received in order to make it 6172 easier to make future revisions in a way that does not break 6173 backwards compatibility; 6175 11. To simplify and clarify how shared state is maintained in the 6176 presence of network failures and DoS attacks; and 6178 12. To maintain existing syntax and magic numbers to the extent 6179 possible to make it likely that implementations of IKEv1 can be 6180 enhanced to support IKEv2 with minimum effort. 6182 Appendix B. Diffie-Hellman Groups 6184 There are two Diffie-Hellman groups defined here for use in IKE. 6185 These groups were generated by Richard Schroeppel at the University 6186 of Arizona. Properties of these primes are described in [OAKLEY]. 6188 The strength supplied by group 1 may not be sufficient for typical 6189 uses and is here for historic reasons. 6191 Additional Diffie-Hellman groups have been defined in [ADDGROUP]. 6193 B.1. Group 1 - 768 Bit MODP 6195 This group is assigned id 1 (one). 6197 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 6198 Its hexadecimal value is: 6200 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 6201 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 6202 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 6203 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF 6205 The generator is 2. 6207 B.2. Group 2 - 1024 Bit MODP 6209 This group is assigned id 2 (two). 6211 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 6212 Its hexadecimal value is: 6214 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 6215 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 6216 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 6217 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 6218 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 6219 FFFFFFFF FFFFFFFF 6221 The generator is 2. 6223 Appendix C. Exchanges and Payloads 6225 This appendix contains a short summary of the IKEv2 exchanges, and 6226 what payloads can appear in which message. This appendix is purely 6227 informative; if it disagrees with the body of this document, the 6228 other text is considered correct. 6230 Vendor-ID (V) payloads may be included in any place in any message. 6231 This sequence here shows what are the most logical places for them. 6233 C.1. IKE_SA_INIT Exchange 6235 request --> [N(COOKIE)], 6236 SA, KE, Ni, 6237 [N(NAT_DETECTION_SOURCE_IP)+, 6238 N(NAT_DETECTION_DESTINATION_IP)], 6239 [V+][N+] 6241 normal response <-- SA, KE, Nr, 6242 (no cookie) [N(NAT_DETECTION_SOURCE_IP), 6243 N(NAT_DETECTION_DESTINATION_IP)], 6244 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 6245 [V+][N+] 6247 cookie response <-- N(COOKIE), 6248 [V+][N+] 6250 different Diffie- <-- N(INVALID_KE_PAYLOAD), 6251 Hellman group [V+][N+] 6252 wanted 6254 C.2. IKE_AUTH Exchange without EAP 6256 request --> IDi, [CERT+], 6257 [N(INITIAL_CONTACT)], 6258 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 6259 [IDr], 6260 AUTH, 6261 [CP(CFG_REQUEST)], 6262 [N(IPCOMP_SUPPORTED)+], 6263 [N(USE_TRANSPORT_MODE)], 6264 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 6265 [N(NON_FIRST_FRAGMENTS_ALSO)], 6266 SA, TSi, TSr, 6267 [V+][N+] 6269 response <-- IDr, [CERT+], 6270 AUTH, 6271 [CP(CFG_REPLY)], 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 [N(ADDITIONAL_TS_POSSIBLE)], 6278 [V+][N+] 6280 error in Child SA <-- IDr, [CERT+], 6281 creation AUTH, 6282 N(error), 6283 [V+][N+] 6285 C.3. IKE_AUTH Exchange with EAP 6287 first request --> IDi, 6288 [N(INITIAL_CONTACT)], 6289 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 6290 [IDr], 6291 [CP(CFG_REQUEST)], 6292 [N(IPCOMP_SUPPORTED)+], 6293 [N(USE_TRANSPORT_MODE)], 6294 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 6295 [N(NON_FIRST_FRAGMENTS_ALSO)], 6296 SA, TSi, TSr, 6297 [V+][N+] 6299 first response <-- IDr, [CERT+], AUTH, 6300 EAP, 6301 [V+][N+] 6303 / --> EAP 6304 repeat 1..N times | 6305 \ <-- EAP 6307 last request --> AUTH 6309 last response <-- AUTH, 6310 [CP(CFG_REPLY)], 6311 [N(IPCOMP_SUPPORTED)], 6312 [N(USE_TRANSPORT_MODE)], 6313 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 6314 [N(NON_FIRST_FRAGMENTS_ALSO)], 6315 SA, TSi, TSr, 6316 [N(ADDITIONAL_TS_POSSIBLE)], 6317 [V+][N+] 6319 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying Child SAs 6321 request --> [N(REKEY_SA)], 6322 [CP(CFG_REQUEST)], 6323 [N(IPCOMP_SUPPORTED)+], 6324 [N(USE_TRANSPORT_MODE)], 6325 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 6326 [N(NON_FIRST_FRAGMENTS_ALSO)], 6327 SA, Ni, [KEi], TSi, TSr 6328 [V+][N+] 6330 normal <-- [CP(CFG_REPLY)], 6331 response [N(IPCOMP_SUPPORTED)], 6332 [N(USE_TRANSPORT_MODE)], 6333 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 6334 [N(NON_FIRST_FRAGMENTS_ALSO)], 6335 SA, Nr, [KEr], TSi, TSr, 6336 [N(ADDITIONAL_TS_POSSIBLE)] 6337 [V+][N+] 6339 error case <-- N(error) 6341 different Diffie- <-- N(INVALID_KE_PAYLOAD), 6342 Hellman group [V+][N+] 6343 wanted 6345 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA 6347 request --> SA, Ni, KEi 6348 [V+][N+] 6350 response <-- SA, Nr, KEr 6351 [V+][N+] 6353 C.6. INFORMATIONAL Exchange 6355 request --> [N+], 6356 [D+], 6357 [CP(CFG_REQUEST)] 6359 response <-- [N+], 6360 [D+], 6361 [CP(CFG_REPLY)] 6363 Appendix D. Changes Between Internet Draft Versions 6365 This section will be removed before publication as an RFC, but should 6366 be left intact until then so that reviewers can follow what has 6367 changed. 6369 D.1. Changes from IKEv2 to draft -00 6371 There were a zillion additions from RFC 4718. These are noted with 6372 "{{ Clarif-nn }}". 6374 Cleaned up many of the figures. Made the table headings consistent. 6375 Made some tables easier to read by removing blank spaces. Removed 6376 the "reserved to IANA" and "private use" text wording and moved it 6377 into the tables. 6379 Changed many SHOULD requirements to better match RFC 2119. These are 6380 also marked with comments such as "{{ Demoted the SHOULD }}". 6382 In Section 2.16, changed the MUST requirement of authenticating the 6383 responder from "public key signature based" to "strong" because that 6384 is what most current IKEv2 implementations do, and it better matches 6385 the actual security requirement. 6387 D.2. Changes from draft -00 to draft -01 6389 The most significant technical change was to make KE optional but 6390 strongly recommended in Section 1.3.2. 6392 Updated all references to the IKEv2 Clarifications document to RFC 6393 4718. 6395 Moved a lot of the protocol description out of the long tables in 6396 Section 3.10.1 into the body of the document. These are noted with 6397 "{{ 3.10.1-nnnn }}", where "nnnn" is the notification type number. 6399 Made some table changes based on suggestions from Alfred Hoenes. 6401 Changed "byte" to "octet" in many places. 6403 Removed discussion of ESP+AH bundles in many places, and added a 6404 paragraph about it in Section 1.7. 6406 Removed the discussion of INTERNAL_ADDRESS_EXPIRY in many places, and 6407 added a paragraph about it in Section 1.7. 6409 Moved Clarif-7.10 from Section 1.2 to Section 3.2. 6411 In the figure in Section 1.3.2, made KEi optional, and added text 6412 saying "The KEi payload SHOULD be included." 6414 In the figure in Section 1.3.2, maked KEr optional, and removed text 6415 saying "KEi and KEr are required for rekeying an IKE SA." 6417 In Section 1.4, clarified that the half-closed connections being 6418 discussed are AH and ESP. 6420 Rearranged the end of Section 1.7, and added the new notation for 6421 moving text out of 3.10.1. 6423 Clarified the wording in the second paragraph of Section 2.2. This 6424 allowd the removal of the fourth paragraph, which previously had 6425 Clarif-2.2 in it. 6427 In section 2.5, removed "or later" from "version 2.0". 6429 Added the question for implementers about payload order at the end of 6430 Section 2.5. 6432 Corrected Section 2.7 based on Clarif-7-13 to say that you can't do 6433 ESP and AH at one time. 6435 In Section 2.8, clarified the wording about how to replace an IKE SA. 6437 Clarified the text in the last many paragraphs in Section 2.9. Also 6438 moved some text from near the beginning of 2.9 to the beginning of 6439 2.9.1. 6441 Removed some redundant text in Section 2.9 concerning creating a 6442 Child SA pair not in response to an arriving packet. 6444 Added the following to the end of the first paragraph of Section 6445 2.14: "The lengths of SK_d, SK_pi, and SK_pr are the key length of 6446 the agreed-to PRF." 6448 Added the restriction in Section 2.15 that all PRFs used with IKEv2 6449 MUST take variable-sized keys. 6451 In Section 2.17, removed "If multiple IPsec protocols are negotiated, 6452 keying material is taken in the order in which the protocol headers 6453 will appear in the encapsulated packet" because multiple IPsec 6454 protocols cannot be negotiated at one time. 6456 Added the material from Clarif-5.12 to Section 2.18. 6458 Changed "hash of" to "expected value of" in Section 2.23. 6460 In the bulleted list in Section 2.23, replaced "this end" with a 6461 clearer description of which system is being discussed. 6463 Added the paragraph at the beginning of Section 3 about 6464 interoperability and UNSPECIFIED values ("In the tables in this 6465 section..."). 6467 Fixed Section 3.3 to not include proposal that include both AH and 6468 ESP. Ditto for the "Proposal #" bullet in Section 3.3.1. 6470 In the description of ID_FQDN in Section 3.5, added "All characters 6471 in the ID_FQDN are ASCII; this follows that for an "internationalized 6472 domain name" as defined in [IDNA]." 6474 In Section 3.8, shortened and clarified the description of "RSA 6475 Digital Signature". 6477 In Section 3.10, shortened and clarified the description of "Protocol 6478 ID". 6480 In Section 3.15, "The requested address is valid until the expiry 6481 time defined with the INTERNAL_ADDRESS_EXPIRY attribute or there are 6482 no IKE SAs between the peers" is shortened to just "The requested 6483 address is valid until there are no IKE SAs between the peers." 6485 In Section 3.15.1, changed "INTERNAL_IP6_NBNS" to unspecified. 6487 Made [ADDRIPV6] an informative reference instead of a normative 6488 reference and updated it. 6490 Made [PKCS1] a normative reference instead of an informative 6491 reference and changed the pointer to RFC 3447. 6493 D.3. Changes from draft -00 to draft -01 6495 In Section 1.5, added "request" to first sentence to make it "If an 6496 encrypted IKE request packet arrives on port 500 or 4500 with an 6497 unrecognized SPI...". 6499 In Section 3.3, fifth paragraph, upped the number of transforms for 6500 AH and ESP by one each to account for ESN, which is now mandatory. 6502 In Section 2.1, added "or equal to" in "The responder MUST remember 6503 each response until it receives a request whose sequence number is 6504 larger than or equal to the sequence number in the response plus its 6505 window size." 6507 In Section 2.18, removed " Note that this may not work if the new IKE 6508 SA's PRF has a fixed key size because the output of the PRF may not 6509 be of the correct size." because it is no longer relevant. 6511 D.4. Changes from draft -01 to draft -02 6513 Many grammatical fixes. 6515 In Section 1.2, reworded Clarif-4.3 to be clearer. 6517 In Section 1.3.3, reworded 3.10.1-16393 and Clarif-5.4 to remove 6518 redundant text. 6520 In Section 2.13, replaced text about variable length keys with 6521 clearer explanation and requirement on non-HMAC PRFs. Also added 6522 "preferred" to Section 2.14 for the key length, and removed redundant 6523 text. 6525 In Section 2.14, removed the "half and half" description and replaced 6526 it with exceptions for RFC4434 and RFC4615. 6528 Removed the now-redundant "All PRFs used with IKEv2 MUST take 6529 variable-sized keys" from Section 2.15. 6531 In Section 2.15, added "(IKE_SA_INIT response)" after "of the second 6532 message" and "(IKE_SA_INIT request)" after "the first message". 6534 In Section 2.17, simplified because there are no more bundles. "A 6535 single Child SA negotiation may result in multiple security 6536 associations. ESP and AH SAs exist in pairs (one in each 6537 direction)." becomes "For ESP and AH, a single Child SA negotiation 6538 results in two security associations (one in each direction)." 6540 In section 3.3, made the example of combinations of algorithms and 6541 the contents of the first proposal clearer. 6543 Added Clarif-4.4 to the end of Section 3.3.2. 6545 Reordered Section 3.3.5 and added Clarif-7.11. 6547 Clarified Section 3.3.6 about choosing a single proposal. Also added 6548 second paragraph about transforms not understood, and clarified third 6549 paragraph about picking D-H groups. 6551 Moved 3.10.1-16392 from Section 3.6 to 3.7. 6553 In Section 3.10, clarified 3.10.1-16394. 6555 Updated Section 6 to indicate that there is nothing new for IANA in 6556 this spec. Also removed the definition of "Expert Review" from 6557 Section 1.6 for the same reason. 6559 In Appendix A, removed "and not commit any state to an exchange until 6560 the initiator can be cryptographically authenticated" because that 6561 was only true in an earlier version of IKEv2. 6563 D.5. Changes from draft -02 to draft -03 6565 In Section 1.3, changed "If the responder rejects the Diffie-Hellman 6566 group of the KEi payload, the responder MUST reject the request and 6567 indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD 6568 Notification payload." to "If the responder selects a proposal using 6569 a different Diffie-Hellman group (other than NONE), the responder 6570 MUST reject the request and indicate its preferred Diffie-Hellman 6571 group in the INVALID_KE_PAYLOAD Notification payload. 6573 In Section 2.3, added the last two paragraphs covering why you 6574 initiator's SPI and/or IP to differentiate if this is a "half-open" 6575 IKE SA or a new request. Also removed similar text from Section 2.2. 6577 In Section 2.5, added "Payloads sent in IKE response messages MUST 6578 NOT have the critical flag set. Note that the critical flag applies 6579 only to the payload type, not the contents. If the payload type is 6580 recognized, but the payload contains something which is not (such as 6581 an unknown transform inside an SA payload, or an unknown Notify 6582 Message Type inside a Notify payload), the critical flag is ignored." 6584 In Section 2.6, moved the text about {{ 3.10.1-16390 }} later in the 6585 section. Also reworded the text to make it clearer what the COOKIE 6586 is for. 6588 Moved text from Clarif-2.1 from Section 2.6 to Section 2.7. 6590 In Section 2.13, added "(see Section 3.3.5 for the defintion of the 6591 Key Length transform attribute)". 6593 In Section 2.17, change the description of the keying material from 6594 the list with two bullets to a clearer list. 6596 In Section 2.23, added "Implementations MUST process received UDP- 6597 encapsulated ESP packets even when no NAT was detected." 6599 In Section 3.3, changed "Each proposal may contain a" to "Each 6600 proposal contains a". 6602 Added the asterisks to the transform type table in Section 3.3.2 and 6603 the types table in 3.3.3 to foreshadow future developments. 6605 In Section 3.3.2, changed the following algorithms to (UNSPECIFIED) 6606 because the RFCs listed didn't really specify how to implement them 6607 in an interoperable fashion: 6609 Encryption Algorithms 6610 ENCR_DES_IV64 1 (RFC1827) 6611 ENCR_3IDEA 8 (RFC2451) 6612 ENCR_DES_IV32 9 6613 Pseudo-random Functions 6614 PRF_HMAC_TIGER 3 (RFC2104) 6615 Integrity Algorithms 6616 AUTH_DES_MAC 3 6617 AUTH_KPDK_MD5 4 (RFC1826) 6619 In Section 3.4, added "(other than NONE)" to the second-to-last 6620 paragraph. 6622 Rewrote the third paragraph of Section 3.14 to talk about other 6623 modes, and to clarify which encryption and integrity protection we 6624 are talking about. 6626 Changed the "Initialization Vector" bullet in Section 3.14 to specify 6627 better what is needed for the IV. Upgraded the SHOULDs to MUSTs. 6628 Also added the reference for [MODES]. 6630 In Section 5, in the second-to-last paragraph, changed "a public-key- 6631 based" to "strong" to match the wording in Section 2.16. 6633 D.6. Changes from draft -03 to draft-ietf-ipsecme-ikev2bis-00 6635 Changed the document's filename to draft-ietf-ipsecme-ikev2bis-00. 6636 Added Yoav Nir as a co-author. 6638 In many places in the document, changed "and/or" to "or" when talking 6639 about combinations of ESP and AH SAs. For example, in the intro, it 6640 said "can be used to efficiently establish SAs for Encapsulating 6641 Security Payload (ESP) and/or Authentication Header (AH)". This is 6642 changed to "or" to indicate that you can only establish one type of 6643 SA at a time. 6645 In Section 1, clarified that RFC 4306 already replaced IKEv1, and 6646 that this document replaces RFC 4306. Also fixed Section 2.5 for 6647 similar issue. Also updated the Abstract to cover this. 6649 In Section 2.15, in the responder's signed octets, changed: 6651 RestOfRespIDPayload = IDType | RESERVED | InitIDData 6652 to 6653 RestOfRespIDPayload = IDType | RESERVED | RespIDData 6655 In 2.16, changed "strong" back to "public key signature based" to 6656 make it the same as 4306. 6658 In section 3.10, added "and the field must be empty" to make it clear 6659 that a zero-length SPI is really empty. 6661 D.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to 6662 draft-ietf-ipsecme-ikev2bis-01 6664 Throughout, changed "IKE_SA" to "IKE SA", and changed "CHILD_SA" to 6665 "Child SA" (except left "CREATE_CHILD_SA" alone). 6667 Added the middle sentence in the Abstract to say what IKE actually 6668 does. 6670 Added in section 1 "(unless there is failure setting up the AH or ESP 6671 Child SA, in which case the IKE SA is still established without Child 6672 SA)". 6674 Clarified the titles of 1.1.1, 1.1.2, and 1.1.3. 6676 In 1.1.2, changed "If there is an inner IP header, the inner 6677 addresses will be the same as the outer addresses." because we are 6678 talking about transport mode here. 6680 Added reference to section 2.14 to setion 1.2 and 1.3. 6682 In 1.2, clarified what is and isn't encrypted in a message. 6684 Added the following to 1.2: "If the IDr proposed by the initiator is 6685 not acceptable to the responder, the responder might use some other 6686 IDr to finish the exchange. If the initiator then does not accept 6687 that fact that responder used different IDr than the one that was 6688 requested, the initiator can close the SA after noticing the fact." 6690 Moved the paragraph beginning "All messages following..." from 1.3 up 6691 to 1.2, and reworded it to apply to all the cases it covers. 6693 At the end of section 1.3.1, clarified that the responder is the one 6694 who controls whether non-first-fragments will be sent, and reworded 6695 the paragraph. 6697 In section 1.3.3, added "The Protocol ID field of the REKEY_SA 6698 notification is set to match the protocol of the SA we are rekeying, 6699 for example, 3 for ESP and 2 for AH." [Issue #10] 6701 In 1.3.2, added "of the SA payload" to "New initiator and responder 6702 SPIs are supplied in the SPI fields." 6704 In 1.3.3, fixed the art. 6706 <-- HDR, SK {SA, Nr, [KEr], 6707 Si, TSr} 6708 becomes 6709 <-- HDR, SK {SA, Nr, [KEr], 6710 TSi, TSr} 6712 In 1.4 and 2.18, changed "replaced for the purpose of rekeying" to 6713 "rekeyed". 6715 Split out the SA deletion material from section 1.4 into its own 6716 subsection, 1.4.1. 6718 Clarified which bits are set at the end of Section 1.5. 6720 In 1.7, added "That is, the version number is *not* changed from RFC 6721 4306.". 6723 In 2.1, added wording about retransmissions needing to be identical. 6725 In 2.2, added "or rekeyed" to "In the unlikely event that Message IDs 6726 grow too large to fit in 32 bits, the IKE SA MUST be closed" 6728 In 2.2, moved the sentence "Rekeying an IKE SA resets the sequence 6729 numbers." up higher so it would be more likely to be seen. [Issue 6730 #15] 6732 Moved the definition of "original initiator" from 2.8 into 2.2 6733 because that is where it is first used. 6735 In 2.4, added "fresh (i.e., not retransmitted)" to "If a 6736 cryptographically protected message has been received from the other 6737 side recently". Also added the sentence saying that liveness checks 6738 are sometimes call dead peer detection. 6740 Removed the question to implementers about payload order in 2.5. 6742 Changed the title of 2.6 to "IKE SA SPIs and Cookies". Also, in the 6743 paragraph that describes how to implement the responder, changed the 6744 lower-case "should" to "can" to emphasize that this is a choice. 6746 Added the second paragraph in 2.6 to make it clear that the SPI is 6747 used for mapping. 6749 In section 2.6, upgraded "needs to choose them so as to be unique 6750 identifiers of an IKE_SA" to a MUST. 6752 Added sentences at the end of 2.6 eplaining wny the initiator should 6753 limit the number of responses it sends out. 6755 In 2.6.1, added the example of the shorter exchange; this is copied 6756 from RFC 4718 but was dropped in early drafts of this document. 6758 Added the paragraph to 2.7 that describes needing two proposals if 6759 you are having both normal ciphers and combined-mode ciphers. [Issue 6760 #20]. 6762 In section 2.8, added "Note that, when rekeying, the new Child SA MAY 6763 have different traffic selectors and algorithms than the old one." 6765 Added a note in 2.9 that PFKEY applies only to IKEv1. Also added 6766 that unknown traffic selector types are not returned in narrowed 6767 responses. 6769 Added note in the first paragraph of Setion 2.9.1 about decorrelated 6770 policies preventing the problem mentioned. 6772 In 2.12, removed "In particular, it MUST forget the secrets used in 6773 the Diffie-Hellman calculation and any state that may persist in the 6774 state of a pseudo-random number generator that could be used to 6775 recompute the Diffie-Hellman secrets." 6777 In 2.15, noted that the retry could happen multiple times for 6778 different reasons. 6780 In section 2.16, changed "This shared key generated during an IKE 6781 exchange" to "This key". 6783 At the end of 2.19, added statement that FAILED_CP_REQUIRED is not 6784 fatal to the IKE SA. 6786 Added the reference to ROHCV2 to the end of 2.22. 6788 In 2.23, changed "can negotiate" to "will use". for UDP 6789 encapsulation. Added "or 4500" to "...MUST be sent from and to UDP 6790 port 500". Also removed the text about why not to do NAT-traversal 6791 over port 500 because we later say you can't do that anyway. [Issue 6792 #27] Also removed the last paragraph, which obliquely pointed to 6793 MOBIKE. More will be added later on MOBIKE. 6795 In 3.1, removed "and orderings of messages" from "Exchange type". 6796 [Issue #29] 6798 In 3.1, added "This bit changes to reflect who initiated the last 6799 rekey of the IKE SA." to the description of the Initiator bit. 6801 In 3.3, added a long example of why you might use a Proposal 6802 structure because of combined-mode algorithms. [Issue #42] 6804 In 3.3.2, changed "is unnecessary because the last Proposal could be 6805 identified from the length of the SA" to "is unnecessary because the 6806 last transform could be identified from the length of the proposal." 6808 Added reference to AEAD to 3.3.2 and 3.3.3. 6810 Added the reference to RFC 2104 back for PRF_HMAC_TIGER in 3.3.2. 6811 [Issue #33] 6813 Added note at the bottom of 3.3.2 to see the IANA registry. 6815 In 3.3.4, removed all the "this could happen in the future" stuff 6816 because it already happened. 6818 Added a reference to email address internationalization to 3.5, 6819 making the address binary (not ASCII). 6821 In the table in 3.6, made "Authority Revocation List (ARL) 8" and 6822 "X.509 Certificate - Attribute 10" unspecified. 6824 In 3.7, changed the last sentence of the first paragraph to eliminate 6825 the non-protocol SHOULD. 6827 In 3.13.1, added "(including protocol 0)" for the start port and end 6828 port. 6830 In 3.14, updated the discussion of initialization modes to reflect 6831 that it is only about CBC, and that other specs have to specify their 6832 own IVs. 6834 In 3.15.1, added a pointer to 3.15.3. In the entries for 6835 INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET, added a pointer to 6836 3.15.2. 6838 In 3.15.4, added "The IKE SA is still created even if the initial 6839 Child SA cannot be created because of this failure." 6841 Changed "EAP exchange" to "EAP authentication" in 5. 6843 Removed "In particular, these exponents MUST NOT be derived from 6844 long-lived secrets like the seed to a pseudo-random generator that is 6845 not erased after use." from section 5 because it is not possible in 6846 most implementations to do so. 6848 Updated a bunch of reference to their newer versions. 6850 Added "[V+]" to the end of the exchanges in C.4 and C.5. 6852 Added two more response templates to Appendix C.1. Added another 6853 response template in Appendix C.2. Added two more responses in 6854 Appendix C.4. 6856 D.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to 6857 draft-ietf-ipsecme-ikev2bis-02 6859 In section 1.3.1, added "Failure of an attempt to create a CHILD SA 6860 SHOULD NOT tear down the IKE SA: there is no reason to lose the work 6861 done to set up the IKE SA. When an IKE SA is not created, the error 6862 message return SHOULD NOT be encrypted because the other party will 6863 not be able to authenticate that message." This may be changed again 6864 in the future. [Issue #9] 6866 In section 1.3.2, changed "The KEi payload SHOULD be included" to be 6867 "The KEi payload MUST be included". This also led to changes in 6868 section 2.18. The square brackets around "g^ir (new)" in the 6869 SKEYSEED calculation are eliminated, and the requirement language in 6870 the paragraph starting "The main rekeying" is changed from SHOULD to 6871 MUST. [Issue #50] 6873 In section 1.3.2, changed "The window size starts at 1 for any new 6874 IKE SA." to "The first IKE requests from both sides on the new IKE SA 6875 will have message ID 0. The old IKE SA retains its numbering, so any 6876 further requests (for example, to delete the IKE SA) will have 6877 consecutive numbering. The new IKE SA also has its window size reset 6878 to 1, and the initiator in this rekey exchange is the new "original 6879 initiator" of the new IKE SA." [Issue #65] 6881 Added to section 1.5: For a one-way INVALID_IKE_SPI notification for 6882 an unrecognized SPI, the responder SHOULD copy the Exchange Type from 6883 the request. [Issue #46] 6885 In 2.1, at the end of the paragraph about retransmission timers, 6886 added "In order to allow saving memory, responders are allowed to 6887 forget response after a timeout of several minutes. If the responder 6888 receives a retransmitted request for which it has already forgotten 6889 the response, it MUST ignore the request (and not, for example, 6890 attempt constructing a new response)." [Issue #14] 6892 In 2.6, added: "Also, incorporating Ni in the hash prevents an 6893 attacker from fetching one one cookie from the other end, and then 6894 initiating many IKE_SA_INIT exchanges all with different initiator 6895 SPIs (and perhaps port numbers) so that the responder thinks that 6896 there are lots of machines behind one NAT box who are all trying to 6897 connect." [Issue #19] 6899 Added text for the new 2.8.2, and bumped the section number of the 6900 old 2.8.2 to 2.8.3. [Issue #22] 6902 Added a reference to the end of 2.12 on key reuse. 6904 Added to the end of the first paragraph in 2.19: Note, however, it is 6905 usual to only assign one IP address during the IKE_AUTH exchange. 6906 That address persists at least until the deletion of the IKE SA. 6907 [Issue #79] 6909 Added the following to 2.23: An initiator can float to port 4500, 6910 regardless whether or not there is NAT, even at the beginning of IKE. 6911 When either side is using port 4500, sending with UDP encapsulation 6912 is not required, but understanding received packets with UDP 6913 encapsulation is required. UDP encapsulation MUST NOT be done on 6914 port 500. If NAT-T is supported (that is, if NAT_DETECTION_*_IP 6915 payloads were exchanged during IKE_SA_INIT), all devices MUST be able 6916 to receive and process both UDP encapsulated and non-UDP encapsulated 6917 packets at any time. Either side can decide whether or not to use 6918 UDP encapsulation irrespective of the choice made by the other side. 6919 However, if a NAT is detected, both devices MUST send UDP 6920 encapsulated packets. [Issue #40] 6922 The second-to-last paragraph in section 3.4 is changed to: The DH 6923 Group # identifies the Diffie-Hellman group in which the Key Exchange 6924 Data was computed (see Section 3.3.2. This Group # MUST match a DH 6925 Group specified in a proposal in the SA payload that is sent in the 6926 same message, and SHOULD match the DH group in the first group in the 6927 first proposal, if such exists. If none of the proposals in that SA 6928 payload specifies a DH Group, the KE payload MUST NOT be present. If 6929 the selected proposal uses a different Diffie-Hellman group (other 6930 than NONE), the message MUST be rejected with a Notify payload of 6931 type INVALID_KE_PAYLOAD. [Issue #30] 6933 In 3.10.1, changed the definition of NO_PROPOSAL_CHOSEN, 14, to: None 6934 of the proposed crypto suites was acceptable. This can be sent in 6935 any case where the offered proposal (including but not limited to SA 6936 payload values, USE_TRANSPORT_MODE notify, IPCOMP_SUPPORTED notify) 6937 are not acceptable for the responder. This can also be used as 6938 "generic" Child SA error when Child SA cannot be created for some 6939 other reason. See also Section 2.7. [Issue #81] 6941 In the description of IVs in 3.14, reorganized the text a bit to 6942 emphasize when we are and are not talking about CBC. [Issue #68] 6944 Added the following to section 5 (Security Considerations): "The 6945 IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator has 6946 been authenticated. As a result, an implementation of this protocol 6947 needs to be completely robust when deployed on any insecure network. 6948 Implementation vulnerabilities, particularly denial-of-service 6949 attacks, can be exploited by unauthenticated peers. This issue is 6950 particularly worrisome because of the unlimited number of messages in 6951 EAP-based authentication." [Issue #62] 6953 Added new Appendix D, "Significant Changes from RFC 4306", as a 6954 placeholder for now. [Issue #3] 6956 D.9. Changes from draft-ietf-ipsecme-ikev2bis-01 to 6957 draft-ietf-ipsecme-ikev2bis-02 6959 Near the end of 1.3, changed "If the guess turns out to be wrong, the 6960 responder will indicate the correct group in the response and the 6961 initiator SHOULD pick an element of that group for its KE value when 6962 retrying the first message." to "If the responder selects a proposal 6963 using a different Diffie-Hellman group (other than NONE), the 6964 responder will indicate the correct group in the response and the 6965 initiator SHOULD pick an element of that group for its KE value when 6966 retrying the first message." [Issue #6] 6968 In the figures in 1.3.2, changed the diagrams from "HDR, SK {SA, Ni, 6969 [KEi]}" to "HDR, SK {SA, Ni, KEi}", and "HDR, SK {SA, Nr,[KEr]}" to 6970 "HDR, SK {SA, Nr,KEr}". This matches the text in the section, which 6971 was updated in the last revision. [Issue #50] 6973 Reorganized the beginning of section 2.3 and clarified some of the 6974 logic. [Issue #52] 6976 Clarified the octets to be signed in setion 2.15. Changed 6978 AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), ) 6980 to 6982 For the initiator: 6983 AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"), 6984 ) 6985 For the responder: 6986 AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"), 6987 ) 6989 [Issue #72] 6991 Changed the last bullet item in section 2.23 to discuss MOBIKE in 6992 more detail. [Issue #41] 6994 In section 3.1, the bullet about bit 4, changed "must" to "MUST". 6996 In section 3.3.6, added two sentences at the end of the second 6997 paragraph to indicate that there is an exception for when the 6998 proposal is a DH group of NONE. [Issue #6] 7000 D.10. Changes from draft-ietf-ipsecme-ikev2bis-02 to 7001 draft-ietf-ipsecme-ikev2bis-03 7003 In section 2.4, change "The INITIAL_CONTACT notification, if sent, 7004 MUST be in the first IKE_AUTH request, not as a separate exchange 7005 afterwards; however, receiving parties need to deal with it in other 7006 requests." to "The INITIAL_CONTACT notification, if sent, MUST be in 7007 the first IKE_AUTH request or response, not as a separate exchange 7008 afterwards; receiving parties MAY ignore it in other messages." 7009 [Issue #53] 7011 Added to the security considerations: "Admission control is critical 7012 to the security of the protocol. For example, trust anchors used for 7013 identifying IKE peers should probably be different than those used 7014 for other forms of trust, such as those used to identify public web 7015 servers. Moreover, although IKE provides a great deal of leeway in 7016 defining the security policy for a trusted peer's identity, 7017 credentials, and the correlation between them, having such security 7018 policy defined explicitly is essential to a secure implementation." 7019 [Issue #61] 7021 Changed "[V+]" to "[V+][N+]" throughout Appendix C. [Issue #63] 7023 D.11. Changes from draft-ietf-ipsecme-ikev2bis-03 to 7024 draft-ietf-ipsecme-ikev2bis-04 7026 Throughout, removed the marks that showed where text from the 7027 Clarifications RFC was inserted, or where a "SHOULD" was demoted to 7028 weaker language. 7030 In section 1, added "IKEv2 was a change to the IKE protocol that was 7031 not backward compatible. In contrast, the current document not only 7032 provides a clarification of IKEv2, but makes minimum changes to the 7033 IKE protocol." [Issue #48] 7035 In 1.5, added "The recipient of this notification cannot tell whether 7036 the SPI is for AH or ESP, but this is not important because the SPIs 7037 are supposed to be different for the two." [Issue #35] 7039 In 1.5, added "(INVALID_MAJOR_VERSION is also a one-way message which 7040 is sent outside of an IKE SA, although it is sent as a response to 7041 the incoming IKE SA creation.)" [Issue #13] 7043 In 1.7, added "This document removes the allowance for rejecting 7044 messages where the payloads were not in the "right" order; now 7045 implementations MUST NOT reject them. This is due to the lack of 7046 clarity where the orders for th payloads are described." 7048 Added "The Message ID is reset to zero in the new IKE SA after the 7049 IKE SA is rekeyed" in the first paragraph of 2.2. [Issue #15] 7051 In 2.5, changed "implementations MUST send the payloads defined in 7052 this specification in the order shown in the figures in Section 2; 7053 implementations are explicitly allowed to reject as invalid a message 7054 with those payloads in any other order" to "implementations SHOULD 7055 send the payloads defined in this specification in the order shown in 7056 the figures in Section 2; implementations MUST NOT reject as invalid 7057 a message with those payloads in any other order". [Issue #16] 7058 [Issue #45] 7060 In 2.9, added "Maintenance of a system's SPD is outside the scope of 7061 IKE (see [PFKEY] for an example programming interface, although it 7062 only applies to IKEv1), though some implementations might update 7063 their SPD in connection with the running of IKE (for an example 7064 scenario, see Section 1.1.3)." This was actually done in -03 but not 7065 noted in the change notes. [Issue #64] [Issue #54] 7067 In 2.18, added "using SPIi, SPIr, Ni, and Nr from the new exchange" 7068 to the last sentence. 7070 In the last paragraph of 2.25, added "The SA that the initiator 7071 attempted to rekey is indicated by the SPI field in the Notify 7072 Payload, which is copied from the SPI field in the REYEY_SA 7073 notification." 7075 Removed INTERNAL_IP6_NBNS from 3.15.1. [Issue #44] 7077 Changed "The requested address is valid until there are no IKE_SAs 7078 between the peers" to "The requested address is valid as long as this 7079 IKE SA (or its rekeyed successors) requesting the address is valid." 7080 [Issue #43] 7082 D.12. Changes from draft-ietf-ipsecme-ikev2bis-04 to 7083 draft-ietf-ipsecme-ikev2bis-05 7085 Added the following near the end of 1.2: "If the failure is related 7086 to creating the IKE SA (for example, AUTHENTICATION_FAILED), the IKE 7087 SA is not created. Note that although the IKE_AUTH messages are 7088 encrypted and integrity protected, if the peer receiving this 7089 notification has not yet authenticated the other end (or if the peer 7090 fails to authenticate the other end for some reason), the information 7091 needs to be treated with caution. More precisely, assuming that the 7092 MAC verifies correctly, the sender of the error indication is known 7093 to be the responder of the IKE_SA_INIT exchange, but the sender's 7094 identity cannot be assured." [Issue #9] 7096 Added "Section 2.21 also covers error messages in great detail" near 7097 the beginning of 1.4. 7099 Added "Section 2.21 has been greatly expanded to cover the different 7100 cases where error responses are needed and the appropriate responses 7101 to them" to the end of 1.7. 7103 In 1.5, changed "There are two cases when such a one-way 7104 notification" to "There are two cases when a one-way notification". 7105 Also changed "notification" to "message" throughout this paragraph. 7107 In 2.8, changed "Note that, when rekeying, the new Child SA MAY have 7108 different traffic selectors and algorithms than the old one." to 7109 "Note that, when rekeying, the new Child SA SHOULD NOT have different 7110 traffic selectors and algorithms than the old one.". [Issue #12] 7112 Section 2.21 was replaced and significantly expanded to cover many 7113 different error situations. [Issue #26] 7115 Added 2.23.1, which covers how to handle NAT traversal when transport 7116 mode is requested. [Issue #28] 7118 In 3.3.2, after the table for tranform type 4, added "Although ESP 7119 and AH do not directly include a Diffie-Hellman exchange, a Diffie- 7120 Hellman group MAY be negotiated for the Child SA. This allows the 7121 peers to employ Diffie-Hellman in the CREATE_CHILD_SA exchange, 7122 providing perfect forward secrecy for the generated Child SA keys." 7123 [Issue #57] 7125 In 3.5, added "The Peer Authorization Database (PAD) as described in 7126 RFC 4301 [IPSECARCH] describes the use of the ID payload in IKEv2 and 7127 provides a formal model for the binding of identity to policy in 7128 addition to providing services that deal more specifically with the 7129 details of policy enforcement. The PAD is intended to provide a link 7130 between the SPD and the IKE security association management. See 7131 Section 4.4.3 of RFC 4301 for more details." [Issue #58] 7133 Added to the definition of "X.509 Certificate" in 3.6: "Note that 7134 with this encoding, if a chain of certificates needs to be sent, 7135 multiple CERT payloads are used, only the first of which holds the 7136 public key used to validate the sender's AUTH payload." [Issue 7137 #107]. 7139 In 3.14, added "When an authenticated encryption algorithm is used to 7140 protect the IKE SA, the construction of the encrypted payload is 7141 different that what is described here. See [RFC5282] for more 7142 information on authenticated encryption algorithms and their use in 7143 ESP." 7145 Added the last two paragraphs of 3.15 (on CFG_REQUEST and CFG_REPLY, 7146 and CFG_SET and CFG_ACK). Removed all of 2.19.1 which contained the 7147 same material and a lot of material that was duplicated from other 7148 parts of the document. [Issue #108] 7150 Added the following to 3.15.3: "Note that there is an additional 7151 document that discusses IPv6 configuration in IKEv2, [IPV6CONFIG]. 7152 At the present time, it is an experimental document, but there is a 7153 hope that with more implementation experience, it will gain the same 7154 standards treatment as this document." [Issue #47 and Issue #60] 7156 Reworded the acknowledgements to be more inclusive. 7158 D.13. Changes from draft-ietf-ipsecme-ikev2bis-05 to 7159 draft-ietf-ipsecme-ikev2bis-06 7161 Many small editorial nits fixed. 7163 Changed all the tables to only list the values that were defined in 7164 RFC 4306. Removed reserved and private use ranges. Also, a pointer 7165 to the IANA registry is given repeatedly. 7167 At the end of 1.3.1, added "See Section 2.21 for a list of error 7168 messages that might occur if creating a Child SA fails." 7170 In 1.3.2, made the response "HDR, SK {SA, Nr, KEr}", as it was 7171 supposed to be from earlier changes. [Issue #50] 7173 In 1.3.2, added "Once a peer receives a request to rekey an IKE SA or 7174 sends a request to rekey an IKE SA, it SHOULD NOT start any new 7175 CREATE_CHILD_SA exchanges on the IKE SA that is being rekeyed." 7176 [Issue #22] 7178 In 1.3.2, removed "[[ Note: this text may be changed in the future. 7179 ]]" 7181 Added "All of Section 2.25 was added to explain how to act when there 7182 are timing collisions when deleting and/or rekeying SAs." to 1.7. 7183 [Issue #22] 7185 In 2.8, split the third paragraph into two paragraphs to make the 7186 different types of rekeying clearer. Also, changed "The old IKE SA 7187 is then deleted" to "After the new equivalent IKE SA is created, the 7188 initiator deletes the old IKE SA". 7190 In 2.8, changed "The initiator MAY begin sending on an SA as soon as 7191 it processes the response" to "The initiator SHOULD begin sending on 7192 an SA as soon as it processes the response". 7194 Completely revised and expanded the second paragraph of 2.8.2 ("The 7195 case where both..."). [Issue #22] 7197 Changed the first parenthetical statement at the beginning of 2.15 to 7198 read "or MAC using a padded shared secret as the key, as described 7199 later in this section". Also, changed the formatting of the MAC 7200 calculation at the end of the section very slightly. 7202 Also in 2.15, in the description of the signed octets, fixed two 7203 lines. 7205 . . . 7206 InitiatorIDPayload = PayloadHeader | RestOfIDPayload 7207 RestOfInitIDPayload = IDType | RESERVED | InitIDData 7208 . . . 7210 becomes 7212 . . . 7213 InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload 7214 RestOfInitIDPayload = IDType | RESERVED | InitIDData 7215 . . . 7217 ...and the same change for the responder. 7219 In 2.23, removed the second-to-last bullet because it was 7220 accidentally left there when the last bullet was copied and expanded 7221 from it. 7223 Added 2.25 and its subsections. [Issue #22] 7225 Added to the end of 3.6: "Implementations MUST support the HTTP 7226 method for hash-and-URL lookup. The behavior of other URL methods is 7227 not currently specified, and such methods SHOULD NOT be used in the 7228 absence of a document specifying them." [Issue #117] 7230 In 3.7, removed "10" from the list of acceptable types for the 7231 "Certification Authority" field. [Issue #120] 7233 In 3.8, definition of RSA Digital Signature, added: "Implementations 7234 can use the certificates received from a given peer as a hint for 7235 selecting a mutually-understood hash function for the AUTH payload 7236 signature. Note, however, that the hash algorithm used in the AUTH 7237 payload signature doesn't have to be the same as any hash 7238 algorithm(s) used in the certificate(s)." [Isse #116] 7240 In 3.10.1, added 7242 TEMPORARY_FAILURE 7243 See section 2.25. 7245 CHILD_SA_NOT_FOUND 7246 See section 2.25. 7248 Also added these to the IANA considerations in section 6. [Issue 7249 #22] 7251 In 3.15, changed "Requestors MUST ignore returned attributes that 7252 they do not recognize" to "Unrecognized or unsupported attributes 7253 MUST be ignored in both requests and responses". This brings back 7254 some text that was removed a few iterations ago. 7256 In 4, changed "If an implementation does support issuing such 7257 requests" to "If an implementation does support issuing such requests 7258 and its policy requires using temporary IP addresses". 7260 In 8 (Refereneces), changed the reference for AEAD from RFC 5116 to 7261 RFC 5282. Also added IKEV2IANA as a normative reference. Also 7262 changed the FTP URLs to the RFC Editor to HTTP references. 7264 D.14. Changes from draft-ietf-ipsecme-ikev2bis-06 to 7265 draft-ietf-ipsecme-ikev2bis-07 7267 These changes were made during and after WG Last Call. 7269 Many small editorial nits fixed. 7271 In 1.2, added "(A man-in-the-middle who cannot complete the IKE_AUTH 7272 exchange can nonetheless see the identity of the initiator.)" 7274 In the table in 1.2, added " (not a payload)" to "IKE Header" because 7275 the other items are, in fact, payloads. Also changed "E Encrypted" 7276 to "SK Encrypted and Authenticated". 7278 Removed "When an IKE SA is not created, the error message return 7279 SHOULD NOT be encrypted because the other party will not be able to 7280 authenticate that message." from the end of 1.3.1. [Issue #127] 7282 In 1.3.1, added "An IPCOMP_SUPPORTED notification, covered in 7283 Section 2.22, can also be included in the exchange." 7285 In 1.3.2, changed "New initiator and responder SPIs are supplied in 7286 the SPI fields of the SA payload." to "A new initiator SPI is 7287 supplied in the SPI field of the SA payload." Also added "A new 7288 responder SPI is supplied in the SPI field of the SA payload." a few 7289 paragraphs down. 7291 In 1.3.3, changed the figure for the initiator from: 7293 Initiator Responder 7294 ------------------------------------------------------------------- 7295 HDR, SK {N, SA, Ni, [KEi], 7296 TSi, TSr} --> 7298 to: 7300 Initiator Responder 7301 ------------------------------------------------------------------- 7302 HDR, SK {N(REKEY_SA), SA, Ni, [KEi], 7303 TSi, TSr} --> 7305 Added to 1.4: "Note that some informational messages, not exchanges, 7306 can be sent outside the context of an IKE SA." 7308 In 1.5, changed "it MAY send an informational message" to "it MAY 7309 indicate this with a Notify payload". Made a similar change in the 7310 following paragraph. 7312 In 1.5, changed "If the receiving node has an active IKE SA to the IP 7313 address from whence the packet came, it MAY send a notification of 7314 the wayward packet over that IKE SA in an INFORMATIONAL exchange. If 7315 it does not have such an IKE SA, it MAY indicate this with a Notify 7316 payload without cryptographic protection to the source IP address." 7317 to "If the receiving node does not have an active IKE SA to the IP 7318 address from whence the packet came, it MAY send a notification of 7319 the wayward packet with a Notify payload without cryptographic 7320 protection to the source IP address." 7322 Fixed the boilerplate wording in 1.6. 7324 Added and clarified materila in 1.7. Also added "Significant" to the 7325 title of the section because it cannot list all the differences. 7326 [Issue #126] 7328 In 2.1, changed "IKE is a reliable protocol, in the sense that the 7329 initiator MUST retransmit a request until either it receives a 7330 corresponding reply OR it deems the IKE security association to have 7331 failed and it discards all state associated with the IKE SA and any 7332 Child SAs negotiated using that IKE SA." to "IKE is a reliable 7333 protocol: the initiator MUST retransmit a request until either it 7334 receives a corresponding reply, or until it deems the IKE SA to have 7335 failed. In the latter case, the initiator discards all state 7336 associated with the IKE SA and any Child SAs that were negotiated 7337 using that IKE SA." 7339 In 2.1, removed ", and the zero non-ESP marker" because it was 7340 confusing. 7342 In 2.2, rearranged the paragraphs beginning "The Message ID is a 32- 7343 bit.." and "Throughout this document, "initiator"...". 7345 In 2.5, changed "implementations SHOULD send the payloads defined in 7346 this specification in the order shown in the figures in Section 2" to 7347 "...the figures in Sections 1 and 2". 7349 In 2.6, changed "Also, incorporating Ni" to "Also, incorporating 7350 SPi". 7352 In 2.6, removed the paragraph that started "In addition to cookies" 7353 because it was redundant with information in 2.7 that was stated 7354 better. 7356 In 2.8, changed "It should do so if there has been no traffic since 7357 the last time the SA was rekeyed." to "It can also do so if ..." 7359 In 2.8.1, changed NO_PROPOSAL_CHOSEN to CHILD_SA_NOT_FOUND in the 7360 paragraph that starts "To B, it looks like A is trying to rekey" and 7361 the artwork after it. 7363 In 2.8.2, changed "In this case, when the peer that did not notice 7364 the simultaneous rekey gets the request to rekey the IKE SA that it 7365 has already successfully rekeyed, it MUST return 7366 TEMPORARY_FAILURE..." to "...it SHOULD return TEMPORARY_FAILURE...". 7367 [Issue #131] 7369 In 2.9, changed "To enable the responder to choose the appropriate 7370 range in this case, if the initiator has requested the SA due to a 7371 data packet, the initiator SHOULD include as the first traffic 7372 selector in each of TSi and TSr a very specific traffic selector 7373 including the addresses in the packet triggering the request" to "If 7374 the initiator requests an SA because it wants to sen a data packet, 7375 including the specific addresses in the packet triggering the request 7376 in the first traffic selector in both TSi and TSr enables the 7377 responder to choose the appropriate range". 7379 In 2.9, removed "Such misconfigurations should be recorded in error 7380 logs." [Issue #125] 7382 In 2.9, changed the end of the paragraph that starts "It is possible 7383 for the responder's policy..." to actually match the scenario, which 7384 is not a triggering packet. 7386 In 2.9, changed the "192.0.1" example network to "198.51.100" and 7387 removed the parenthetical comment about the old ones. Did the same 7388 change in 3.15.2 and 5.1. 7390 Rewrote parts of 2.13 to make it clearer when general functions and 7391 specific functions were being discussed. Also cleaned up 7392 inconsistent use of "prf" and "PRF" throughout the document. 7394 In 2.18, added "to generate SKEYSEED" to the end of "The old and new 7395 IKE SA...", and added "and using the new IKE SA's PRF" to the end of 7396 the last paragraph. [Issue #121] 7398 At the end of 2.19, removed some redundancy and split the final 7399 paragraph into two. 7401 In 2.21.2, removed "NOTE FOR WG DISCUSSION: Having other payloads in 7402 the message is allowed but there are none suggested. One WG member 7403 mentioned the possibility of adding a DELETE payload when the error 7404 is sent in a separate INFORMATIONAL exchange. Do we want to allow 7405 such additional payloads that have operational semantics?" 7407 In 2.23, changed "float to" to "use". 7409 In 2.23, changed "In the case of a mismatching 7410 NAT_DETECTION_SOURCE_IP hash, the recipient MAY reject the connection 7411 attempt if NAT traversal is not supported." to "In the case there is 7412 a mismatch of the NAT_DETECTION_SOURCE_IP hash with all of the 7413 NAT_DETECTION_SOURCE_IP payloads received, the recipient MAY reject 7414 the connection attempt if NAT traversal is not supported." Also 7415 removed the bullet that started "If the NAT_DETECTION_DESTINATION_IP 7416 payload received does not match the hash of the destination IP" 7417 because it was already covered above. 7419 In 2.23, removed "so this method MUST NOT be used when MOBIKE is 7420 used" but left in the reference to section 3.8 in MOBIKE so that 7421 readers can see what is and is not allowed. 7423 In 2.23.1, in the first bullet for the responder in transport mode, 7424 changed "Store the original traffic selector IP addresses as received 7425 source and destination address in case we need to undo address 7426 substitution." to "Store the original traffic selector IP addresses 7427 as received source and destination address, both in case we need to 7428 undo address substitution, and to use as the "real source and 7429 destination address" specified by [UDPENCAPS], and for TCP/UDP 7430 checksum fixup." 7432 In 2.25, changed: "A peer that receives a CHILD_SA_NOT_FOUND 7433 notification SHOULD silently delete the Child SA and send a request 7434 to create a new Child SA from scratch." to "A peer that receives a 7435 CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child SA 7436 (if it still exists) and send a request to create a new Child SA from 7437 scratch (if the Child SA does not yet exist)." 7439 In the flags description in 3.1, replaced "The bits are defined LSB 7440 first, so bit 0 would be the least significant bit of the Flags 7441 octet. " with "The bits are as follows: 7443 +-+-+-+-+-+-+-+-+ 7444 |X|X|R|V|I|X|X|X| 7445 +-+-+-+-+-+-+-+-+ 7447 Also added: ""X" bits MUST be cleared when sending and MUST be 7448 ignored on receipt." Then removed the bit positions from the 7449 description. 7451 In 3.1, added "See Section 2.5 for more information on this bit" to 7452 the end of the Critical bit description. 7454 In 3.2, changed "E Encrypted" to "SK Encrypted and Authenticated". 7456 In 3.3, fourth paragraph, changed "Combined-mode ciphers include both 7457 integrity and encryption in a single encryption algorithm, and are 7458 not allowed to be offered with a separate integrity algorithm other 7459 than "none"." to "Combined-mode ciphers include both integrity and 7460 encryption in a single encryption algorithm, and MUST either offer no 7461 integrity algorithm or a single integrity algorithm of "none", with 7462 no integrity algorithm being the RECOMMENDED method." Also, removed 7463 "If an algorithm that combines encryption and integrity protection is 7464 proposed, it MUST be proposed as an encryption algorithm and an 7465 integrity protection algorithm MUST NOT be proposed" from the 7466 following paragraph. [Issue #122] 7468 In 3.3.6, moved the last sentence from the second paragraph and moved 7469 it to third paragraph. It now reads "If one of the proposals offered 7470 is for the Diffie-Hellman group of NONE, the responder MUST ignore 7471 the initiator's KE payload and omit the KE payload from the 7472 response." 7474 In 3.4, added "See also Section 1.2 and Section 2.7." 7476 In 3.6, changed "Certificate payloads SHOULD be included in an 7477 exchange if certificates are available to the sender unless the peer 7478 has indicated an ability to retrieve this information from elsewhere 7479 using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload." to "Certificate 7480 payloads SHOULD be included in an exchange if certificates are 7481 available to the sender. The Hash and URL formats of the Certificate 7482 payloads should be used in case the peer has indicated an ability to 7483 retrieve this information from elsewhere using an 7484 HTTP_CERT_LOOKUP_SUPPORTED Notify payload." 7486 In 3.10.1, added "More information on error handling can be found in 7487 Section 2.21." 7489 Added TEMPORARY_FAILURE and CHILD_SA_NOT_FOUND to the table in 7490 3.10.1. 7492 Replaced the Start Port and End Port discussions in 3.13.1 with ones 7493 that describe the ICMP and ICMPv6 in more detail. Also replaced the 7494 two paragraphs starting "The traffic selector types 7..." and 7495 "Traffic selectors can use" with "he traffic selector types 7 and 8 7496 can also refer to ICMP or ICMPv6 type and code fields, as well as MH 7497 Type fields for the IPv6 mobility header [MIPV6]. Note, however, 7498 that neither ICMP nor MIPv6 packets have separate source and 7499 destination fields. The method for specifying the traffic selectors 7500 for ICMP and MIPv6 is shown by example in Section 4.4.1.3 of 7501 [IPSECARCH]". [Issue #129] 7503 In 3.15.1, made the table heading "Multi-Valued" instead of "Valued". 7505 In 3.15.1, added "(except INTERNAL_ADDRESS_EXPIRY and 7506 INTERNAL_IP6_NBNS which were removed by this document)" to the bullet 7507 point for "Value" because those two were removed from the table. 7509 Added new paragraph at the end of 3.15.4 to suggest what the 7510 initiator should do if they don't get enough addresses. [Issue #124] 7512 In 5, changed "An implementation using EAP MUST also use strong 7513 authentication" back to "An implementation using EAP MUST also use a 7514 public-key-based authentication" soas not to change mandatory 7515 requirements from RFC 4306. 7517 Added to section 6: "Two items are removed from the IKEv2 7518 Configuration Payload Attribute Types table: INTERNAL_IP6_NBNS and 7519 INTERNAL_ADDRESS_EXPIRY." 7521 Removed Appendix C, "Significant Changes from RFC 4306", because this 7522 information is actually going in section 1.7. 7524 In C.5, changed the figure from: 7526 request --> SA, Ni, [KEi] 7527 [V+][N+] 7529 response <-- SA, Nr, [KEr] 7530 [V+][N+] 7532 to 7534 request --> SA, Ni, KEi 7535 [V+][N+] 7537 response <-- SA, Nr, KEr 7538 [V+][N+] 7540 D.15. Changes from draft-ietf-ipsecme-ikev2bis-07 to 7541 draft-ietf-ipsecme-ikev2bis-08 7543 Lots more small editorial issues fixed. 7545 These changes were made after WG Last Call, mostly to close out open 7546 issues. 7548 In 1.2, changed "The recipients of messages 3 and 4 MUST verify that 7549 all signatures and MACs are computed correctly and that the names in 7550 the ID payloads correspond to the keys used to generate the AUTH 7551 payload." to "The recipients of messages 3 and 4 MUST verify that all 7552 signatures and MACs are computed correctly. If either side uses a 7553 shared secret for authentication, the names in the ID payload MUST 7554 correspond to the key used to generate the AUTH payload." 7556 In 1.3, added "This notify can also be used to reject IKE SA rekey" 7557 to the discussion of sending the NO_ADDITIONAL_SAS notification. 7558 [Issue #132] 7560 In 1.3.2, added a pointer to 2.18; vice versa. 7562 Added to 1.3.3: "The notifications described in Section 1.3.1 may 7563 also be sent in a rekeying exchange. Usually these will be the same 7564 notifications that were used in the original exchange; for example, 7565 when rekeying a transport mode SA, the USE_TRANSPORT_MODE 7566 notification will be used." [Issue #133] 7568 In 1.4.1, replaced the last paragraph ("Half-closed ESP or AH 7569 connections...") with two paragraphs that clarify deleting IKE SAs as 7570 compared to half-closed ESP or AH connections. 7572 In 1.5, changed "If the receiving node does not have an active IKE SA 7573 to the IP address from whence the packet came, it" to "The receiving 7574 node". 7576 In 1.5, replaced the last three paragraphs ("There are two cases...", 7577 "In case of INVALID_IKE_SPI...", and "In case of INVALID_SPI...") 7578 with a more detailed description. [Issue #143] 7580 In 1.7, added "Section 2.23 clarified that, in NAT traversal, now 7581 both UDP encapsulated IPsec packets and non-UDP encapsulated IPsec 7582 packets packets need to be understood when receiving." 7584 Added a new paragraph at the end of 2.1 ("The retransmission policy 7585 for one-way messages is somewhat different..."). [Issue #147] 7587 Replaced the first paragraph in 2.6 with a shorter one, and moved the 7588 historical material to the end of the section. [Issue #148] 7590 In 2.6.1, removed "SAi1 and" from "For instance, if the responder 7591 includes the SAi1 and KEi payloads in cookie calculation..." [Issue 7592 #134] 7594 In 2.7, moved the paragraph that begins "Because the initiator sends 7595 its Diffie-Hellman value in the IKE_SA_INIT" to 1.2. [Issue #144] 7597 In 2.8, replaced "MAY send a dummy message on a newly created SA" 7598 with "MAY send a dummy ESP message on a newly created ESP SA". 7599 [Issue #154] 7601 In 2.8, changed "...it has received a cryptographically valid message 7602 on the new SA..." to "...it has received a cryptographically valid 7603 message on the other half of the SA pair...". [Issue #149] 7605 In 2.8.2, changed "The new IKE SA containing the lowest nonce 7606 inherits the Child SAs" to "The new IKE SA containing the lowest 7607 nonce SHOULD be deleted by the node that created it, and the other 7608 suriving new IKE SA MUST inherit all the Child SAs". [Issue #135] 7610 In 2.8.2, added "In addition to normal simultaneous rekeying cases, 7611 there is a special case where one peer finishes its rekey before it 7612 even notices that other peer is doing a rekey." [Issue #171] 7614 In 2.8.2, added "Support of the TEMPORARY_FAILURE notification is not 7615 negotiated, so older peers may receive these notifications. In that 7616 case, they will treat it the same as any other unknown error 7617 notification, and will stop the exchange. Because the other peer has 7618 already rekeyed the exchange, doing so does not have any ill 7619 effects." [Issue #150] 7621 In 2.9, reverted to using a SHOULD for trigger packets. Replaced "If 7622 the initiator requests an SA because it wants to send a data packet, 7623 including the specific addresses in the packet triggering the request 7624 in the first traffic selector in both TSi and TSr enables the 7625 responder to choose the appropriate range" with "To enable the 7626 responder to choose the appropriate range in this case, if the 7627 initiator has requested the SA due to a data packet, the initiator 7628 SHOULD include as the first traffic selector in each of TSi and TSr a 7629 very specific traffic selector including the addresses in the packet 7630 triggering the request." [Issue #155] 7632 In 2.14, changed "only the first 64 bits of Ni and the first 64 bits 7633 of Nr are used in the calculation" to "only the first 64 bits of Ni 7634 and the first 64 bits of Nr are used in calculating SKEYSEED, but all 7635 the bits are used for input to the prf+ function". [Issue #138] 7637 Added to the end of 2.15: "There are two types of EAP authentication 7638 (described in Section 2.16), and each type uses different values in 7639 the AUTH computations shown above. If the EAP method is key- 7640 generating, substitute MSK for the Shared Secret in the computation. 7641 For non-key-generating methods, substitute SK_pi and SK_pr, 7642 respectively, for the Shared Secret in the two AUTH computations." 7643 [Issue #151] 7645 In 2.16, changed "the authenticated identity has to be sent" to "the 7646 authenticated identity, if different from that in the IDi payload, 7647 has to be sent". [Issue #174] 7649 In 2.17, significantly changed the discussion of the order in which 7650 keying material is taken from KEYMAT. The result is the same, but 7651 the description is quite different, and now also refers to ROHC. 7652 [Issue #139] 7654 In 2.21, changed "Only authentication failures 7655 (AUTHENTICATION_FAILED)..." to "Only authentication failures 7656 (AUTHENTICATION_FAILED and EAP failure)...". Also added "If the 7657 exchange is terminated with EAP Failure, an AUTHENTICATION_FAILED 7658 notification is not sent." [Issue #152 and #160] 7660 In 2.21.2, removed INVALID_SELECTORS from the list of things that are 7661 returned from the piggybacked exchanges. [Issue #166] 7663 In 2.23, changed "In the case of NAT traversal, the Traffic Selectors 7664 MUST contain exactly one IP address, which is then used as the 7665 original IP address" to "In the case of transport mode NAT traversal, 7666 the traffic selectors MUST contain exactly one IP address, which is 7667 then used as the original IP address". [Issue #136] 7669 In 2.23, completely replaced the paragraph that begins "An initiator 7670 can use port 4500". [Issue #146] 7672 In 2.23, changed "In addition, firewalls may be configured to pass 7673 IPsec traffic over UDP but not ESP/AH or vice versa." to "In 7674 addition, firewalls may be configured to pass UDP-encapsulated IPsec 7675 traffic but not plain, unencapsulated ESP/AH or vice versa". 7677 In 2.23, changed "SPIs, source IP address, and port" to "SPIs, source 7678 or recipient IP address respectively, and port". [Issue #162]. 7680 In 2.23, completely replaced the last paragraph ("There are cases 7681 where a NAT box..."). [Issue #175] 7683 In 2.23.1, changed "When the client starts creating the IKEv2 SA and 7684 Child SA for sending traffic to the server, it has a triggering 7685 packet with source IP address of IP1, and a destination IP address of 7686 IPN2" to "...it may have a triggering packet...". Changed "The first 7687 traffic selector of TSi and TSr SHOULD have very specific traffic 7688 selectors including protocol and port numbers from the packet 7689 triggering the request" to "...SHOULD have very specific traffic 7690 selectors including protocol and port numbers, such as from the 7691 packet...". The same change is made in the third bullet of the 7692 client list near the end of the section. [Issue #173] 7694 At the beginning of the second paragraph of 3.1, changed "The 7695 Recipient SPI" to the "The responder's SPI". 7697 In 3.1, changed "Payloads are processed in the order in which they 7698 appear in an IKE message by invoking the appropriate processing 7699 routine according to the "Next Payload" field in the IKE header and 7700 subsequently according to the "Next Payload" field in the IKE payload 7701 itself until a "Next Payload" field of zero indicates that no 7702 payloads follow" to "Payloads are identified in the order in which 7703 they appear in an IKE message by looking in the "Next Payload" field 7704 in the IKE header, and subsequently according to the "Next Payload" 7705 field in the IKE payload itself until a "Next Payload" field of zero 7706 indicates that no payloads follow". [Issue #159] 7708 In 3.1, added "including multiple sessions per peer" to the end of 7709 the second paragraph. 7711 In 3.2, changed "In the header of an Encrypted payload, the Next 7712 Payload field is set to the payload type of the first contained 7713 payload (instead of 0)" to "In the header of an Encrypted payload, 7714 the Next Payload field is set to the payload type of the first 7715 contained payload (instead of 0); conversely, the Next Payload field 7716 of the last contained payload is set to zero." [Issue #164] 7718 In 3.3, changed the example of the two proposals and added a worked- 7719 out figure for them. [Issue #157] 7721 In 3.3.2, changed PRF_HMAC_TIGER to UNSPECIFIED. 7723 In 3.3.5, added "unless that length exceeds two bytes" to the end of 7724 "Attributes described as fixed length MUST NOT be encoded using the 7725 variable-length encoding". [Issue #167] 7727 In 3.3.6, changed "The initiator of an exchange MUST check that the 7728 accepted offer is consistent with one of its proposals, and if not 7729 that response MUST be rejected" to "The initiator of an exchange MUST 7730 check that the accepted offer is consistent with one of its 7731 proposals, and if not MUST terminate the exchange". 7733 In 3.3.6, changed "Similarly, if the responder receives a transform 7734 that contains a Transform Attribute it does not understand..." to 7735 "Similarly, if the responder receives a transform that it does not 7736 understand, or one that contains a Transform Attribute it does not 7737 understand...". 7739 In 3.4, changed "The length of the Diffie-Hellman public value MUST 7740 be equal to the length of the prime modulus over which the 7741 exponentiation was performed, prepending zero bits to the value if 7742 necessary" to "The length of the the Diffie-Hellman public value for 7743 MODP groups..." (because it is not true for elliptic curve groups). 7745 In 3.5, changed "IPv6-only implementations MAY be configurable to 7746 send only ID_IPV6_ADDR" to "IPv6-only implementations MAY be 7747 configurable to send ID_IPV6_ADDR instead of ID_IPV6_ADDR for IP 7748 addresses." 7750 In 3.6, replaced "Use the following ASN.1 definition for an X.509 7751 bundle" by "The "Hash and URL of a bundle" type uses the following 7752 ASN.1 definition for the X.509 bundle". 7754 In 3.7, removed "If multiple CAs are trusted and the certificate 7755 encoding does not allow a list, then multiple Certificate Request 7756 payloads would need to be transmitted". 7758 In 3.14, added "This payload is also called the "Encrypted and 7759 Authenticated" payload." 7761 In 3.16, removed the table of EAP types and replaced it with "Note 7762 that since IKE passes an indication of initiator identity in message 7763 3 of the protocol, the responder SHOULD NOT send EAP Identity 7764 requests (type 1). The initiator MAY, however, respond to such 7765 requests if it receives them." [Issue #153] 7767 In 3.16, removed "In other messages, this field MAY be set to any 7768 value" from the bullet defining Identifier. [Issue #168] 7770 In 4, changed "Ability to support various types of legacy 7771 authentication" to "Ability to support EAP-based authentication". 7773 In section 4, removed two sentences ("A minimal IPv4 responder 7774 implementation..." and "A minimal IPv4 initiator...") because they 7775 were redundant with the preceding text but also used new terms that 7776 were not defined. [Issue #172] 7778 In 5, removed "or overrun of either endpoint". [Issue #169] 7780 In 6, added that IANA should change "46 Encrypted E" to "46 Encrypted 7781 SK". 7783 In 8.2, updated the pointer for IPV6CONFIG to RFC 5739. 7785 D.16. Changes from draft-ietf-ipsecme-ikev2bis-08 to 7786 draft-ietf-ipsecme-ikev2bis-09 7788 These changes came during IETF Last Call. 7790 Fixed more minor editorial nits. 7792 Throughout, changed "#" in the name of variables to "Num" or "Number" 7793 because "#" is US-centric and confusing. 7795 Throughout, changed "denial of service" to "DoS" after the first 7796 definition to be consistent. 7798 In many places, changed "message 3" to "the first message in the 7799 IKE_AUTH exchange". 7801 In 1, changed 'The pair is called an "exchange"' to 'The pair is 7802 called an "exchange", and is sometimes called "request/response"'. 7803 Then changed most of the rest of "request/response" to "exchange" 7804 throughout the document. 7806 In 1, changed "We call the first messages establishing an IKE SA 7807 IKE_SA_INIT and IKE_AUTH exchanges and subsequent IKE exchanges 7808 CREATE_CHILD_SA or INFORMATIONAL exchanges" to "The first exchange of 7809 messages establishing an IKE SA are called the IKE_SA_INIT and 7810 IKE_AUTH exchanges; subsequent IKE exchanges are called the 7811 CREATE_CHILD_SA or INFORMATIONAL exchanges". 7813 In 1.2, added "see Section 2.13 and Section 2.14 for details on the 7814 key derivation". 7816 In 1.2, copied text from 2.2 to describe what a Message ID is before 7817 we start talking about it. 7819 In 1.2, added "The traffic selectors (TSi and TSr) are discussed in 7820 Section 2.9" because it was ignored in the section. 7822 In 1.2, changed "The recipients of messages 3 and 4 MUST verify..." 7823 to "Both parties in the IKE_SA_INIT exchange MUST verify...". 7825 In 1.2, changed "The list of responses..." to "Notify message 7826 types...". 7828 In 1.2, changed "If the failure is related to creating the IKE SA 7829 (for example, AUTHENTICATION_FAILED)" to "If the failure is related 7830 to creating the IKE SA (for example, an AUTHENTICATION_FAILED Notify 7831 error message is returned)". 7833 In 1.2, changed "the sender of the error indication" to "the sender 7834 of the error Notify message". 7836 In 1.3, removed the paragraph starting "All messages following..." 7837 because it is a duplicate from 1.2. 7839 In 1.3, changed "this notify" to "this notification". 7841 In 1.3, removed "The CREATE_CHILD_SA is also used for rekeying IKE 7842 SAs and Child SAs" because it is redundant with the first sentence of 7843 the section. 7845 In 1.3.1, changed "Failure of an attempt" to "A failed attempt". 7847 In 1.5, added "these flags are described in Section 3.1" because they 7848 had not beed defined yet. 7850 In 2.2, added "Retransmission of a message MUST use the same Message 7851 ID as the original message." 7853 At the end of 2.3, changed "is optional" to "is OPTIONAL". 7855 In 2.4, changed "Every implementation MUST be capable of responding 7856 to an INFORMATIONAL exchange, but a minimal implementation MAY 7857 respond to any INFORMATIONAL message with an empty INFORMATIONAL 7858 response" to "Every implementation MUST be capable of responding to 7859 an INFORMATIONAL exchange, but a minimal implementation MAY respond 7860 to any request in the INFORMATIONAL exchange with an empty response". 7862 In 2.4, changed "An implementation MUST NOT continue sending on any 7863 SA if some failure prevents it from receiving on all of the 7864 associated SAs" to "An implementation needs to stop sending on any 7865 SA..." because there is no way for the implementation to know if 7866 "some failure" has occured. 7868 In 2.4, changed "If Child SAs can fail independently from one another 7869 without the associated IKE SA being able to send a delete message, 7870 then they MUST be negotiated by separate IKE SAs" to "If a system 7871 creates Child SAs that can fail independently from one another 7872 without the associated IKE SA being able to send a delete message, 7873 then the system MUST negotiate such Child SAs using separate IKE 7874 SAs". [Issue #181] 7876 In 2.6, changed "will cause two packets:" to "will cause two packets 7877 to be sent:". 7879 In 2.6, added "possibly using exponential back-off" to the discussion 7880 of limiting the number of cookies it sends. 7882 Moved the paragraph that starts "When the IKE_SA_INIT exchange does 7883 not result" from 2.7 to 2.6. Also changed"the responder's SPI will 7884 be zero" to "the responder's SPI will be zero also in the response 7885 message". 7887 In 2.8.1, removed "lexicographical" because it was undefined and 7888 unnecessary. 7890 In 2.8.2, last paragraph: Change the beginning of the sentence and 7891 changed "older peers may receive these notifications" to "older peers 7892 that implement RFC 4306 but not this document may receive these 7893 notifications". 7895 Fixed the first two paragraphs of 2.9 to talk about PFKEY in the 7896 correct context. 7898 In 2.9, changed "reject the request with a status of 7899 SINGLE_PAIR_REQUIRED" with "reject the request with a 7900 SINGLE_PAIR_REQUIRED Notify message". 7902 In 2.13, changed "The preferred key size is used as the length of 7903 SK_d, SK_pi, and SK_pr" to "The preferred key size MUST be used as 7904 the length of SK_d, SK_pi, and SK_pr". 7906 In 2.14, changed "The lengths of SK_d, SK_pi, and SK_pr are the 7907 preferred key length of the agreed-to PRF" to "The lengths of SK_d, 7908 SK_pi, and SK_pr MUST be the preferred key length of the agreed-to 7909 PRF". 7911 In 2.15, moved "In the above calculation, IDi' and IDr' are the 7912 entire ID payloads excluding the fixed header" earlier and removed 7913 redundant definitions. 7915 In 2.16, added "(Note that the AUTH payload is required for non-EAP 7916 authentication, and is thus not marked as optional in the rest of 7917 this document.)" 7919 In 2.17, added a reference to [ROHCV2]. 7921 In 2.20, removed "to prevent trolling" because it is not a widely- 7922 known term. 7924 In 2.21.2, added "using the Vendor ID payload" to the last sentence. 7926 In 2.23, clarified the paragraph that starts "An initiator can 7927 use..." in many places, saying that it is UDP encapsulated ESP. 7929 In the bulleted list in 2.23 that lists what implementations that 7930 support NAT traversal must do, removed "IKE MUST listen on port 4500 7931 as well as port 500. IKE MUST respond to the IP address and port 7932 from which packets arrived". That requirement applies to all IKE 7933 implementations. 7935 In 2.23, changed "these payloads" to "the NAT_DETECTION_SOURCE_IP or 7936 NAT_DETECTION_DESTINATION_IP payloads". 7938 Throughout subsections of 3, added ", unsigned integer" in 7939 definitions of multi-octet items such as Message ID and Payload 7940 Length. 7942 In 3.1, added "(with one exception; see Section 2.21.2)" to the 7943 discussion of the Response flag. 7945 In 3.3.1, changed "the SPI is obtained from outer header" to "the SPI 7946 is obtained from outer IP header". 7948 In 3.3.6, changed "If one of the proposals offered is for the Diffie- 7949 Hellman group of NONE, the responder MUST ignore the initiator's KE 7950 payload and omit the KE payload from the response" to "If one of the 7951 proposals offered is for the Diffie-Hellman group of NONE, and the 7952 responder selects that Diffie-Hellman group, then it MUST ignore the 7953 initiator's KE payload and omit the KE payload from the response". 7954 [Issue #176] 7956 In 3.5, changed "[X.501]" and "[X.509]" to "[PKIX]". Also removed 7957 those two now-unneeded references. [Issue #183] 7959 In 3.5, changed "IPv6-only implementations MAY be configurable to 7960 send only ID_IPV6_ADDR instead of ID_IPV6_ADDR for IP addresses" to 7961 "IPv6-only implementations MAY be configurable to send only 7962 ID_IPV6_ADDR instead of ID_IPV4_ADDR for IP addresses". 7964 In 3.5, changed "and MUST be configurable to accept all of these 7965 types" to "and MUST be configurable to accept all of these four 7966 types". [Issue #186] 7968 In 3.6, changed "MUST be capable of being configured to send and 7969 accept the two Hash and URL formats (with HTTP URLs)" to "MUST be 7970 capable of being configured to send and accept the Hash and URL 7971 format (with HTTP URLs)" because there is only one format. 7973 At the beginning of 3.16, changed "The full set of acceptable values 7974 for the payload is defined elsewhere, but a short summary of RFC 3748 7975 is included here to make this document stand alone in the common 7976 cases" to "When using EAP, an appropriate EAP method needs to be 7977 selected. Many of these methods have been defined, specifying the 7978 protocol's use with various authentication mechanisms. EAP method 7979 types are listed in [EAP-IANA]. A short summary of the EAP format is 7980 included here for clarity.". Also added the reference to [EAP-IANA] 7981 to the informative references. [Issue #187] 7983 In 4, changed "There are a series of optional features that can 7984 easily be ignored by a particular implementation if it does not 7985 support that feature. Those features include:" to "The following are 7986 some of the features that can be omitted in a minimal 7987 implementation:". 7989 In the references, moved [AEAD] from informative to normative. 7991 In Appendix B, changed "The strength supplied by group one may not be 7992 sufficient for the mandatory-to-implement encryption algorithm and is 7993 here for historic reasons" to "The strength supplied by group 1 may 7994 not be sufficient for typical uses and is here for historic reasons". 7996 D.17. Changes from draft-ietf-ipsecme-ikev2bis-09 to 7997 draft-ietf-ipsecme-ikev2bis-10 7999 Small editorial changes. 8001 D.18. Changes from draft-ietf-ipsecme-ikev2bis-10 to 8002 draft-ietf-ipsecme-ikev2bis-11 8004 Changes made during IESG review. 8006 In 1.7, changed "The clarifications are mostly based on [Clarif]" to 8007 "Many of the clarifications are based on [Clarif]". 8009 Added to 1.7: The small number of technical changes listed here are 8010 not expected to affect RFC 4306 implementations that have already 8011 been deployed at the time of publication of this document. 8013 Added to 3.3.4: At the time of publication of this document, 8014 [RFC4307] specifies these suites, but note that it might be updated 8015 in the future, and other RFCs might specify different sets of suites. 8017 In 8.1, added normative references for [HTTP], [RFC4307], and [URLS]. 8019 Editorial: changed "elliptical curve" to "elliptic curve". 8021 Authors' Addresses 8023 Charlie Kaufman 8024 Microsoft 8025 1 Microsoft Way 8026 Redmond, WA 98052 8027 US 8029 Phone: 1-425-707-3335 8030 Email: charliek@microsoft.com 8032 Paul Hoffman 8033 VPN Consortium 8034 127 Segre Place 8035 Santa Cruz, CA 95060 8036 US 8038 Phone: 1-831-426-9827 8039 Email: paul.hoffman@vpnc.org 8041 Yoav Nir 8042 Check Point Software Technologies Ltd. 8043 5 Hasolelim St. 8044 Tel Aviv 67897 8045 Israel 8047 Email: ynir@checkpoint.com 8049 Pasi Eronen 8050 Nokia Research Center 8051 P.O. Box 407 8052 FIN-00045 Nokia Group 8053 Finland 8055 Email: pasi.eronen@nokia.com