idnits 2.17.00 (12 Aug 2021) /tmp/idnits2129/draft-kivinen-ipsecme-ikev2-rfc5996bis-03.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: ---------------------------------------------------------------------------- No issues found here. 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. 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, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 25, 2014) is 2948 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CERTREQ' is mentioned on line 2370, but not defined == Missing Reference: 'KEi' is mentioned on line 6344, but not defined == Missing Reference: 'KEr' is mentioned on line 6352, but not defined == Missing Reference: 'CP' is mentioned on line 783, but not defined -- Looks like a reference, but probably isn't: '0' on line 4333 -- Looks like a reference, but probably isn't: '1' on line 4334 == Missing Reference: 'IDr' is mentioned on line 6307, 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 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 4282 (ref. 'NAI') (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 12 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: 5996 (if approved) P. Hoffman 5 Intended status: Standards Track VPN Consortium 6 Expires: October 27, 2014 Y. Nir 7 Check Point 8 P. Eronen 9 Independent 10 T. Kivinen 11 INSIDE Secure 12 April 25, 2014 14 Internet Key Exchange Protocol Version 2 (IKEv2) 15 draft-kivinen-ipsecme-ikev2-rfc5996bis-03.txt 17 Abstract 19 This document describes version 2 of the Internet Key Exchange (IKE) 20 protocol. IKE is a component of IPsec used for performing mutual 21 authentication and establishing and maintaining Security Associations 22 (SAs). This document obsoletes RFC 5996, and includes all of the 23 errata for it, and it is intended to update IKEv2 to be Internet 24 Standard. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 27, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 73 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6 74 1.1.1. Security Gateway to Security Gateway in Tunnel Mode . 7 75 1.1.2. Endpoint-to-Endpoint Transport Mode . . . . . . . . . 7 76 1.1.3. Endpoint to Security Gateway in Tunnel Mode . . . . . 8 77 1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 9 78 1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 9 79 1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 13 80 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA 81 Exchange . . . . . . . . . . . . . . . . . . . . . . 14 82 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange . 15 83 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA 84 Exchange . . . . . . . . . . . . . . . . . . . . . . 16 85 1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 17 86 1.4.1. Deleting an SA with INFORMATIONAL Exchanges . . . . . 17 87 1.5. Informational Messages outside of an IKE SA . . . . . . . 18 88 1.6. Requirements Terminology . . . . . . . . . . . . . . . . 19 89 1.7. Significant Differences between RFC 4306 and RFC5996 . . 19 90 1.8. Differences between RFC 5996 and This Document . . . . . 22 91 2. IKE Protocol Details and Variations . . . . . . . . . . . . . 23 92 2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 23 93 2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 25 94 2.3. Window Size for Overlapping Requests . . . . . . . . . . 26 95 2.4. State Synchronization and Connection Timeouts . . . . . . 27 96 2.5. Version Numbers and Forward Compatibility . . . . . . . . 29 97 2.6. IKE SA SPIs and Cookies . . . . . . . . . . . . . . . . . 30 98 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 33 99 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 34 100 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 35 101 2.8.1. Simultaneous Child SA Rekeying . . . . . . . . . . . 37 102 2.8.2. Simultaneous IKE SA Rekeying . . . . . . . . . . . . 39 103 2.8.3. Rekeying the IKE SA versus Reauthentication . . . . . 40 104 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 41 105 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 44 106 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 44 107 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 45 108 2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 45 109 2.13. Generating Keying Material . . . . . . . . . . . . . . . 46 110 2.14. Generating Keying Material for the IKE SA . . . . . . . . 47 111 2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 48 112 2.16. Extensible Authentication Protocol Methods . . . . . . . 50 113 2.17. Generating Keying Material for Child SAs . . . . . . . . 52 114 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . . 53 115 2.19. Requesting an Internal Address on a Remote Network . . . 54 116 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 55 117 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 56 118 2.21.1. Error Handling in IKE_SA_INIT . . . . . . . . . . . . 56 119 2.21.2. Error Handling in IKE_AUTH . . . . . . . . . . . . . 57 120 2.21.3. Error Handling after IKE SA is Authenticated . . . . 58 121 2.21.4. Error Handling Outside IKE SA . . . . . . . . . . . . 58 122 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 59 123 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 60 124 2.23.1. Transport Mode NAT Traversal . . . . . . . . . . . . 64 125 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 68 126 2.25. Exchange Collisions . . . . . . . . . . . . . . . . . . . 68 127 2.25.1. Collisions while Rekeying or Closing Child SAs . . . 69 128 2.25.2. Collisions while Rekeying or Closing IKE SAs . . . . 70 129 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 70 130 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 70 131 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 73 132 3.3. Security Association Payload . . . . . . . . . . . . . . 75 133 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 79 134 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 80 135 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 84 136 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 84 137 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 85 138 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 87 139 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 88 140 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 89 141 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 91 142 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 94 143 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 96 144 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 97 145 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 98 146 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 99 147 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 102 148 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 103 149 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 105 150 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 106 151 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 108 152 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 110 153 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 111 154 3.15.2. Meaning of INTERNAL_IP4_SUBNET and 155 INTERNAL_IP6_SUBNET . . . . . . . . . . . . . . . . . 114 156 3.15.3. Configuration Payloads for IPv6 . . . . . . . . . . . 116 157 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 117 158 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 118 159 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 119 160 5. Security Considerations . . . . . . . . . . . . . . . . . . . 121 161 5.1. Traffic Selector Authorization . . . . . . . . . . . . . 124 162 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 125 163 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 125 164 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 127 165 8.1. Normative References . . . . . . . . . . . . . . . . . . 127 166 8.2. Informative References . . . . . . . . . . . . . . . . . 128 167 Appendix A. Summary of Changes from IKEv1 . . . . . . . . . . . 132 168 Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 133 169 B.1. Group 1 - 768-bit MODP . . . . . . . . . . . . . . . . . 134 170 B.2. Group 2 - 1024-bit MODP . . . . . . . . . . . . . . . . . 134 171 Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 134 172 C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 135 173 C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 136 174 C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 137 175 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying 176 Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 138 177 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 138 178 C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 138 180 1. Introduction 182 IP Security (IPsec) provides confidentiality, data integrity, access 183 control, and data source authentication to IP datagrams. These 184 services are provided by maintaining shared state between the source 185 and the sink of an IP datagram. This state defines, among other 186 things, the specific services provided to the datagram, which 187 cryptographic algorithms will be used to provide the services, and 188 the keys used as input to the cryptographic algorithms. 190 Establishing this shared state in a manual fashion does not scale 191 well. Therefore, a protocol to establish this state dynamically is 192 needed. This document describes such a protocol -- the Internet Key 193 Exchange (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI], 194 2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 replaced all of those RFCs. 195 IKEv2 was defined in [IKEV2] (RFC 4306) and was clarified in [Clarif] 196 (RFC 4718). The [RFC5996] replaced and updated RFC 4306 and RFC 197 4718, and this document replaces the RFC 5996 and the intended status 198 for this document will be Internet Standard. IKEv2 as stated in RFC 199 4306 was a change to the IKE protocol that was not backward 200 compatible. RFC 5996 revised RFC 4306 to provide a clarification of 201 IKEv2, making minimum changes to the IKEv2 protocol. The current 202 document slightly revises RFC 5996 to make it suitable for 203 progression to Internet Standard. A list of the significant 204 differences between RFC 4306 and RFC 5996 is given in Section 1.7 and 205 differences between RFC 5996 and this document is given in 206 Section 1.8. 208 IKE performs mutual authentication between two parties and 209 establishes an IKE security association (SA) that includes shared 210 secret information that can be used to efficiently establish SAs for 211 Encapsulating Security Payload (ESP) [ESP] or Authentication Header 212 (AH) [AH] and a set of cryptographic algorithms to be used by the SAs 213 to protect the traffic that they carry. In this document, the term 214 "suite" or "cryptographic suite" refers to a complete set of 215 algorithms used to protect an SA. An initiator proposes one or more 216 suites by listing supported algorithms that can be combined into 217 suites in a mix-and-match fashion. IKE can also negotiate use of IP 218 Compression (IPComp) [IP-COMP] in connection with an ESP or AH SA. 219 The SAs for ESP or AH that get set up through that IKE SA we call 220 "Child SAs". 222 All IKE communications consist of pairs of messages: a request and a 223 response. The pair is called an "exchange", and is sometimes called 224 a "request/response pair". The first exchange of messages 225 establishing an IKE SA are called the IKE_SA_INIT and IKE_AUTH 226 exchanges; subsequent IKE exchanges are called the CREATE_CHILD_SA or 227 INFORMATIONAL exchanges. In the common case, there is a single 228 IKE_SA_INIT exchange and a single IKE_AUTH exchange (a total of four 229 messages) to establish the IKE SA and the first Child SA. In 230 exceptional cases, there may be more than one of each of these 231 exchanges. In all cases, all IKE_SA_INIT exchanges MUST complete 232 before any other exchange type, then all IKE_AUTH exchanges MUST 233 complete, and following that, any number of CREATE_CHILD_SA and 234 INFORMATIONAL exchanges may occur in any order. In some scenarios, 235 only a single Child SA is needed between the IPsec endpoints, and 236 therefore there would be no additional exchanges. Subsequent 237 exchanges MAY be used to establish additional Child SAs between the 238 same authenticated pair of endpoints and to perform housekeeping 239 functions. 241 An IKE message flow always consists of a request followed by a 242 response. It is the responsibility of the requester to ensure 243 reliability. If the response is not received within a timeout 244 interval, the requester needs to retransmit the request (or abandon 245 the connection). 247 The first exchange of an IKE session, IKE_SA_INIT, negotiates 248 security parameters for the IKE SA, sends nonces, and sends Diffie- 249 Hellman values. 251 The second exchange, IKE_AUTH, transmits identities, proves knowledge 252 of the secrets corresponding to the two identities, and sets up an SA 253 for the first (and often only) AH or ESP Child SA (unless there is 254 failure setting up the AH or ESP Child SA, in which case the IKE SA 255 is still established without the Child SA). 257 The types of subsequent exchanges are CREATE_CHILD_SA (which creates 258 a Child SA) and INFORMATIONAL (which deletes an SA, reports error 259 conditions, or does other housekeeping). Every request requires a 260 response. An INFORMATIONAL request with no payloads (other than the 261 empty Encrypted payload required by the syntax) is commonly used as a 262 check for liveness. These subsequent exchanges cannot be used until 263 the initial exchanges have completed. 265 In the description that follows, we assume that no errors occur. 266 Modifications to the flow when errors occur are described in 267 Section 2.21. 269 1.1. Usage Scenarios 271 IKE is used to negotiate ESP or AH SAs in a number of different 272 scenarios, each with its own special requirements. 274 1.1.1. Security Gateway to Security Gateway in Tunnel Mode 276 +-+-+-+-+-+ +-+-+-+-+-+ 277 | | IPsec | | 278 Protected |Tunnel | tunnel |Tunnel | Protected 279 Subnet <-->|Endpoint |<---------->|Endpoint |<--> Subnet 280 | | | | 281 +-+-+-+-+-+ +-+-+-+-+-+ 283 Figure 1: Security Gateway to Security Gateway Tunnel 285 In this scenario, neither endpoint of the IP connection implements 286 IPsec, but network nodes between them protect traffic for part of the 287 way. Protection is transparent to the endpoints, and depends on 288 ordinary routing to send packets through the tunnel endpoints for 289 processing. Each endpoint would announce the set of addresses 290 "behind" it, and packets would be sent in tunnel mode where the inner 291 IP header would contain the IP addresses of the actual endpoints. 293 1.1.2. Endpoint-to-Endpoint Transport Mode 295 +-+-+-+-+-+ +-+-+-+-+-+ 296 | | IPsec transport | | 297 |Protected| or tunnel mode SA |Protected| 298 |Endpoint |<---------------------------------------->|Endpoint | 299 | | | | 300 +-+-+-+-+-+ +-+-+-+-+-+ 302 Figure 2: Endpoint to Endpoint 304 In this scenario, both endpoints of the IP connection implement 305 IPsec, as required of hosts in [IPSECARCH]. Transport mode will 306 commonly be used with no inner IP header. A single pair of addresses 307 will be negotiated for packets to be protected by this SA. These 308 endpoints MAY implement application-layer access controls based on 309 the IPsec authenticated identities of the participants. This 310 scenario enables the end-to-end security that has been a guiding 311 principle for the Internet since [ARCHPRINC], [TRANSPARENCY], and a 312 method of limiting the inherent problems with complexity in networks 313 noted by [ARCHGUIDEPHIL]. Although this scenario may not be fully 314 applicable to the IPv4 Internet, it has been deployed successfully in 315 specific scenarios within intranets using IKEv1. It should be more 316 broadly enabled during the transition to IPv6 and with the adoption 317 of IKEv2. 319 It is possible in this scenario that one or both of the protected 320 endpoints will be behind a network address translation (NAT) node, in 321 which case the tunneled packets will have to be UDP encapsulated so 322 that port numbers in the UDP headers can be used to identify 323 individual endpoints "behind" the NAT (see Section 2.23). 325 1.1.3. Endpoint to Security Gateway in Tunnel Mode 327 +-+-+-+-+-+ +-+-+-+-+-+ 328 | | IPsec | | Protected 329 |Protected| tunnel |Tunnel | Subnet 330 |Endpoint |<------------------------>|Endpoint |<--- and/or 331 | | | | Internet 332 +-+-+-+-+-+ +-+-+-+-+-+ 334 Figure 3: Endpoint to Security Gateway Tunnel 336 In this scenario, a protected endpoint (typically a portable roaming 337 computer) connects back to its corporate network through an IPsec- 338 protected tunnel. It might use this tunnel only to access 339 information on the corporate network, or it might tunnel all of its 340 traffic back through the corporate network in order to take advantage 341 of protection provided by a corporate firewall against Internet-based 342 attacks. In either case, the protected endpoint will want an IP 343 address associated with the security gateway so that packets returned 344 to it will go to the security gateway and be tunneled back. This IP 345 address may be static or may be dynamically allocated by the security 346 gateway. In support of the latter case, IKEv2 includes a mechanism 347 (namely, configuration payloads) for the initiator to request an IP 348 address owned by the security gateway for use for the duration of its 349 SA. 351 In this scenario, packets will use tunnel mode. On each packet from 352 the protected endpoint, the outer IP header will contain the source 353 IP address associated with its current location (i.e., the address 354 that will get traffic routed to the endpoint directly), while the 355 inner IP header will contain the source IP address assigned by the 356 security gateway (i.e., the address that will get traffic routed to 357 the security gateway for forwarding to the endpoint). The outer 358 destination address will always be that of the security gateway, 359 while the inner destination address will be the ultimate destination 360 for the packet. 362 In this scenario, it is possible that the protected endpoint will be 363 behind a NAT. In that case, the IP address as seen by the security 364 gateway will not be the same as the IP address sent by the protected 365 endpoint, and packets will have to be UDP encapsulated in order to be 366 routed properly. Interaction with NATs is covered in detail in 367 Section 2.23. 369 1.1.4. Other Scenarios 371 Other scenarios are possible, as are nested combinations of the 372 above. One notable example combines aspects of Sections 1.1.1 and 373 1.1.3. A subnet may make all external accesses through a remote 374 security gateway using an IPsec tunnel, where the addresses on the 375 subnet are routed to the security gateway by the rest of the 376 Internet. An example would be someone's home network being virtually 377 on the Internet with static IP addresses even though connectivity is 378 provided by an ISP that assigns a single dynamically assigned IP 379 address to the user's security gateway (where the static IP addresses 380 and an IPsec relay are provided by a third party located elsewhere). 382 1.2. The Initial Exchanges 384 Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH 385 exchanges (known in IKEv1 as Phase 1). These initial exchanges 386 normally consist of four messages, though in some scenarios that 387 number can grow. All communications using IKE consist of request/ 388 response pairs. We'll describe the base exchange first, followed by 389 variations. The first pair of messages (IKE_SA_INIT) negotiate 390 cryptographic algorithms, exchange nonces, and do a Diffie-Hellman 391 exchange [DH]. 393 The second pair of messages (IKE_AUTH) authenticate the previous 394 messages, exchange identities and certificates, and establish the 395 first Child SA. Parts of these messages are encrypted and integrity 396 protected with keys established through the IKE_SA_INIT exchange, so 397 the identities are hidden from eavesdroppers and all fields in all 398 the messages are authenticated. See Section 2.14 for information on 399 how the encryption keys are generated. (A man-in-the-middle attacker 400 who cannot complete the IKE_AUTH exchange can nonetheless see the 401 identity of the initiator.) 403 All messages following the initial exchange are cryptographically 404 protected using the cryptographic algorithms and keys negotiated in 405 the IKE_SA_INIT exchange. These subsequent messages use the syntax 406 of the Encrypted payload described in Section 3.14, encrypted with 407 keys that are derived as described in Section 2.14. All subsequent 408 messages include an Encrypted payload, even if they are referred to 409 in the text as "empty". For the CREATE_CHILD_SA, IKE_AUTH, or 410 INFORMATIONAL exchanges, the message following the header is 411 encrypted and the message including the header is integrity protected 412 using the cryptographic algorithms negotiated for the IKE SA. 414 Every IKE message contains a Message ID as part of its fixed header. 415 This Message ID is used to match up requests and responses, and to 416 identify retransmissions of messages. 418 In the following descriptions, the payloads contained in the message 419 are indicated by names as listed below. 421 Notation Payload 422 ----------------------------------------- 423 AUTH Authentication 424 CERT Certificate 425 CERTREQ Certificate Request 426 CP Configuration 427 D Delete 428 EAP Extensible Authentication 429 HDR IKE header (not a payload) 430 IDi Identification - Initiator 431 IDr Identification - Responder 432 KE Key Exchange 433 Ni, Nr Nonce 434 N Notify 435 SA Security Association 436 SK Encrypted and Authenticated 437 TSi Traffic Selector - Initiator 438 TSr Traffic Selector - Responder 439 V Vendor ID 441 The details of the contents of each payload are described in section 442 3. Payloads that may optionally appear will be shown in brackets, 443 such as [CERTREQ]; this indicates that a Certificate Request payload 444 can optionally be included. 446 The initial exchanges are as follows: 448 Initiator Responder 449 ------------------------------------------------------------------- 450 HDR, SAi1, KEi, Ni --> 452 HDR contains the Security Parameter Indexes (SPIs), version numbers, 453 Exchange Type, Message ID, and flags of various sorts. The SAi1 454 payload states the cryptographic algorithms the initiator supports 455 for the IKE SA. The KE payload sends the initiator's Diffie-Hellman 456 value. Ni is the initiator's nonce. 458 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 460 The responder chooses a cryptographic suite from the initiator's 461 offered choices and expresses that choice in the SAr1 payload, 462 completes the Diffie-Hellman exchange with the KEr payload, and sends 463 its nonce in the Nr payload. 465 At this point in the negotiation, each party can generate a quantity 466 called SKEYSEED (see Section 2.14), from which all keys are derived 467 for that IKE SA. The messages that follow are encrypted and 468 integrity protected in their entirety, with the exception of the 469 message headers. The keys used for the encryption and integrity 470 protection are derived from SKEYSEED and are known as SK_e 471 (encryption) and SK_a (authentication, a.k.a. integrity protection); 472 see Sections 2.13 and 2.14 for details on the key derivation. A 473 separate SK_e and SK_a is computed for each direction. In addition 474 to the keys SK_e and SK_a derived from the Diffie-Hellman value for 475 protection of the IKE SA, another quantity SK_d is derived and used 476 for derivation of further keying material for Child SAs. The 477 notation SK { ... } indicates that these payloads are encrypted and 478 integrity protected using that direction's SK_e and SK_a. 480 HDR, SK {IDi, [CERT,] [CERTREQ,] 481 [IDr,] AUTH, SAi2, 482 TSi, TSr} --> 484 The initiator asserts its identity with the IDi payload, proves 485 knowledge of the secret corresponding to IDi and integrity protects 486 the contents of the first message using the AUTH payload (see 487 Section 2.15). It might also send its certificate(s) in CERT 488 payload(s) and a list of its trust anchors in CERTREQ payload(s). If 489 any CERT payloads are included, the first certificate provided MUST 490 contain the public key used to verify the AUTH field. 492 The optional payload IDr enables the initiator to specify to which of 493 the responder's identities it wants to talk. This is useful when the 494 machine on which the responder is running is hosting multiple 495 identities at the same IP address. If the IDr proposed by the 496 initiator is not acceptable to the responder, the responder might use 497 some other IDr to finish the exchange. If the initiator then does 498 not accept the fact that responder used an IDr different than the one 499 that was requested, the initiator can close the SA after noticing the 500 fact. 502 The Traffic Selectors (TSi and TSr) are discussed in Section 2.9. 504 The initiator begins negotiation of a Child SA using the SAi2 505 payload. The final fields (starting with SAi2) are described in the 506 description of the CREATE_CHILD_SA exchange. 508 <-- HDR, SK {IDr, [CERT,] AUTH, 509 SAr2, TSi, TSr} 511 The responder asserts its identity with the IDr payload, optionally 512 sends one or more certificates (again with the certificate containing 513 the public key used to verify AUTH listed first), authenticates its 514 identity and protects the integrity of the second message with the 515 AUTH payload, and completes negotiation of a Child SA with the 516 additional fields described below in the CREATE_CHILD_SA exchange. 518 Both parties in the IKE_AUTH exchange MUST verify that all signatures 519 and Message Authentication Codes (MACs) are computed correctly. If 520 either side uses a shared secret for authentication, the names in the 521 ID payload MUST correspond to the key used to generate the AUTH 522 payload. 524 Because the initiator sends its Diffie-Hellman value in the 525 IKE_SA_INIT, it must guess the Diffie-Hellman group that the 526 responder will select from its list of supported groups. If the 527 initiator guesses wrong, the responder will respond with a Notify 528 payload of type INVALID_KE_PAYLOAD indicating the selected group. In 529 this case, the initiator MUST retry the IKE_SA_INIT with the 530 corrected Diffie-Hellman group. The initiator MUST again propose its 531 full set of acceptable cryptographic suites because the rejection 532 message was unauthenticated and otherwise an active attacker could 533 trick the endpoints into negotiating a weaker suite than a stronger 534 one that they both prefer. 536 If creating the Child SA during the IKE_AUTH exchange fails for some 537 reason, the IKE SA is still created as usual. The list of Notify 538 message types in the IKE_AUTH exchange that do not prevent an IKE SA 539 from being set up include at least the following: NO_PROPOSAL_CHOSEN, 540 TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and 541 FAILED_CP_REQUIRED. 543 If the failure is related to creating the IKE SA (for example, an 544 AUTHENTICATION_FAILED Notify error message is returned), the IKE SA 545 is not created. Note that although the IKE_AUTH messages are 546 encrypted and integrity protected, if the peer receiving this Notify 547 error message has not yet authenticated the other end (or if the peer 548 fails to authenticate the other end for some reason), the information 549 needs to be treated with caution. More precisely, assuming that the 550 MAC verifies correctly, the sender of the error Notify message is 551 known to be the responder of the IKE_SA_INIT exchange, but the 552 sender's identity cannot be assured. 554 Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads. 555 Thus, the SA payloads in the IKE_AUTH exchange cannot contain 556 Transform Type 4 (Diffie-Hellman group) with any value other than 557 NONE. Implementations SHOULD omit the whole transform substructure 558 instead of sending value NONE. 560 1.3. The CREATE_CHILD_SA Exchange 562 The CREATE_CHILD_SA exchange is used to create new Child SAs and to 563 rekey both IKE SAs and Child SAs. This exchange consists of a single 564 request/response pair, and some of its function was referred to as a 565 Phase 2 exchange in IKEv1. It MAY be initiated by either end of the 566 IKE SA after the initial exchanges are completed. 568 An SA is rekeyed by creating a new SA and then deleting the old one. 569 This section describes the first part of rekeying, the creation of 570 new SAs; Section 2.8 covers the mechanics of rekeying, including 571 moving traffic from old to new SAs and the deletion of the old SAs. 572 The two sections must be read together to understand the entire 573 process of rekeying. 575 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this 576 section the term initiator refers to the endpoint initiating this 577 exchange. An implementation MAY refuse all CREATE_CHILD_SA requests 578 within an IKE SA. 580 The CREATE_CHILD_SA request MAY optionally contain a KE payload for 581 an additional Diffie-Hellman exchange to enable stronger guarantees 582 of forward secrecy for the Child SA. The keying material for the 583 Child SA is a function of SK_d established during the establishment 584 of the IKE SA, the nonces exchanged during the CREATE_CHILD_SA 585 exchange, and the Diffie-Hellman value (if KE payloads are included 586 in the CREATE_CHILD_SA exchange). 588 If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of 589 the SA offers MUST include the Diffie-Hellman group of the KEi. The 590 Diffie-Hellman group of the KEi MUST be an element of the group the 591 initiator expects the responder to accept (additional Diffie-Hellman 592 groups can be proposed). If the responder selects a proposal using a 593 different Diffie-Hellman group (other than NONE), the responder MUST 594 reject the request and indicate its preferred Diffie-Hellman group in 595 the INVALID_KE_PAYLOAD Notify payload. There are two octets of data 596 associated with this notification: the accepted Diffie-Hellman group 597 number in big endian order. In the case of such a rejection, the 598 CREATE_CHILD_SA exchange fails, and the initiator will probably retry 599 the exchange with a Diffie-Hellman proposal and KEi in the group that 600 the responder gave in the INVALID_KE_PAYLOAD Notify payload. 602 The responder sends a NO_ADDITIONAL_SAS notification to indicate that 603 a CREATE_CHILD_SA request is unacceptable because the responder is 604 unwilling to accept any more Child SAs on this IKE SA. This 605 notification can also be used to reject IKE SA rekey. Some minimal 606 implementations may only accept a single Child SA setup in the 607 context of an initial IKE exchange and reject any subsequent attempts 608 to add more. 610 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA Exchange 612 A Child SA may be created by sending a CREATE_CHILD_SA request. The 613 CREATE_CHILD_SA request for creating a new Child SA is: 615 Initiator Responder 616 ------------------------------------------------------------------- 617 HDR, SK {SA, Ni, [KEi], 618 TSi, TSr} --> 620 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 621 payload, optionally a Diffie-Hellman value in the KEi payload, and 622 the proposed Traffic Selectors for the proposed Child SA in the TSi 623 and TSr payloads. 625 The CREATE_CHILD_SA response for creating a new Child SA is: 627 <-- HDR, SK {SA, Nr, [KEr], 628 TSi, TSr} 630 The responder replies (using the same Message ID to respond) with the 631 accepted offer in an SA payload, nonce in the Nr payload, and a 632 Diffie-Hellman value in the KEr payload if KEi was included in the 633 request and the selected cryptographic suite includes that group. 635 The Traffic Selectors for traffic to be sent on that SA are specified 636 in the TS payloads in the response, which may be a subset of what the 637 initiator of the Child SA proposed. 639 The USE_TRANSPORT_MODE notification MAY be included in a request 640 message that also includes an SA payload requesting a Child SA. It 641 requests that the Child SA use transport mode rather than tunnel mode 642 for the SA created. If the request is accepted, the response MUST 643 also include a notification of type USE_TRANSPORT_MODE. If the 644 responder declines the request, the Child SA will be established in 645 tunnel mode. If this is unacceptable to the initiator, the initiator 646 MUST delete the SA. Note: Except when using this option to negotiate 647 transport mode, all Child SAs will use tunnel mode. 649 The ESP_TFC_PADDING_NOT_SUPPORTED notification asserts that the 650 sending endpoint will not accept packets that contain Traffic Flow 651 Confidentiality (TFC) padding over the Child SA being negotiated. If 652 neither endpoint accepts TFC padding, this notification is included 653 in both the request and the response. If this notification is 654 included in only one of the messages, TFC padding can still be sent 655 in the other direction. 657 The NON_FIRST_FRAGMENTS_ALSO notification is used for fragmentation 658 control. See [IPSECARCH] for a fuller explanation. Both parties 659 need to agree to sending non-first fragments before either party does 660 so. It is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is 661 included in both the request proposing an SA and the response 662 accepting it. If the responder does not want to send or receive non- 663 first fragments, it only omits NON_FIRST_FRAGMENTS_ALSO notification 664 from its response, but does not reject the whole Child SA creation. 666 An IPCOMP_SUPPORTED notification, covered in Section 2.22, can also 667 be included in the exchange. 669 A failed attempt to create a Child SA SHOULD NOT tear down the IKE 670 SA: there is no reason to lose the work done to set up the IKE SA. 671 See Section 2.21 for a list of error messages that might occur if 672 creating a Child SA fails. 674 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange 676 The CREATE_CHILD_SA request for rekeying an IKE SA is: 678 Initiator Responder 679 ------------------------------------------------------------------- 680 HDR, SK {SA, Ni, KEi} --> 682 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 683 payload, and a Diffie-Hellman value in the KEi payload. The KEi 684 payload MUST be included. A new initiator SPI is supplied in the SPI 685 field of the SA payload. Once a peer receives a request to rekey an 686 IKE SA or sends a request to rekey an IKE SA, it SHOULD NOT start any 687 new CREATE_CHILD_SA exchanges on the IKE SA that is being rekeyed. 689 The CREATE_CHILD_SA response for rekeying an IKE SA is: 691 <-- HDR, SK {SA, Nr, KEr} 693 The responder replies (using the same Message ID to respond) with the 694 accepted offer in an SA payload, nonce in the Nr payload, and a 695 Diffie-Hellman value in the KEr payload if the selected cryptographic 696 suite includes that group. A new responder SPI is supplied in the 697 SPI field of the SA payload. 699 The new IKE SA has its message counters set to 0, regardless of what 700 they were in the earlier IKE SA. The first IKE requests from both 701 sides on the new IKE SA will have Message ID 0. The old IKE SA 702 retains its numbering, so any further requests (for example, to 703 delete the IKE SA) will have consecutive numbering. The new IKE SA 704 also has its window size reset to 1, and the initiator in this rekey 705 exchange is the new "original initiator" of the new IKE SA. 707 Section 2.18 also covers IKE SA rekeying in detail. 709 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange 711 The CREATE_CHILD_SA request for rekeying a Child SA is: 713 Initiator Responder 714 ------------------------------------------------------------------- 715 HDR, SK {N(REKEY_SA), SA, Ni, [KEi], 716 TSi, TSr} --> 718 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 719 payload, optionally a Diffie-Hellman value in the KEi payload, and 720 the proposed Traffic Selectors for the proposed Child SA in the TSi 721 and TSr payloads. 723 The notifications described in Section 1.3.1 may also be sent in a 724 rekeying exchange. Usually, these will be the same notifications 725 that were used in the original exchange; for example, when rekeying a 726 transport mode SA, the USE_TRANSPORT_MODE notification will be used. 728 The REKEY_SA notification MUST be included in a CREATE_CHILD_SA 729 exchange if the purpose of the exchange is to replace an existing ESP 730 or AH SA. The SA being rekeyed is identified by the SPI field in the 731 Notify payload; this is the SPI the exchange initiator would expect 732 in inbound ESP or AH packets. There is no data associated with this 733 Notify message type. The Protocol ID field of the REKEY_SA 734 notification is set to match the protocol of the SA we are rekeying, 735 for example, 3 for ESP and 2 for AH. 737 The CREATE_CHILD_SA response for rekeying a Child SA is: 739 <-- HDR, SK {SA, Nr, [KEr], 740 TSi, TSr} 742 The responder replies (using the same Message ID to respond) with the 743 accepted offer in an SA payload, nonce in the Nr, and a Diffie- 744 Hellman value in the KEr payload if KEi was included in the request 745 and the selected cryptographic suite includes that group. 747 The Traffic Selectors for traffic to be sent on that SA are specified 748 in the TS payloads in the response, which may be a subset of what the 749 initiator of the Child SA proposed. 751 1.4. The INFORMATIONAL Exchange 753 At various points during the operation of an IKE SA, peers may desire 754 to convey control messages to each other regarding errors or 755 notifications of certain events. To accomplish this, IKE defines an 756 INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur 757 after the initial exchanges and are cryptographically protected with 758 the negotiated keys. Note that some informational messages, not 759 exchanges, can be sent outside the context of an IKE SA. Section 760 2.21 also covers error messages in great detail. 762 Control messages that pertain to an IKE SA MUST be sent under that 763 IKE SA. Control messages that pertain to Child SAs MUST be sent 764 under the protection of the IKE SA that generated them (or its 765 successor if the IKE SA was rekeyed). 767 Messages in an INFORMATIONAL exchange contain zero or more 768 Notification, Delete, and Configuration payloads. The recipient of 769 an INFORMATIONAL exchange request MUST send some response; otherwise, 770 the sender will assume the message was lost in the network and will 771 retransmit it. That response MAY be an empty message. The request 772 message in an INFORMATIONAL exchange MAY also contain no payloads. 773 This is the expected way an endpoint can ask the other endpoint to 774 verify that it is alive. 776 The INFORMATIONAL exchange is defined as: 778 Initiator Responder 779 ------------------------------------------------------------------- 780 HDR, SK {[N,] [D,] 781 [CP,] ...} --> 782 <-- HDR, SK {[N,] [D,] 783 [CP], ...} 785 The processing of an INFORMATIONAL exchange is determined by its 786 component payloads. 788 1.4.1. Deleting an SA with INFORMATIONAL Exchanges 790 ESP and AH SAs always exist in pairs, with one SA in each direction. 791 When an SA is closed, both members of the pair MUST be closed (that 792 is, deleted). Each endpoint MUST close its incoming SAs and allow 793 the other endpoint to close the other SA in each pair. To delete an 794 SA, an INFORMATIONAL exchange with one or more Delete payloads is 795 sent listing the SPIs (as they would be expected in the headers of 796 inbound packets) of the SAs to be deleted. The recipient MUST close 797 the designated SAs. Note that one never sends Delete payloads for 798 the two sides of an SA in a single message. If there are many SAs to 799 delete at the same time, one includes Delete payloads for the inbound 800 half of each SA pair in the INFORMATIONAL exchange. 802 Normally, the response in the INFORMATIONAL exchange will contain 803 Delete payloads for the paired SAs going in the other direction. 804 There is one exception. If, by chance, both ends of a set of SAs 805 independently decide to close them, each may send a Delete payload 806 and the two requests may cross in the network. If a node receives a 807 delete request for SAs for which it has already issued a delete 808 request, it MUST delete the outgoing SAs while processing the request 809 and the incoming SAs while processing the response. In that case, 810 the responses MUST NOT include Delete payloads for the deleted SAs, 811 since that would result in duplicate deletion and could in theory 812 delete the wrong SA. 814 Similar to ESP and AH SAs, IKE SAs are also deleted by sending an 815 Informational exchange. Deleting an IKE SA implicitly closes any 816 remaining Child SAs negotiated under it. The response to a request 817 that deletes the IKE SA is an empty INFORMATIONAL response. 819 Half-closed ESP or AH connections are anomalous, and a node with 820 auditing capability should probably audit their existence if they 821 persist. Note that this specification does not specify time periods, 822 so it is up to individual endpoints to decide how long to wait. A 823 node MAY refuse to accept incoming data on half-closed connections 824 but MUST NOT unilaterally close them and reuse the SPIs. If 825 connection state becomes sufficiently messed up, a node MAY close the 826 IKE SA, as described above. It can then rebuild the SAs it needs on 827 a clean base under a new IKE SA. 829 1.5. Informational Messages outside of an IKE SA 831 There are some cases in which a node receives a packet that it cannot 832 process, but it may want to notify the sender about this situation. 834 o If an ESP or AH packet arrives with an unrecognized SPI. This 835 might be due to the receiving node having recently crashed and 836 lost state, or because of some other system malfunction or attack. 838 o If an encrypted IKE request packet arrives on port 500 or 4500 839 with an unrecognized IKE SPI. This might be due to the receiving 840 node having recently crashed and lost state, or because of some 841 other system malfunction or attack. 843 o If an IKE request packet arrives with a higher major version 844 number than the implementation supports. 846 In the first case, if the receiving node has an active IKE SA to the 847 IP address from whence the packet came, it MAY send an INVALID_SPI 848 notification of the wayward packet over that IKE SA in an 849 INFORMATIONAL exchange. The Notification Data contains the SPI of 850 the invalid packet. The recipient of this notification cannot tell 851 whether the SPI is for AH or ESP, but this is not important because 852 in many cases the SPIs will be different for the two. If no suitable 853 IKE SA exists, the node MAY send an informational message without 854 cryptographic protection to the source IP address, using the source 855 UDP port as the destination port if the packet was UDP (UDP- 856 encapsulated ESP or AH). In this case, it should only be used by the 857 recipient as a hint that something might be wrong (because it could 858 easily be forged). This message is not part of an INFORMATIONAL 859 exchange, and the receiving node MUST NOT respond to it because doing 860 so could cause a message loop. The message is constructed as 861 follows: there are no IKE SPI values that would be meaningful to the 862 recipient of such a notification; using zero values or random values 863 are both acceptable, this being the exception to the rule in 864 Section 3.1 that prohibits zero IKE Initiator SPIs. The Initiator 865 flag is set to 1, the Response flag is set to 0, and the version 866 flags are set in the normal fashion; these flags are described in 867 Section 3.1. 869 In the second and third cases, the message is always sent without 870 cryptographic protection (outside of an IKE SA), and includes either 871 an INVALID_IKE_SPI or an INVALID_MAJOR_VERSION notification (with no 872 notification data). The message is a response message, and thus it 873 is sent to the IP address and port from whence it came with the same 874 IKE SPIs and the Message ID and Exchange Type are copied from the 875 request. The Response flag is set to 1, and the version flags are 876 set in the normal fashion. 878 1.6. Requirements Terminology 880 Definitions of the primitive terms in this document (such as Security 881 Association or SA) can be found in [IPSECARCH]. It should be noted 882 that parts of IKEv2 rely on some of the processing rules in 883 [IPSECARCH], as described in various sections of this document. 885 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 886 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 887 document are to be interpreted as described in [MUSTSHOULD]. 889 1.7. Significant Differences between RFC 4306 and RFC5996 891 This document contains clarifications and amplifications to IKEv2 892 [IKEV2]. Many of the clarifications are based on [Clarif]. The 893 changes listed in that document were discussed in the IPsec Working 894 Group and, after the Working Group was disbanded, on the IPsec 895 mailing list. That document contains detailed explanations of areas 896 that were unclear in IKEv2, and is thus useful to implementers of 897 IKEv2. 899 The protocol described in this document retains the same major 900 version number (2) and minor version number (0) as was used in RFC 901 4306. That is, the version number is *not* changed from RFC 4306. 902 The small number of technical changes listed here are not expected to 903 affect RFC 4306 implementations that have already been deployed at 904 the time of publication of this document. 906 This document makes the figures and references a bit more consistent 907 than they were in [IKEV2]. 909 IKEv2 developers have noted that the SHOULD-level requirements in RFC 910 4306 are often unclear in that they don't say when it is OK to not 911 obey the requirements. They also have noted that there are MUST- 912 level requirements that are not related to interoperability. This 913 document has more explanation of some of these requirements. All 914 non-capitalized uses of the words SHOULD and MUST now mean their 915 normal English sense, not the interoperability sense of [MUSTSHOULD]. 917 IKEv2 (and IKEv1) developers have noted that there is a great deal of 918 material in the tables of codes in Section 3.10.1 in RFC 4306. This 919 leads to implementers not having all the needed information in the 920 main body of the document. Much of the material from those tables 921 has been moved into the associated parts of the main body of the 922 document. 924 This document removes discussion of nesting AH and ESP. This was a 925 mistake in RFC 4306 caused by the lag between finishing RFC 4306 and 926 RFC 4301. Basically, IKEv2 is based on RFC 4301, which does not 927 include "SA bundles" that were part of RFC 2401. While a single 928 packet can go through IPsec processing multiple times, each of these 929 passes uses a separate SA, and the passes are coordinated by the 930 forwarding tables. In IKEv2, each of these SAs has to be created 931 using a separate CREATE_CHILD_SA exchange. 933 This document removes discussion of the INTERNAL_ADDRESS_EXPIRY 934 configuration attribute because its implementation was very 935 problematic. Implementations that conform to this document MUST 936 ignore proposals that have configuration attribute type 5, the old 937 value for INTERNAL_ADDRESS_EXPIRY. This document also removed 938 INTERNAL_IP6_NBNS as a configuration attribute. 940 This document removes the allowance for rejecting messages in which 941 the payloads were not in the "right" order; now implementations MUST 942 NOT reject them. This is due to the lack of clarity where the orders 943 for the payloads are described. 945 The lists of items from RFC 4306 that ended up in the IANA registry 946 were trimmed to only include items that were actually defined in RFC 947 4306. Also, many of those lists are now preceded with the very 948 important instruction to developers that they really should look at 949 the IANA registry at the time of development because new items have 950 been added since RFC 4306. 952 This document adds clarification on when notifications are and are 953 not sent encrypted, depending on the state of the negotiation at the 954 time. 956 This document discusses more about how to negotiate combined-mode 957 ciphers. 959 In Section 1.3.2, "The KEi payload SHOULD be included" was changed to 960 be "The KEi payload MUST be included". This also led to changes in 961 Section 2.18. 963 In Section 2.1, there is new material covering how the initiator's 964 SPI and/or IP is used to differentiate if this is a "half-open" IKE 965 SA or a new request. 967 This document clarifies the use of the critical flag in Section 2.5. 969 In Section 2.8, "Note that, when rekeying, the new Child SA MAY have 970 different Traffic Selectors and algorithms than the old one" was 971 changed to "Note that, when rekeying, the new Child SA SHOULD NOT 972 have different Traffic Selectors and algorithms than the old one". 974 The new Section 2.8.2 covers simultaneous IKE SA rekeying. 976 The new Section 2.9.2 covers Traffic Selectors in rekeying. 978 This document adds the restriction in Section 2.13 that all 979 pseudorandom functions (PRFs) used with IKEv2 MUST take variable- 980 sized keys. This should not affect any implementations because there 981 were no standardized PRFs that have fixed-size keys. 983 Section 2.18 requires doing a Diffie-Hellman exchange when rekeying 984 the IKE_SA. In theory, RFC 4306 allowed a policy where the Diffie- 985 Hellman exchange was optional, but this was not useful (or 986 appropriate) when rekeying the IKE_SA. 988 Section 2.21 has been greatly expanded to cover the different cases 989 where error responses are needed and the appropriate responses to 990 them. 992 Section 2.23 clarified that, in NAT traversal, now both UDP- 993 encapsulated IPsec packets and non-UDP-encapsulated IPsec packets 994 need to be understood when receiving. 996 Added Section 2.23.1 to describe NAT traversal when transport mode is 997 requested. 999 Added Section 2.25 to explain how to act when there are timing 1000 collisions when deleting and/or rekeying SAs, and two new error 1001 notifications (TEMPORARY_FAILURE and CHILD_SA_NOT_FOUND) were 1002 defined. 1004 In Section 3.6, "Implementations MUST support the HTTP method for 1005 hash-and-URL lookup. The behavior of other URL methods is not 1006 currently specified, and such methods SHOULD NOT be used in the 1007 absence of a document specifying them" was added. 1009 In Section 3.15.3, a pointer to a new document that is related to 1010 configuration of IPv6 addresses was added. 1012 Appendix C was expanded and clarified. 1014 1.8. Differences between RFC 5996 and This Document 1016 Fixed section 3.6 and 3.10 as specified in the RFC5996 errata 2707 1017 and 3036. 1019 Deprecated Raw RSA Public keys. There is new work ongoing to replace 1020 that with more generic format for generic raw public keys. 1022 Added reference to the RFC6989 when using non Sophie-Germain Diffie- 1023 Hellman groups, or when reusing Diffie-Hellman Exponentials. 1025 Added reference to the RFC4945 in the Identification Payloads 1026 section. 1028 Added IANA Considerations section note about deprecating the Raw RSA 1029 Key, and removed the old contents which was already done during 1030 RFC5996 processing. Added note that IANA should update IKEv2 1031 registry to point to this document instead of RFC5996. 1033 Clarified that the intended status of this document is Internet 1034 Standard both in abstract and Introduction section. 1036 Added name Last Substruc for the Proposal and Transform Substructure 1037 header for the 0 (last) or 2/3 (more) field. 1039 2. IKE Protocol Details and Variations 1041 IKE normally listens and sends on UDP port 500, though IKE messages 1042 may also be received on UDP port 4500 with a slightly different 1043 format (see Section 2.23). Since UDP is a datagram (unreliable) 1044 protocol, IKE includes in its definition recovery from transmission 1045 errors, including packet loss, packet replay, and packet forgery. 1046 IKE is designed to function so long as (1) at least one of a series 1047 of retransmitted packets reaches its destination before timing out; 1048 and (2) the channel is not so full of forged and replayed packets so 1049 as to exhaust the network or CPU capacities of either endpoint. Even 1050 in the absence of those minimum performance requirements, IKE is 1051 designed to fail cleanly (as though the network were broken). 1053 Although IKEv2 messages are intended to be short, they contain 1054 structures with no hard upper bound on size (in particular, digital 1055 certificates), and IKEv2 itself does not have a mechanism for 1056 fragmenting large messages. IP defines a mechanism for fragmentation 1057 of oversized UDP messages, but implementations vary in the maximum 1058 message size supported. Furthermore, use of IP fragmentation opens 1059 an implementation to denial-of-service (DoS) attacks [DOSUDPPROT]. 1060 Finally, some NAT and/or firewall implementations may block IP 1061 fragments. 1063 All IKEv2 implementations MUST be able to send, receive, and process 1064 IKE messages that are up to 1280 octets long, and they SHOULD be able 1065 to send, receive, and process messages that are up to 3000 octets 1066 long. IKEv2 implementations need to be aware of the maximum UDP 1067 message size supported and MAY shorten messages by leaving out some 1068 certificates or cryptographic suite proposals if that will keep 1069 messages below the maximum. Use of the "Hash and URL" formats rather 1070 than including certificates in exchanges where possible can avoid 1071 most problems. Implementations and configuration need to keep in 1072 mind, however, that if the URL lookups are possible only after the 1073 Child SA is established, recursion issues could prevent this 1074 technique from working. 1076 The UDP payload of all packets containing IKE messages sent on port 1077 4500 MUST begin with the prefix of four zeros; otherwise, the 1078 receiver won't know how to handle them. 1080 2.1. Use of Retransmission Timers 1082 All messages in IKE exist in pairs: a request and a response. The 1083 setup of an IKE SA normally consists of two exchanges. Once the IKE 1084 SA is set up, either end of the Security Association may initiate 1085 requests at any time, and there can be many requests and responses 1086 "in flight" at any given moment. But each message is labeled as 1087 either a request or a response, and for each exchange, one end of the 1088 Security Association is the initiator and the other is the responder. 1090 For every pair of IKE messages, the initiator is responsible for 1091 retransmission in the event of a timeout. The responder MUST never 1092 retransmit a response unless it receives a retransmission of the 1093 request. In that event, the responder MUST ignore the retransmitted 1094 request except insofar as it causes a retransmission of the response. 1095 The initiator MUST remember each request until it receives the 1096 corresponding response. The responder MUST remember each response 1097 until it receives a request whose sequence number is larger than or 1098 equal to the sequence number in the response plus its window size 1099 (see Section 2.3). In order to allow saving memory, responders are 1100 allowed to forget the response after a timeout of several minutes. 1101 If the responder receives a retransmitted request for which it has 1102 already forgotten the response, it MUST ignore the request (and not, 1103 for example, attempt constructing a new response). 1105 IKE is a reliable protocol: the initiator MUST retransmit a request 1106 until it either receives a corresponding response or deems the IKE SA 1107 to have failed. In the latter case, the initiator discards all state 1108 associated with the IKE SA and any Child SAs that were negotiated 1109 using that IKE SA. A retransmission from the initiator MUST be 1110 bitwise identical to the original request. That is, everything 1111 starting from the IKE header (the IKE SA initiator's SPI onwards) 1112 must be bitwise identical; items before it (such as the IP and UDP 1113 headers) do not have to be identical. 1115 Retransmissions of the IKE_SA_INIT request require some special 1116 handling. When a responder receives an IKE_SA_INIT request, it has 1117 to determine whether the packet is a retransmission belonging to an 1118 existing "half-open" IKE SA (in which case the responder retransmits 1119 the same response), or a new request (in which case the responder 1120 creates a new IKE SA and sends a fresh response), or it belongs to an 1121 existing IKE SA where the IKE_AUTH request has been already received 1122 (in which case the responder ignores it). 1124 It is not sufficient to use the initiator's SPI and/or IP address to 1125 differentiate between these three cases because two different peers 1126 behind a single NAT could choose the same initiator SPI. Instead, a 1127 robust responder will do the IKE SA lookup using the whole packet, 1128 its hash, or the Ni payload. 1130 The retransmission policy for one-way messages is somewhat different 1131 from that for regular messages. Because no acknowledgement is ever 1132 sent, there is no reason to gratuitously retransmit one-way messages. 1133 Given that all these messages are errors, it makes sense to send them 1134 only once per "offending" packet, and only retransmit if further 1135 offending packets are received. Still, it also makes sense to limit 1136 retransmissions of such error messages. 1138 2.2. Use of Sequence Numbers for Message ID 1140 Every IKE message contains a Message ID as part of its fixed header. 1141 This Message ID is used to match up requests and responses and to 1142 identify retransmissions of messages. Retransmission of a message 1143 MUST use the same Message ID as the original message. 1145 The Message ID is a 32-bit quantity, which is zero for the 1146 IKE_SA_INIT messages (including retries of the message due to 1147 responses such as COOKIE and INVALID_KE_PAYLOAD), and incremented for 1148 each subsequent exchange. Thus, the first pair of IKE_AUTH messages 1149 will have an ID of 1, the second (when EAP is used) will be 2, and so 1150 on. The Message ID is reset to zero in the new IKE SA after the IKE 1151 SA is rekeyed. 1153 Each endpoint in the IKE Security Association maintains two "current" 1154 Message IDs: the next one to be used for a request it initiates and 1155 the next one it expects to see in a request from the other end. 1156 These counters increment as requests are generated and received. 1157 Responses always contain the same Message ID as the corresponding 1158 request. That means that after the initial exchange, each integer n 1159 may appear as the Message ID in four distinct messages: the nth 1160 request from the original IKE initiator, the corresponding response, 1161 the nth request from the original IKE responder, and the 1162 corresponding response. If the two ends make a very different number 1163 of requests, the Message IDs in the two directions can be very 1164 different. There is no ambiguity in the messages, however, because 1165 the Initiator and Response flags in the message header specify which 1166 of the four messages a particular one is. 1168 Throughout this document, "initiator" refers to the party who 1169 initiated the exchange being described. The "original initiator" 1170 always refers to the party who initiated the exchange that resulted 1171 in the current IKE SA. In other words, if the "original responder" 1172 starts rekeying the IKE SA, that party becomes the "original 1173 initiator" of the new IKE SA. 1175 Note that Message IDs are cryptographically protected and provide 1176 protection against message replays. In the unlikely event that 1177 Message IDs grow too large to fit in 32 bits, the IKE SA MUST be 1178 closed or rekeyed. 1180 2.3. Window Size for Overlapping Requests 1182 The SET_WINDOW_SIZE notification asserts that the sending endpoint is 1183 capable of keeping state for multiple outstanding exchanges, 1184 permitting the recipient to send multiple requests before getting a 1185 response to the first. The data associated with a SET_WINDOW_SIZE 1186 notification MUST be 4 octets long and contain the big endian 1187 representation of the number of messages the sender promises to keep. 1188 The window size is always one until the initial exchanges complete. 1190 An IKE endpoint MUST wait for a response to each of its messages 1191 before sending a subsequent message unless it has received a 1192 SET_WINDOW_SIZE Notify message from its peer informing it that the 1193 peer is prepared to maintain state for multiple outstanding messages 1194 in order to allow greater throughput. 1196 After an IKE SA is set up, in order to maximize IKE throughput, an 1197 IKE endpoint MAY issue multiple requests before getting a response to 1198 any of them, up to the limit set by its peer's SET_WINDOW_SIZE. 1199 These requests may pass one another over the network. An IKE 1200 endpoint MUST be prepared to accept and process a request while it 1201 has a request outstanding in order to avoid a deadlock in this 1202 situation. An IKE endpoint may also accept and process multiple 1203 requests while it has a request outstanding. 1205 An IKE endpoint MUST NOT exceed the peer's stated window size for 1206 transmitted IKE requests. In other words, if the responder stated 1207 its window size is N, then when the initiator needs to make a request 1208 X, it MUST wait until it has received responses to all requests up 1209 through request X-N. An IKE endpoint MUST keep a copy of (or be able 1210 to regenerate exactly) each request it has sent until it receives the 1211 corresponding response. An IKE endpoint MUST keep a copy of (or be 1212 able to regenerate exactly) the number of previous responses equal to 1213 its declared window size in case its response was lost and the 1214 initiator requests its retransmission by retransmitting the request. 1216 An IKE endpoint supporting a window size greater than one ought to be 1217 capable of processing incoming requests out of order to maximize 1218 performance in the event of network failures or packet reordering. 1220 The window size is normally a (possibly configurable) property of a 1221 particular implementation, and is not related to congestion control 1222 (unlike the window size in TCP, for example). In particular, what 1223 the responder should do when it receives a SET_WINDOW_SIZE 1224 notification containing a smaller value than is currently in effect 1225 is not defined. Thus, there is currently no way to reduce the window 1226 size of an existing IKE SA; you can only increase it. When rekeying 1227 an IKE SA, the new IKE SA starts with window size 1 until it is 1228 explicitly increased by sending a new SET_WINDOW_SIZE notification. 1230 The INVALID_MESSAGE_ID notification is sent when an IKE Message ID 1231 outside the supported window is received. This Notify message MUST 1232 NOT be sent in a response; the invalid request MUST NOT be 1233 acknowledged. Instead, inform the other side by initiating an 1234 INFORMATIONAL exchange with Notification data containing the four- 1235 octet invalid Message ID. Sending this notification is OPTIONAL, and 1236 notifications of this type MUST be rate limited. 1238 2.4. State Synchronization and Connection Timeouts 1240 An IKE endpoint is allowed to forget all of its state associated with 1241 an IKE SA and the collection of corresponding Child SAs at any time. 1242 This is the anticipated behavior in the event of an endpoint crash 1243 and restart. It is important when an endpoint either fails or 1244 reinitializes its state that the other endpoint detect those 1245 conditions and not continue to waste network bandwidth by sending 1246 packets over discarded SAs and having them fall into a black hole. 1248 The INITIAL_CONTACT notification asserts that this IKE SA is the only 1249 IKE SA currently active between the authenticated identities. It MAY 1250 be sent when an IKE SA is established after a crash, and the 1251 recipient MAY use this information to delete any other IKE SAs it has 1252 to the same authenticated identity without waiting for a timeout. 1253 This notification MUST NOT be sent by an entity that may be 1254 replicated (e.g., a roaming user's credentials where the user is 1255 allowed to connect to the corporate firewall from two remote systems 1256 at the same time). The INITIAL_CONTACT notification, if sent, MUST 1257 be in the first IKE_AUTH request or response, not as a separate 1258 exchange afterwards; receiving parties MAY ignore it in other 1259 messages. 1261 Since IKE is designed to operate in spite of DoS attacks from the 1262 network, an endpoint MUST NOT conclude that the other endpoint has 1263 failed based on any routing information (e.g., ICMP messages) or IKE 1264 messages that arrive without cryptographic protection (e.g., Notify 1265 messages complaining about unknown SPIs). An endpoint MUST conclude 1266 that the other endpoint has failed only when repeated attempts to 1267 contact it have gone unanswered for a timeout period or when a 1268 cryptographically protected INITIAL_CONTACT notification is received 1269 on a different IKE SA to the same authenticated identity. An 1270 endpoint should suspect that the other endpoint has failed based on 1271 routing information and initiate a request to see whether the other 1272 endpoint is alive. To check whether the other side is alive, IKE 1273 specifies an empty INFORMATIONAL message that (like all IKE requests) 1274 requires an acknowledgement (note that within the context of an IKE 1275 SA, an "empty" message consists of an IKE header followed by an 1276 Encrypted payload that contains no payloads). If a cryptographically 1277 protected (fresh, i.e., not retransmitted) message has been received 1278 from the other side recently, unprotected Notify messages MAY be 1279 ignored. Implementations MUST limit the rate at which they take 1280 actions based on unprotected messages. 1282 The number of retries and length of timeouts are not covered in this 1283 specification because they do not affect interoperability. It is 1284 suggested that messages be retransmitted at least a dozen times over 1285 a period of at least several minutes before giving up on an SA, but 1286 different environments may require different rules. To be a good 1287 network citizen, retransmission times MUST increase exponentially to 1288 avoid flooding the network and making an existing congestion 1289 situation worse. If there has only been outgoing traffic on all of 1290 the SAs associated with an IKE SA, it is essential to confirm 1291 liveness of the other endpoint to avoid black holes. If no 1292 cryptographically protected messages have been received on an IKE SA 1293 or any of its Child SAs recently, the system needs to perform a 1294 liveness check in order to prevent sending messages to a dead peer. 1295 (This is sometimes called "dead peer detection" or "DPD", although it 1296 is really detecting live peers, not dead ones.) Receipt of a fresh 1297 cryptographically protected message on an IKE SA or any of its Child 1298 SAs ensures liveness of the IKE SA and all of its Child SAs. Note 1299 that this places requirements on the failure modes of an IKE 1300 endpoint. An implementation needs to stop sending over any SA if 1301 some failure prevents it from receiving on all of the associated SAs. 1302 If a system creates Child SAs that can fail independently from one 1303 another without the associated IKE SA being able to send a delete 1304 message, then the system MUST negotiate such Child SAs using separate 1305 IKE SAs. 1307 There is a DoS attack on the initiator of an IKE SA that can be 1308 avoided if the initiator takes the proper care. Since the first two 1309 messages of an SA setup are not cryptographically protected, an 1310 attacker could respond to the initiator's message before the genuine 1311 responder and poison the connection setup attempt. To prevent this, 1312 the initiator MAY be willing to accept multiple responses to its 1313 first message, treat each as potentially legitimate, respond to it, 1314 and then discard all the invalid half-open connections when it 1315 receives a valid cryptographically protected response to any one of 1316 its requests. Once a cryptographically valid response is received, 1317 all subsequent responses should be ignored whether or not they are 1318 cryptographically valid. 1320 Note that with these rules, there is no reason to negotiate and agree 1321 upon an SA lifetime. If IKE presumes the partner is dead, based on 1322 repeated lack of acknowledgement to an IKE message, then the IKE SA 1323 and all Child SAs set up through that IKE SA are deleted. 1325 An IKE endpoint may at any time delete inactive Child SAs to recover 1326 resources used to hold their state. If an IKE endpoint chooses to 1327 delete Child SAs, it MUST send Delete payloads to the other end 1328 notifying it of the deletion. It MAY similarly time out the IKE SA. 1329 Closing the IKE SA implicitly closes all associated Child SAs. In 1330 this case, an IKE endpoint SHOULD send a Delete payload indicating 1331 that it has closed the IKE SA unless the other endpoint is no longer 1332 responding. 1334 2.5. Version Numbers and Forward Compatibility 1336 This document describes version 2.0 of IKE, meaning the major version 1337 number is 2 and the minor version number is 0. This document is a 1338 replacement for [IKEV2]. It is likely that some implementations will 1339 want to support version 1.0 and version 2.0, and in the future, other 1340 versions. 1342 The major version number should be incremented only if the packet 1343 formats or required actions have changed so dramatically that an 1344 older version node would not be able to interoperate with a newer 1345 version node if it simply ignored the fields it did not understand 1346 and took the actions specified in the older specification. The minor 1347 version number indicates new capabilities, and MUST be ignored by a 1348 node with a smaller minor version number, but used for informational 1349 purposes by the node with the larger minor version number. For 1350 example, it might indicate the ability to process a newly defined 1351 Notify message type. The node with the larger minor version number 1352 would simply note that its correspondent would not be able to 1353 understand that message and therefore would not send it. 1355 If an endpoint receives a message with a higher major version number, 1356 it MUST drop the message and SHOULD send an unauthenticated Notify 1357 message of type INVALID_MAJOR_VERSION containing the highest 1358 (closest) version number it supports. If an endpoint supports major 1359 version n, and major version m, it MUST support all versions between 1360 n and m. If it receives a message with a major version that it 1361 supports, it MUST respond with that version number. In order to 1362 prevent two nodes from being tricked into corresponding with a lower 1363 major version number than the maximum that they both support, IKE has 1364 a flag that indicates that the node is capable of speaking a higher 1365 major version number. 1367 Thus, the major version number in the IKE header indicates the 1368 version number of the message, not the highest version number that 1369 the transmitter supports. If the initiator is capable of speaking 1370 versions n, n+1, and n+2, and the responder is capable of speaking 1371 versions n and n+1, then they will negotiate speaking n+1, where the 1372 initiator will set a flag indicating its ability to speak a higher 1373 version. If they mistakenly (perhaps through an active attacker 1374 sending error messages) negotiate to version n, then both will notice 1375 that the other side can support a higher version number, and they 1376 MUST break the connection and reconnect using version n+1. 1378 Note that IKEv1 does not follow these rules, because there is no way 1379 in v1 of noting that you are capable of speaking a higher version 1380 number. So an active attacker can trick two v2-capable nodes into 1381 speaking v1. When a v2-capable node negotiates down to v1, it should 1382 note that fact in its logs. 1384 Also, for forward compatibility, all fields marked RESERVED MUST be 1385 set to zero by an implementation running version 2.0, and their 1386 content MUST be ignored by an implementation running version 2.0 ("Be 1387 conservative in what you send and liberal in what you receive" [IP]). 1388 In this way, future versions of the protocol can use those fields in 1389 a way that is guaranteed to be ignored by implementations that do not 1390 understand them. Similarly, payload types that are not defined are 1391 reserved for future use; implementations of a version where they are 1392 undefined MUST skip over those payloads and ignore their contents. 1394 IKEv2 adds a "critical" flag to each payload header for further 1395 flexibility for forward compatibility. If the critical flag is set 1396 and the payload type is unrecognized, the message MUST be rejected 1397 and the response to the IKE request containing that payload MUST 1398 include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an 1399 unsupported critical payload was included. In that Notify payload, 1400 the notification data contains the one-octet payload type. If the 1401 critical flag is not set and the payload type is unsupported, that 1402 payload MUST be ignored. Payloads sent in IKE response messages MUST 1403 NOT have the critical flag set. Note that the critical flag applies 1404 only to the payload type, not the contents. If the payload type is 1405 recognized, but the payload contains something that is not (such as 1406 an unknown transform inside an SA payload, or an unknown Notify 1407 Message Type inside a Notify payload), the critical flag is ignored. 1409 Although new payload types may be added in the future and may appear 1410 interleaved with the fields defined in this specification, 1411 implementations SHOULD send the payloads defined in this 1412 specification in the order shown in the figures in Sections 1 and 2; 1413 implementations MUST NOT reject as invalid a message with those 1414 payloads in any other order. 1416 2.6. IKE SA SPIs and Cookies 1418 The initial two eight-octet fields in the header, called the "IKE 1419 SPIs", are used as a connection identifier at the beginning of IKE 1420 packets. Each endpoint chooses one of the two SPIs and MUST choose 1421 them so as to be unique identifiers of an IKE SA. An SPI value of 1422 zero is special: it indicates that the remote SPI value is not yet 1423 known by the sender. 1425 Incoming IKE packets are mapped to an IKE SA only using the packet's 1426 SPI, not using (for example) the source IP address of the packet. 1428 Unlike ESP and AH where only the recipient's SPI appears in the 1429 header of a message, in IKE the sender's SPI is also sent in every 1430 message. Since the SPI chosen by the original initiator of the IKE 1431 SA is always sent first, an endpoint with multiple IKE SAs open that 1432 wants to find the appropriate IKE SA using the SPI it assigned must 1433 look at the Initiator flag in the header to determine whether it 1434 assigned the first or the second eight octets. 1436 In the first message of an initial IKE exchange, the initiator will 1437 not know the responder's SPI value and will therefore set that field 1438 to zero. When the IKE_SA_INIT exchange does not result in the 1439 creation of an IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, 1440 or COOKIE, the responder's SPI will be zero also in the response 1441 message. However, if the responder sends a non-zero responder SPI, 1442 the initiator should not reject the response for only that reason. 1444 Two expected attacks against IKE are state and CPU exhaustion, where 1445 the target is flooded with session initiation requests from forged IP 1446 addresses. These attacks can be made less effective if a responder 1447 uses minimal CPU and commits no state to an SA until it knows the 1448 initiator can receive packets at the address from which it claims to 1449 be sending them. 1451 When a responder detects a large number of half-open IKE SAs, it 1452 SHOULD reply to IKE_SA_INIT requests with a response containing the 1453 COOKIE notification. The data associated with this notification MUST 1454 be between 1 and 64 octets in length (inclusive), and its generation 1455 is described later in this section. If the IKE_SA_INIT response 1456 includes the COOKIE notification, the initiator MUST then retry the 1457 IKE_SA_INIT request, and include the COOKIE notification containing 1458 the received data as the first payload, and all other payloads 1459 unchanged. The initial exchange will then be as follows: 1461 Initiator Responder 1462 ------------------------------------------------------------------- 1463 HDR(A,0), SAi1, KEi, Ni --> 1464 <-- HDR(A,0), N(COOKIE) 1465 HDR(A,0), N(COOKIE), SAi1, 1466 KEi, Ni --> 1467 <-- HDR(A,B), SAr1, KEr, 1468 Nr, [CERTREQ] 1469 HDR(A,B), SK {IDi, [CERT,] 1470 [CERTREQ,] [IDr,] AUTH, 1471 SAi2, TSi, TSr} --> 1472 <-- HDR(A,B), SK {IDr, [CERT,] 1473 AUTH, SAr2, TSi, TSr} 1475 The first two messages do not affect any initiator or responder state 1476 except for communicating the cookie. In particular, the message 1477 sequence numbers in the first four messages will all be zero and the 1478 message sequence numbers in the last two messages will be one. 'A' 1479 is the SPI assigned by the initiator, while 'B' is the SPI assigned 1480 by the responder. 1482 An IKE implementation can implement its responder cookie generation 1483 in such a way as to not require any saved state to recognize its 1484 valid cookie when the second IKE_SA_INIT message arrives. The exact 1485 algorithms and syntax used to generate cookies do not affect 1486 interoperability and hence are not specified here. The following is 1487 an example of how an endpoint could use cookies to implement limited 1488 DoS protection. 1490 A good way to do this is to set the responder cookie to be: 1492 Cookie = | Hash(Ni | IPi | SPIi | ) 1494 where is a randomly generated secret known only to the 1495 responder and periodically changed and | indicates concatenation. 1496 should be changed whenever is 1497 regenerated. The cookie can be recomputed when the IKE_SA_INIT 1498 arrives the second time and compared to the cookie in the received 1499 message. If it matches, the responder knows that the cookie was 1500 generated since the last change to and that IPi must be the 1501 same as the source address it saw the first time. Incorporating SPIi 1502 into the calculation ensures that if multiple IKE SAs are being set 1503 up in parallel they will all get different cookies (assuming the 1504 initiator chooses unique SPIi's). Incorporating Ni in the hash 1505 ensures that an attacker who sees only message 2 can't successfully 1506 forge a message 3. Also, incorporating SPIi in the hash prevents an 1507 attacker from fetching one cookie from the other end, and then 1508 initiating many IKE_SA_INIT exchanges all with different initiator 1509 SPIs (and perhaps port numbers) so that the responder thinks that 1510 there are a lot of machines behind one NAT box that are all trying to 1511 connect. 1513 If a new value for is chosen while there are connections in 1514 the process of being initialized, an IKE_SA_INIT might be returned 1515 with other than the current . The responder in 1516 that case MAY reject the message by sending another response with a 1517 new cookie or it MAY keep the old value of around for a 1518 short time and accept cookies computed from either one. The 1519 responder should not accept cookies indefinitely after is 1520 changed, since that would defeat part of the DoS protection. The 1521 responder should change the value of frequently, especially 1522 if under attack. 1524 When one party receives an IKE_SA_INIT request containing a cookie 1525 whose contents do not match the value expected, that party MUST 1526 ignore the cookie and process the message as if no cookie had been 1527 included; usually this means sending a response containing a new 1528 cookie. The initiator should limit the number of cookie exchanges it 1529 tries before giving up, possibly using exponential back-off. An 1530 attacker can forge multiple cookie responses to the initiator's 1531 IKE_SA_INIT message, and each of those forged cookie replies will 1532 cause two packets to be sent: one packet from the initiator to the 1533 responder (which will reject those cookies), and one response from 1534 responder to initiator that includes the correct cookie. 1536 A note on terminology: the term "cookies" originates with Karn and 1537 Simpson [PHOTURIS] in Photuris, an early proposal for key management 1538 with IPsec, and it has persisted. The Internet Security Association 1539 and Key Management Protocol (ISAKMP) [ISAKMP] fixed message header 1540 includes two eight-octet fields called "cookies", and that syntax is 1541 used by both IKEv1 and IKEv2, although in IKEv2 they are referred to 1542 as the "IKE SPI" and there is a new separate field in a Notify 1543 payload holding the cookie. 1545 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD 1547 There are two common reasons why the initiator may have to retry the 1548 IKE_SA_INIT exchange: the responder requests a cookie or wants a 1549 different Diffie-Hellman group than was included in the KEi payload. 1550 If the initiator receives a cookie from the responder, the initiator 1551 needs to decide whether or not to include the cookie in only the next 1552 retry of the IKE_SA_INIT request, or in all subsequent retries as 1553 well. 1555 If the initiator includes the cookie only in the next retry, one 1556 additional round trip may be needed in some cases. An additional 1557 round trip is needed also if the initiator includes the cookie in all 1558 retries, but the responder does not support this. For instance, if 1559 the responder includes the KEi payloads in cookie calculation, it 1560 will reject the request by sending a new cookie. 1562 If both peers support including the cookie in all retries, a slightly 1563 shorter exchange can happen. 1565 Initiator Responder 1566 ----------------------------------------------------------- 1567 HDR(A,0), SAi1, KEi, Ni --> 1568 <-- HDR(A,0), N(COOKIE) 1569 HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> 1570 <-- HDR(A,0), N(INVALID_KE_PAYLOAD) 1571 HDR(A,0), N(COOKIE), SAi1, KEi', Ni --> 1572 <-- HDR(A,B), SAr1, KEr, Nr 1574 Implementations SHOULD support this shorter exchange, but MUST NOT 1575 fail if other implementations do not support this shorter exchange. 1577 2.7. Cryptographic Algorithm Negotiation 1579 The payload type known as "SA" indicates a proposal for a set of 1580 choices of IPsec protocols (IKE, ESP, or AH) for the SA as well as 1581 cryptographic algorithms associated with each protocol. 1583 An SA payload consists of one or more proposals. Each proposal 1584 includes one protocol. Each protocol contains one or more transforms 1585 -- each specifying a cryptographic algorithm. Each transform 1586 contains zero or more attributes (attributes are needed only if the 1587 Transform ID does not completely specify the cryptographic 1588 algorithm). 1590 This hierarchical structure was designed to efficiently encode 1591 proposals for cryptographic suites when the number of supported 1592 suites is large because multiple values are acceptable for multiple 1593 transforms. The responder MUST choose a single suite, which may be 1594 any subset of the SA proposal following the rules below. 1596 Each proposal contains one protocol. If a proposal is accepted, the 1597 SA response MUST contain the same protocol. The responder MUST 1598 accept a single proposal or reject them all and return an error. The 1599 error is given in a notification of type NO_PROPOSAL_CHOSEN. 1601 Each IPsec protocol proposal contains one or more transforms. Each 1602 transform contains a Transform Type. The accepted cryptographic 1603 suite MUST contain exactly one transform of each type included in the 1604 proposal. For example: if an ESP proposal includes transforms 1605 ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, 1606 AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one 1607 of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six 1608 combinations are acceptable. 1610 If an initiator proposes both normal ciphers with integrity 1611 protection as well as combined-mode ciphers, then two proposals are 1612 needed. One of the proposals includes the normal ciphers with the 1613 integrity algorithms for them, and the other proposal includes all 1614 the combined-mode ciphers without the integrity algorithms (because 1615 combined-mode ciphers are not allowed to have any integrity algorithm 1616 other than "none"). 1618 2.8. Rekeying 1620 IKE, ESP, and AH Security Associations use secret keys that should be 1621 used only for a limited amount of time and to protect a limited 1622 amount of data. This limits the lifetime of the entire Security 1623 Association. When the lifetime of a Security Association expires, 1624 the Security Association MUST NOT be used. If there is demand, new 1625 Security Associations MAY be established. Reestablishment of 1626 Security Associations to take the place of ones that expire is 1627 referred to as "rekeying". 1629 To allow for minimal IPsec implementations, the ability to rekey SAs 1630 without restarting the entire IKE SA is optional. An implementation 1631 MAY refuse all CREATE_CHILD_SA requests within an IKE SA. If an SA 1632 has expired or is about to expire and rekeying attempts using the 1633 mechanisms described here fail, an implementation MUST close the IKE 1634 SA and any associated Child SAs and then MAY start new ones. 1635 Implementations may wish to support in-place rekeying of SAs, since 1636 doing so offers better performance and is likely to reduce the number 1637 of packets lost during the transition. 1639 To rekey a Child SA within an existing IKE SA, create a new, 1640 equivalent SA (see Section 2.17 below), and when the new one is 1641 established, delete the old one. Note that, when rekeying, the new 1642 Child SA SHOULD NOT have different Traffic Selectors and algorithms 1643 than the old one. 1645 To rekey an IKE SA, establish a new equivalent IKE SA (see 1646 Section 2.18 below) with the peer to whom the old IKE SA is shared 1647 using a CREATE_CHILD_SA within the existing IKE SA. An IKE SA so 1648 created inherits all of the original IKE SA's Child SAs, and the new 1649 IKE SA is used for all control messages needed to maintain those 1650 Child SAs. After the new equivalent IKE SA is created, the initiator 1651 deletes the old IKE SA, and the Delete payload to delete itself MUST 1652 be the last request sent over the old IKE SA. 1654 SAs should be rekeyed proactively, i.e., the new SA should be 1655 established before the old one expires and becomes unusable. Enough 1656 time should elapse between the time the new SA is established and the 1657 old one becomes unusable so that traffic can be switched over to the 1658 new SA. 1660 A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes 1661 were negotiated. In IKEv2, each end of the SA is responsible for 1662 enforcing its own lifetime policy on the SA and rekeying the SA when 1663 necessary. If the two ends have different lifetime policies, the end 1664 with the shorter lifetime will end up always being the one to request 1665 the rekeying. If an SA has been inactive for a long time and if an 1666 endpoint would not initiate the SA in the absence of traffic, the 1667 endpoint MAY choose to close the SA instead of rekeying it when its 1668 lifetime expires. It can also do so if there has been no traffic 1669 since the last time the SA was rekeyed. 1671 Note that IKEv2 deliberately allows parallel SAs with the same 1672 Traffic Selectors between common endpoints. One of the purposes of 1673 this is to support traffic quality of service (QoS) differences among 1674 the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and Section 4.1 of 1675 [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints 1676 and the Traffic Selectors may not uniquely identify an SA between 1677 those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on 1678 the basis of duplicate Traffic Selectors SHOULD NOT be used. 1680 There are timing windows -- particularly in the presence of lost 1681 packets -- where endpoints may not agree on the state of an SA. The 1682 responder to a CREATE_CHILD_SA MUST be prepared to accept messages on 1683 an SA before sending its response to the creation request, so there 1684 is no ambiguity for the initiator. The initiator MAY begin sending 1685 on an SA as soon as it processes the response. The initiator, 1686 however, cannot receive on a newly created SA until it receives and 1687 processes the response to its CREATE_CHILD_SA request. How, then, is 1688 the responder to know when it is OK to send on the newly created SA? 1690 From a technical correctness and interoperability perspective, the 1691 responder MAY begin sending on an SA as soon as it sends its response 1692 to the CREATE_CHILD_SA request. In some situations, however, this 1693 could result in packets unnecessarily being dropped, so an 1694 implementation MAY defer such sending. 1696 The responder can be assured that the initiator is prepared to 1697 receive messages on an SA if either (1) it has received a 1698 cryptographically valid message on the other half of the SA pair, or 1699 (2) the new SA rekeys an existing SA and it receives an IKE request 1700 to close the replaced SA. When rekeying an SA, the responder 1701 continues to send traffic on the old SA until one of those events 1702 occurs. When establishing a new SA, the responder MAY defer sending 1703 messages on a new SA until either it receives one or a timeout has 1704 occurred. If an initiator receives a message on an SA for which it 1705 has not received a response to its CREATE_CHILD_SA request, it 1706 interprets that as a likely packet loss and retransmits the 1707 CREATE_CHILD_SA request. An initiator MAY send a dummy ESP message 1708 on a newly created ESP SA if it has no messages queued in order to 1709 assure the responder that the initiator is ready to receive messages. 1711 2.8.1. Simultaneous Child SA Rekeying 1713 If the two ends have the same lifetime policies, it is possible that 1714 both will initiate a rekeying at the same time (which will result in 1715 redundant SAs). To reduce the probability of this happening, the 1716 timing of rekeying requests SHOULD be jittered (delayed by a random 1717 amount of time after the need for rekeying is noticed). 1719 This form of rekeying may temporarily result in multiple similar SAs 1720 between the same pairs of nodes. When there are two SAs eligible to 1721 receive packets, a node MUST accept incoming packets through either 1722 SA. If redundant SAs are created though such a collision, the SA 1723 created with the lowest of the four nonces used in the two exchanges 1724 SHOULD be closed by the endpoint that created it. "Lowest" means an 1725 octet-by-octet comparison (instead of, for instance, comparing the 1726 nonces as large integers). In other words, start by comparing the 1727 first octet; if they're equal, move to the next octet, and so on. If 1728 you reach the end of one nonce, that nonce is the lower one. The 1729 node that initiated the surviving rekeyed SA should delete the 1730 replaced SA after the new one is established. 1732 The following is an explanation on the impact this has on 1733 implementations. Assume that hosts A and B have an existing Child SA 1734 pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same 1735 time: 1737 Host A Host B 1738 ------------------------------------------------------------------- 1739 send req1: N(REKEY_SA,SPIa1), 1740 SA(..,SPIa2,..),Ni1,.. --> 1741 <-- send req2: N(REKEY_SA,SPIb1), 1742 SA(..,SPIb2,..),Ni2 1743 recv req2 <-- 1745 At this point, A knows there is a simultaneous rekeying happening. 1746 However, it cannot yet know which of the exchanges will have the 1747 lowest nonce, so it will just note the situation and respond as 1748 usual. 1750 send resp2: SA(..,SPIa3,..), 1751 Nr1,.. --> 1752 --> recv req1 1754 Now B also knows that simultaneous rekeying is going on. It responds 1755 as usual. 1757 <-- send resp1: SA(..,SPIb3,..), 1758 Nr2,.. 1759 recv resp1 <-- 1760 --> recv resp2 1762 At this point, there are three Child SA pairs between A and B (the 1763 old one and two new ones). A and B can now compare the nonces. 1764 Suppose that the lowest nonce was Nr1 in message resp2; in this case, 1765 B (the sender of req2) deletes the redundant new SA, and A (the node 1766 that initiated the surviving rekeyed SA), deletes the old one. 1768 send req3: D(SPIa1) --> 1769 <-- send req4: D(SPIb2) 1770 --> recv req3 1771 <-- send resp3: D(SPIb1) 1772 recv req4 <-- 1773 send resp4: D(SPIa3) --> 1775 The rekeying is now finished. 1777 However, there is a second possible sequence of events that can 1778 happen if some packets are lost in the network, resulting in 1779 retransmissions. The rekeying begins as usual, but A's first packet 1780 (req1) is lost. 1782 Host A Host B 1783 ------------------------------------------------------------------- 1784 send req1: N(REKEY_SA,SPIa1), 1785 SA(..,SPIa2,..), 1786 Ni1,.. --> (lost) 1787 <-- send req2: N(REKEY_SA,SPIb1), 1788 SA(..,SPIb2,..),Ni2 1789 recv req2 <-- 1790 send resp2: SA(..,SPIa3,..), 1791 Nr1,.. --> 1792 --> recv resp2 1793 <-- send req3: D(SPIb1) 1794 recv req3 <-- 1795 send resp3: D(SPIa1) --> 1796 --> recv resp3 1798 From B's point of view, the rekeying is now completed, and since it 1799 has not yet received A's req1, it does not even know that there was 1800 simultaneous rekeying. However, A will continue retransmitting the 1801 message, and eventually it will reach B. 1803 resend req1 --> 1804 --> recv req1 1806 To B, it looks like A is trying to rekey an SA that no longer exists; 1807 thus, B responds to the request with something non-fatal such as 1808 CHILD_SA_NOT_FOUND. 1810 <-- send resp1: N(CHILD_SA_NOT_FOUND) 1811 recv resp1 <-- 1813 When A receives this error, it already knows there was simultaneous 1814 rekeying, so it can ignore the error message. 1816 2.8.2. Simultaneous IKE SA Rekeying 1818 Probably the most complex case occurs when both peers try to rekey 1819 the IKE_SA at the same time. Basically, the text in Section 2.8 1820 applies to this case as well; however, it is important to ensure that 1821 the Child SAs are inherited by the correct IKE_SA. 1823 The case where both endpoints notice the simultaneous rekeying works 1824 the same way as with Child SAs. After the CREATE_CHILD_SA exchanges, 1825 three IKE SAs exist between A and B: the old IKE SA and two new IKE 1826 SAs. The new IKE SA containing the lowest nonce SHOULD be deleted by 1827 the node that created it, and the other surviving new IKE SA MUST 1828 inherit all the Child SAs. 1830 In addition to normal simultaneous rekeying cases, there is a special 1831 case where one peer finishes its rekey before it even notices that 1832 other peer is doing a rekey. If only one peer detects a simultaneous 1833 rekey, redundant SAs are not created. In this case, when the peer 1834 that did not notice the simultaneous rekey gets the request to rekey 1835 the IKE SA that it has already successfully rekeyed, it SHOULD return 1836 TEMPORARY_FAILURE because it is an IKE SA that it is currently trying 1837 to close (whether or not it has already sent the delete notification 1838 for the SA). If the peer that did notice the simultaneous rekey gets 1839 the delete request from the other peer for the old IKE SA, it knows 1840 that the other peer did not detect the simultaneous rekey, and the 1841 first peer can forget its own rekey attempt. 1843 Host A Host B 1844 ------------------------------------------------------------------- 1845 send req1: 1846 SA(..,SPIa1,..),Ni1,.. --> 1847 <-- send req2: SA(..,SPIb1,..),Ni2,.. 1848 --> recv req1 1849 <-- send resp1: SA(..,SPIb2,..),Nr2,.. 1850 recv resp1 <-- 1851 send req3: D() --> 1852 --> recv req3 1854 At this point, host B sees a request to close the IKE_SA. There's 1855 not much more to do than to reply as usual. However, at this point 1856 host B should stop retransmitting req2, since once host A receives 1857 resp3, it will delete all the state associated with the old IKE_SA 1858 and will not be able to reply to it. 1860 <-- send resp3: () 1862 The TEMPORARY_FAILURE notification was not included in RFC 4306, and 1863 support of the TEMPORARY_FAILURE notification is not negotiated. 1864 Thus, older peers that implement RFC 4306 but not this document may 1865 receive these notifications. In that case, they will treat it the 1866 same as any other unknown error notification, and will stop the 1867 exchange. Because the other peer has already rekeyed the exchange, 1868 doing so does not have any ill effects. 1870 2.8.3. Rekeying the IKE SA versus Reauthentication 1872 Rekeying the IKE SA and reauthentication are different concepts in 1873 IKEv2. Rekeying the IKE SA establishes new keys for the IKE SA and 1874 resets the Message ID counters, but it does not authenticate the 1875 parties again (no AUTH or EAP payloads are involved). 1877 Although rekeying the IKE SA may be important in some environments, 1878 reauthentication (the verification that the parties still have access 1879 to the long-term credentials) is often more important. 1881 IKEv2 does not have any special support for reauthentication. 1882 Reauthentication is done by creating a new IKE SA from scratch (using 1883 IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA Notify 1884 payloads), creating new Child SAs within the new IKE SA (without 1885 REKEY_SA Notify payloads), and finally deleting the old IKE SA (which 1886 deletes the old Child SAs as well). 1888 This means that reauthentication also establishes new keys for the 1889 IKE SA and Child SAs. Therefore, while rekeying can be performed 1890 more often than reauthentication, the situation where "authentication 1891 lifetime" is shorter than "key lifetime" does not make sense. 1893 While creation of a new IKE SA can be initiated by either party 1894 (initiator or responder in the original IKE SA), the use of EAP 1895 and/or Configuration payloads means in practice that reauthentication 1896 has to be initiated by the same party as the original IKE SA. IKEv2 1897 does not currently allow the responder to request reauthentication in 1898 this case; however, there are extensions that add this functionality 1899 such as [REAUTH]. 1901 2.9. Traffic Selector Negotiation 1903 When an RFC4301-compliant IPsec subsystem receives an IP packet that 1904 matches a "protect" selector in its Security Policy Database (SPD), 1905 the subsystem protects that packet with IPsec. When no SA exists 1906 yet, it is the task of IKE to create it. Maintenance of a system's 1907 SPD is outside the scope of IKE, although some implementations might 1908 update their SPD in connection with the running of IKE (for an 1909 example scenario, see Section 1.1.3). 1911 Traffic Selector (TS) payloads allow endpoints to communicate some of 1912 the information from their SPD to their peers. These must be 1913 communicated to IKE from the SPD (for example, the PF_KEY API [PFKEY] 1914 uses the SADB_ACQUIRE message). TS payloads specify the selection 1915 criteria for packets that will be forwarded over the newly set up SA. 1916 This can serve as a consistency check in some scenarios to assure 1917 that the SPDs are consistent. In others, it guides the dynamic 1918 update of the SPD. 1920 Two TS payloads appear in each of the messages in the exchange that 1921 creates a Child SA pair. Each TS payload contains one or more 1922 Traffic Selectors. Each Traffic Selector consists of an address 1923 range (IPv4 or IPv6), a port range, and an IP protocol ID. 1925 The first of the two TS payloads is known as TSi (Traffic Selector- 1926 initiator). The second is known as TSr (Traffic Selector-responder). 1927 TSi specifies the source address of traffic forwarded from (or the 1928 destination address of traffic forwarded to) the initiator of the 1929 Child SA pair. TSr specifies the destination address of the traffic 1930 forwarded to (or the source address of the traffic forwarded from) 1931 the responder of the Child SA pair. For example, if the original 1932 initiator requests the creation of a Child SA pair, and wishes to 1933 tunnel all traffic from subnet 198.51.100.* on the initiator's side 1934 to subnet 192.0.2.* on the responder's side, the initiator would 1935 include a single Traffic Selector in each TS payload. TSi would 1936 specify the address range (198.51.100.0 - 198.51.100.255) and TSr 1937 would specify the address range (192.0.2.0 - 192.0.2.255). Assuming 1938 that proposal was acceptable to the responder, it would send 1939 identical TS payloads back. 1941 IKEv2 allows the responder to choose a subset of the traffic proposed 1942 by the initiator. This could happen when the configurations of the 1943 two endpoints are being updated but only one end has received the new 1944 information. Since the two endpoints may be configured by different 1945 people, the incompatibility may persist for an extended period even 1946 in the absence of errors. It also allows for intentionally different 1947 configurations, as when one end is configured to tunnel all addresses 1948 and depends on the other end to have the up-to-date list. 1950 When the responder chooses a subset of the traffic proposed by the 1951 initiator, it narrows the Traffic Selectors to some subset of the 1952 initiator's proposal (provided the set does not become the null set). 1953 If the type of Traffic Selector proposed is unknown, the responder 1954 ignores that Traffic Selector, so that the unknown type is not 1955 returned in the narrowed set. 1957 To enable the responder to choose the appropriate range in this case, 1958 if the initiator has requested the SA due to a data packet, the 1959 initiator SHOULD include as the first Traffic Selector in each of TSi 1960 and TSr a very specific Traffic Selector including the addresses in 1961 the packet triggering the request. In the example, the initiator 1962 would include in TSi two Traffic Selectors: the first containing the 1963 address range (198.51.100.43 - 198.51.100.43) and the source port and 1964 IP protocol from the packet and the second containing (198.51.100.0 - 1965 198.51.100.255) with all ports and IP protocols. The initiator would 1966 similarly include two Traffic Selectors in TSr. If the initiator 1967 creates the Child SA pair not in response to an arriving packet, but 1968 rather, say, upon startup, then there may be no specific addresses 1969 the initiator prefers for the initial tunnel over any other. In that 1970 case, the first values in TSi and TSr can be ranges rather than 1971 specific values. 1973 The responder performs the narrowing as follows: 1975 o If the responder's policy does not allow it to accept any part of 1976 the proposed Traffic Selectors, it responds with a TS_UNACCEPTABLE 1977 Notify message. 1979 o If the responder's policy allows the entire set of traffic covered 1980 by TSi and TSr, no narrowing is necessary, and the responder can 1981 return the same TSi and TSr values. 1983 o If the responder's policy allows it to accept the first selector 1984 of TSi and TSr, then the responder MUST narrow the Traffic 1985 Selectors to a subset that includes the initiator's first choices. 1986 In this example above, the responder might respond with TSi being 1987 (198.51.100.43 - 198.51.100.43) with all ports and IP protocols. 1989 o If the responder's policy does not allow it to accept the first 1990 selector of TSi and TSr, the responder narrows to an acceptable 1991 subset of TSi and TSr. 1993 When narrowing is done, there may be several subsets that are 1994 acceptable but their union is not. In this case, the responder 1995 arbitrarily chooses one of them, and MAY include an 1996 ADDITIONAL_TS_POSSIBLE notification in the response. The 1997 ADDITIONAL_TS_POSSIBLE notification asserts that the responder 1998 narrowed the proposed Traffic Selectors but that other Traffic 1999 Selectors would also have been acceptable, though only in a separate 2000 SA. There is no data associated with this Notify type. This case 2001 will occur only when the initiator and responder are configured 2002 differently from one another. If the initiator and responder agree 2003 on the granularity of tunnels, the initiator will never request a 2004 tunnel wider than the responder will accept. 2006 It is possible for the responder's policy to contain multiple smaller 2007 ranges, all encompassed by the initiator's Traffic Selector, and with 2008 the responder's policy being that each of those ranges should be sent 2009 over a different SA. Continuing the example above, the responder 2010 might have a policy of being willing to tunnel those addresses to and 2011 from the initiator, but might require that each address pair be on a 2012 separately negotiated Child SA. If the initiator didn't generate its 2013 request based on the packet, but (for example) upon startup, there 2014 would not be the very specific first Traffic Selectors helping the 2015 responder to select the correct range. There would be no way for the 2016 responder to determine which pair of addresses should be included in 2017 this tunnel, and it would have to make a guess or reject the request 2018 with a SINGLE_PAIR_REQUIRED Notify message. 2020 The SINGLE_PAIR_REQUIRED error indicates that a CREATE_CHILD_SA 2021 request is unacceptable because its sender is only willing to accept 2022 Traffic Selectors specifying a single pair of addresses. The 2023 requestor is expected to respond by requesting an SA for only the 2024 specific traffic it is trying to forward. 2026 Few implementations will have policies that require separate SAs for 2027 each address pair. Because of this, if only some parts of the TSi 2028 and TSr proposed by the initiator are acceptable to the responder, 2029 responders SHOULD narrow the selectors to an acceptable subset rather 2030 than use SINGLE_PAIR_REQUIRED. 2032 2.9.1. Traffic Selectors Violating Own Policy 2034 When creating a new SA, the initiator needs to avoid proposing 2035 Traffic Selectors that violate its own policy. If this rule is not 2036 followed, valid traffic may be dropped. If you use decorrelated 2037 policies from [IPSECARCH], this kind of policy violations cannot 2038 happen. 2040 This is best illustrated by an example. Suppose that host A has a 2041 policy whose effect is that traffic to 198.51.100.66 is sent via host 2042 B encrypted using AES, and traffic to all other hosts in 2043 198.51.100.0/24 is also sent via B, but must use 3DES. Suppose also 2044 that host B accepts any combination of AES and 3DES. 2046 If host A now proposes an SA that uses 3DES, and includes TSr 2047 containing (198.51.100.0-198.51.100.255), this will be accepted by 2048 host B. Now, host B can also use this SA to send traffic from 2049 198.51.100.66, but those packets will be dropped by A since it 2050 requires the use of AES for this traffic. Even if host A creates a 2051 new SA only for 198.51.100.66 that uses AES, host B may freely 2052 continue to use the first SA for the traffic. In this situation, 2053 when proposing the SA, host A should have followed its own policy, 2054 and included a TSr containing ((198.51.100.0- 2055 198.51.100.65),(198.51.100.67-198.51.100.255)) instead. 2057 In general, if (1) the initiator makes a proposal "for traffic X 2058 (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator 2059 does not actually accept traffic X' with SA, and (3) the initiator 2060 would be willing to accept traffic X' with some SA' (!=SA), valid 2061 traffic can be unnecessarily dropped since the responder can apply 2062 either SA or SA' to traffic X'. 2064 2.10. Nonces 2066 The IKE_SA_INIT messages each contain a nonce. These nonces are used 2067 as inputs to cryptographic functions. The CREATE_CHILD_SA request 2068 and the CREATE_CHILD_SA response also contain nonces. These nonces 2069 are used to add freshness to the key derivation technique used to 2070 obtain keys for Child SA, and to ensure creation of strong 2071 pseudorandom bits from the Diffie-Hellman key. Nonces used in IKEv2 2072 MUST be randomly chosen, MUST be at least 128 bits in size, and MUST 2073 be at least half the key size of the negotiated pseudorandom function 2074 (PRF). However, the initiator chooses the nonce before the outcome 2075 of the negotiation is known. Because of that, the nonce has to be 2076 long enough for all the PRFs being proposed. If the same random 2077 number source is used for both keys and nonces, care must be taken to 2078 ensure that the latter use does not compromise the former. 2080 2.11. Address and Port Agility 2082 IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and 2083 AH associations for the same IP addresses over which it runs. The IP 2084 addresses and ports in the outer header are, however, not themselves 2085 cryptographically protected, and IKE is designed to work even through 2086 Network Address Translation (NAT) boxes. An implementation MUST 2087 accept incoming requests even if the source port is not 500 or 4500, 2088 and MUST respond to the address and port from which the request was 2089 received. It MUST specify the address and port at which the request 2090 was received as the source address and port in the response. IKE 2091 functions identically over IPv4 or IPv6. 2093 2.12. Reuse of Diffie-Hellman Exponentials 2095 IKE generates keying material using an ephemeral Diffie-Hellman 2096 exchange in order to gain the property of "perfect forward secrecy". 2097 This means that once a connection is closed and its corresponding 2098 keys are forgotten, even someone who has recorded all of the data 2099 from the connection and gets access to all of the long-term keys of 2100 the two endpoints cannot reconstruct the keys used to protect the 2101 conversation without doing a brute force search of the session key 2102 space. 2104 Achieving perfect forward secrecy requires that when a connection is 2105 closed, each endpoint MUST forget not only the keys used by the 2106 connection but also any information that could be used to recompute 2107 those keys. 2109 Because computing Diffie-Hellman exponentials is computationally 2110 expensive, an endpoint may find it advantageous to reuse those 2111 exponentials for multiple connection setups. There are several 2112 reasonable strategies for doing this. An endpoint could choose a new 2113 exponential only periodically though this could result in less-than- 2114 perfect forward secrecy if some connection lasts for less than the 2115 lifetime of the exponential. Or it could keep track of which 2116 exponential was used for each connection and delete the information 2117 associated with the exponential only when some corresponding 2118 connection was closed. This would allow the exponential to be reused 2119 without losing perfect forward secrecy at the cost of maintaining 2120 more state. 2122 Whether and when to reuse Diffie-Hellman exponentials are private 2123 decisions in the sense that they will not affect interoperability. 2124 An implementation that reuses exponentials MAY choose to remember the 2125 exponential used by the other endpoint on past exchanges and if one 2126 is reused to avoid the second half of the calculation. See [REUSE] 2127 and [RFC6989] for a security analysis of this practice and for 2128 additional security considerations when reusing ephemeral Diffie- 2129 Hellman keys. 2131 2.13. Generating Keying Material 2133 In the context of the IKE SA, four cryptographic algorithms are 2134 negotiated: an encryption algorithm, an integrity protection 2135 algorithm, a Diffie-Hellman group, and a pseudorandom function (PRF). 2136 The PRF is used for the construction of keying material for all of 2137 the cryptographic algorithms used in both the IKE SA and the Child 2138 SAs. 2140 We assume that each encryption algorithm and integrity protection 2141 algorithm uses a fixed-size key and that any randomly chosen value of 2142 that fixed size can serve as an appropriate key. For algorithms that 2143 accept a variable-length key, a fixed key size MUST be specified as 2144 part of the cryptographic transform negotiated (see Section 3.3.5 for 2145 the definition of the Key Length transform attribute). For 2146 algorithms for which not all values are valid keys (such as DES or 2147 3DES with key parity), the algorithm by which keys are derived from 2148 arbitrary values MUST be specified by the cryptographic transform. 2149 For integrity protection functions based on Hashed Message 2150 Authentication Code (HMAC), the fixed key size is the size of the 2151 output of the underlying hash function. 2153 It is assumed that PRFs accept keys of any length, but have a 2154 preferred key size. The preferred key size MUST be used as the 2155 length of SK_d, SK_pi, and SK_pr (see Section 2.14). For PRFs based 2156 on the HMAC construction, the preferred key size is equal to the 2157 length of the output of the underlying hash function. Other types of 2158 PRFs MUST specify their preferred key size. 2160 Keying material will always be derived as the output of the 2161 negotiated PRF algorithm. Since the amount of keying material needed 2162 may be greater than the size of the output of the PRF, the PRF is 2163 used iteratively. The term "prf+" describes a function that outputs 2164 a pseudorandom stream based on the inputs to a pseudorandom function 2165 called "prf". 2167 In the following, | indicates concatenation. prf+ is defined as: 2169 prf+ (K,S) = T1 | T2 | T3 | T4 | ... 2171 where: 2172 T1 = prf (K, S | 0x01) 2173 T2 = prf (K, T1 | S | 0x02) 2174 T3 = prf (K, T2 | S | 0x03) 2175 T4 = prf (K, T3 | S | 0x04) 2176 ... 2178 This continues until all the material needed to compute all required 2179 keys has been output from prf+. The keys are taken from the output 2180 string without regard to boundaries (e.g., if the required keys are a 2181 256-bit Advanced Encryption Standard (AES) key and a 160-bit HMAC 2182 key, and the prf function generates 160 bits, the AES key will come 2183 from T1 and the beginning of T2, while the HMAC key will come from 2184 the rest of T2 and the beginning of T3). 2186 The constant concatenated to the end of each prf function is a single 2187 octet. The prf+ function is not defined beyond 255 times the size of 2188 the prf function output. 2190 2.14. Generating Keying Material for the IKE SA 2192 The shared keys are computed as follows. A quantity called SKEYSEED 2193 is calculated from the nonces exchanged during the IKE_SA_INIT 2194 exchange and the Diffie-Hellman shared secret established during that 2195 exchange. SKEYSEED is used to calculate seven other secrets: SK_d 2196 used for deriving new keys for the Child SAs established with this 2197 IKE SA; SK_ai and SK_ar used as a key to the integrity protection 2198 algorithm for authenticating the component messages of subsequent 2199 exchanges; SK_ei and SK_er used for encrypting (and of course 2200 decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are 2201 used when generating an AUTH payload. The lengths of SK_d, SK_pi, 2202 and SK_pr MUST be the preferred key length of the PRF agreed upon. 2204 SKEYSEED and its derivatives are computed as follows: 2206 SKEYSEED = prf(Ni | Nr, g^ir) 2208 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } 2209 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) 2211 (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, 2212 SK_pi, and SK_pr are taken in order from the generated bits of the 2213 prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman 2214 exchange. g^ir is represented as a string of octets in big endian 2215 order padded with zeros if necessary to make it the length of the 2216 modulus. Ni and Nr are the nonces, stripped of any headers. For 2217 historical backward-compatibility reasons, there are two PRFs that 2218 are treated specially in this calculation. If the negotiated PRF is 2219 AES-XCBC-PRF-128 [AESXCBCPRF128] or AES-CMAC-PRF-128 [AESCMACPRF128], 2220 only the first 64 bits of Ni and the first 64 bits of Nr are used in 2221 calculating SKEYSEED, but all the bits are used for input to the prf+ 2222 function. 2224 The two directions of traffic flow use different keys. The keys used 2225 to protect messages from the original initiator are SK_ai and SK_ei. 2226 The keys used to protect messages in the other direction are SK_ar 2227 and SK_er. 2229 2.15. Authentication of the IKE SA 2231 When not using extensible authentication (see Section 2.16), the 2232 peers are authenticated by having each sign (or MAC using a padded 2233 shared secret as the key, as described later in this section) a block 2234 of data. In these calculations, IDi' and IDr' are the entire ID 2235 payloads excluding the fixed header. For the responder, the octets 2236 to be signed start with the first octet of the first SPI in the 2237 header of the second message (IKE_SA_INIT response) and end with the 2238 last octet of the last payload in the second message. Appended to 2239 this (for the purposes of computing the signature) are the 2240 initiator's nonce Ni (just the value, not the payload containing it), 2241 and the value prf(SK_pr, IDr'). Note that neither the nonce Ni nor 2242 the value prf(SK_pr, IDr') are transmitted. Similarly, the initiator 2243 signs the first message (IKE_SA_INIT request), starting with the 2244 first octet of the first SPI in the header and ending with the last 2245 octet of the last payload. Appended to this (for purposes of 2246 computing the signature) are the responder's nonce Nr, and the value 2247 prf(SK_pi, IDi'). It is critical to the security of the exchange 2248 that each side sign the other side's nonce. 2250 The initiator's signed octets can be described as: 2252 InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI 2253 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 2254 RealIKEHDR = SPIi | SPIr | . . . | Length 2255 RealMessage1 = RealIKEHDR | RestOfMessage1 2256 NonceRPayload = PayloadHeader | NonceRData 2257 InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload 2258 RestOfInitIDPayload = IDType | RESERVED | InitIDData 2259 MACedIDForI = prf(SK_pi, RestOfInitIDPayload) 2261 The responder's signed octets can be described as: 2263 ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR 2264 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 2265 RealIKEHDR = SPIi | SPIr | . . . | Length 2266 RealMessage2 = RealIKEHDR | RestOfMessage2 2267 NonceIPayload = PayloadHeader | NonceIData 2268 ResponderIDPayload = PayloadHeader | RestOfRespIDPayload 2269 RestOfRespIDPayload = IDType | RESERVED | RespIDData 2270 MACedIDForR = prf(SK_pr, RestOfRespIDPayload) 2271 Note that all of the payloads are included under the signature, 2272 including any payload types not defined in this document. If the 2273 first message of the exchange is sent multiple times (such as with a 2274 responder cookie and/or a different Diffie-Hellman group), it is the 2275 latest version of the message that is signed. 2277 Optionally, messages 3 and 4 MAY include a certificate, or 2278 certificate chain providing evidence that the key used to compute a 2279 digital signature belongs to the name in the ID payload. The 2280 signature or MAC will be computed using algorithms dictated by the 2281 type of key used by the signer, and specified by the Auth Method 2282 field in the Authentication payload. There is no requirement that 2283 the initiator and responder sign with the same cryptographic 2284 algorithms. The choice of cryptographic algorithms depends on the 2285 type of key each has. In particular, the initiator may be using a 2286 shared key while the responder may have a public signature key and 2287 certificate. It will commonly be the case (but it is not required) 2288 that, if a shared secret is used for authentication, the same key is 2289 used in both directions. 2291 Note that it is a common but typically insecure practice to have a 2292 shared key derived solely from a user-chosen password without 2293 incorporating another source of randomness. This is typically 2294 insecure because user-chosen passwords are unlikely to have 2295 sufficient unpredictability to resist dictionary attacks and these 2296 attacks are not prevented in this authentication method. 2297 (Applications using password-based authentication for bootstrapping 2298 and IKE SA should use the authentication method in Section 2.16, 2299 which is designed to prevent off-line dictionary attacks.) The pre- 2300 shared key needs to contain as much unpredictability as the strongest 2301 key being negotiated. In the case of a pre-shared key, the AUTH 2302 value is computed as: 2304 For the initiator: 2305 AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), 2306 ) 2307 For the responder: 2308 AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), 2309 ) 2311 where the string "Key Pad for IKEv2" is 17 ASCII characters without 2312 null termination. The shared secret can be variable length. The pad 2313 string is added so that if the shared secret is derived from a 2314 password, the IKE implementation need not store the password in 2315 cleartext, but rather can store the value prf(Shared Secret,"Key Pad 2316 for IKEv2"), which could not be used as a password equivalent for 2317 protocols other than IKEv2. As noted above, deriving the shared 2318 secret from a password is not secure. This construction is used 2319 because it is anticipated that people will do it anyway. The 2320 management interface by which the shared secret is provided MUST 2321 accept ASCII strings of at least 64 octets and MUST NOT add a null 2322 terminator before using them as shared secrets. It MUST also accept 2323 a hex encoding of the shared secret. The management interface MAY 2324 accept other encodings if the algorithm for translating the encoding 2325 to a binary string is specified. 2327 There are two types of EAP authentication (described in 2328 Section 2.16), and each type uses different values in the AUTH 2329 computations shown above. If the EAP method is key-generating, 2330 substitute master session key (MSK) for the shared secret in the 2331 computation. For non-key-generating methods, substitute SK_pi and 2332 SK_pr, respectively, for the shared secret in the two AUTH 2333 computations. 2335 2.16. Extensible Authentication Protocol Methods 2337 In addition to authentication using public key signatures and shared 2338 secrets, IKE supports authentication using methods defined in RFC 2339 3748 [EAP]. Typically, these methods are asymmetric (designed for a 2340 user authenticating to a server), and they may not be mutual. For 2341 this reason, these protocols are typically used to authenticate the 2342 initiator to the responder and MUST be used in conjunction with a 2343 public-key-signature-based authentication of the responder to the 2344 initiator. These methods are often associated with mechanisms 2345 referred to as "Legacy Authentication" mechanisms. 2347 While this document references [EAP] with the intent that new methods 2348 can be added in the future without updating this specification, some 2349 simpler variations are documented here. [EAP] defines an 2350 authentication protocol requiring a variable number of messages. 2351 Extensible Authentication is implemented in IKE as additional 2352 IKE_AUTH exchanges that MUST be completed in order to initialize the 2353 IKE SA. 2355 An initiator indicates a desire to use EAP by leaving out the AUTH 2356 payload from the first message in the IKE_AUTH exchange. (Note that 2357 the AUTH payload is required for non-EAP authentication, and is thus 2358 not marked as optional in the rest of this document.) By including 2359 an IDi payload but not an AUTH payload, the initiator has declared an 2360 identity but has not proven it. If the responder is willing to use 2361 an EAP method, it will place an Extensible Authentication Protocol 2362 (EAP) payload in the response of the IKE_AUTH exchange and defer 2363 sending SAr2, TSi, and TSr until initiator authentication is complete 2364 in a subsequent IKE_AUTH exchange. In the case of a minimal EAP 2365 method, the initial SA establishment will appear as follows: 2367 Initiator Responder 2368 ------------------------------------------------------------------- 2369 HDR, SAi1, KEi, Ni --> 2370 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 2371 HDR, SK {IDi, [CERTREQ,] 2372 [IDr,] SAi2, 2373 TSi, TSr} --> 2374 <-- HDR, SK {IDr, [CERT,] AUTH, 2375 EAP } 2376 HDR, SK {EAP} --> 2377 <-- HDR, SK {EAP (success)} 2378 HDR, SK {AUTH} --> 2379 <-- HDR, SK {AUTH, SAr2, TSi, TSr } 2381 As described in Section 2.2, when EAP is used, each pair of IKE SA 2382 initial setup messages will have their message numbers incremented; 2383 the first pair of IKE_AUTH messages will have an ID of 1, the second 2384 will be 2, and so on. 2386 For EAP methods that create a shared key as a side effect of 2387 authentication, that shared key MUST be used by both the initiator 2388 and responder to generate AUTH payloads in messages 7 and 8 using the 2389 syntax for shared secrets specified in Section 2.15. The shared key 2390 from EAP is the field from the EAP specification named MSK. This 2391 shared key generated during an IKE exchange MUST NOT be used for any 2392 other purpose. 2394 EAP methods that do not establish a shared key SHOULD NOT be used, as 2395 they are subject to a number of man-in-the-middle attacks [EAPMITM] 2396 if these EAP methods are used in other protocols that do not use a 2397 server-authenticated tunnel. Please see the Security Considerations 2398 section for more details. If EAP methods that do not generate a 2399 shared key are used, the AUTH payloads in messages 7 and 8 MUST be 2400 generated using SK_pi and SK_pr, respectively. 2402 The initiator of an IKE SA using EAP needs to be capable of extending 2403 the initial protocol exchange to at least ten IKE_AUTH exchanges in 2404 the event the responder sends notification messages and/or retries 2405 the authentication prompt. Once the protocol exchange defined by the 2406 chosen EAP authentication method has successfully terminated, the 2407 responder MUST send an EAP payload containing the Success message. 2408 Similarly, if the authentication method has failed, the responder 2409 MUST send an EAP payload containing the Failure message. The 2410 responder MAY at any time terminate the IKE exchange by sending an 2411 EAP payload containing the Failure message. 2413 Following such an extended exchange, the EAP AUTH payloads MUST be 2414 included in the two messages following the one containing the EAP 2415 Success message. 2417 When the initiator authentication uses EAP, it is possible that the 2418 contents of the IDi payload is used only for Authentication, 2419 Authorization, and Accounting (AAA) routing purposes and selecting 2420 which EAP method to use. This value may be different from the 2421 identity authenticated by the EAP method. It is important that 2422 policy lookups and access control decisions use the actual 2423 authenticated identity. Often the EAP server is implemented in a 2424 separate AAA server that communicates with the IKEv2 responder. In 2425 this case, the authenticated identity, if different from that in the 2426 IDi payload, has to be sent from the AAA server to the IKEv2 2427 responder. 2429 2.17. Generating Keying Material for Child SAs 2431 A single Child SA is created by the IKE_AUTH exchange, and additional 2432 Child SAs can optionally be created in CREATE_CHILD_SA exchanges. 2433 Keying material for them is generated as follows: 2435 KEYMAT = prf+(SK_d, Ni | Nr) 2437 Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this 2438 request is the first Child SA created or the fresh Ni and Nr from the 2439 CREATE_CHILD_SA exchange if this is a subsequent creation. 2441 For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman 2442 exchange, the keying material is defined as: 2444 KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) 2446 where g^ir (new) is the shared secret from the ephemeral Diffie- 2447 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 2448 octet string in big endian order padded with zeros in the high-order 2449 bits if necessary to make it the length of the modulus). 2451 A single CREATE_CHILD_SA negotiation may result in multiple Security 2452 Associations. ESP and AH SAs exist in pairs (one in each direction), 2453 so two SAs are created in a single Child SA negotiation for them. 2454 Furthermore, Child SA negotiation may include some future IPsec 2455 protocol(s) in addition to, or instead of, ESP or AH (for example, 2456 ROHC_INTEG as described in [ROHCV2]). In any case, keying material 2457 for each Child SA MUST be taken from the expanded KEYMAT using the 2458 following rules: 2460 o All keys for SAs carrying data from the initiator to the responder 2461 are taken before SAs going from the responder to the initiator. 2463 o If multiple IPsec protocols are negotiated, keying material for 2464 each Child SA is taken in the order in which the protocol headers 2465 will appear in the encapsulated packet. 2467 o If an IPsec protocol requires multiple keys, the order in which 2468 they are taken from the SA's keying material needs to be described 2469 in the protocol's specification. For ESP and AH, [IPSECARCH] 2470 defines the order, namely: the encryption key (if any) MUST be 2471 taken from the first bits and the integrity key (if any) MUST be 2472 taken from the remaining bits. 2474 Each cryptographic algorithm takes a fixed number of bits of keying 2475 material specified as part of the algorithm, or negotiated in SA 2476 payloads (see Section 2.13 for description of key lengths, and 2477 Section 3.3.5 for the definition of the Key Length transform 2478 attribute). 2480 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange 2482 The CREATE_CHILD_SA exchange can be used to rekey an existing IKE SA 2483 (see Sections 1.3.2 and 2.8). New initiator and responder SPIs are 2484 supplied in the SPI fields in the Proposal structures inside the 2485 Security Association (SA) payloads (not the SPI fields in the IKE 2486 header). The TS payloads are omitted when rekeying an IKE SA. 2487 SKEYSEED for the new IKE SA is computed using SK_d from the existing 2488 IKE SA as follows: 2490 SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr) 2492 where g^ir (new) is the shared secret from the ephemeral Diffie- 2493 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 2494 octet string in big endian order padded with zeros if necessary to 2495 make it the length of the modulus) and Ni and Nr are the two nonces 2496 stripped of any headers. 2498 The old and new IKE SA may have selected a different PRF. Because 2499 the rekeying exchange belongs to the old IKE SA, it is the old IKE 2500 SA's PRF that is used to generate SKEYSEED. 2502 The main reason for rekeying the IKE SA is to ensure that the 2503 compromise of old keying material does not provide information about 2504 the current keys, or vice versa. Therefore, implementations MUST 2505 perform a new Diffie-Hellman exchange when rekeying the IKE SA. In 2506 other words, an initiator MUST NOT propose the value "NONE" for the 2507 Diffie-Hellman transform, and a responder MUST NOT accept such a 2508 proposal. This means that a successful exchange rekeying the IKE SA 2509 always includes the KEi/KEr payloads. 2511 The new IKE SA MUST reset its message counters to 0. 2513 SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as 2514 specified in Section 2.14, using SPIi, SPIr, Ni, and Nr from the new 2515 exchange, and using the new IKE SA's PRF. 2517 2.19. Requesting an Internal Address on a Remote Network 2519 Most commonly occurring in the endpoint-to-security-gateway scenario, 2520 an endpoint may need an IP address in the network protected by the 2521 security gateway and may need to have that address dynamically 2522 assigned. A request for such a temporary address can be included in 2523 any request to create a Child SA (including the implicit request in 2524 message 3) by including a CP payload. Note, however, it is usual to 2525 only assign one IP address during the IKE_AUTH exchange. That 2526 address persists at least until the deletion of the IKE SA. 2528 This function provides address allocation to an IPsec Remote Access 2529 Client (IRAC) trying to tunnel into a network protected by an IPsec 2530 Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an 2531 IKE SA and a Child SA, the IRAC MUST request the IRAS-controlled 2532 address (and optionally other information concerning the protected 2533 network) in the IKE_AUTH exchange. The IRAS may procure an address 2534 for the IRAC from any number of sources such as a DHCP/BOOTP 2535 (Bootstrap Protocol) server or its own address pool. 2537 Initiator Responder 2538 ------------------------------------------------------------------- 2539 HDR, SK {IDi, [CERT,] 2540 [CERTREQ,] [IDr,] AUTH, 2541 CP(CFG_REQUEST), SAi2, 2542 TSi, TSr} --> 2543 <-- HDR, SK {IDr, [CERT,] AUTH, 2544 CP(CFG_REPLY), SAr2, 2545 TSi, TSr} 2547 In all cases, the CP payload MUST be inserted before the SA payload. 2548 In variations of the protocol where there are multiple IKE_AUTH 2549 exchanges, the CP payloads MUST be inserted in the messages 2550 containing the SA payloads. 2552 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute 2553 (either IPv4 or IPv6) but MAY contain any number of additional 2554 attributes the initiator wants returned in the response. 2556 For example, message from initiator to responder: 2558 CP(CFG_REQUEST)= 2559 INTERNAL_ADDRESS() 2560 TSi = (0, 0-65535,0.0.0.0-255.255.255.255) 2561 TSr = (0, 0-65535,0.0.0.0-255.255.255.255) 2563 NOTE: Traffic Selectors contain (protocol, port range, address 2564 range). 2566 Message from responder to initiator: 2568 CP(CFG_REPLY)= 2569 INTERNAL_ADDRESS(192.0.2.202) 2570 INTERNAL_NETMASK(255.255.255.0) 2571 INTERNAL_SUBNET(192.0.2.0/255.255.255.0) 2572 TSi = (0, 0-65535,192.0.2.202-192.0.2.202) 2573 TSr = (0, 0-65535,192.0.2.0-192.0.2.255) 2575 All returned values will be implementation dependent. As can be seen 2576 in the above example, the IRAS MAY also send other attributes that 2577 were not included in CP(CFG_REQUEST) and MAY ignore the non- 2578 mandatory attributes that it does not support. 2580 The responder MUST NOT send a CFG_REPLY without having first received 2581 a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS 2582 to perform an unnecessary configuration lookup if the IRAC cannot 2583 process the REPLY. 2585 In the case where the IRAS's configuration requires that CP be used 2586 for a given identity IDi, but IRAC has failed to send a 2587 CP(CFG_REQUEST), IRAS MUST fail the request, and terminate the Child 2588 SA creation with a FAILED_CP_REQUIRED error. The FAILED_CP_REQUIRED 2589 is not fatal to the IKE SA; it simply causes the Child SA creation to 2590 fail. The initiator can fix this by later starting a new 2591 Configuration payload request. There is no associated data in the 2592 FAILED_CP_REQUIRED error. 2594 2.20. Requesting the Peer's Version 2596 An IKE peer wishing to inquire about the other peer's IKE software 2597 version information MAY use the method below. This is an example of 2598 a configuration request within an INFORMATIONAL exchange, after the 2599 IKE SA and first Child SA have been created. 2601 An IKE implementation MAY decline to give out version information 2602 prior to authentication or even after authentication in case some 2603 implementation is known to have some security weakness. In that 2604 case, it MUST either return an empty string or no CP payload if CP is 2605 not supported. 2607 Initiator Responder 2608 ------------------------------------------------------------------- 2609 HDR, SK{CP(CFG_REQUEST)} --> 2610 <-- HDR, SK{CP(CFG_REPLY)} 2612 CP(CFG_REQUEST)= 2613 APPLICATION_VERSION("") 2615 CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar 2616 Inc.") 2618 2.21. Error Handling 2620 There are many kinds of errors that can occur during IKE processing. 2621 The general rule is that if a request is received that is badly 2622 formatted, or unacceptable for reasons of policy (such as no matching 2623 cryptographic algorithms), the response contains a Notify payload 2624 indicating the error. The decision whether or not to send such a 2625 response depends whether or not there is an authenticated IKE SA. 2627 If there is an error parsing or processing a response packet, the 2628 general rule is to not send back any error message because responses 2629 should not generate new requests (and a new request would be the only 2630 way to send back an error message). Such errors in parsing or 2631 processing response packets should still cause the recipient to clean 2632 up the IKE state (for example, by sending a Delete for a bad SA). 2634 Only authentication failures (AUTHENTICATION_FAILED and EAP failure) 2635 and malformed messages (INVALID_SYNTAX) lead to a deletion of the IKE 2636 SA without requiring an explicit INFORMATIONAL exchange carrying a 2637 Delete payload. Other error conditions MAY require such an exchange 2638 if policy dictates that this is needed. If the exchange is 2639 terminated with EAP Failure, an AUTHENTICATION_FAILED notification is 2640 not sent. 2642 2.21.1. Error Handling in IKE_SA_INIT 2644 Errors that occur before a cryptographically protected IKE SA is 2645 established need to be handled very carefully. There is a trade-off 2646 between wanting to help the peer to diagnose a problem and thus 2647 responding to the error and wanting to avoid being part of a DoS 2648 attack based on forged messages. 2650 In an IKE_SA_INIT exchange, any error notification causes the 2651 exchange to fail. Note that some error notifications such as COOKIE, 2652 INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent 2653 successful exchange. Because all error notifications are completely 2654 unauthenticated, the recipient should continue trying for some time 2655 before giving up. The recipient should not immediately act based on 2656 the error notification unless corrective actions are defined in this 2657 specification, such as for COOKIE, INVALID_KE_PAYLOAD, and 2658 INVALID_MAJOR_VERSION. 2660 2.21.2. Error Handling in IKE_AUTH 2662 All errors that occur in an IKE_AUTH exchange, causing the 2663 authentication to fail for whatever reason (invalid shared secret, 2664 invalid ID, untrusted certificate issuer, revoked or expired 2665 certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED 2666 notification. If the error occurred on the responder, the 2667 notification is returned in the protected response, and is usually 2668 the only payload in that response. Although the IKE_AUTH messages 2669 are encrypted and integrity protected, if the peer receiving this 2670 notification has not authenticated the other end yet, that peer needs 2671 to treat the information with caution. 2673 If the error occurs on the initiator, the notification MAY be 2674 returned in a separate INFORMATIONAL exchange, usually with no other 2675 payloads. This is an exception for the general rule of not starting 2676 new exchanges based on errors in responses. 2678 Note, however, that request messages that contain an unsupported 2679 critical payload, or where the whole message is malformed (rather 2680 than just bad payload contents), MUST be rejected in their entirety, 2681 and MUST only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or 2682 INVALID_SYNTAX Notification sent as a response. The receiver should 2683 not verify the payloads related to authentication in this case. 2685 If authentication has succeeded in the IKE_AUTH exchange, the IKE SA 2686 is established; however, establishing the Child SA or requesting 2687 configuration information may still fail. This failure does not 2688 automatically cause the IKE SA to be deleted. Specifically, a 2689 responder may include all the payloads associated with authentication 2690 (IDr, CERT, and AUTH) while sending error notifications for the 2691 piggybacked exchanges (FAILED_CP_REQUIRED, NO_PROPOSAL_CHOSEN, and so 2692 on), and the initiator MUST NOT fail the authentication because of 2693 this. The initiator MAY, of course, for reasons of policy later 2694 delete such an IKE SA. 2696 In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately 2697 following it (in case an error happened when processing a response to 2698 IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and 2699 AUTHENTICATION_FAILED notifications are the only ones to cause the 2700 IKE SA to be deleted or not created, without a Delete payload. 2701 Extension documents may define new error notifications with these 2702 semantics, but MUST NOT use them unless the peer has been shown to 2703 understand them, such as by using the Vendor ID payload. 2705 2.21.3. Error Handling after IKE SA is Authenticated 2707 After the IKE SA is authenticated, all requests having errors MUST 2708 result in a response notifying about the error. 2710 In normal situations, there should not be cases where a valid 2711 response from one peer results in an error situation in the other 2712 peer, so there should not be any reason for a peer to send error 2713 messages to the other end except as a response. Because sending such 2714 error messages as an INFORMATIONAL exchange might lead to further 2715 errors that could cause loops, such errors SHOULD NOT be sent. If 2716 errors are seen that indicate that the peers do not have the same 2717 state, it might be good to delete the IKE SA to clean up state and 2718 start over. 2720 If a peer parsing a request notices that it is badly formatted (after 2721 it has passed the message authentication code checks and window 2722 checks) and it returns an INVALID_SYNTAX notification, then this 2723 error notification is considered fatal in both peers, meaning that 2724 the IKE SA is deleted without needing an explicit Delete payload. 2726 2.21.4. Error Handling Outside IKE SA 2728 A node needs to limit the rate at which it will send messages in 2729 response to unprotected messages. 2731 If a node receives a message on UDP port 500 or 4500 outside the 2732 context of an IKE SA known to it (and the message is not a request to 2733 start an IKE SA), this may be the result of a recent crash of the 2734 node. If the message is marked as a response, the node can audit the 2735 suspicious event but MUST NOT respond. If the message is marked as a 2736 request, the node can audit the suspicious event and MAY send a 2737 response. If a response is sent, the response MUST be sent to the IP 2738 address and port from where it came with the same IKE SPIs and the 2739 Message ID copied. The response MUST NOT be cryptographically 2740 protected and MUST contain an INVALID_IKE_SPI Notify payload. The 2741 INVALID_IKE_SPI notification indicates an IKE message was received 2742 with an unrecognized destination SPI; this usually indicates that the 2743 recipient has rebooted and forgotten the existence of an IKE SA. 2745 A peer receiving such an unprotected Notify payload MUST NOT respond 2746 and MUST NOT change the state of any existing SAs. The message might 2747 be a forgery or might be a response that a genuine correspondent was 2748 tricked into sending. A node should treat such a message (and also a 2749 network message like ICMP destination unreachable) as a hint that 2750 there might be problems with SAs to that IP address and should 2751 initiate a liveness check for any such IKE SA. An implementation 2752 SHOULD limit the frequency of such tests to avoid being tricked into 2753 participating in a DoS attack. 2755 If an error occurs outside the context of an IKE request (e.g., the 2756 node is getting ESP messages on a nonexistent SPI), the node SHOULD 2757 initiate an INFORMATIONAL exchange with a Notify payload describing 2758 the problem. 2760 A node receiving a suspicious message from an IP address (and port, 2761 if NAT traversal is used) with which it has an IKE SA SHOULD send an 2762 IKE Notify payload in an IKE INFORMATIONAL exchange over that SA. 2763 The recipient MUST NOT change the state of any SAs as a result, but 2764 may wish to audit the event to aid in diagnosing malfunctions. 2766 2.22. IPComp 2768 Use of IP Compression [IP-COMP] can be negotiated as part of the 2769 setup of a Child SA. While IP Compression involves an extra header 2770 in each packet and a compression parameter index (CPI), the virtual 2771 "compression association" has no life outside the ESP or AH SA that 2772 contains it. Compression associations disappear when the 2773 corresponding ESP or AH SA goes away. It is not explicitly mentioned 2774 in any Delete payload. 2776 Negotiation of IP Compression is separate from the negotiation of 2777 cryptographic parameters associated with a Child SA. A node 2778 requesting a Child SA MAY advertise its support for one or more 2779 compression algorithms through one or more Notify payloads of type 2780 IPCOMP_SUPPORTED. This Notify message may be included only in a 2781 message containing an SA payload negotiating a Child SA and indicates 2782 a willingness by its sender to use IPComp on this SA. The response 2783 MAY indicate acceptance of a single compression algorithm with a 2784 Notify payload of type IPCOMP_SUPPORTED. These payloads MUST NOT 2785 occur in messages that do not contain SA payloads. 2787 The data associated with this Notify message includes a two-octet 2788 IPComp CPI followed by a one-octet Transform ID optionally followed 2789 by attributes whose length and format are defined by that Transform 2790 ID. A message proposing an SA may contain multiple IPCOMP_SUPPORTED 2791 notifications to indicate multiple supported algorithms. A message 2792 accepting an SA may contain at most one. 2794 The Transform IDs are listed here. The values in the following table 2795 are only current as of the publication date of RFC 4306. Other 2796 values may have been added since then or will be added after the 2797 publication of this document. Readers should refer to [IKEV2IANA] 2798 for the latest values. 2800 Name Number Defined In 2801 ------------------------------------- 2802 IPCOMP_OUI 1 2803 IPCOMP_DEFLATE 2 RFC 2394 2804 IPCOMP_LZS 3 RFC 2395 2805 IPCOMP_LZJH 4 RFC 3051 2807 Although there has been discussion of allowing multiple compression 2808 algorithms to be accepted and to have different compression 2809 algorithms available for the two directions of a Child SA, 2810 implementations of this specification MUST NOT accept an IPComp 2811 algorithm that was not proposed, MUST NOT accept more than one, and 2812 MUST NOT compress using an algorithm other than one proposed and 2813 accepted in the setup of the Child SA. 2815 A side effect of separating the negotiation of IPComp from 2816 cryptographic parameters is that it is not possible to propose 2817 multiple cryptographic suites and propose IP Compression with some of 2818 them but not others. 2820 In some cases, Robust Header Compression (ROHC) may be more 2821 appropriate than IP Compression. [ROHCV2] defines the use of ROHC 2822 with IKEv2 and IPsec. 2824 2.23. NAT Traversal 2826 Network Address Translation (NAT) gateways are a controversial 2827 subject. This section briefly describes what they are and how they 2828 are likely to act on IKE traffic. Many people believe that NATs are 2829 evil and that we should not design our protocols so as to make them 2830 work better. IKEv2 does specify some unintuitive processing rules in 2831 order that NATs are more likely to work. 2833 NATs exist primarily because of the shortage of IPv4 addresses, 2834 though there are other rationales. IP nodes that are "behind" a NAT 2835 have IP addresses that are not globally unique, but rather are 2836 assigned from some space that is unique within the network behind the 2837 NAT but that are likely to be reused by nodes behind other NATs. 2838 Generally, nodes behind NATs can communicate with other nodes behind 2839 the same NAT and with nodes with globally unique addresses, but not 2840 with nodes behind other NATs. There are exceptions to that rule. 2841 When those nodes make connections to nodes on the real Internet, the 2842 NAT gateway "translates" the IP source address to an address that 2843 will be routed back to the gateway. Messages to the gateway from the 2844 Internet have their destination addresses "translated" to the 2845 internal address that will route the packet to the correct endnode. 2847 NATs are designed to be "transparent" to endnodes. Neither software 2848 on the node behind the NAT nor the node on the Internet requires 2849 modification to communicate through the NAT. Achieving this 2850 transparency is more difficult with some protocols than with others. 2851 Protocols that include IP addresses of the endpoints within the 2852 payloads of the packet will fail unless the NAT gateway understands 2853 the protocol and modifies the internal references as well as those in 2854 the headers. Such knowledge is inherently unreliable, is a network 2855 layer violation, and often results in subtle problems. 2857 Opening an IPsec connection through a NAT introduces special 2858 problems. If the connection runs in transport mode, changing the IP 2859 addresses on packets will cause the checksums to fail and the NAT 2860 cannot correct the checksums because they are cryptographically 2861 protected. Even in tunnel mode, there are routing problems because 2862 transparently translating the addresses of AH and ESP packets 2863 requires special logic in the NAT and that logic is heuristic and 2864 unreliable in nature. For that reason, IKEv2 will use UDP 2865 encapsulation of IKE and ESP packets. This encoding is slightly less 2866 efficient but is easier for NATs to process. In addition, firewalls 2867 may be configured to pass UDP-encapsulated IPsec traffic but not 2868 plain, unencapsulated ESP/AH or vice versa. 2870 It is a common practice of NATs to translate TCP and UDP port numbers 2871 as well as addresses and use the port numbers of inbound packets to 2872 decide which internal node should get a given packet. For this 2873 reason, even though IKE packets MUST be sent to and from UDP port 500 2874 or 4500, they MUST be accepted coming from any port and responses 2875 MUST be sent to the port from whence they came. This is because the 2876 ports may be modified as the packets pass through NATs. Similarly, 2877 IP addresses of the IKE endpoints are generally not included in the 2878 IKE payloads because the payloads are cryptographically protected and 2879 could not be transparently modified by NATs. 2881 Port 4500 is reserved for UDP-encapsulated ESP and IKE. An IPsec 2882 endpoint that discovers a NAT between it and its correspondent (as 2883 described below) MUST send all subsequent traffic from port 4500, 2884 which NATs should not treat specially (as they might with port 500). 2886 An initiator can use port 4500 for both IKE and ESP, regardless of 2887 whether or not there is a NAT, even at the beginning of IKE. When 2888 either side is using port 4500, sending ESP with UDP encapsulation is 2889 not required, but understanding received UDP-encapsulated ESP packets 2890 is required. UDP encapsulation MUST NOT be done on port 500. If 2891 Network Address Translation Traversal (NAT-T) is supported (that is, 2892 if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), 2893 all devices MUST be able to receive and process both UDP-encapsulated 2894 ESP and non-UDP-encapsulated ESP packets at any time. Either side 2895 can decide whether or not to use UDP encapsulation for ESP 2896 irrespective of the choice made by the other side. However, if a NAT 2897 is detected, both devices MUST use UDP encapsulation for ESP. 2899 The specific requirements for supporting NAT traversal [NATREQ] are 2900 listed below. Support for NAT traversal is optional. In this 2901 section only, requirements listed as MUST apply only to 2902 implementations supporting NAT traversal. 2904 o Both the IKE initiator and responder MUST include in their 2905 IKE_SA_INIT packets Notify payloads of type 2906 NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP. Those 2907 payloads can be used to detect if there is NAT between the hosts, 2908 and which end is behind the NAT. The location of the payloads in 2909 the IKE_SA_INIT packets is just after the Ni and Nr payloads 2910 (before the optional CERTREQ payload). 2912 o The data associated with the NAT_DETECTION_SOURCE_IP notification 2913 is a SHA-1 digest of the SPIs (in the order they appear in the 2914 header), IP address, and port from which this packet was sent. 2915 There MAY be multiple NAT_DETECTION_SOURCE_IP payloads in a 2916 message if the sender does not know which of several network 2917 attachments will be used to send the packet. 2919 o The data associated with the NAT_DETECTION_DESTINATION_IP 2920 notification is a SHA-1 digest of the SPIs (in the order they 2921 appear in the header), IP address, and port to which this packet 2922 was sent. 2924 o The recipient of either the NAT_DETECTION_SOURCE_IP or 2925 NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied 2926 value to a SHA-1 hash of the SPIs, source or recipient IP address 2927 (respectively), address, and port, and if they don't match, it 2928 SHOULD enable NAT traversal. In the case there is a mismatch of 2929 the NAT_DETECTION_SOURCE_IP hash with all of the 2930 NAT_DETECTION_SOURCE_IP payloads received, the recipient MAY 2931 reject the connection attempt if NAT traversal is not supported. 2932 In the case of a mismatching NAT_DETECTION_DESTINATION_IP hash, it 2933 means that the system receiving the NAT_DETECTION_DESTINATION_IP 2934 payload is behind a NAT and that system SHOULD start sending 2935 keepalive packets as defined in [UDPENCAPS]; alternately, it MAY 2936 reject the connection attempt if NAT traversal is not supported. 2938 o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches 2939 the expected value of the source IP and port found from the IP 2940 header of the packet containing the payload, it means that the 2941 system sending those payloads is behind a NAT (i.e., someone along 2942 the route changed the source address of the original packet to 2943 match the address of the NAT box). In this case, the system 2944 receiving the payloads should allow dynamic updates of the other 2945 systems' IP address, as described later. 2947 o The IKE initiator MUST check the NAT_DETECTION_SOURCE_IP or 2948 NAT_DETECTION_DESTINATION_IP payloads if present, and if they do 2949 not match the addresses in the outer packet, MUST tunnel all 2950 future IKE and ESP packets associated with this IKE SA over UDP 2951 port 4500. 2953 o To tunnel IKE packets over UDP port 4500, the IKE header has four 2954 octets of zero prepended and the result immediately follows the 2955 UDP header. To tunnel ESP packets over UDP port 4500, the ESP 2956 header immediately follows the UDP header. Since the first four 2957 octets of the ESP header contain the SPI, and the SPI cannot 2958 validly be zero, it is always possible to distinguish ESP and IKE 2959 messages. 2961 o Implementations MUST process received UDP-encapsulated ESP packets 2962 even when no NAT was detected. 2964 o The original source and destination IP address required for the 2965 transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) 2966 are obtained from the Traffic Selectors associated with the 2967 exchange. In the case of transport mode NAT traversal, the 2968 Traffic Selectors MUST contain exactly one IP address, which is 2969 then used as the original IP address. This is covered in greater 2970 detail in Section 2.23.1. 2972 o There are cases where a NAT box decides to remove mappings that 2973 are still alive (for example, the keepalive interval is too long, 2974 or the NAT box is rebooted). This will be apparent to a host if 2975 it receives a packet whose integrity protection validates, but has 2976 a different port, address, or both from the one that was 2977 associated with the SA in the validated packet. When such a 2978 validated packet is found, a host that does not support other 2979 methods of recovery such as IKEv2 Mobility and Multihoming 2980 (MOBIKE) [MOBIKE], and that is not behind a NAT, SHOULD send all 2981 packets (including retransmission packets) to the IP address and 2982 port in the validated packet, and SHOULD store this as the new 2983 address and port combination for the SA (that is, they SHOULD 2984 dynamically update the address). A host behind a NAT SHOULD NOT 2985 do this type of dynamic address update if a validated packet has 2986 different port and/or address values because it opens a possible 2987 DoS attack (such as allowing an attacker to break the connection 2988 with a single packet). Also, dynamic address update should only 2989 be done in response to a new packet; otherwise, an attacker can 2990 revert the addresses with old replayed packets. Because of this, 2991 dynamic updates can only be done safely if replay protection is 2992 enabled. When IKEv2 is used with MOBIKE, dynamically updating the 2993 addresses described above interferes with MOBIKE's way of 2994 recovering from the same situation. See Section 3.8 of [MOBIKE] 2995 for more information. 2997 2.23.1. Transport Mode NAT Traversal 2999 Transport mode used with NAT Traversal requires special handling of 3000 the Traffic Selectors used in the IKEv2. The complete scenario looks 3001 like: 3003 +------+ +------+ +------+ +------+ 3004 |Client| IP1 | NAT | IPN1 IPN2 | NAT | IP2 |Server| 3005 |node |<------>| A |<---------->| B |<------->| | 3006 +------+ +------+ +------+ +------+ 3008 (Other scenarios are simplifications of this complex case, so this 3009 discussion uses the complete scenario.) 3011 In this scenario, there are two address translating NATs: NAT A and 3012 NAT B. NAT A is a dynamic NAT that maps the client's source address 3013 IP1 to IPN1. NAT B is a static NAT configured so that connections 3014 coming to IPN2 address are mapped to the gateway's address IP2, that 3015 is, IPN2 destination address is mapped to IP2. This allows the 3016 client to connect to a server by connecting to the IPN2. NAT B does 3017 not necessarily need to be a static NAT, but the client needs to know 3018 how to connect to the server, and it can only do that if it somehow 3019 knows the outer address of the NAT B, that is, the IPN2 address. If 3020 NAT B is a static NAT, then its address can be configured to the 3021 client's configuration. Another option would be to find it using 3022 some other protocol (like DNS), but that is outside of scope of 3023 IKEv2. 3025 In this scenario, both the client and server are configured to use 3026 transport mode for the traffic originating from the client node and 3027 destined to the server. 3029 When the client starts creating the IKEv2 SA and Child SA for sending 3030 traffic to the server, it may have a triggering packet with source IP 3031 address of IP1, and a destination IP address of IPN2. Its Peer 3032 Authorization Database (PAD) and SPD needs to have a configuration 3033 matching those addresses (or wildcard entries covering them). 3034 Because this is transport mode, it uses exactly same addresses as the 3035 Traffic Selectors and outer IP address of the IKE packets. For 3036 transport mode, it MUST use exactly one IP address in the TSi and TSr 3037 payloads. It can have multiple Traffic Selectors if it has, for 3038 example, multiple port ranges that it wants to negotiate, but all TSi 3039 entries must use the IP1-IP1 range as the IP addresses, and all TSr 3040 entries must have the IPN2-IPN2 range as IP addresses. The first 3041 Traffic Selector of TSi and TSr SHOULD have very specific Traffic 3042 Selectors including protocol and port numbers, such as from the 3043 packet triggering the request. 3045 NAT A will then replace the source address of the IKE packet from IP1 3046 to IPN1, and NAT B will replace the destination address of the IKE 3047 packet from IPN2 to IP2, so when the packet arrives to the server it 3048 will still have the exactly same Traffic Selectors that were sent by 3049 the client, but the IP address of the IKE packet has been replaced by 3050 IPN1 and IP2. 3052 When the server receives this packet, it normally looks in the Peer 3053 Authorization Database (PAD) described in RFC 4301 [IPSECARCH] based 3054 on the ID and then searches the SPD based on the Traffic Selectors. 3055 Because IP1 does not really mean anything to the server (it is the 3056 address client has behind the NAT), it is useless to do a lookup 3057 based on that if transport mode is used. On the other hand, the 3058 server cannot know whether transport mode is allowed by its policy 3059 before it finds the matching SPD entry. 3061 In this case, the server should first check that the initiator 3062 requested transport mode, and then do address substitution on the 3063 Traffic Selectors. It needs to first store the old Traffic Selector 3064 IP addresses to be used later for the incremental checksum fixup (the 3065 IP address in the TSi can be stored as the original source address 3066 and the IP address in the TSr can be stored as the original 3067 destination address). After that, if the other end was detected as 3068 being behind a NAT, the server replaces the IP address in TSi 3069 payloads with the IP address obtained from the source address of the 3070 IKE packet received (that is, it replaces IP1 in TSi with IPN1). If 3071 the server's end was detected to be behind NAT, it replaces the IP 3072 address in the TSr payloads with the IP address obtained from the 3073 destination address of the IKE packet received (that is, it replaces 3074 IPN2 in TSr with IP2). 3076 After this address substitution, both the Traffic Selectors and the 3077 IKE UDP source/destination addresses look the same, and the server 3078 does SPD lookup based on those new Traffic Selectors. If an entry is 3079 found and it allows transport mode, then that entry is used. If an 3080 entry is found but it does not allow transport mode, then the server 3081 MAY undo the address substitution and redo the SPD lookup using the 3082 original Traffic Selectors. If the second lookup succeeds, the 3083 server will create an SA in tunnel mode using real Traffic Selectors 3084 sent by the other end. 3086 This address substitution in transport mode is needed because the SPD 3087 is looked up using the addresses that will be seen by the local host. 3089 This also will make sure the Security Association Database (SAD) 3090 entries for the tunnel exit checks and return packets is added using 3091 the addresses as seen by the local operating system stack. 3093 The most common case is that the server's SPD will contain wildcard 3094 entries matching any addresses, but this also allows making different 3095 SPD entries, for example, for different known NATs' outer addresses. 3097 After the SPD lookup, the server will do Traffic Selector narrowing 3098 based on the SPD entry it found. It will again use the already 3099 substituted Traffic Selectors, and it will thus send back Traffic 3100 Selectors having IPN1 and IP2 as their IP addresses; it can still 3101 narrow down the protocol number or port ranges used by the Traffic 3102 Selectors. The SAD entry created for the Child SA will have the 3103 addresses as seen by the server, namely IPN1 and IP2. 3105 When the client receives the server's response to the Child SA, it 3106 will do similar processing. If the transport mode SA was created, 3107 the client can store the original returned Traffic Selectors as 3108 original source and destination addresses. It will replace the IP 3109 addresses in the Traffic Selectors with the ones from the IP header 3110 of the IKE packet: it will replace IPN1 with IP1 and IP2 with IPN2. 3111 Then, it will use those Traffic Selectors when verifying the SA 3112 against sent Traffic Selectors, and when installing the SAD entry. 3114 A summary of the rules for NAT traversal in transport mode is: 3116 For the client proposing transport mode: 3118 - The TSi entries MUST have exactly one IP address, and that MUST 3119 match the source address of the IKE SA. 3121 - The TSr entries MUST have exactly one IP address, and that MUST 3122 match the destination address of the IKE SA. 3124 - The first TSi and TSr Traffic Selectors SHOULD have very specific 3125 Traffic Selectors including protocol and port numbers, such as 3126 from the packet triggering the request. 3128 - There MAY be multiple TSi and TSr entries. 3130 - If transport mode for the SA was selected (that is, if the server 3131 included USE_TRANSPORT_MODE notification in its response): 3133 - Store the original Traffic Selectors as the received source and 3134 destination address. 3136 - If the server is behind a NAT, substitute the IP address in the 3137 TSr entries with the remote address of the IKE SA. 3139 - If the client is behind a NAT, substitute the IP address in the 3140 TSi entries with the local address of the IKE SA. 3142 - Do address substitution before using those Traffic Selectors 3143 for anything other than storing original content of them. 3144 This includes verification that Traffic Selectors were narrowed 3145 correctly by the other end, creation of the SAD entry, and so on. 3147 For the responder, when transport mode is proposed by client: 3149 - Store the original Traffic Selector IP addresses as received source 3150 and destination address, in case undo address 3151 substitution is needed, to use as the "real source and destination 3152 address" specified by [UDPENCAPS], and for TCP/UDP checksum fixup. 3154 - If the client is behind a NAT, substitute the IP address in the 3155 TSi entries with the remote address of the IKE SA. 3157 - If the server is behind a NAT, substitute the IP address in the 3158 TSr entries with the local address of the IKE SA. 3160 - Do PAD and SPD lookup using the ID and substituted Traffic 3161 Selectors. 3163 - If no SPD entry was found, or if found SPD entry does not 3164 allow transport mode, undo the Traffic Selector substitutions. 3165 Do PAD and SPD lookup again using the ID and original Traffic 3166 Selectors, but also searching for tunnel mode SPD entry (that 3167 is, fall back to tunnel mode). 3169 - However, if a transport mode SPD entry was found, do normal 3170 traffic selection narrowing based on the substituted Traffic 3171 Selectors and SPD entry. Use the resulting Traffic Selectors when 3172 creating SAD entries, and when sending Traffic Selectors back to 3173 the client. 3175 2.24. Explicit Congestion Notification (ECN) 3177 When IPsec tunnels behave as originally specified in [IPSECARCH-OLD], 3178 ECN usage is not appropriate for the outer IP headers because tunnel 3179 decapsulation processing discards ECN congestion indications to the 3180 detriment of the network. ECN support for IPsec tunnels for IKEv1- 3181 based IPsec requires multiple operating modes and negotiation (see 3182 [ECN]). IKEv2 simplifies this situation by requiring that ECN be 3183 usable in the outer IP headers of all tunnel mode Child SAs created 3184 by IKEv2. Specifically, tunnel encapsulators and decapsulators for 3185 all tunnel mode SAs created by IKEv2 MUST support the ECN full- 3186 functionality option for tunnels specified in [ECN] and MUST 3187 implement the tunnel encapsulation and decapsulation processing 3188 specified in [IPSECARCH] to prevent discarding of ECN congestion 3189 indications. 3191 2.25. Exchange Collisions 3193 Because IKEv2 exchanges can be initiated by either peer, it is 3194 possible that two exchanges affecting the same SA partly overlap. 3196 This can lead to a situation where the SA state information is 3197 temporarily not synchronized, and a peer can receive a request that 3198 it cannot process in a normal fashion. 3200 Obviously, using a window size greater than 1 leads to more complex 3201 situations, especially if requests are processed out of order. This 3202 section concentrates on problems that can arise even with a window 3203 size of 1, and recommends solutions. 3205 A TEMPORARY_FAILURE notification SHOULD be sent when a peer receives 3206 a request that cannot be completed due to a temporary condition such 3207 as a rekeying operation. When a peer receives a TEMPORARY_FAILURE 3208 notification, it MUST NOT immediately retry the operation; it MUST 3209 wait so that the sender may complete whatever operation caused the 3210 temporary condition. The recipient MAY retry the request one or more 3211 times over a period of several minutes. If a peer continues to 3212 receive TEMPORARY_FAILURE on the same IKE SA after several minutes, 3213 it SHOULD conclude that the state information is out of sync and 3214 close the IKE SA. 3216 A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives 3217 a request to rekey a Child SA that does not exist. The SA that the 3218 initiator attempted to rekey is indicated by the SPI field in the 3219 Notify payload, which is copied from the SPI field in the REKEY_SA 3220 notification. A peer that receives a CHILD_SA_NOT_FOUND notification 3221 SHOULD silently delete the Child SA (if it still exists) and send a 3222 request to create a new Child SA from scratch (if the Child SA does 3223 not yet exist). 3225 2.25.1. Collisions while Rekeying or Closing Child SAs 3227 If a peer receives a request to rekey a Child SA that it is currently 3228 trying to close, it SHOULD reply with TEMPORARY_FAILURE. If a peer 3229 receives a request to rekey a Child SA that it is currently rekeying, 3230 it SHOULD reply as usual, and SHOULD prepare to close redundant SAs 3231 later based on the nonces (see Section 2.8.1). If a peer receives a 3232 request to rekey a Child SA that does not exist, it SHOULD reply with 3233 CHILD_SA_NOT_FOUND. 3235 If a peer receives a request to close a Child SA that it is currently 3236 trying to close, it SHOULD reply without a Delete payload (see 3237 Section 1.4.1). If a peer receives a request to close a Child SA 3238 that it is currently rekeying, it SHOULD reply as usual, with a 3239 Delete payload. If a peer receives a request to close a Child SA 3240 that does not exist, it SHOULD reply without a Delete payload. 3242 If a peer receives a request to rekey the IKE SA, and it is currently 3243 creating, rekeying, or closing a Child SA of that IKE SA, it SHOULD 3244 reply with TEMPORARY_FAILURE. 3246 2.25.2. Collisions while Rekeying or Closing IKE SAs 3248 If a peer receives a request to rekey an IKE SA that it is currently 3249 rekeying, it SHOULD reply as usual, and SHOULD prepare to close 3250 redundant SAs and move inherited Child SAs later based on the nonces 3251 (see Section 2.8.2). If a peer receives a request to rekey an IKE SA 3252 that it is currently trying to close, it SHOULD reply with 3253 TEMPORARY_FAILURE. 3255 If a peer receives a request to close an IKE SA that it is currently 3256 rekeying, it SHOULD reply as usual, and forget about its own rekeying 3257 request. If a peer receives a request to close an IKE SA that it is 3258 currently trying to close, it SHOULD reply as usual, and forget about 3259 its own close request. 3261 If a peer receives a request to create or rekey a Child SA when it is 3262 currently rekeying the IKE SA, it SHOULD reply with 3263 TEMPORARY_FAILURE. If a peer receives a request to delete a Child SA 3264 when it is currently rekeying the IKE SA, it SHOULD reply as usual, 3265 with a Delete payload. 3267 3. Header and Payload Formats 3269 In the tables in this section, some cryptographic primitives and 3270 configuration attributes are marked as "UNSPECIFIED". These are 3271 items for which there are no known specifications and therefore 3272 interoperability is currently impossible. A future specification may 3273 describe their use, but until such specification is made, 3274 implementations SHOULD NOT attempt to use items marked as 3275 "UNSPECIFIED" in implementations that are meant to be interoperable. 3277 3.1. The IKE Header 3279 IKE messages use UDP ports 500 and/or 4500, with one IKE message per 3280 UDP datagram. Information from the beginning of the packet through 3281 the UDP header is largely ignored except that the IP addresses and 3282 UDP ports from the headers are reversed and used for return packets. 3283 When sent on UDP port 500, IKE messages begin immediately following 3284 the UDP header. When sent on UDP port 4500, IKE messages have 3285 prepended four octets of zero. These four octets of zeros are not 3286 part of the IKE message and are not included in any of the length 3287 fields or checksums defined by IKE. Each IKE message begins with the 3288 IKE header, denoted HDR in this document. Following the header are 3289 one or more IKE payloads each identified by a "Next Payload" field in 3290 the preceding payload. Payloads are identified in the order in which 3291 they appear in an IKE message by looking in the "Next Payload" field 3292 in the IKE header, and subsequently according to the "Next Payload" 3293 field in the IKE payload itself until a "Next Payload" field of zero 3294 indicates that no payloads follow. If a payload of type "Encrypted" 3295 is found, that payload is decrypted and its contents parsed as 3296 additional payloads. An Encrypted payload MUST be the last payload 3297 in a packet and an Encrypted payload MUST NOT contain another 3298 Encrypted payload. 3300 The responder's SPI in the header identifies an instance of an IKE 3301 Security Association. It is therefore possible for a single instance 3302 of IKE to multiplex distinct sessions with multiple peers, including 3303 multiple sessions per peer. 3305 All multi-octet fields representing integers are laid out in big 3306 endian order (also known as "most significant byte first", or 3307 "network byte order"). 3309 The format of the IKE header is shown in Figure 4. 3311 1 2 3 3312 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 3313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3314 | IKE SA Initiator's SPI | 3315 | | 3316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3317 | IKE SA Responder's SPI | 3318 | | 3319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3320 | Next Payload | MjVer | MnVer | Exchange Type | Flags | 3321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3322 | Message ID | 3323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3324 | Length | 3325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3327 Figure 4: IKE Header Format 3329 o Initiator's SPI (8 octets) - A value chosen by the initiator to 3330 identify a unique IKE Security Association. This value MUST NOT 3331 be zero. 3333 o Responder's SPI (8 octets) - A value chosen by the responder to 3334 identify a unique IKE Security Association. This value MUST be 3335 zero in the first message of an IKE initial exchange (including 3336 repeats of that message including a cookie). 3338 o Next Payload (1 octet) - Indicates the type of payload that 3339 immediately follows the header. The format and value of each 3340 payload are defined below. 3342 o Major Version (4 bits) - Indicates the major version of the IKE 3343 protocol in use. Implementations based on this version of IKE 3344 MUST set the major version to 2. Implementations based on 3345 previous versions of IKE and ISAKMP MUST set the major version to 3346 1. Implementations based on this document's version (version 2) 3347 of IKE MUST reject or ignore messages containing a version number 3348 greater than 2 with an INVALID_MAJOR_VERSION notification message 3349 as described in Section 2.5. 3351 o Minor Version (4 bits) - Indicates the minor version of the IKE 3352 protocol in use. Implementations based on this version of IKE 3353 MUST set the minor version to 0. They MUST ignore the minor 3354 version number of received messages. 3356 o Exchange Type (1 octet) - Indicates the type of exchange being 3357 used. This constrains the payloads sent in each message in an 3358 exchange. The values in the following table are only current as 3359 of the publication date of RFC 4306. Other values may have been 3360 added since then or will be added after the publication of this 3361 document. Readers should refer to [IKEV2IANA] for the latest 3362 values. 3364 Exchange Type Value 3365 ---------------------------------- 3366 IKE_SA_INIT 34 3367 IKE_AUTH 35 3368 CREATE_CHILD_SA 36 3369 INFORMATIONAL 37 3371 o Flags (1 octet) - Indicates specific options that are set for the 3372 message. Presence of options is indicated by the appropriate bit 3373 in the flags field being set. The bits are as follows: 3375 +-+-+-+-+-+-+-+-+ 3376 |X|X|R|V|I|X|X|X| 3377 +-+-+-+-+-+-+-+-+ 3379 In the description below, a bit being 'set' means its value is 3380 '1', while 'cleared' means its value is '0'. 'X' bits MUST be 3381 cleared when sending and MUST be ignored on receipt. 3383 * R (Response) - This bit indicates that this message is a 3384 response to a message containing the same Message ID. This bit 3385 MUST be cleared in all request messages and MUST be set in all 3386 responses. An IKE endpoint MUST NOT generate a response to a 3387 message that is marked as being a response (with one exception; 3388 see Section 2.21.2). 3390 * V (Version) - This bit indicates that the transmitter is 3391 capable of speaking a higher major version number of the 3392 protocol than the one indicated in the major version number 3393 field. Implementations of IKEv2 MUST clear this bit when 3394 sending and MUST ignore it in incoming messages. 3396 * I (Initiator) - This bit MUST be set in messages sent by the 3397 original initiator of the IKE SA and MUST be cleared in 3398 messages sent by the original responder. It is used by the 3399 recipient to determine which eight octets of the SPI were 3400 generated by the recipient. This bit changes to reflect who 3401 initiated the last rekey of the IKE SA. 3403 o Message ID (4 octets, unsigned integer) - Message identifier used 3404 to control retransmission of lost packets and matching of requests 3405 and responses. It is essential to the security of the protocol 3406 because it is used to prevent message replay attacks. See 3407 Sections 2.1 and 2.2. 3409 o Length (4 octets, unsigned integer) - Length of the total message 3410 (header + payloads) in octets. 3412 3.2. Generic Payload Header 3414 Each IKE payload defined in Sections 3.3 through 3.16 begins with a 3415 generic payload header, shown in Figure 5. Figures for each payload 3416 below will include the generic payload header, but for brevity, the 3417 description of each field will be omitted. 3419 1 2 3 3420 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 3421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3422 | Next Payload |C| RESERVED | Payload Length | 3423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3425 Figure 5: Generic Payload Header 3427 The Generic Payload Header fields are defined as follows: 3429 o Next Payload (1 octet) - Identifier for the payload type of the 3430 next payload in the message. If the current payload is the last 3431 in the message, then this field will be 0. This field provides a 3432 "chaining" capability whereby additional payloads can be added to 3433 a message by appending each one to the end of the message and 3434 setting the "Next Payload" field of the preceding payload to 3435 indicate the new payload's type. An Encrypted payload, which must 3436 always be the last payload of a message, is an exception. It 3437 contains data structures in the format of additional payloads. In 3438 the header of an Encrypted payload, the Next Payload field is set 3439 to the payload type of the first contained payload (instead of 0); 3440 conversely, the Next Payload field of the last contained payload 3441 is set to zero. The payload type values are listed here. The 3442 values in the following table are only current as of the 3443 publication date of RFC 4306. Other values may have been added 3444 since then or will be added after the publication of this 3445 document. Readers should refer to [IKEV2IANA] for the latest 3446 values. 3448 Next Payload Type Notation Value 3449 -------------------------------------------------- 3450 No Next Payload 0 3451 Security Association SA 33 3452 Key Exchange KE 34 3453 Identification - Initiator IDi 35 3454 Identification - Responder IDr 36 3455 Certificate CERT 37 3456 Certificate Request CERTREQ 38 3457 Authentication AUTH 39 3458 Nonce Ni, Nr 40 3459 Notify N 41 3460 Delete D 42 3461 Vendor ID V 43 3462 Traffic Selector - Initiator TSi 44 3463 Traffic Selector - Responder TSr 45 3464 Encrypted and Authenticated SK 46 3465 Configuration CP 47 3466 Extensible Authentication EAP 48 3468 (Payload type values 1-32 should not be assigned in the 3469 future so that there is no overlap with the code assignments 3470 for IKEv1.) 3472 o Critical (1 bit) - MUST be set to zero if the sender wants the 3473 recipient to skip this payload if it does not understand the 3474 payload type code in the Next Payload field of the previous 3475 payload. MUST be set to one if the sender wants the recipient to 3476 reject this entire message if it does not understand the payload 3477 type. MUST be ignored by the recipient if the recipient 3478 understands the payload type code. MUST be set to zero for 3479 payload types defined in this document. Note that the critical 3480 bit applies to the current payload rather than the "next" payload 3481 whose type code appears in the first octet. The reasoning behind 3482 not setting the critical bit for payloads defined in this document 3483 is that all implementations MUST understand all payload types 3484 defined in this document and therefore must ignore the critical 3485 bit's value. Skipped payloads are expected to have valid Next 3486 Payload and Payload Length fields. See Section 2.5 for more 3487 information on this bit. 3489 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on 3490 receipt. 3492 o Payload Length (2 octets, unsigned integer) - Length in octets of 3493 the current payload, including the generic payload header. 3495 Many payloads contain fields marked as "RESERVED". Some payloads in 3496 IKEv2 (and historically in IKEv1) are not aligned to 4-octet 3497 boundaries. 3499 3.3. Security Association Payload 3501 The Security Association payload, denoted SA in this document, is 3502 used to negotiate attributes of a Security Association. Assembly of 3503 Security Association payloads requires great peace of mind. An SA 3504 payload MAY contain multiple proposals. If there is more than one, 3505 they MUST be ordered from most preferred to least preferred. Each 3506 proposal contains a single IPsec protocol (where a protocol is IKE, 3507 ESP, or AH), each protocol MAY contain multiple transforms, and each 3508 transform MAY contain multiple attributes. When parsing an SA, an 3509 implementation MUST check that the total Payload Length is consistent 3510 with the payload's internal lengths and counts. Proposals, 3511 Transforms, and Attributes each have their own variable-length 3512 encodings. They are nested such that the Payload Length of an SA 3513 includes the combined contents of the SA, Proposal, Transform, and 3514 Attribute information. The length of a Proposal includes the lengths 3515 of all Transforms and Attributes it contains. The length of a 3516 Transform includes the lengths of all Attributes it contains. 3518 The syntax of Security Associations, Proposals, Transforms, and 3519 Attributes is based on ISAKMP; however, the semantics are somewhat 3520 different. The reason for the complexity and the hierarchy is to 3521 allow for multiple possible combinations of algorithms to be encoded 3522 in a single SA. Sometimes there is a choice of multiple algorithms, 3523 whereas other times there is a combination of algorithms. For 3524 example, an initiator might want to propose using ESP with either 3525 (3DES and HMAC_MD5) or (AES and HMAC_SHA1). 3527 One of the reasons the semantics of the SA payload have changed from 3528 ISAKMP and IKEv1 is to make the encodings more compact in common 3529 cases. 3531 The Proposal structure contains within it a Proposal Num and an IPsec 3532 protocol ID. Each structure MUST have a proposal number one (1) 3533 greater than the previous structure. The first Proposal in the 3534 initiator's SA payload MUST have a Proposal Num of one (1). One 3535 reason to use multiple proposals is to propose both standard crypto 3536 ciphers and combined-mode ciphers. Combined-mode ciphers include 3537 both integrity and encryption in a single encryption algorithm, and 3538 MUST either offer no integrity algorithm or a single integrity 3539 algorithm of "none", with no integrity algorithm being the 3540 RECOMMENDED method. If an initiator wants to propose both combined- 3541 mode ciphers and normal ciphers, it must include two proposals: one 3542 will have all the combined-mode ciphers, and the other will have all 3543 the normal ciphers with the integrity algorithms. For example, one 3544 such proposal would have two proposal structures. Proposal 1 is ESP 3545 with AES-128, AES-192, and AES-256 bits in Cipher Block Chaining 3546 (CBC) mode, with either HMAC-SHA1-96 or XCBC-96 as the integrity 3547 algorithm; Proposal 2 is AES-128 or AES-256 in GCM mode with an 3548 8-octet Integrity Check Value (ICV). Both proposals allow but do not 3549 require the use of ESNs (Extended Sequence Numbers). This can be 3550 illustrated as: 3552 SA Payload 3553 | 3554 +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4, 3555 | | 7 transforms, SPI = 0x052357bb ) 3556 | | 3557 | +-- Transform ENCR ( Name = ENCR_AES_CBC ) 3558 | | +-- Attribute ( Key Length = 128 ) 3559 | | 3560 | +-- Transform ENCR ( Name = ENCR_AES_CBC ) 3561 | | +-- Attribute ( Key Length = 192 ) 3562 | | 3563 | +-- Transform ENCR ( Name = ENCR_AES_CBC ) 3564 | | +-- Attribute ( Key Length = 256 ) 3565 | | 3566 | +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 ) 3567 | +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 ) 3568 | +-- Transform ESN ( Name = ESNs ) 3569 | +-- Transform ESN ( Name = No ESNs ) 3570 | 3571 +--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4, 3572 | 4 transforms, SPI = 0x35a1d6f2 ) 3573 | 3574 +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) 3575 | +-- Attribute ( Key Length = 128 ) 3576 | 3577 +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) 3578 | +-- Attribute ( Key Length = 256 ) 3579 | 3580 +-- Transform ESN ( Name = ESNs ) 3581 +-- Transform ESN ( Name = No ESNs ) 3583 Each Proposal/Protocol structure is followed by one or more transform 3584 structures. The number of different transforms is generally 3585 determined by the Protocol. AH generally has two transforms: 3586 Extended Sequence Numbers (ESNs) and an integrity check algorithm. 3587 ESP generally has three: ESN, an encryption algorithm, and an 3588 integrity check algorithm. IKE generally has four transforms: a 3589 Diffie-Hellman group, an integrity check algorithm, a PRF algorithm, 3590 and an encryption algorithm. For each Protocol, the set of 3591 permissible transforms is assigned Transform ID numbers, which appear 3592 in the header of each transform. 3594 If there are multiple transforms with the same Transform Type, the 3595 proposal is an OR of those transforms. If there are multiple 3596 transforms with different Transform Types, the proposal is an AND of 3597 the different groups. For example, to propose ESP with (3DES or AES- 3598 CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two 3599 Transform Type 1 candidates (one for 3DES and one for AEC-CBC) and 3600 two Transform Type 3 candidates (one for HMAC_MD5 and one for 3601 HMAC_SHA). This effectively proposes four combinations of 3602 algorithms. If the initiator wanted to propose only a subset of 3603 those, for example (3DES and HMAC_MD5) or (IDEA and HMAC_SHA), there 3604 is no way to encode that as multiple transforms within a single 3605 Proposal. Instead, the initiator would have to construct two 3606 different Proposals, each with two transforms. 3608 A given transform MAY have one or more Attributes. Attributes are 3609 necessary when the transform can be used in more than one way, as 3610 when an encryption algorithm has a variable key size. The transform 3611 would specify the algorithm and the attribute would specify the key 3612 size. Most transforms do not have attributes. A transform MUST NOT 3613 have multiple attributes of the same type. To propose alternate 3614 values for an attribute (for example, multiple key sizes for the AES 3615 encryption algorithm), an implementation MUST include multiple 3616 transforms with the same Transform Type each with a single Attribute. 3618 Note that the semantics of Transforms and Attributes are quite 3619 different from those in IKEv1. In IKEv1, a single Transform carried 3620 multiple algorithms for a protocol with one carried in the Transform 3621 and the others carried in the Attributes. 3623 1 2 3 3624 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 3625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3626 | Next Payload |C| RESERVED | Payload Length | 3627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3628 | | 3629 ~ ~ 3630 | | 3631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3633 Figure 6: Security Association Payload 3635 o Proposals (variable) - One or more proposal substructures. 3637 The payload type for the Security Association payload is thirty-three 3638 (33). 3640 3.3.1. Proposal Substructure 3642 1 2 3 3643 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 3644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3645 | Last Substruc | RESERVED | Proposal Length | 3646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3647 | Proposal Num | Protocol ID | SPI Size |Num Transforms| 3648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3649 ~ SPI (variable) ~ 3650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3651 | | 3652 ~ ~ 3653 | | 3654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3656 Figure 7: Proposal Substructure 3658 o Last Substruc (1 octet) - Specifies whether or not this is the 3659 last Proposal Substructure in the SA. This field has a value of 0 3660 if this was last Proposal Substructure, and a value of 2 if there 3661 are more Proposal Substructures. This syntax is inherited from 3662 ISAKMP, but is unnecessary because the last Proposal could be 3663 identified from the length of the SA. The value (2) corresponds 3664 to a payload type of Proposal in IKEv1, and the first four octets 3665 of the Proposal structure are designed to look somewhat like the 3666 header of a payload. 3668 o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on 3669 receipt. 3671 o Proposal Length (2 octets, unsigned integer) - Length of this 3672 proposal, including all transforms and attributes that follow. 3674 o Proposal Num (1 octet) - When a proposal is made, the first 3675 proposal in an SA payload MUST be 1, and subsequent proposals MUST 3676 be one more than the previous proposal (indicating an OR of the 3677 two proposals). When a proposal is accepted, the proposal number 3678 in the SA payload MUST match the number on the proposal sent that 3679 was accepted. 3681 o Protocol ID (1 octet) - Specifies the IPsec protocol identifier 3682 for the current negotiation. The values in the following table 3683 are only current as of the publication date of RFC 4306. Other 3684 values may have been added since then or will be added after the 3685 publication of this document. Readers should refer to [IKEV2IANA] 3686 for the latest values. 3688 Protocol Protocol ID 3689 ----------------------------------- 3690 IKE 1 3691 AH 2 3692 ESP 3 3694 o SPI Size (1 octet) - For an initial IKE SA negotiation, this field 3695 MUST be zero; the SPI is obtained from the outer header. During 3696 subsequent negotiations, it is equal to the size, in octets, of 3697 the SPI of the corresponding protocol (8 for IKE, 4 for ESP and 3698 AH). 3700 o Num Transforms (1 octet) - Specifies the number of transforms in 3701 this proposal. 3703 o SPI (variable) - The sending entity's SPI. Even if the SPI Size 3704 is not a multiple of 4 octets, there is no padding applied to the 3705 payload. When the SPI Size field is zero, this field is not 3706 present in the Security Association payload. 3708 o Transforms (variable) - One or more transform substructures. 3710 3.3.2. Transform Substructure 3712 1 2 3 3713 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 3714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3715 | Last Substruc | RESERVED | Transform Length | 3716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3717 |Transform Type | RESERVED | Transform ID | 3718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3719 | | 3720 ~ Transform Attributes ~ 3721 | | 3722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3724 Figure 8: Transform Substructure 3726 o Last Substruc (1 octet) - Specifies whether or not this is the 3727 last Transform Substructure in the Proposal. This field has a 3728 value of 0 if this was last Transform Substructure, and a value of 3729 3 if there are more Transform Substructures. This syntax is 3730 inherited from ISAKMP, but is unnecessary because the last 3731 transform could be identified from the length of the proposal. 3732 The value (3) corresponds to a payload type of Transform in IKEv1, 3733 and the first four octets of the Transform structure are designed 3734 to look somewhat like the header of a payload. 3736 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 3738 o Transform Length - The length (in octets) of the Transform 3739 Substructure including Header and Attributes. 3741 o Transform Type (1 octet) - The type of transform being specified 3742 in this transform. Different protocols support different 3743 Transform Types. For some protocols, some of the transforms may 3744 be optional. If a transform is optional and the initiator wishes 3745 to propose that the transform be omitted, no transform of the 3746 given type is included in the proposal. If the initiator wishes 3747 to make use of the transform optional to the responder, it 3748 includes a transform substructure with Transform ID = 0 as one of 3749 the options. 3751 o Transform ID (2 octets) - The specific instance of the Transform 3752 Type being proposed. 3754 The Transform Type values are listed below. The values in the 3755 following table are only current as of the publication date of RFC 3756 4306. Other values may have been added since then or will be added 3757 after the publication of this document. Readers should refer to 3758 [IKEV2IANA] for the latest values. 3760 Description Trans. Used In 3761 Type 3762 ------------------------------------------------------------------ 3763 Encryption Algorithm (ENCR) 1 IKE and ESP 3764 Pseudorandom Function (PRF) 2 IKE 3765 Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP 3766 Diffie-Hellman group (D-H) 4 IKE, optional in AH & ESP 3767 Extended Sequence Numbers (ESN) 5 AH and ESP 3769 (*) Negotiating an integrity algorithm is mandatory for the 3770 Encrypted payload format specified in this document. For example, 3771 [AEAD] specifies additional formats based on authenticated 3772 encryption, in which a separate integrity algorithm is not 3773 negotiated. 3775 For Transform Type 1 (Encryption Algorithm), the Transform IDs are 3776 listed below. The values in the following table are only current as 3777 of the publication date of RFC 4306. Other values may have been 3778 added since then or will be added after the publication of this 3779 document. Readers should refer to [IKEV2IANA] for the latest values. 3781 Name Number Defined In 3782 --------------------------------------------------- 3783 ENCR_DES_IV64 1 (UNSPECIFIED) 3784 ENCR_DES 2 (RFC2405), [DES] 3785 ENCR_3DES 3 (RFC2451) 3786 ENCR_RC5 4 (RFC2451) 3787 ENCR_IDEA 5 (RFC2451), [IDEA] 3788 ENCR_CAST 6 (RFC2451) 3789 ENCR_BLOWFISH 7 (RFC2451) 3790 ENCR_3IDEA 8 (UNSPECIFIED) 3791 ENCR_DES_IV32 9 (UNSPECIFIED) 3792 ENCR_NULL 11 (RFC2410) 3793 ENCR_AES_CBC 12 (RFC3602) 3794 ENCR_AES_CTR 13 (RFC3686) 3796 For Transform Type 2 (Pseudorandom Function), the 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 PRF_HMAC_MD5 1 (RFC2104), [MD5] 3805 PRF_HMAC_SHA1 2 (RFC2104), [SHA] 3806 PRF_HMAC_TIGER 3 (UNSPECIFIED) 3808 For Transform Type 3 (Integrity Algorithm), defined Transform IDs are 3809 listed below. The values in the following table are only current as 3810 of the publication date of RFC 4306. Other values may have been 3811 added since then or will be added after the publication of this 3812 document. Readers should refer to [IKEV2IANA] for the latest values. 3814 Name Number Defined In 3815 ---------------------------------------- 3816 NONE 0 3817 AUTH_HMAC_MD5_96 1 (RFC2403) 3818 AUTH_HMAC_SHA1_96 2 (RFC2404) 3819 AUTH_DES_MAC 3 (UNSPECIFIED) 3820 AUTH_KPDK_MD5 4 (UNSPECIFIED) 3821 AUTH_AES_XCBC_96 5 (RFC3566) 3823 For Transform Type 4 (Diffie-Hellman group), defined Transform IDs 3824 are listed below. The values in the following table are only current 3825 as of the publication date of RFC 4306. Other values may have been 3826 added since then or will be added after the publication of this 3827 document. Readers should refer to [IKEV2IANA] for the latest values. 3829 Name Number Defined In 3830 ---------------------------------------- 3831 NONE 0 3832 768-bit MODP 1 Appendix B 3833 1024-bit MODP 2 Appendix B 3834 1536-bit MODP 5 [ADDGROUP] 3835 2048-bit MODP 14 [ADDGROUP] 3836 3072-bit MODP 15 [ADDGROUP] 3837 4096-bit MODP 16 [ADDGROUP] 3838 6144-bit MODP 17 [ADDGROUP] 3839 8192-bit MODP 18 [ADDGROUP] 3841 Although ESP and AH do not directly include a Diffie-Hellman 3842 exchange, a Diffie-Hellman group MAY be negotiated for the Child SA. 3843 This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA 3844 exchange, providing perfect forward secrecy for the generated Child 3845 SA keys. 3847 Note, that MODP Diffie-Hellman groups listed above does not need any 3848 special validity tests to be performed, but other types of groups 3849 (ECP and MODP groups with small subgroups) need to have some 3850 additional tests to be performed on them to use them securely. See 3851 "Additional Diffie-Hellman Tests for IKEv2" ([RFC6989]) for more 3852 information. 3854 For Transform Type 5 (Extended Sequence Numbers), defined Transform 3855 IDs are listed below. The values in the following table are only 3856 current as of the publication date of RFC 4306. Other values may 3857 have been added since then or will be added after the publication of 3858 this document. Readers should refer to [IKEV2IANA] for the latest 3859 values. 3861 Name Number 3862 -------------------------------------------- 3863 No Extended Sequence Numbers 0 3864 Extended Sequence Numbers 1 3866 Note that an initiator who supports ESNs will usually include two ESN 3867 transforms, with values "0" and "1", in its proposals. A proposal 3868 containing a single ESN transform with value "1" means that using 3869 normal (non-extended) sequence numbers is not acceptable. 3871 Numerous additional Transform Types have been defined since the 3872 publication of RFC 4306. Please refer to the IANA IKEv2 registry for 3873 details. 3875 3.3.3. Valid Transform Types by Protocol 3877 The number and type of transforms that accompany an SA payload are 3878 dependent on the protocol in the SA itself. An SA payload proposing 3879 the establishment of an SA has the following mandatory and optional 3880 Transform Types. A compliant implementation MUST understand all 3881 mandatory and optional types for each protocol it supports (though it 3882 need not accept proposals with unacceptable suites). A proposal MAY 3883 omit the optional types if the only value for them it will accept is 3884 NONE. 3886 Protocol Mandatory Types Optional Types 3887 --------------------------------------------------- 3888 IKE ENCR, PRF, INTEG*, D-H 3889 ESP ENCR, ESN INTEG, D-H 3890 AH INTEG, ESN D-H 3892 (*) Negotiating an integrity algorithm is mandatory for the 3893 Encrypted payload format specified in this document. For example, 3894 [AEAD] specifies additional formats based on authenticated 3895 encryption, in which a separate integrity algorithm is not 3896 negotiated. 3898 3.3.4. Mandatory Transform IDs 3900 The specification of suites that MUST and SHOULD be supported for 3901 interoperability has been removed from this document because they are 3902 likely to change more rapidly than this document evolves. At the 3903 time of publication of this document, [RFC4307] specifies these 3904 suites, but note that it might be updated in the future, and other 3905 RFCs might specify different sets of suites. 3907 An important lesson learned from IKEv1 is that no system should only 3908 implement the mandatory algorithms and expect them to be the best 3909 choice for all customers. 3911 It is likely that IANA will add additional transforms in the future, 3912 and some users may want to use private suites, especially for IKE 3913 where implementations should be capable of supporting different 3914 parameters, up to certain size limits. In support of this goal, all 3915 implementations of IKEv2 SHOULD include a management facility that 3916 allows specification (by a user or system administrator) of Diffie- 3917 Hellman parameters (the generator, modulus, and exponent lengths and 3918 values) for new Diffie-Hellman groups. Implementations SHOULD 3919 provide a management interface through which these parameters and the 3920 associated Transform IDs may be entered (by a user or system 3921 administrator), to enable negotiating such groups. 3923 All implementations of IKEv2 MUST include a management facility that 3924 enables a user or system administrator to specify the suites that are 3925 acceptable for use with IKE. Upon receipt of a payload with a set of 3926 Transform IDs, the implementation MUST compare the transmitted 3927 Transform IDs against those locally configured via the management 3928 controls, to verify that the proposed suite is acceptable based on 3929 local policy. The implementation MUST reject SA proposals that are 3930 not authorized by these IKE suite controls. Note that cryptographic 3931 suites that MUST be implemented need not be configured as acceptable 3932 to local policy. 3934 3.3.5. Transform Attributes 3936 Each transform in a Security Association payload may include 3937 attributes that modify or complete the specification of the 3938 transform. The set of valid attributes depends on the transform. 3939 Currently, only a single attribute type is defined: the Key Length 3940 attribute is used by certain encryption transforms with variable- 3941 length keys (see below for details). 3943 The attributes are type/value pairs and are defined below. 3944 Attributes can have a value with a fixed two-octet length or a 3945 variable-length value. For the latter, the attribute is encoded as 3946 type/length/value. 3948 1 2 3 3949 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 3950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3951 |A| Attribute Type | AF=0 Attribute Length | 3952 |F| | AF=1 Attribute Value | 3953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3954 | AF=0 Attribute Value | 3955 | AF=1 Not Transmitted | 3956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3958 Figure 9: Data Attributes 3960 o Attribute Format (AF) (1 bit) - Indicates whether the data 3961 attribute follows the Type/Length/Value (TLV) format or a 3962 shortened Type/Value (TV) format. If the AF bit is zero (0), then 3963 the attribute uses TLV format; if the AF bit is one (1), the TV 3964 format (with two-byte value) is used. 3966 o Attribute Type (15 bits) - Unique identifier for each type of 3967 attribute (see below). 3969 o Attribute Value (variable length) - Value of the attribute 3970 associated with the attribute type. If the AF bit is a zero (0), 3971 this field has a variable length defined by the Attribute Length 3972 field. If the AF bit is a one (1), the Attribute Value has a 3973 length of 2 octets. 3975 The only currently defined attribute type (Key Length) is fixed 3976 length; the variable-length encoding specification is included only 3977 for future extensions. Attributes described as fixed length MUST NOT 3978 be encoded using the variable-length encoding unless that length 3979 exceeds two bytes. Variable-length attributes MUST NOT be encoded as 3980 fixed-length even if their value can fit into two octets. Note: This 3981 is a change from IKEv1, where increased flexibility may have 3982 simplified the composer of messages but certainly complicated the 3983 parser. 3985 The values in the following table are only current as of the 3986 publication date of RFC 4306. Other values may have been added since 3987 then or will be added after the publication of this document. 3988 Readers should refer to [IKEV2IANA] for the latest values. 3990 Attribute Type Value Attribute Format 3991 ------------------------------------------------------------ 3992 Key Length (in bits) 14 TV 3994 Values 0-13 and 15-17 were used in a similar context in IKEv1, and 3995 should not be assigned except to matching values. 3997 The Key Length attribute specifies the key length in bits (MUST use 3998 network byte order) for certain transforms as follows: 4000 o The Key Length attribute MUST NOT be used with transforms that use 4001 a fixed-length key. For example, this includes ENCR_DES, 4002 ENCR_IDEA, and all the Type 2 (Pseudorandom function) and Type 3 4003 (Integrity Algorithm) transforms specified in this document. It 4004 is recommended that future Type 2 or 3 transforms do not use this 4005 attribute. 4007 o Some transforms specify that the Key Length attribute MUST be 4008 always included (omitting the attribute is not allowed, and 4009 proposals not containing it MUST be rejected). For example, this 4010 includes ENCR_AES_CBC and ENCR_AES_CTR. 4012 o Some transforms allow variable-length keys, but also specify a 4013 default key length if the attribute is not included. For example, 4014 these transforms include ENCR_RC5 and ENCR_BLOWFISH. 4016 Implementation note: To further interoperability and to support 4017 upgrading endpoints independently, implementers of this protocol 4018 SHOULD accept values that they deem to supply greater security. For 4019 instance, if a peer is configured to accept a variable-length cipher 4020 with a key length of X bits and is offered that cipher with a larger 4021 key length, the implementation SHOULD accept the offer if it supports 4022 use of the longer key. 4024 Support for this capability allows a responder to express a concept 4025 of "at least" a certain level of security -- "a key length of _at 4026 least_ X bits for cipher Y". However, as the attribute is always 4027 returned unchanged (see the next section), an initiator willing to 4028 accept multiple key lengths has to include multiple transforms with 4029 the same Transform Type, each with a different Key Length attribute. 4031 3.3.6. Attribute Negotiation 4033 During Security Association negotiation initiators present offers to 4034 responders. Responders MUST select a single complete set of 4035 parameters from the offers (or reject all offers if none are 4036 acceptable). If there are multiple proposals, the responder MUST 4037 choose a single proposal. If the selected proposal has multiple 4038 transforms with the same type, the responder MUST choose a single 4039 one. Any attributes of a selected transform MUST be returned 4040 unmodified. The initiator of an exchange MUST check that the 4041 accepted offer is consistent with one of its proposals, and if not 4042 MUST terminate the exchange. 4044 If the responder receives a proposal that contains a Transform Type 4045 it does not understand, or a proposal that is missing a mandatory 4046 Transform Type, it MUST consider this proposal unacceptable; however, 4047 other proposals in the same SA payload are processed as usual. 4048 Similarly, if the responder receives a transform that it does not 4049 understand, or one that contains a Transform Attribute it does not 4050 understand, it MUST consider this transform unacceptable; other 4051 transforms with the same Transform Type are processed as usual. This 4052 allows new Transform Types and Transform Attributes to be defined in 4053 the future. 4055 Negotiating Diffie-Hellman groups presents some special challenges. 4056 SA offers include proposed attributes and a Diffie-Hellman public 4057 number (KE) in the same message. If in the initial exchange the 4058 initiator offers to use one of several Diffie-Hellman groups, it 4059 SHOULD pick the one the responder is most likely to accept and 4060 include a KE corresponding to that group. If the responder selects a 4061 proposal using a different Diffie-Hellman group (other than NONE), 4062 the responder will indicate the correct group in the response and the 4063 initiator SHOULD pick an element of that group for its KE value when 4064 retrying the first message. It SHOULD, however, continue to propose 4065 its full supported set of groups in order to prevent a man-in-the- 4066 middle downgrade attack. If one of the proposals offered is for the 4067 Diffie-Hellman group of NONE, and the responder selects that Diffie- 4068 Hellman group, then it MUST ignore the initiator's KE payload and 4069 omit the KE payload from the response. 4071 3.4. Key Exchange Payload 4073 The Key Exchange payload, denoted KE in this document, is used to 4074 exchange Diffie-Hellman public numbers as part of a Diffie-Hellman 4075 key exchange. The Key Exchange payload consists of the IKE generic 4076 payload header followed by the Diffie-Hellman public value itself. 4078 1 2 3 4079 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 4080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4081 | Next Payload |C| RESERVED | Payload Length | 4082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4083 | Diffie-Hellman Group Num | RESERVED | 4084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4085 | | 4086 ~ Key Exchange Data ~ 4087 | | 4088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4090 Figure 10: Key Exchange Payload Format 4092 A Key Exchange payload is constructed by copying one's Diffie-Hellman 4093 public value into the "Key Exchange Data" portion of the payload. 4094 The length of the Diffie-Hellman public value for modular 4095 exponentiation group (MODP) groups MUST be equal to the length of the 4096 prime modulus over which the exponentiation was performed, prepending 4097 zero bits to the value if necessary. 4099 The Diffie-Hellman Group Num identifies the Diffie-Hellman group in 4100 which the Key Exchange Data was computed (see Section 3.3.2). This 4101 Diffie-Hellman Group Num MUST match a Diffie-Hellman group specified 4102 in a proposal in the SA payload that is sent in the same message, and 4103 SHOULD match the Diffie-Hellman group in the first group in the first 4104 proposal, if such exists. If none of the proposals in that SA 4105 payload specifies a Diffie-Hellman group, the KE payload MUST NOT be 4106 present. If the selected proposal uses a different Diffie-Hellman 4107 group (other than NONE), the message MUST be rejected with a Notify 4108 payload of type INVALID_KE_PAYLOAD. See also Sections 1.2 and 2.7. 4110 The payload type for the Key Exchange payload is thirty-four (34). 4112 3.5. Identification Payloads 4114 The Identification payloads, denoted IDi and IDr in this document, 4115 allow peers to assert an identity to one another. This identity may 4116 be used for policy lookup, but does not necessarily have to match 4117 anything in the CERT payload; both fields may be used by an 4118 implementation to perform access control decisions. When using the 4119 ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 4120 does not require this address to match the address in the IP header 4121 of IKEv2 packets, or anything in the TSi/TSr payloads. The contents 4122 of IDi/IDr are used purely to fetch the policy and authentication 4123 data related to the other party. 4125 NOTE: In IKEv1, two ID payloads were used in each direction to hold 4126 Traffic Selector (TS) information for data passing over the SA. In 4127 IKEv2, this information is carried in TS payloads (see Section 3.13). 4129 The Peer Authorization Database (PAD) as described in RFC 4301 4130 [IPSECARCH] describes the use of the ID payload in IKEv2 and provides 4131 a formal model for the binding of identity to policy in addition to 4132 providing services that deal more specifically with the details of 4133 policy enforcement. The PAD is intended to provide a link between 4134 the SPD and the IKE Security Association management. See Section 4135 4.4.3 of RFC 4301 for more details. 4137 The Identification payload consists of the IKE generic payload header 4138 followed by identification fields as follows: 4140 1 2 3 4141 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 4142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4143 | Next Payload |C| RESERVED | Payload Length | 4144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4145 | ID Type | RESERVED | 4146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4147 | | 4148 ~ Identification Data ~ 4149 | | 4150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4152 Figure 11: Identification Payload Format 4154 o ID Type (1 octet) - Specifies the type of Identification being 4155 used. 4157 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 4159 o Identification Data (variable length) - Value, as indicated by the 4160 Identification Type. The length of the Identification Data is 4161 computed from the size in the ID payload header. 4163 The payload types for the Identification payload are thirty-five (35) 4164 for IDi and thirty-six (36) for IDr. 4166 The following table lists the assigned semantics for the 4167 Identification Type field. The values in the following table are 4168 only current as of the publication date of RFC 4306. Other values 4169 may have been added since then or will be added after the publication 4170 of this document. Readers should refer to [IKEV2IANA] for the latest 4171 values. 4173 ID Type Value 4174 ------------------------------------------------------------------- 4175 ID_IPV4_ADDR 1 4176 A single four (4) octet IPv4 address. 4178 ID_FQDN 2 4179 A fully-qualified domain name string. An example of an ID_FQDN 4180 is "example.com". The string MUST NOT contain any terminators 4181 (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; 4182 for an "internationalized domain name", the syntax is as defined 4183 in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net". 4185 ID_RFC822_ADDR 3 4186 A fully-qualified RFC 822 email address string. An example of a 4187 ID_RFC822_ADDR is "jsmith@example.com". The string MUST NOT 4188 contain any terminators. Because of [EAI], implementations would 4189 be wise to treat this field as UTF-8 encoded text, not as 4190 pure ASCII. 4192 ID_IPV6_ADDR 5 4193 A single sixteen (16) octet IPv6 address. 4195 ID_DER_ASN1_DN 9 4196 The binary Distinguished Encoding Rules (DER) encoding of an 4197 ASN.1 X.500 Distinguished Name [PKIX]. 4199 ID_DER_ASN1_GN 10 4200 The binary DER encoding of an ASN.1 X.509 GeneralName [PKIX]. 4202 ID_KEY_ID 11 4203 An opaque octet stream that may be used to pass vendor- 4204 specific information necessary to do certain proprietary 4205 types of identification. 4207 Two implementations will interoperate only if each can generate a 4208 type of ID acceptable to the other. To assure maximum 4209 interoperability, implementations MUST be configurable to send at 4210 least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and 4211 MUST be configurable to accept all of these four types. 4212 Implementations SHOULD be capable of generating and accepting all of 4213 these types. IPv6-capable implementations MUST additionally be 4214 configurable to accept ID_IPV6_ADDR. IPv6-only implementations MAY 4215 be configurable to send only ID_IPV6_ADDR instead of ID_IPV4_ADDR for 4216 IP addresses. 4218 EAP [EAP] does not mandate the use of any particular type of 4219 identifier, but often EAP is used with Network Access Identifiers 4220 (NAIs) defined in [NAI]. Although NAIs look a bit like email 4221 addresses (e.g., "joe@example.com"), the syntax is not exactly the 4222 same as the syntax of email address in [MAILFORMAT]. For those NAIs 4223 that include the realm component, the ID_RFC822_ADDR identification 4224 type SHOULD be used. Responder implementations should not attempt to 4225 verify that the contents actually conform to the exact syntax given 4226 in [MAILFORMAT], but instead should accept any reasonable-looking 4227 NAI. For NAIs that do not include the realm component, the ID_KEY_ID 4228 identification type SHOULD be used. 4230 See "IPsec PKI Profile of IKEv1, IKEv2 and PKIX" ([RFC4945]) for more 4231 information about matching Identification payloads and the contents 4232 of the PKIX Certificates. 4234 3.6. Certificate Payload 4236 The Certificate payload, denoted CERT in this document, provides a 4237 means to transport certificates or other authentication-related 4238 information via IKE. Certificate payloads SHOULD be included in an 4239 exchange if certificates are available to the sender. The Hash and 4240 URL formats of the Certificate payloads should be used in case the 4241 peer has indicated an ability to retrieve this information from 4242 elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note 4243 that the term "Certificate payload" is somewhat misleading, because 4244 not all authentication mechanisms use certificates and data other 4245 than certificates may be passed in this payload. 4247 The Certificate payload is defined as follows: 4249 1 2 3 4250 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 4251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4252 | Next Payload |C| RESERVED | Payload Length | 4253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4254 | Cert Encoding | | 4255 +-+-+-+-+-+-+-+-+ | 4256 ~ Certificate Data ~ 4257 | | 4258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4260 Figure 12: Certificate Payload Format 4262 o Certificate Encoding (1 octet) - This field indicates the type of 4263 certificate or certificate-related information contained in the 4264 Certificate Data field. The values in the following table are 4265 only current as of the publication date of RFC 4306. Other values 4266 may have been added since then or will be added after the 4267 publication of this document. Readers should refer to [IKEV2IANA] 4268 for the latest values. 4270 Certificate Encoding Value 4271 ---------------------------------------------------- 4272 PKCS #7 wrapped X.509 certificate 1 UNSPECIFIED 4273 PGP Certificate 2 UNSPECIFIED 4274 DNS Signed Key 3 UNSPECIFIED 4275 X.509 Certificate - Signature 4 4276 Kerberos Token 6 UNSPECIFIED 4277 Certificate Revocation List (CRL) 7 4278 Authority Revocation List (ARL) 8 UNSPECIFIED 4279 SPKI Certificate 9 UNSPECIFIED 4280 X.509 Certificate - Attribute 10 UNSPECIFIED 4281 Deprecated (Was Raw RSA Key) 11 DEPRECATED 4282 Hash and URL of X.509 certificate 12 4283 Hash and URL of X.509 bundle 13 4285 o Certificate Data (variable length) - Actual encoding of 4286 certificate data. The type of certificate is indicated by the 4287 Certificate Encoding field. 4289 The payload type for the Certificate payload is thirty-seven (37). 4291 Specific syntax for some of the certificate type codes above is not 4292 defined in this document. The types whose syntax is defined in this 4293 document are: 4295 o "X.509 Certificate - Signature" contains a DER-encoded X.509 4296 certificate whose public key is used to validate the sender's AUTH 4297 payload. Note that with this encoding, if a chain of certificates 4298 needs to be sent, multiple CERT payloads are used, only the first 4299 of which holds the public key used to validate the sender's AUTH 4300 payload. 4302 o "Certificate Revocation List" contains a DER-encoded X.509 4303 certificate revocation list. 4305 o Hash and URL encodings allow IKE messages to remain short by 4306 replacing long data structures with a 20-octet SHA-1 hash (see 4307 [SHA]) of the replaced value followed by a variable-length URL 4308 that resolves to the DER-encoded data structure itself. This 4309 improves efficiency when the endpoints have certificate data 4310 cached and makes IKE less subject to DoS attacks that become 4311 easier to mount when IKE messages are large enough to require IP 4312 fragmentation [DOSUDPPROT]. 4314 The "Hash and URL of a bundle" type uses the following ASN.1 4315 definition for the X.509 bundle: 4317 CertBundle 4318 { iso(1) identified-organization(3) dod(6) internet(1) 4319 security(5) mechanisms(5) pkix(7) id-mod(0) 4320 id-mod-cert-bundle(34) } 4322 DEFINITIONS EXPLICIT TAGS ::= 4323 BEGIN 4325 IMPORTS 4326 Certificate, CertificateList 4327 FROM PKIX1Explicit88 4328 { iso(1) identified-organization(3) dod(6) 4329 internet(1) security(5) mechanisms(5) pkix(7) 4330 id-mod(0) id-pkix1-explicit(18) } ; 4332 CertificateOrCRL ::= CHOICE { 4333 cert [0] Certificate, 4334 crl [1] CertificateList } 4336 CertificateBundle ::= SEQUENCE OF CertificateOrCRL 4338 END 4340 Implementations MUST be capable of being configured to send and 4341 accept up to four X.509 certificates in support of authentication, 4342 and also MUST be capable of being configured to send and accept the 4343 two Hash and URL formats (with HTTP URLs). If multiple certificates 4344 are sent, the first certificate MUST contain the public key 4345 associated with the private key used to sign the AUTH payload. The 4346 other certificates may be sent in any order. 4348 Implementations MUST support the HTTP [HTTP] method for hash-and-URL 4349 lookup. The behavior of other URL methods [URLS] is not currently 4350 specified, and such methods SHOULD NOT be used in the absence of a 4351 document specifying them. 4353 3.7. Certificate Request Payload 4355 The Certificate Request payload, denoted CERTREQ in this document, 4356 provides a means to request preferred certificates via IKE and can 4357 appear in the IKE_INIT_SA response and/or the IKE_AUTH request. 4358 Certificate Request payloads MAY be included in an exchange when the 4359 sender needs to get the certificate of the receiver. 4361 The Certificate Request payload is defined as follows: 4363 1 2 3 4364 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 4365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4366 | Next Payload |C| RESERVED | Payload Length | 4367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4368 | Cert Encoding | | 4369 +-+-+-+-+-+-+-+-+ | 4370 ~ Certification Authority ~ 4371 | | 4372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4374 Figure 13: Certificate Request Payload Format 4376 o Certificate Encoding (1 octet) - Contains an encoding of the type 4377 or format of certificate requested. Values are listed in 4378 Section 3.6. 4380 o Certification Authority (variable length) - Contains an encoding 4381 of an acceptable certification authority for the type of 4382 certificate requested. 4384 The payload type for the Certificate Request payload is thirty-eight 4385 (38). 4387 The Certificate Encoding field has the same values as those defined 4388 in Section 3.6. The Certification Authority field contains an 4389 indicator of trusted authorities for this certificate type. The 4390 Certification Authority value is a concatenated list of SHA-1 hashes 4391 of the public keys of trusted Certification Authorities (CAs). Each 4392 is encoded as the SHA-1 hash of the Subject Public Key Info element 4393 (see section 4.1.2.7 of [PKIX]) from each Trust Anchor certificate. 4394 The 20-octet hashes are concatenated and included with no other 4395 formatting. 4397 The contents of the "Certification Authority" field are defined only 4398 for X.509 certificates, which are types 4, 12, and 13. Other values 4399 SHOULD NOT be used until Standards-Track specifications that specify 4400 their use are published. 4402 Note that the term "Certificate Request" is somewhat misleading, in 4403 that values other than certificates are defined in a "Certificate" 4404 payload and requests for those values can be present in a Certificate 4405 Request payload. The syntax of the Certificate Request payload in 4406 such cases is not defined in this document. 4408 The Certificate Request payload is processed by inspecting the "Cert 4409 Encoding" field to determine whether the processor has any 4410 certificates of this type. If so, the "Certification Authority" 4411 field is inspected to determine if the processor has any certificates 4412 that can be validated up to one of the specified certification 4413 authorities. This can be a chain of certificates. 4415 If an end-entity certificate exists that satisfies the criteria 4416 specified in the CERTREQ, a certificate or certificate chain SHOULD 4417 be sent back to the certificate requestor if the recipient of the 4418 CERTREQ: 4420 o is configured to use certificate authentication, 4422 o is allowed to send a CERT payload, 4424 o has matching CA trust policy governing the current negotiation, 4425 and 4427 o has at least one time-wise and usage-appropriate end-entity 4428 certificate chaining to a CA provided in the CERTREQ. 4430 Certificate revocation checking must be considered during the 4431 chaining process used to select a certificate. Note that even if two 4432 peers are configured to use two different CAs, cross-certification 4433 relationships should be supported by appropriate selection logic. 4435 The intent is not to prevent communication through the strict 4436 adherence of selection of a certificate based on CERTREQ, when an 4437 alternate certificate could be selected by the sender that would 4438 still enable the recipient to successfully validate and trust it 4439 through trust conveyed by cross-certification, CRLs, or other out-of- 4440 band configured means. Thus, the processing of a CERTREQ should be 4441 seen as a suggestion for a certificate to select, not a mandated one. 4442 If no certificates exist, then the CERTREQ is ignored. This is not 4443 an error condition of the protocol. There may be cases where there 4444 is a preferred CA sent in the CERTREQ, but an alternate might be 4445 acceptable (perhaps after prompting a human operator). 4447 The HTTP_CERT_LOOKUP_SUPPORTED notification MAY be included in any 4448 message that can include a CERTREQ payload and indicates that the 4449 sender is capable of looking up certificates based on an HTTP-based 4450 URL (and hence presumably would prefer to receive certificate 4451 specifications in that format). 4453 3.8. Authentication Payload 4455 The Authentication payload, denoted AUTH in this document, contains 4456 data used for authentication purposes. The syntax of the 4457 Authentication data varies according to the Auth Method as specified 4458 below. 4460 The Authentication payload is defined as follows: 4462 1 2 3 4463 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 4464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4465 | Next Payload |C| RESERVED | Payload Length | 4466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4467 | Auth Method | RESERVED | 4468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4469 | | 4470 ~ Authentication Data ~ 4471 | | 4472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4474 Figure 14: Authentication Payload Format 4476 o Auth Method (1 octet) - Specifies the method of authentication 4477 used. The types of signatures are listed here. The values in the 4478 following table are only current as of the publication date of RFC 4479 4306. Other values may have been added since then or will be 4480 added after the publication of this document. Readers should 4481 refer to [IKEV2IANA] for the latest values. 4483 Mechanism Value 4484 ----------------------------------------------------------------- 4485 RSA Digital Signature 1 4486 Computed as specified in Section 2.15 using an RSA private key 4487 with RSASSA-PKCS1-v1_5 signature scheme specified in [PKCS1] 4488 (implementers should note that IKEv1 used a different method for 4489 RSA signatures). To promote interoperability, implementations 4490 that support this type SHOULD support signatures that use SHA-1 4491 as the hash function and SHOULD use SHA-1 as the default hash 4492 function when generating signatures. Implementations can use the 4493 certificates received from a given peer as a hint for selecting a 4494 mutually understood hash function for the AUTH payload signature. 4495 Note, however, that the hash algorithm used in the AUTH payload 4496 signature doesn't have to be the same as any hash algorithm(s) 4497 used in the certificate(s). 4499 Shared Key Message Integrity Code 2 4500 Computed as specified in Section 2.15 using the shared key 4501 associated with the identity in the ID payload and the negotiated 4502 PRF. 4504 DSS Digital Signature 3 4505 Computed as specified in Section 2.15 using a DSS private key 4506 (see [DSS]) over a SHA-1 hash. 4508 o Authentication Data (variable length) - see Section 2.15. 4510 The payload type for the Authentication payload is thirty-nine (39). 4512 3.9. Nonce Payload 4514 The Nonce payload, denoted as Ni and Nr in this document for the 4515 initiator's and responder's nonce, respectively, contains random data 4516 used to guarantee liveness during an exchange and protect against 4517 replay attacks. 4519 The Nonce payload is defined as follows: 4521 1 2 3 4522 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 4523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4524 | Next Payload |C| RESERVED | Payload Length | 4525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4526 | | 4527 ~ Nonce Data ~ 4528 | | 4529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4530 Figure 15: Nonce Payload Format 4532 o Nonce Data (variable length) - Contains the random data generated 4533 by the transmitting entity. 4535 The payload type for the Nonce payload is forty (40). 4537 The size of the Nonce Data MUST be between 16 and 256 octets, 4538 inclusive. Nonce values MUST NOT be reused. 4540 3.10. Notify Payload 4542 The Notify payload, denoted N in this document, is used to transmit 4543 informational data, such as error conditions and state transitions, 4544 to an IKE peer. A Notify payload may appear in a response message 4545 (usually specifying why a request was rejected), in an INFORMATIONAL 4546 Exchange (to report an error not in an IKE request), or in any other 4547 message to indicate sender capabilities or to modify the meaning of 4548 the request. 4550 The Notify payload is defined as follows: 4552 1 2 3 4553 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 4554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4555 | Next Payload |C| RESERVED | Payload Length | 4556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4557 | Protocol ID | SPI Size | Notify Message Type | 4558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4559 | | 4560 ~ Security Parameter Index (SPI) ~ 4561 | | 4562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4563 | | 4564 ~ Notification Data ~ 4565 | | 4566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4568 Figure 16: Notify Payload Format 4570 o Protocol ID (1 octet) - If this notification concerns an existing 4571 SA whose SPI is given in the SPI field, this field indicates the 4572 type of that SA. For notifications concerning Child SAs, this 4573 field MUST contain either (2) to indicate AH or (3) to indicate 4574 ESP. Of the notifications defined in this document, the SPI is 4575 included only with INVALID_SELECTORS, REKEY_SA and 4576 CHILD_SA_NOT_FOUND. If the SPI field is empty, this field MUST be 4577 sent as zero and MUST be ignored on receipt. 4579 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 4580 IPsec protocol ID or zero if no SPI is applicable. For a 4581 notification concerning the IKE SA, the SPI Size MUST be zero and 4582 the field must be empty. 4584 o Notify Message Type (2 octets) - Specifies the type of 4585 notification message. 4587 o SPI (variable length) - Security Parameter Index. 4589 o Notification Data (variable length) - Status or error data 4590 transmitted in addition to the Notify Message Type. Values for 4591 this field are type specific (see below). 4593 The payload type for the Notify payload is forty-one (41). 4595 3.10.1. Notify Message Types 4597 Notification information can be error messages specifying why an SA 4598 could not be established. It can also be status data that a process 4599 managing an SA database wishes to communicate with a peer process. 4600 The table below lists the Notification messages and their 4601 corresponding values. The number of different error statuses was 4602 greatly reduced from IKEv1 both for simplification and to avoid 4603 giving configuration information to probers. 4605 Types in the range 0 - 16383 are intended for reporting errors. An 4606 implementation receiving a Notify payload with one of these types 4607 that it does not recognize in a response MUST assume that the 4608 corresponding request has failed entirely. Unrecognized error types 4609 in a request and status types in a request or response MUST be 4610 ignored, and they should be logged. 4612 Notify payloads with status types MAY be added to any message and 4613 MUST be ignored if not recognized. They are intended to indicate 4614 capabilities, and as part of SA negotiation, are used to negotiate 4615 non-cryptographic parameters. 4617 More information on error handling can be found in Section 2.21. 4619 The values in the following table are only current as of the 4620 publication date of RFC 4306, plus two error types added in this 4621 document. Other values may have been added since then or will be 4622 added after the publication of this document. Readers should refer 4623 to [IKEV2IANA] for the latest values. 4625 NOTIFY messages: error types Value 4626 ------------------------------------------------------------------- 4627 UNSUPPORTED_CRITICAL_PAYLOAD 1 4628 See Section 2.5. 4630 INVALID_IKE_SPI 4 4631 See Section 2.21. 4633 INVALID_MAJOR_VERSION 5 4634 See Section 2.5. 4636 INVALID_SYNTAX 7 4637 Indicates the IKE message that was received was invalid because 4638 some type, length, or value was out of range or because the 4639 request was rejected for policy reasons. To avoid a DoS 4640 attack using forged messages, this status may only be 4641 returned for and in an encrypted packet if the Message ID and 4642 cryptographic checksum were valid. To avoid leaking information 4643 to someone probing a node, this status MUST be sent in response 4644 to any error not covered by one of the other status types. 4645 To aid debugging, more detailed error information should be 4646 written to a console or log. 4648 INVALID_MESSAGE_ID 9 4649 See Section 2.3. 4651 INVALID_SPI 11 4652 See Section 1.5. 4654 NO_PROPOSAL_CHOSEN 14 4655 None of the proposed crypto suites was acceptable. This can be 4656 sent in any case where the offered proposals (including but not 4657 limited to SA payload values, USE_TRANSPORT_MODE notify, 4658 IPCOMP_SUPPORTED notify) are not acceptable for the responder. 4659 This can also be used as "generic" Child SA error when Child SA 4660 cannot be created for some other reason. See also Section 2.7. 4662 INVALID_KE_PAYLOAD 17 4663 See Sections 1.2 and 1.3. 4665 AUTHENTICATION_FAILED 24 4666 Sent in the response to an IKE_AUTH message when, for some 4667 reason, the authentication failed. There is no associated 4668 data. See also Section 2.21.2. 4670 SINGLE_PAIR_REQUIRED 34 4671 See Section 2.9. 4673 NO_ADDITIONAL_SAS 35 4674 See Section 1.3. 4676 INTERNAL_ADDRESS_FAILURE 36 4677 See Section 3.15.4. 4679 FAILED_CP_REQUIRED 37 4680 See Section 2.19. 4682 TS_UNACCEPTABLE 38 4683 See Section 2.9. 4685 INVALID_SELECTORS 39 4686 MAY be sent in an IKE INFORMATIONAL exchange when a node receives 4687 an ESP or AH packet whose selectors do not match those of the SA 4688 on which it was delivered (and that caused the packet to be 4689 dropped). The Notification Data contains the start of the 4690 offending packet (as in ICMP messages) and the SPI field of the 4691 notification is set to match the SPI of the Child SA. 4693 TEMPORARY_FAILURE 43 4694 See section 2.25. 4696 CHILD_SA_NOT_FOUND 44 4697 See section 2.25. 4699 NOTIFY messages: status types Value 4700 ------------------------------------------------------------------- 4701 INITIAL_CONTACT 16384 4702 See Section 2.4. 4704 SET_WINDOW_SIZE 16385 4705 See Section 2.3. 4707 ADDITIONAL_TS_POSSIBLE 16386 4708 See Section 2.9. 4710 IPCOMP_SUPPORTED 16387 4711 See Section 2.22. 4713 NAT_DETECTION_SOURCE_IP 16388 4714 See Section 2.23. 4716 NAT_DETECTION_DESTINATION_IP 16389 4717 See Section 2.23. 4719 COOKIE 16390 4720 See Section 2.6. 4722 USE_TRANSPORT_MODE 16391 4723 See Section 1.3.1. 4725 HTTP_CERT_LOOKUP_SUPPORTED 16392 4726 See Section 3.6. 4728 REKEY_SA 16393 4729 See Section 1.3.3. 4731 ESP_TFC_PADDING_NOT_SUPPORTED 16394 4732 See Section 1.3.1. 4734 NON_FIRST_FRAGMENTS_ALSO 16395 4735 See Section 1.3.1. 4737 3.11. Delete Payload 4739 The Delete payload, denoted D in this document, contains a protocol- 4740 specific Security Association identifier that the sender has removed 4741 from its Security Association database and is, therefore, no longer 4742 valid. Figure 17 shows the format of the Delete payload. It is 4743 possible to send multiple SPIs in a Delete payload; however, each SPI 4744 MUST be for the same protocol. Mixing of protocol identifiers MUST 4745 NOT be performed in the Delete payload. It is permitted, however, to 4746 include multiple Delete payloads in a single INFORMATIONAL exchange 4747 where each Delete payload lists SPIs for a different protocol. 4749 Deletion of the IKE SA is indicated by a protocol ID of 1 (IKE) but 4750 no SPIs. Deletion of a Child SA, such as ESP or AH, will contain the 4751 IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI 4752 is the SPI the sending endpoint would expect in inbound ESP or AH 4753 packets. 4755 The Delete payload is defined as follows: 4757 1 2 3 4758 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 4759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4760 | Next Payload |C| RESERVED | Payload Length | 4761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4762 | Protocol ID | SPI Size | Num of SPIs | 4763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4764 | | 4765 ~ Security Parameter Index(es) (SPI) ~ 4766 | | 4767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4769 Figure 17: Delete Payload Format 4771 o Protocol ID (1 octet) - Must be 1 for an IKE SA, 2 for AH, or 3 4772 for ESP. 4774 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 4775 protocol ID. It MUST be zero for IKE (SPI is in message header) 4776 or four for AH and ESP. 4778 o Num of SPIs (2 octets, unsigned integer) - The number of SPIs 4779 contained in the Delete payload. The size of each SPI is defined 4780 by the SPI Size field. 4782 o Security Parameter Index(es) (variable length) - Identifies the 4783 specific Security Association(s) to delete. The length of this 4784 field is determined by the SPI Size and Num of SPIs fields. 4786 The payload type for the Delete payload is forty-two (42). 4788 3.12. Vendor ID Payload 4790 The Vendor ID payload, denoted V in this document, contains a vendor- 4791 defined constant. The constant is used by vendors to identify and 4792 recognize remote instances of their implementations. This mechanism 4793 allows a vendor to experiment with new features while maintaining 4794 backward compatibility. 4796 A Vendor ID payload MAY announce that the sender is capable of 4797 accepting certain extensions to the protocol, or it MAY simply 4798 identify the implementation as an aid in debugging. A Vendor ID 4799 payload MUST NOT change the interpretation of any information defined 4800 in this specification (i.e., the critical bit MUST be set to 0). 4801 Multiple Vendor ID payloads MAY be sent. An implementation is not 4802 required to send any Vendor ID payload at all. 4804 A Vendor ID payload may be sent as part of any message. Reception of 4805 a familiar Vendor ID payload allows an implementation to make use of 4806 private use numbers described throughout this document, such as 4807 private payloads, private exchanges, private notifications, etc. 4808 Unfamiliar Vendor IDs MUST be ignored. 4810 Writers of documents who wish to extend this protocol MUST define a 4811 Vendor ID payload to announce the ability to implement the extension 4812 in the document. It is expected that documents that gain acceptance 4813 and are standardized will be given "magic numbers" out of the Future 4814 Use range by IANA, and the requirement to use a Vendor ID will go 4815 away. 4817 The Vendor ID payload fields are defined as follows: 4819 1 2 3 4820 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 4821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4822 | Next Payload |C| RESERVED | Payload Length | 4823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4824 | | 4825 ~ Vendor ID (VID) ~ 4826 | | 4827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4829 Figure 18: Vendor ID Payload Format 4831 o Vendor ID (variable length) - It is the responsibility of the 4832 person choosing the Vendor ID to assure its uniqueness in spite of 4833 the absence of any central registry for IDs. Good practice is to 4834 include a company name, a person name, or some such information. 4835 If you want to show off, you might include the latitude and 4836 longitude and time where you were when you chose the ID and some 4837 random input. A message digest of a long unique string is 4838 preferable to the long unique string itself. 4840 The payload type for the Vendor ID payload is forty-three (43). 4842 3.13. Traffic Selector Payload 4844 The Traffic Selector payload, denoted TS in this document, allows 4845 peers to identify packet flows for processing by IPsec security 4846 services. The Traffic Selector payload consists of the IKE generic 4847 payload header followed by individual Traffic Selectors as follows: 4849 1 2 3 4850 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 4851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4852 | Next Payload |C| RESERVED | Payload Length | 4853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4854 | Number of TSs | RESERVED | 4855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4856 | | 4857 ~ ~ 4858 | | 4859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4861 Figure 19: Traffic Selectors Payload Format 4863 o Number of TSs (1 octet) - Number of Traffic Selectors being 4864 provided. 4866 o RESERVED - This field MUST be sent as zero and MUST be ignored on 4867 receipt. 4869 o Traffic Selectors (variable length) - One or more individual 4870 Traffic Selectors. 4872 The length of the Traffic Selector payload includes the TS header and 4873 all the Traffic Selectors. 4875 The payload type for the Traffic Selector payload is forty-four (44) 4876 for addresses at the initiator's end of the SA and forty-five (45) 4877 for addresses at the responder's end. 4879 There is no requirement that TSi and TSr contain the same number of 4880 individual Traffic Selectors. Thus, they are interpreted as follows: 4881 a packet matches a given TSi/TSr if it matches at least one of the 4882 individual selectors in TSi, and at least one of the individual 4883 selectors in TSr. 4885 For instance, the following Traffic Selectors: 4887 TSi = ((17, 100, 198.51.100.66-198.51.100.66), 4888 (17, 200, 198.51.100.66-198.51.100.66)) 4889 TSr = ((17, 300, 0.0.0.0-255.255.255.255), 4890 (17, 400, 0.0.0.0-255.255.255.255)) 4892 would match UDP packets from 198.51.100.66 to anywhere, with any of 4893 the four combinations of source/destination ports (100,300), 4894 (100,400), (200,300), and (200, 400). 4896 Thus, some types of policies may require several Child SA pairs. For 4897 instance, a policy matching only source/destination ports (100,300) 4898 and (200,400), but not the other two combinations, cannot be 4899 negotiated as a single Child SA pair. 4901 3.13.1. Traffic Selector 4903 1 2 3 4904 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 4905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4906 | TS Type |IP Protocol ID*| Selector Length | 4907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4908 | Start Port* | End Port* | 4909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4910 | | 4911 ~ Starting Address* ~ 4912 | | 4913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4914 | | 4915 ~ Ending Address* ~ 4916 | | 4917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4919 Figure 20: Traffic Selector 4921 *Note: All fields other than TS Type and Selector Length depend on 4922 the TS Type. The fields shown are for TS Types 7 and 8, the only two 4923 values currently defined. 4925 o TS Type (one octet) - Specifies the type of Traffic Selector. 4927 o IP protocol ID (1 octet) - Value specifying an associated IP 4928 protocol ID (such as UDP, TCP, and ICMP). A value of zero means 4929 that the protocol ID is not relevant to this Traffic Selector -- 4930 the SA can carry all protocols. 4932 o Selector Length - Specifies the length of this Traffic Selector 4933 substructure including the header. 4935 o Start Port (2 octets, unsigned integer) - Value specifying the 4936 smallest port number allowed by this Traffic Selector. For 4937 protocols for which port is undefined (including protocol 0), or 4938 if all ports are allowed, this field MUST be zero. ICMP and 4939 ICMPv6 Type and Code values, as well as Mobile IP version 6 4940 (MIPv6) mobility header (MH) Type values, are represented in this 4941 field as specified in Section 4.4.1.1 of [IPSECARCH]. ICMP Type 4942 and Code values are treated as a single 16-bit integer port 4943 number, with Type in the most significant eight bits and Code in 4944 the least significant eight bits. MIPv6 MH Type values are 4945 treated as a single 16-bit integer port number, with Type in the 4946 most significant eight bits and the least significant eight bits 4947 set to zero. 4949 o End Port (2 octets, unsigned integer) - Value specifying the 4950 largest port number allowed by this Traffic Selector. For 4951 protocols for which port is undefined (including protocol 0), or 4952 if all ports are allowed, this field MUST be 65535. ICMP and 4953 ICMPv6 Type and Code values, as well as MIPv6 MH Type values, are 4954 represented in this field as specified in Section 4.4.1.1 of 4955 [IPSECARCH]. ICMP Type and Code values are treated as a single 4956 16-bit integer port number, with Type in the most significant 4957 eight bits and Code in the least significant eight bits. MIPv6 MH 4958 Type values are treated as a single 16-bit integer port number, 4959 with Type in the most significant eight bits and the least 4960 significant eight bits set to zero. 4962 o Starting Address - The smallest address included in this Traffic 4963 Selector (length determined by TS Type). 4965 o Ending Address - The largest address included in this Traffic 4966 Selector (length determined by TS Type). 4968 Systems that are complying with [IPSECARCH] that wish to indicate 4969 "ANY" ports MUST set the start port to 0 and the end port to 65535; 4970 note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems 4971 working with [IPSECARCH] that wish to indicate "OPAQUE" ports, but 4972 not "ANY" ports, MUST set the start port to 65535 and the end port to 4973 0. 4975 The Traffic Selector types 7 and 8 can also refer to ICMP or ICMPv6 4976 type and code fields, as well as MH Type fields for the IPv6 mobility 4977 header [MIPV6]. Note, however, that neither ICMP nor MIPv6 packets 4978 have separate source and destination fields. The method for 4979 specifying the Traffic Selectors for ICMP and MIPv6 is shown by 4980 example in Section 4.4.1.3 of [IPSECARCH]. 4982 The following table lists values for the Traffic Selector Type field 4983 and the corresponding Address Selector Data. The values in the 4984 following table are only current as of the publication date of RFC 4985 4306. Other values may have been added since then or will be added 4986 after the publication of this document. Readers should refer to 4987 [IKEV2IANA] for the latest values. 4989 TS Type Value 4990 ------------------------------------------------------------------- 4991 TS_IPV4_ADDR_RANGE 7 4993 A range of IPv4 addresses, represented by two four-octet 4994 values. The first value is the beginning IPv4 address 4995 (inclusive) and the second value is the ending IPv4 address 4996 (inclusive). All addresses falling between the two specified 4997 addresses are considered to be within the list. 4999 TS_IPV6_ADDR_RANGE 8 5001 A range of IPv6 addresses, represented by two sixteen-octet 5002 values. The first value is the beginning IPv6 address 5003 (inclusive) and the second value is the ending IPv6 address 5004 (inclusive). All addresses falling between the two specified 5005 addresses are considered to be within the list. 5007 3.14. Encrypted Payload 5009 The Encrypted payload, denoted SK{...} in this document, contains 5010 other payloads in encrypted form. The Encrypted payload, if present 5011 in a message, MUST be the last payload in the message. Often, it is 5012 the only payload in the message. This payload is also called the 5013 "Encrypted and Authenticated" payload. 5015 The algorithms for encryption and integrity protection are negotiated 5016 during IKE SA setup, and the keys are computed as specified in 5017 Sections 2.14 and 2.18. 5019 This document specifies the cryptographic processing of Encrypted 5020 payloads using a block cipher in CBC mode and an integrity check 5021 algorithm that computes a fixed-length checksum over a variable size 5022 message. The design is modeled after the ESP algorithms described in 5023 RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document 5024 completely specifies the cryptographic processing of IKE data, but 5025 those documents should be consulted for design rationale. Future 5026 documents may specify the processing of Encrypted payloads for other 5027 types of transforms, such as counter mode encryption and 5028 authenticated encryption algorithms. Peers MUST NOT negotiate 5029 transforms for which no such specification exists. 5031 When an authenticated encryption algorithm is used to protect the IKE 5032 SA, the construction of the Encrypted payload is different than what 5033 is described here. See [AEAD] for more information on authenticated 5034 encryption algorithms and their use in ESP. 5036 The payload type for an Encrypted payload is forty-six (46). The 5037 Encrypted payload consists of the IKE generic payload header followed 5038 by individual fields as follows: 5040 1 2 3 5041 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 5042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5043 | Next Payload |C| RESERVED | Payload Length | 5044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5045 | Initialization Vector | 5046 | (length is block size for encryption algorithm) | 5047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5048 ~ Encrypted IKE Payloads ~ 5049 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5050 | | Padding (0-255 octets) | 5051 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 5052 | | Pad Length | 5053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5054 ~ Integrity Checksum Data ~ 5055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5057 Figure 21: Encrypted Payload Format 5059 o Next Payload - The payload type of the first embedded payload. 5060 Note that this is an exception in the standard header format, 5061 since the Encrypted payload is the last payload in the message and 5062 therefore the Next Payload field would normally be zero. But 5063 because the content of this payload is embedded payloads and there 5064 was no natural place to put the type of the first one, that type 5065 is placed here. 5067 o Payload Length - Includes the lengths of the header, 5068 initialization vector (IV), Encrypted IKE payloads, Padding, Pad 5069 Length, and Integrity Checksum Data. 5071 o Initialization Vector - For CBC mode ciphers, the length of the 5072 initialization vector (IV) is equal to the block length of the 5073 underlying encryption algorithm. Senders MUST select a new 5074 unpredictable IV for every message; recipients MUST accept any 5075 value. The reader is encouraged to consult [MODES] for advice on 5076 IV generation. In particular, using the final ciphertext block of 5077 the previous message is not considered unpredictable. For modes 5078 other than CBC, the IV format and processing is specified in the 5079 document specifying the encryption algorithm and mode. 5081 o IKE payloads are as specified earlier in this section. This field 5082 is encrypted with the negotiated cipher. 5084 o Padding MAY contain any value chosen by the sender, and MUST have 5085 a length that makes the combination of the payloads, the Padding, 5086 and the Pad Length to be a multiple of the encryption block size. 5087 This field is encrypted with the negotiated cipher. 5089 o Pad Length is the length of the Padding field. The sender SHOULD 5090 set the Pad Length to the minimum value that makes the combination 5091 of the payloads, the Padding, and the Pad Length a multiple of the 5092 block size, but the recipient MUST accept any length that results 5093 in proper alignment. This field is encrypted with the negotiated 5094 cipher. 5096 o Integrity Checksum Data is the cryptographic checksum of the 5097 entire message starting with the Fixed IKE header through the Pad 5098 Length. The checksum MUST be computed over the encrypted message. 5099 Its length is determined by the integrity algorithm negotiated. 5101 3.15. Configuration Payload 5103 The Configuration payload, denoted CP in this document, is used to 5104 exchange configuration information between IKE peers. The exchange 5105 is for an IRAC to request an internal IP address from an IRAS and to 5106 exchange other information of the sort that one would acquire with 5107 Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly 5108 connected to a LAN. 5110 The Configuration payload is defined as follows: 5112 1 2 3 5113 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 5114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5115 | Next Payload |C| RESERVED | Payload Length | 5116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5117 | CFG Type | RESERVED | 5118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5119 | | 5120 ~ Configuration Attributes ~ 5121 | | 5122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5124 Figure 22: Configuration Payload Format 5126 The payload type for the Configuration payload is forty-seven (47). 5128 o CFG Type (1 octet) - The type of exchange represented by the 5129 Configuration Attributes. The values in the following table are 5130 only current as of the publication date of RFC 4306. Other values 5131 may have been added since then or will be added after the 5132 publication of this document. Readers should refer to [IKEV2IANA] 5133 for the latest values. 5135 CFG Type Value 5136 -------------------------- 5137 CFG_REQUEST 1 5138 CFG_REPLY 2 5139 CFG_SET 3 5140 CFG_ACK 4 5142 o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on 5143 receipt. 5145 o Configuration Attributes (variable length) - These are type length 5146 value (TLV) structures specific to the Configuration payload and 5147 are defined below. There may be zero or more Configuration 5148 Attributes in this payload. 5150 3.15.1. Configuration Attributes 5152 1 2 3 5153 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 5154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5155 |R| Attribute Type | Length | 5156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5157 | | 5158 ~ Value ~ 5159 | | 5160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5162 Figure 23: Configuration Attribute Format 5164 o Reserved (1 bit) - This bit MUST be set to zero and MUST be 5165 ignored on receipt. 5167 o Attribute Type (15 bits) - A unique identifier for each of the 5168 Configuration Attribute Types. 5170 o Length (2 octets, unsigned integer) - Length in octets of value. 5172 o Value (0 or more octets) - The variable-length value of this 5173 Configuration Attribute. The following lists the attribute types. 5175 The values in the following table are only current as of the 5176 publication date of RFC 4306 (except INTERNAL_ADDRESS_EXPIRY and 5177 INTERNAL_IP6_NBNS which were removed by this document). Other values 5178 may have been added since then or will be added after the publication 5179 of this document. Readers should refer to [IKEV2IANA] for the latest 5180 values. 5182 Attribute Type Value Multi-Valued Length 5183 ------------------------------------------------------------ 5184 INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets 5185 INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets 5186 INTERNAL_IP4_DNS 3 YES 0 or 4 octets 5187 INTERNAL_IP4_NBNS 4 YES 0 or 4 octets 5188 INTERNAL_IP4_DHCP 6 YES 0 or 4 octets 5189 APPLICATION_VERSION 7 NO 0 or more 5190 INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets 5191 INTERNAL_IP6_DNS 10 YES 0 or 16 octets 5192 INTERNAL_IP6_DHCP 12 YES 0 or 16 octets 5193 INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets 5194 SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 5195 INTERNAL_IP6_SUBNET 15 YES 17 octets 5197 * These attributes may be multi-valued on return only if 5198 multiple values were requested. 5200 o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the 5201 internal network, sometimes called a red node address or private 5202 address, and it MAY be a private address on the Internet. In a 5203 request message, the address specified is a requested address (or 5204 a zero-length address if no specific address is requested). If a 5205 specific address is requested, it likely indicates that a previous 5206 connection existed with this address and the requestor would like 5207 to reuse that address. With IPv6, a requestor MAY supply the low- 5208 order address octets it wants to use. Multiple internal addresses 5209 MAY be requested by requesting multiple internal address 5210 attributes. The responder MAY only send up to the number of 5211 addresses requested. The INTERNAL_IP6_ADDRESS is made up of two 5212 fields: the first is a 16-octet IPv6 address, and the second is a 5213 one-octet prefix-length as defined in [ADDRIPV6]. The requested 5214 address is valid as long as this IKE SA (or its rekeyed 5215 successors) requesting the address is valid. This is described in 5216 more detail in Section 3.15.3. 5218 o INTERNAL_IP4_NETMASK - The internal network's netmask. Only one 5219 netmask is allowed in the request and response messages (e.g., 5220 255.255.255.0), and it MUST be used only with an 5221 INTERNAL_IP4_ADDRESS attribute. INTERNAL_IP4_NETMASK in a 5222 CFG_REPLY means roughly the same thing as INTERNAL_IP4_SUBNET 5223 containing the same information ("send traffic to these addresses 5224 through me"), but also implies a link boundary. For instance, the 5225 client could use its own address and the netmask to calculate the 5226 broadcast address of the link. An empty INTERNAL_IP4_NETMASK 5227 attribute can be included in a CFG_REQUEST to request this 5228 information (although the gateway can send the information even 5229 when not requested). Non-empty values for this attribute in a 5230 CFG_REQUEST do not make sense and thus MUST NOT be included. 5232 o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS 5233 server within the network. Multiple DNS servers MAY be requested. 5234 The responder MAY respond with zero or more DNS server attributes. 5236 o INTERNAL_IP4_NBNS - Specifies an address of a NetBios Name Server 5237 (WINS) within the network. Multiple NBNS servers MAY be 5238 requested. The responder MAY respond with zero or more NBNS 5239 server attributes. 5241 o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send 5242 any internal DHCP requests to the address contained within the 5243 attribute. Multiple DHCP servers MAY be requested. The responder 5244 MAY respond with zero or more DHCP server attributes. 5246 o APPLICATION_VERSION - The version or application information of 5247 the IPsec host. This is a string of printable ASCII characters 5248 that is NOT null terminated. 5250 o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge- 5251 device protects. This attribute is made up of two fields: the 5252 first being an IP address and the second being a netmask. 5253 Multiple sub-networks MAY be requested. The responder MAY respond 5254 with zero or more sub-network attributes. This is discussed in 5255 more detail in Section 3.15.2. 5257 o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute 5258 MUST be zero-length and specifies a query to the responder to 5259 reply back with all of the attributes that it supports. The 5260 response contains an attribute that contains a set of attribute 5261 identifiers each in 2 octets. The length divided by 2 (octets) 5262 would state the number of supported attributes contained in the 5263 response. 5265 o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge- 5266 device protects. This attribute is made up of two fields: the 5267 first is a 16-octet IPv6 address, and the second is a one-octet 5268 prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY 5269 be requested. The responder MAY respond with zero or more sub- 5270 network attributes. This is discussed in more detail in 5271 Section 3.15.2. 5273 Note that no recommendations are made in this document as to how an 5274 implementation actually figures out what information to send in a 5275 response. That is, we do not recommend any specific method of an 5276 IRAS determining which DNS server should be returned to a requesting 5277 IRAC. 5279 The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request 5280 information from its peer. If an attribute in the CFG_REQUEST 5281 Configuration payload is not zero-length, it is taken as a suggestion 5282 for that attribute. The CFG_REPLY Configuration payload MAY return 5283 that value, or a new one. It MAY also add new attributes and not 5284 include some requested ones. Unrecognized or unsupported attributes 5285 MUST be ignored in both requests and responses. 5287 The CFG_SET and CFG_ACK pair allows an IKE endpoint to push 5288 configuration data to its peer. In this case, the CFG_SET 5289 Configuration payload contains attributes the initiator wants its 5290 peer to alter. The responder MUST return a Configuration payload if 5291 it accepted any of the configuration data and it MUST contain the 5292 attributes that the responder accepted with zero-length data. Those 5293 attributes that it did not accept MUST NOT be in the CFG_ACK 5294 Configuration payload. If no attributes were accepted, the responder 5295 MUST return either an empty CFG_ACK payload or a response message 5296 without a CFG_ACK payload. There are currently no defined uses for 5297 the CFG_SET/CFG_ACK exchange, though they may be used in connection 5298 with extensions based on Vendor IDs. An implementation of this 5299 specification MAY ignore CFG_SET payloads. 5301 3.15.2. Meaning of INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET 5303 INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets, 5304 ones that need one or more separate SAs, that can be reached through 5305 the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET 5306 attributes may also express the gateway's policy about what traffic 5307 should be sent through the gateway; the client can choose whether 5308 other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is 5309 sent through the gateway or directly to the destination. Thus, 5310 traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET 5311 attributes should be sent through the gateway that announces the 5312 attributes. If there are no existing Child SAs whose Traffic 5313 Selectors cover the address in question, new SAs need to be created. 5315 For instance, if there are two subnets, 198.51.100.0/26 and 5316 192.0.2.0/24, and the client's request contains the following: 5318 CP(CFG_REQUEST) = 5319 INTERNAL_IP4_ADDRESS() 5320 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) 5321 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) 5323 then a valid response could be the following (in which TSr and 5324 INTERNAL_IP4_SUBNET contain the same information): 5326 CP(CFG_REPLY) = 5327 INTERNAL_IP4_ADDRESS(198.51.100.234) 5328 INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192) 5329 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 5330 TSi = (0, 0-65535, 198.51.100.234-198.51.100.234) 5331 TSr = ((0, 0-65535, 198.51.100.0-198.51.100.63), 5332 (0, 0-65535, 192.0.2.0-192.0.2.255)) 5334 In these cases, the INTERNAL_IP4_SUBNET does not really carry any 5335 useful information. 5337 A different possible response would have been this: 5339 CP(CFG_REPLY) = 5340 INTERNAL_IP4_ADDRESS(198.51.100.234) 5341 INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192) 5342 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 5343 TSi = (0, 0-65535, 198.51.100.234-198.51.100.234) 5344 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) 5346 That response would mean that the client can send all its traffic 5347 through the gateway, but the gateway does not mind if the client 5348 sends traffic not included by INTERNAL_IP4_SUBNET directly to the 5349 destination (without going through the gateway). 5351 A different situation arises if the gateway has a policy that 5352 requires the traffic for the two subnets to be carried in separate 5353 SAs. Then a response like this would indicate to the client that if 5354 it wants access to the second subnet, it needs to create a separate 5355 SA: 5357 CP(CFG_REPLY) = 5358 INTERNAL_IP4_ADDRESS(198.51.100.234) 5359 INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192) 5360 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 5361 TSi = (0, 0-65535, 198.51.100.234-198.51.100.234) 5362 TSr = (0, 0-65535, 198.51.100.0-198.51.100.63) 5364 INTERNAL_IP4_SUBNET can also be useful if the client's TSr included 5365 only part of the address space. For instance, if the client requests 5366 the following: 5368 CP(CFG_REQUEST) = 5369 INTERNAL_IP4_ADDRESS() 5370 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) 5371 TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) 5373 then the gateway's response might be: 5375 CP(CFG_REPLY) = 5376 INTERNAL_IP4_ADDRESS(198.51.100.234) 5377 INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192) 5378 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 5379 TSi = (0, 0-65535, 198.51.100.234-198.51.100.234) 5380 TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) 5382 Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET in 5383 CFG_REQUESTs is unclear, they cannot be used reliably in 5384 CFG_REQUESTs. 5386 3.15.3. Configuration Payloads for IPv6 5388 The Configuration payloads for IPv6 are based on the corresponding 5389 IPv4 payloads, and do not fully follow the "normal IPv6 way of doing 5390 things". In particular, IPv6 stateless autoconfiguration or router 5391 advertisement messages are not used, neither is neighbor discovery. 5392 Note that there is an additional document that discusses IPv6 5393 configuration in IKEv2, [IPV6CONFIG]. At the present time, it is an 5394 experimental document, but there is a hope that with more 5395 implementation experience, it will gain the same standards treatment 5396 as this document. 5398 A client can be assigned an IPv6 address using the 5399 INTERNAL_IP6_ADDRESS Configuration payload. A minimal exchange might 5400 look like this: 5402 CP(CFG_REQUEST) = 5403 INTERNAL_IP6_ADDRESS() 5404 INTERNAL_IP6_DNS() 5405 TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 5406 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 5408 CP(CFG_REPLY) = 5409 INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) 5410 INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) 5411 TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) 5412 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 5414 The client MAY send a non-empty INTERNAL_IP6_ADDRESS attribute in the 5415 CFG_REQUEST to request a specific address or interface identifier. 5417 The gateway first checks if the specified address is acceptable, and 5418 if it is, returns that one. If the address was not acceptable, the 5419 gateway attempts to use the interface identifier with some other 5420 prefix; if even that fails, the gateway selects another interface 5421 identifier. 5423 The INTERNAL_IP6_ADDRESS attribute also contains a prefix length 5424 field. When used in a CFG_REPLY, this corresponds to the 5425 INTERNAL_IP4_NETMASK attribute in the IPv4 case. 5427 Although this approach to configuring IPv6 addresses is reasonably 5428 simple, it has some limitations. IPsec tunnels configured using 5429 IKEv2 are not fully featured "interfaces" in the IPv6 addressing 5430 architecture sense [ADDRIPV6]. In particular, they do not 5431 necessarily have link-local addresses, and this may complicate the 5432 use of protocols that assume them, such as [MLDV2]. 5434 3.15.4. Address Assignment Failures 5436 If the responder encounters an error while attempting to assign an IP 5437 address to the initiator during the processing of a Configuration 5438 payload, it responds with an INTERNAL_ADDRESS_FAILURE notification. 5439 The IKE SA is still created even if the initial Child SA cannot be 5440 created because of this failure. If this error is generated within 5441 an IKE_AUTH exchange, no Child SA will be created. However, there 5442 are some more complex error cases. 5444 If the responder does not support Configuration payloads at all, it 5445 can simply ignore all Configuration payloads. This type of 5446 implementation never sends INTERNAL_ADDRESS_FAILURE notifications. 5447 If the initiator requires the assignment of an IP address, it will 5448 treat a response without CFG_REPLY as an error. 5450 The initiator may request a particular type of address (IPv4 or IPv6) 5451 that the responder does not support, even though the responder 5452 supports Configuration payloads. In this case, the responder simply 5453 ignores the type of address it does not support and processes the 5454 rest of the request as usual. 5456 If the initiator requests multiple addresses of a type that the 5457 responder supports, and some (but not all) of the requests fail, the 5458 responder replies with the successful addresses only. The responder 5459 sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned. 5461 If the initiator does not receive the IP address(es) required by its 5462 policy, it MAY keep the IKE SA up and retry the Configuration payload 5463 as separate INFORMATIONAL exchange after suitable timeout, or it MAY 5464 tear down the IKE SA by sending a Delete payload inside a separate 5465 INFORMATIONAL exchange and later retry IKE SA from the beginning 5466 after some timeout. Such a timeout should not be too short 5467 (especially if the IKE SA is started from the beginning) because 5468 these error situations may not be able to be fixed quickly; the 5469 timeout should likely be several minutes. For example, an address 5470 shortage problem on the responder will probably only be fixed when 5471 more entries are returned to the address pool when other clients 5472 disconnect or when responder is reconfigured with larger address 5473 pool. 5475 3.16. Extensible Authentication Protocol (EAP) Payload 5477 The Extensible Authentication Protocol payload, denoted EAP in this 5478 document, allows IKE SAs to be authenticated using the protocol 5479 defined in RFC 3748 [EAP] and subsequent extensions to that protocol. 5480 When using EAP, an appropriate EAP method needs to be selected. Many 5481 of these methods have been defined, specifying the protocol's use 5482 with various authentication mechanisms. EAP method types are listed 5483 in [EAP-IANA]. A short summary of the EAP format is included here 5484 for clarity. 5486 1 2 3 5487 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 5488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5489 | Next Payload |C| RESERVED | Payload Length | 5490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5491 | | 5492 ~ EAP Message ~ 5493 | | 5494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5496 Figure 24: EAP Payload Format 5498 The payload type for an EAP payload is forty-eight (48). 5500 1 2 3 5501 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 5502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5503 | Code | Identifier | Length | 5504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5505 | Type | Type_Data... 5506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 5508 Figure 25: EAP Message Format 5510 o Code (1 octet) indicates whether this message is a Request (1), 5511 Response (2), Success (3), or Failure (4). 5513 o Identifier (1 octet) is used in PPP to distinguish replayed 5514 messages from repeated ones. Since in IKE, EAP runs over a 5515 reliable protocol, it serves no function here. In a response 5516 message, this octet MUST be set to match the identifier in the 5517 corresponding request. 5519 o Length (2 octets, unsigned integer) is the length of the EAP 5520 message and MUST be four less than the Payload Length of the 5521 encapsulating payload. 5523 o Type (1 octet) is present only if the Code field is Request (1) or 5524 Response (2). For other codes, the EAP message length MUST be 5525 four octets and the Type and Type_Data fields MUST NOT be present. 5526 In a Request (1) message, Type indicates the data being requested. 5527 In a Response (2) message, Type MUST either be Nak or match the 5528 type of the data requested. Note that since IKE passes an 5529 indication of initiator identity in the first message in the 5530 IKE_AUTH exchange, the responder SHOULD NOT send EAP Identity 5531 requests (type 1). The initiator MAY, however, respond to such 5532 requests if it receives them. 5534 o Type_Data (Variable Length) varies with the Type of Request and 5535 the associated Response. For the documentation of the EAP 5536 methods, see [EAP]. 5538 Note that since IKE passes an indication of initiator identity in the 5539 first message in the IKE_AUTH exchange, the responder should not send 5540 EAP Identity requests. The initiator may, however, respond to such 5541 requests if it receives them. 5543 4. Conformance Requirements 5545 In order to assure that all implementations of IKEv2 can 5546 interoperate, there are "MUST support" requirements in addition to 5547 those listed elsewhere. Of course, IKEv2 is a security protocol, and 5548 one of its major functions is to allow only authorized parties to 5549 successfully complete establishment of SAs. So a particular 5550 implementation may be configured with any of a number of restrictions 5551 concerning algorithms and trusted authorities that will prevent 5552 universal interoperability. 5554 IKEv2 is designed to permit minimal implementations that can 5555 interoperate with all compliant implementations. The following are 5556 features that can be omitted in a minimal implementation: 5558 o Ability to negotiate SAs through a NAT and tunnel the resulting 5559 ESP SA over UDP. 5561 o Ability to request (and respond to a request for) a temporary IP 5562 address on the remote end of a tunnel. 5564 o Ability to support EAP-based authentication. 5566 o Ability to support window sizes greater than one. 5568 o Ability to establish multiple ESP or AH SAs within a single IKE 5569 SA. 5571 o Ability to rekey SAs. 5573 To assure interoperability, all implementations MUST be capable of 5574 parsing all payload types (if only to skip over them) and to ignore 5575 payload types that it does not support unless the critical bit is set 5576 in the payload header. If the critical bit is set in an unsupported 5577 payload header, all implementations MUST reject the messages 5578 containing those payloads. 5580 Every implementation MUST be capable of doing four-message 5581 IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, 5582 one for ESP or AH). Implementations MAY be initiate-only or respond- 5583 only if appropriate for their platform. Every implementation MUST be 5584 capable of responding to an INFORMATIONAL exchange, but a minimal 5585 implementation MAY respond to any request in the INFORMATIONAL 5586 exchange with an empty response (note that within the context of an 5587 IKE SA, an "empty" message consists of an IKE header followed by an 5588 Encrypted payload with no payloads contained in it). A minimal 5589 implementation MAY support the CREATE_CHILD_SA exchange only in so 5590 far as to recognize requests and reject them with a Notify payload of 5591 type NO_ADDITIONAL_SAS. A minimal implementation need not be able to 5592 initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA 5593 expires (based on locally configured values of either lifetime or 5594 octets passed), and implementation MAY either try to renew it with a 5595 CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and 5596 create a new one. If the responder rejects the CREATE_CHILD_SA 5597 request with a NO_ADDITIONAL_SAS notification, the implementation 5598 MUST be capable of instead deleting the old SA and creating a new 5599 one. 5601 Implementations are not required to support requesting temporary IP 5602 addresses or responding to such requests. If an implementation does 5603 support issuing such requests and its policy requires using temporary 5604 IP addresses, it MUST include a CP payload in the first message in 5605 the IKE_AUTH exchange containing at least a field of type 5606 INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. All other fields are 5607 optional. If an implementation supports responding to such requests, 5608 it MUST parse the CP payload of type CFG_REQUEST in the first message 5609 in the IKE_AUTH exchange and recognize a field of type 5610 INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports leasing 5611 an address of the appropriate type, it MUST return a CP payload of 5612 type CFG_REPLY containing an address of the requested type. The 5613 responder may include any other related attributes. 5615 For an implementation to be called conforming to this specification, 5616 it MUST be possible to configure it to accept the following: 5618 o Public Key Infrastructure using X.509 (PKIX) Certificates 5619 containing and signed by RSA keys of size 1024 or 2048 bits, where 5620 the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or 5621 ID_DER_ASN1_DN. 5623 o Shared key authentication where the ID passed is any of ID_KEY_ID, 5624 ID_FQDN, or ID_RFC822_ADDR. 5626 o Authentication where the responder is authenticated using PKIX 5627 Certificates and the initiator is authenticated using shared key 5628 authentication. 5630 5. Security Considerations 5632 While this protocol is designed to minimize disclosure of 5633 configuration information to unauthenticated peers, some such 5634 disclosure is unavoidable. One peer or the other must identify 5635 itself first and prove its identity first. To avoid probing, the 5636 initiator of an exchange is required to identify itself first, and 5637 usually is required to authenticate itself first. The initiator can, 5638 however, learn that the responder supports IKE and what cryptographic 5639 protocols it supports. The responder (or someone impersonating the 5640 responder) can probe the initiator not only for its identity, but 5641 using CERTREQ payloads may be able to determine what certificates the 5642 initiator is willing to use. 5644 Use of EAP authentication changes the probing possibilities somewhat. 5645 When EAP authentication is used, the responder proves its identity 5646 before the initiator does, so an initiator that knew the name of a 5647 valid initiator could probe the responder for both its name and 5648 certificates. 5650 Repeated rekeying using CREATE_CHILD_SA without additional Diffie- 5651 Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a 5652 single key. Implementers should take note of this fact and set a 5653 limit on CREATE_CHILD_SA exchanges between exponentiations. This 5654 document does not prescribe such a limit. 5656 The strength of a key derived from a Diffie-Hellman exchange using 5657 any of the groups defined here depends on the inherent strength of 5658 the group, the size of the exponent used, and the entropy provided by 5659 the random number generator used. Due to these inputs, it is 5660 difficult to determine the strength of a key for any of the defined 5661 groups. Diffie-Hellman group number two, when used with a strong 5662 random number generator and an exponent no less than 200 bits, is 5663 common for use with 3DES. Group five provides greater security than 5664 group two. Group one is for historic purposes only and does not 5665 provide sufficient strength except for use with DES, which is also 5666 for historic use only. Implementations should make note of these 5667 estimates when establishing policy and negotiating security 5668 parameters. 5670 Note that these limitations are on the Diffie-Hellman groups 5671 themselves. There is nothing in IKE that prohibits using stronger 5672 groups nor is there anything that will dilute the strength obtained 5673 from stronger groups (limited by the strength of the other algorithms 5674 negotiated including the PRF). In fact, the extensible framework of 5675 IKE encourages the definition of more groups; use of elliptic curve 5676 groups may greatly increase strength using much smaller numbers. 5678 It is assumed that all Diffie-Hellman exponents are erased from 5679 memory after use. 5681 The IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator 5682 has been authenticated. As a result, an implementation of this 5683 protocol needs to be completely robust when deployed on any insecure 5684 network. Implementation vulnerabilities, particularly DoS attacks, 5685 can be exploited by unauthenticated peers. This issue is 5686 particularly worrisome because of the unlimited number of messages in 5687 EAP-based authentication. 5689 The strength of all keys is limited by the size of the output of the 5690 negotiated PRF. For this reason, a PRF whose output is less than 128 5691 bits (e.g., 3DES-CBC) MUST NOT be used with this protocol. 5693 The security of this protocol is critically dependent on the 5694 randomness of the randomly chosen parameters. These should be 5695 generated by a strong random or properly seeded pseudorandom source 5696 (see [RANDOMNESS]). Implementers should take care to ensure that use 5697 of random numbers for both keys and nonces is engineered in a fashion 5698 that does not undermine the security of the keys. 5700 For information on the rationale of many of the cryptographic design 5701 choices in this protocol, see [SIGMA] and [SKEME]. Though the 5702 security of negotiated Child SAs does not depend on the strength of 5703 the encryption and integrity protection negotiated in the IKE SA, 5704 implementations MUST NOT negotiate NONE as the IKE integrity 5705 protection algorithm or ENCR_NULL as the IKE encryption algorithm. 5707 When using pre-shared keys, a critical consideration is how to assure 5708 the randomness of these secrets. The strongest practice is to ensure 5709 that any pre-shared key contain as much randomness as the strongest 5710 key being negotiated. Deriving a shared secret from a password, 5711 name, or other low-entropy source is not secure. These sources are 5712 subject to dictionary and social-engineering attacks, among others. 5714 The NAT_DETECTION_*_IP notifications contain a hash of the addresses 5715 and ports in an attempt to hide internal IP addresses behind a NAT. 5716 Since the IPv4 address space is only 32 bits, and it is usually very 5717 sparse, it would be possible for an attacker to find out the internal 5718 address used behind the NAT box by trying all possible IP addresses 5719 and trying to find the matching hash. The port numbers are normally 5720 fixed to 500, and the SPIs can be extracted from the packet. This 5721 reduces the number of hash calculations to 2^32. With an educated 5722 guess of the use of private address space, the number of hash 5723 calculations is much smaller. Designers should therefore not assume 5724 that use of IKE will not leak internal address information. 5726 When using an EAP authentication method that does not generate a 5727 shared key for protecting a subsequent AUTH payload, certain man-in- 5728 the-middle and server-impersonation attacks are possible [EAPMITM]. 5729 These vulnerabilities occur when EAP is also used in protocols that 5730 are not protected with a secure tunnel. Since EAP is a general- 5731 purpose authentication protocol, which is often used to provide 5732 single-signon facilities, a deployed IPsec solution that relies on an 5733 EAP authentication method that does not generate a shared key (also 5734 known as a non-key-generating EAP method) can become compromised due 5735 to the deployment of an entirely unrelated application that also 5736 happens to use the same non-key-generating EAP method, but in an 5737 unprotected fashion. Note that this vulnerability is not limited to 5738 just EAP, but can occur in other scenarios where an authentication 5739 infrastructure is reused. For example, if the EAP mechanism used by 5740 IKEv2 utilizes a token authenticator, a man-in-the-middle attacker 5741 could impersonate the web server, intercept the token authentication 5742 exchange, and use it to initiate an IKEv2 connection. For this 5743 reason, use of non-key-generating EAP methods SHOULD be avoided where 5744 possible. Where they are used, it is extremely important that all 5745 usages of these EAP methods SHOULD utilize a protected tunnel, where 5746 the initiator validates the responder's certificate before initiating 5747 the EAP authentication. Implementers should describe the 5748 vulnerabilities of using non-key-generating EAP methods in the 5749 documentation of their implementations so that the administrators 5750 deploying IPsec solutions are aware of these dangers. 5752 An implementation using EAP MUST also use a public-key-based 5753 authentication of the server to the client before the EAP 5754 authentication begins, even if the EAP method offers mutual 5755 authentication. This avoids having additional IKEv2 protocol 5756 variations and protects the EAP data from active attackers. 5758 If the messages of IKEv2 are long enough that IP-level fragmentation 5759 is necessary, it is possible that attackers could prevent the 5760 exchange from completing by exhausting the reassembly buffers. The 5761 chances of this can be minimized by using the Hash and URL encodings 5762 instead of sending certificates (see Section 3.6). Additional 5763 mitigations are discussed in [DOSUDPPROT]. 5765 Admission control is critical to the security of the protocol. For 5766 example, trust anchors used for identifying IKE peers should probably 5767 be different than those used for other forms of trust, such as those 5768 used to identify public web servers. Moreover, although IKE provides 5769 a great deal of leeway in defining the security policy for a trusted 5770 peer's identity, credentials, and the correlation between them, 5771 having such security policy defined explicitly is essential to a 5772 secure implementation. 5774 5.1. Traffic Selector Authorization 5776 IKEv2 relies on information in the Peer Authorization Database (PAD) 5777 when determining what kind of Child SAs a peer is allowed to create. 5778 This process is described in Section 4.4.3 of [IPSECARCH]. When a 5779 peer requests the creation of an Child SA with some Traffic 5780 Selectors, the PAD must contain "Child SA Authorization Data" linking 5781 the identity authenticated by IKEv2 and the addresses permitted for 5782 Traffic Selectors. 5784 For example, the PAD might be configured so that authenticated 5785 identity "sgw23.example.com" is allowed to create Child SAs for 5786 192.0.2.0/24, meaning this security gateway is a valid 5787 "representative" for these addresses. Host-to-host IPsec requires 5788 similar entries, linking, for example, "fooserver4.example.com" with 5789 198.51.100.66/32, meaning this identity is a valid "owner" or 5790 "representative" of the address in question. 5792 As noted in [IPSECARCH], "It is necessary to impose these constraints 5793 on creation of child SAs to prevent an authenticated peer from 5794 spoofing IDs associated with other, legitimate peers". In the 5795 example given above, a correct configuration of the PAD prevents 5796 sgw23 from creating Child SAs with address 198.51.100.66, and 5797 prevents fooserver4 from creating Child SAs with addresses from 5798 192.0.2.0/24. 5800 It is important to note that simply sending IKEv2 packets using some 5801 particular address does not imply a permission to create Child SAs 5802 with that address in the Traffic Selectors. For example, even if 5803 sgw23 would be able to spoof its IP address as 198.51.100.66, it 5804 could not create Child SAs matching fooserver4's traffic. 5806 The IKEv2 specification does not specify how exactly IP address 5807 assignment using Configuration payloads interacts with the PAD. Our 5808 interpretation is that when a security gateway assigns an address 5809 using Configuration payloads, it also creates a temporary PAD entry 5810 linking the authenticated peer identity and the newly allocated inner 5811 address. 5813 It has been recognized that configuring the PAD correctly may be 5814 difficult in some environments. For instance, if IPsec is used 5815 between a pair of hosts whose addresses are allocated dynamically 5816 using DHCP, it is extremely difficult to ensure that the PAD 5817 specifies the correct "owner" for each IP address. This would 5818 require a mechanism to securely convey address assignments from the 5819 DHCP server, and link them to identities authenticated using IKEv2. 5821 Due to this limitation, some vendors have been known to configure 5822 their PADs to allow an authenticated peer to create Child SAs with 5823 Traffic Selectors containing the same address that was used for the 5824 IKEv2 packets. In environments where IP spoofing is possible (i.e., 5825 almost everywhere) this essentially allows any peer to create Child 5826 SAs with any Traffic Selectors. This is not an appropriate or secure 5827 configuration in most circumstances. See [H2HIPSEC] for an extensive 5828 discussion about this issue, and the limitations of host-to-host 5829 IPsec in general. 5831 6. IANA Considerations 5833 [IKEV2] defined many field types and values. IANA has already 5834 registered those types and values in [IKEV2IANA], so they are not 5835 listed here again. 5837 One item has been deprecated from the IKEv2 Certificate Encodings 5838 table: "Raw RSA Key". 5840 IANA has updated all references to RFC 5996 to point to this 5841 document. 5843 7. Acknowledgements 5845 Many individuals in the IPsecME Working Group were very helpful in 5846 contributing ideas and text for this document, as well as in 5847 reviewing the clarifications suggested by others. 5849 The acknowledgements from the IKEv2 document were: 5851 This document is a collaborative effort of the entire IPsec WG. If 5852 there were no limit to the number of authors that could appear on an 5853 RFC, the following, in alphabetical order, would have been listed: 5854 Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt 5855 Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John 5856 Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero 5857 Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer 5858 Reingold, and Michael Richardson. Many other people contributed to 5859 the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, 5860 each of which has its own list of authors. Hugh Daniel suggested the 5861 feature of having the initiator, in message 3, specify a name for the 5862 responder, and gave the feature the cute name "You Tarzan, Me Jane". 5863 David Faucher and Valery Smyslov helped refine the design of the 5864 Traffic Selector negotiation. 5866 8. References 5868 8.1. Normative References 5870 [ADDGROUP] 5871 Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 5872 Diffie-Hellman groups for Internet Key Exchange (IKE)", 5873 RFC 3526, May 2003. 5875 [ADDRIPV6] 5876 Hinden, R. and S. Deering, "IP Version 6 Addressing 5877 Architecture", RFC 4291, February 2006. 5879 [AEAD] Black, D. and D. McGrew, "Using Authenticated Encryption 5880 Algorithms with the Encrypted Payload of the Internet Key 5881 Exchange version 2 (IKEv2) Protocol", RFC 5282, 5882 August 2008. 5884 [AESCMACPRF128] 5885 Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 5886 Advanced Encryption Standard-Cipher-based Message 5887 Authentication Code-Pseudo-Random Function-128 (AES-CMAC- 5888 PRF-128) Algorithm for the Internet Key Exchange Protocol 5889 (IKE)", RFC 4615, August 2006. 5891 [AESXCBCPRF128] 5892 Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the 5893 Internet Key Exchange Protocol (IKE)", RFC 4434, 5894 February 2006. 5896 [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 5897 Levkowetz, "Extensible Authentication Protocol (EAP)", 5898 RFC 3748, June 2004. 5900 [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 5901 of Explicit Congestion Notification (ECN) to IP", 5902 RFC 3168, September 2001. 5904 [ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 5905 Algorithms", RFC 2451, November 1998. 5907 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 5908 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 5909 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 5911 [IKEV2IANA] 5912 "Internet Key Exchange Version 2 (IKEv2) Parameters", 5913 . 5915 [IPSECARCH] 5916 Kent, S. and K. Seo, "Security Architecture for the 5917 Internet Protocol", RFC 4301, December 2005. 5919 [MUSTSHOULD] 5920 Bradner, S., "Key words for use in RFCs to Indicate 5921 Requirement Levels", BCP 14, RFC 2119, March 1997. 5923 [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 5924 Standards (PKCS) #1: RSA Cryptography Specifications 5925 Version 2.1", RFC 3447, February 2003. 5927 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 5928 Housley, R., and W. Polk, "Internet X.509 Public Key 5929 Infrastructure Certificate and Certificate Revocation List 5930 (CRL) Profile", RFC 5280, May 2008. 5932 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the 5933 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, 5934 December 2005. 5936 [UDPENCAPS] 5937 Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 5938 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 5939 RFC 3948, January 2005. 5941 [URLS] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 5942 Resource Identifier (URI): Generic Syntax", STD 66, 5943 RFC 3986, January 2005. 5945 8.2. Informative References 5947 [AH] Kent, S., "IP Authentication Header", RFC 4302, 5948 December 2005. 5950 [ARCHGUIDEPHIL] 5951 Bush, R. and D. Meyer, "Some Internet Architectural 5952 Guidelines and Philosophy", RFC 3439, December 2002. 5954 [ARCHPRINC] 5955 Carpenter, B., "Architectural Principles of the Internet", 5956 RFC 1958, June 1996. 5958 [Clarif] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 5959 Implementation Guidelines", RFC 4718, October 2006. 5961 [DES] American National Standards Institute, "American National 5962 Standard for Information Systems-Data Link Encryption", 5963 ANSI X3.106, 1983. 5965 [DH] Diffie, W. and M. Hellman, "New Directions in 5966 Cryptography", IEEE Transactions on Information Theory, 5967 V.IT-22 n. 6, June 1977. 5969 [DIFFSERVARCH] 5970 Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 5971 and W. Weiss, "An Architecture for Differentiated 5972 Services", RFC 2475, December 1998. 5974 [DIFFSERVFIELD] 5975 Nichols, K., Blake, S., Baker, F., and D. Black, 5976 "Definition of the Differentiated Services Field (DS 5977 Field) in the IPv4 and IPv6 Headers", RFC 2474, 5978 December 1998. 5980 [DIFFTUNNEL] 5981 Black, D., "Differentiated Services and Tunnels", 5982 RFC 2983, October 2000. 5984 [DOI] Piper, D., "The Internet IP Security Domain of 5985 Interpretation for ISAKMP", RFC 2407, November 1998. 5987 [DOSUDPPROT] 5988 C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection 5989 for UDP-based protocols", ACM Conference on Computer and 5990 Communications Security, October 2003. 5992 [DSS] National Institute of Standards and Technology, U.S. 5993 Department of Commerce, "Digital Signature Standard", 5994 Draft FIPS 186-3, June 2008. 5996 [EAI] Yang, A., Steele, S., and N. Freed, "Internationalized 5997 Email Headers", RFC 6532, February 2012. 5999 [EAP-IANA] 6000 "Extensible Authentication Protocol (EAP) Registry: Method 6001 Types", . 6003 [EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, "Man-in-the-Middle in 6004 Tunneled Authentication Protocols", November 2002, 6005 . 6007 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 6008 RFC 4303, December 2005. 6010 [EXCHANGEANALYSIS] 6011 R. Perlman and C. Kaufman, "Analysis of the IPsec key 6012 exchange Standard", WET-ICE Security Conference, MIT, 6013 2001, 6014 . 6016 [H2HIPSEC] 6017 Aura, T., Roe, M., and A. Mohammed, "Experiences with 6018 Host-to-Host IPsec", 13th International Workshop on 6019 Security Protocols, Cambridge, UK, April 2005. 6021 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 6022 Hashing for Message Authentication", RFC 2104, 6023 February 1997. 6025 [IDEA] X. Lai, "On the Design and Security of Block Ciphers", ETH 6026 Series in Information Processing, v. 1, Konstanz: Hartung- 6027 Gorre Verlag, 1992. 6029 [IDNA] Klensin, J., "Internationalized Domain Names for 6030 Applications (IDNA): Definitions and Document Framework", 6031 RFC 5890, August 2010. 6033 [IKEV1] Harkins, D. and D. Carrel, "The Internet Key Exchange 6034 (IKE)", RFC 2409, November 1998. 6036 [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 6037 RFC 4306, December 2005. 6039 [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, 6040 September 1981. 6042 [IP-COMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP 6043 Payload Compression Protocol (IPComp)", RFC 3173, 6044 September 2001. 6046 [IPSECARCH-OLD] 6047 Kent, S. and R. Atkinson, "Security Architecture for the 6048 Internet Protocol", RFC 2401, November 1998. 6050 [IPV6CONFIG] 6051 Eronen, P., Laganier, J., and C. Madson, "IPv6 6052 Configuration in Internet Key Exchange Protocol Version 2 6053 (IKEv2)", RFC 5739, February 2010. 6055 [ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet 6056 Security Association and Key Management Protocol 6057 (ISAKMP)", RFC 2408, November 1998. 6059 [MAILFORMAT] 6060 Resnick, P., Ed., "Internet Message Format", RFC 5322, 6061 October 2008. 6063 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 6064 April 1992. 6066 [MIPV6] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 6067 in IPv6", RFC 6275, July 2011. 6069 [MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery 6070 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 6072 [MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 6073 (MOBIKE)", RFC 4555, June 2006. 6075 [MODES] National Institute of Standards and Technology, U.S. 6076 Department of Commerce, "Recommendation for Block Cipher 6077 Modes of Operation", SP 800-38A, 2001. 6079 [NAI] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 6080 Network Access Identifier", RFC 4282, December 2005. 6082 [NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 6083 (NAT) Compatibility Requirements", RFC 3715, March 2004. 6085 [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", 6086 RFC 2412, November 1998. 6088 [PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 6089 Management API, Version 2", RFC 2367, July 1998. 6091 [PHOTURIS] 6092 Karn, P. and W. Simpson, "Photuris: Session-Key Management 6093 Protocol", RFC 2522, March 1999. 6095 [RANDOMNESS] 6096 Eastlake, D., Schiller, J., and S. Crocker, "Randomness 6097 Requirements for Security", BCP 106, RFC 4086, June 2005. 6099 [REAUTH] Nir, Y., "Repeated Authentication in Internet Key Exchange 6100 (IKEv2) Protocol", RFC 4478, April 2006. 6102 [REUSE] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In 6103 Diffie-Hellman Key Agreement Protocols", December 2008, < 6104 http://www.cacr.math.uwaterloo.ca/techreports/2008/ 6105 cacr2008-24.pdf>. 6107 [RFC4945] Korver, B., "The Internet IP Security PKI Profile of 6108 IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007. 6110 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 6111 "Internet Key Exchange Protocol Version 2 (IKEv2)", 6112 RFC 5996, September 2010. 6114 [RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman 6115 Tests for the Internet Key Exchange Protocol Version 2 6116 (IKEv2)", RFC 6989, July 2013. 6118 [ROHCV2] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. 6119 Bormann, "IKEv2 Extensions to Support Robust Header 6120 Compression over IPsec", RFC 5857, May 2010. 6122 [SHA] National Institute of Standards and Technology, U.S. 6123 Department of Commerce, "Secure Hash Standard", 6124 FIPS 180-3, October 2008. 6126 [SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to 6127 Authenticated Diffie-Hellman and its Use in the IKE 6128 Protocols", Advances in Cryptography - CRYPTO 2003 6129 Proceedings LNCS 2729, 2003, . 6133 [SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange 6134 Mechanism for Internet", IEEE Proceedings of the 1996 6135 Symposium on Network and Distributed Systems Security , 6136 1996. 6138 [TRANSPARENCY] 6139 Carpenter, B., "Internet Transparency", RFC 2775, 6140 February 2000. 6142 Appendix A. Summary of Changes from IKEv1 6144 The goals of this revision to IKE are: 6146 1. To define the entire IKE protocol in a single document, 6147 replacing RFCs 2407, 2408, and 2409 and incorporating subsequent 6148 changes to support NAT Traversal, Extensible Authentication, and 6149 Remote Address acquisition; 6151 2. To simplify IKE by replacing the eight different initial 6152 exchanges with a single four-message exchange (with changes in 6153 authentication mechanisms affecting only a single AUTH payload 6154 rather than restructuring the entire exchange) see 6156 [EXCHANGEANALYSIS]; 6158 3. To remove the Domain of Interpretation (DOI), Situation (SIT), 6159 and Labeled Domain Identifier fields, and the Commit and 6160 Authentication only bits; 6162 4. To decrease IKE's latency in the common case by making the 6163 initial exchange be 2 round trips (4 messages), and allowing the 6164 ability to piggyback setup of a Child SA on that exchange; 6166 5. To replace the cryptographic syntax for protecting the IKE 6167 messages themselves with one based closely on ESP to simplify 6168 implementation and security analysis; 6170 6. To reduce the number of possible error states by making the 6171 protocol reliable (all messages are acknowledged) and sequenced. 6172 This allows shortening CREATE_CHILD_SA exchanges from 3 messages 6173 to 2; 6175 7. To increase robustness by allowing the responder to not do 6176 significant processing until it receives a message proving that 6177 the initiator can receive messages at its claimed IP address; 6179 8. To fix cryptographic weaknesses such as the problem with 6180 symmetries in hashes used for authentication (documented by Tero 6181 Kivinen); 6183 9. To specify Traffic Selectors in their own payloads type rather 6184 than overloading ID payloads, and making more flexible the 6185 Traffic Selectors that may be specified; 6187 10. To specify required behavior under certain error conditions or 6188 when data that is not understood is received in order to make it 6189 easier to make future revisions in a way that does not break 6190 backward compatibility; 6192 11. To simplify and clarify how shared state is maintained in the 6193 presence of network failures and DoS attacks; and 6195 12. To maintain existing syntax and magic numbers to the extent 6196 possible to make it likely that implementations of IKEv1 can be 6197 enhanced to support IKEv2 with minimum effort. 6199 Appendix B. Diffie-Hellman Groups 6201 There are two Diffie-Hellman groups defined here for use in IKE. 6202 These groups were generated by Richard Schroeppel at the University 6203 of Arizona. Properties of these primes are described in [OAKLEY]. 6205 The strength supplied by group 1 may not be sufficient for typical 6206 uses and is here for historic reasons. 6208 Additional Diffie-Hellman groups have been defined in [ADDGROUP]. 6210 B.1. Group 1 - 768-bit MODP 6212 This group is assigned ID 1 (one). 6214 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 6215 Its hexadecimal value is: 6217 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 6218 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 6219 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 6220 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF 6222 The generator is 2. 6224 B.2. Group 2 - 1024-bit MODP 6226 This group is assigned ID 2 (two). 6228 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 6229 Its hexadecimal value is: 6231 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 6232 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 6233 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 6234 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 6235 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 6236 FFFFFFFF FFFFFFFF 6238 The generator is 2. 6240 Appendix C. Exchanges and Payloads 6242 This appendix contains a short summary of the IKEv2 exchanges, and 6243 what payloads can appear in which message. This appendix is purely 6244 informative; if it disagrees with the body of this document, the 6245 other text is considered correct. 6247 Vendor ID (V) payloads may be included in any place in any message. 6248 This sequence here shows what are the most logical places for them. 6250 C.1. IKE_SA_INIT Exchange 6252 request --> [N(COOKIE)], 6253 SA, KE, Ni, 6254 [N(NAT_DETECTION_SOURCE_IP)+, 6255 N(NAT_DETECTION_DESTINATION_IP)], 6256 [V+][N+] 6258 normal response <-- SA, KE, Nr, 6259 (no cookie) [N(NAT_DETECTION_SOURCE_IP), 6260 N(NAT_DETECTION_DESTINATION_IP)], 6261 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 6262 [V+][N+] 6264 cookie response <-- N(COOKIE), 6265 [V+][N+] 6267 different Diffie- <-- N(INVALID_KE_PAYLOAD), 6268 Hellman group [V+][N+] 6269 wanted 6271 C.2. IKE_AUTH Exchange without EAP 6273 request --> IDi, [CERT+], 6274 [N(INITIAL_CONTACT)], 6275 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 6276 [IDr], 6277 AUTH, 6278 [CP(CFG_REQUEST)], 6279 [N(IPCOMP_SUPPORTED)+], 6280 [N(USE_TRANSPORT_MODE)], 6281 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 6282 [N(NON_FIRST_FRAGMENTS_ALSO)], 6283 SA, TSi, TSr, 6284 [V+][N+] 6286 response <-- IDr, [CERT+], 6287 AUTH, 6288 [CP(CFG_REPLY)], 6289 [N(IPCOMP_SUPPORTED)], 6290 [N(USE_TRANSPORT_MODE)], 6291 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 6292 [N(NON_FIRST_FRAGMENTS_ALSO)], 6293 SA, TSi, TSr, 6294 [N(ADDITIONAL_TS_POSSIBLE)], 6295 [V+][N+] 6297 error in Child SA <-- IDr, [CERT+], 6298 creation AUTH, 6299 N(error), 6300 [V+][N+] 6302 C.3. IKE_AUTH Exchange with EAP 6304 first request --> IDi, 6305 [N(INITIAL_CONTACT)], 6306 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 6307 [IDr], 6308 [CP(CFG_REQUEST)], 6309 [N(IPCOMP_SUPPORTED)+], 6310 [N(USE_TRANSPORT_MODE)], 6311 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 6312 [N(NON_FIRST_FRAGMENTS_ALSO)], 6313 SA, TSi, TSr, 6314 [V+][N+] 6316 first response <-- IDr, [CERT+], AUTH, 6317 EAP, 6318 [V+][N+] 6320 / --> EAP 6321 repeat 1..N times | 6322 \ <-- EAP 6324 last request --> AUTH 6326 last response <-- AUTH, 6327 [CP(CFG_REPLY)], 6328 [N(IPCOMP_SUPPORTED)], 6329 [N(USE_TRANSPORT_MODE)], 6330 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 6331 [N(NON_FIRST_FRAGMENTS_ALSO)], 6332 SA, TSi, TSr, 6333 [N(ADDITIONAL_TS_POSSIBLE)], 6334 [V+][N+] 6336 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying Child SAs 6338 request --> [N(REKEY_SA)], 6339 [CP(CFG_REQUEST)], 6340 [N(IPCOMP_SUPPORTED)+], 6341 [N(USE_TRANSPORT_MODE)], 6342 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 6343 [N(NON_FIRST_FRAGMENTS_ALSO)], 6344 SA, Ni, [KEi], TSi, TSr 6345 [V+][N+] 6347 normal <-- [CP(CFG_REPLY)], 6348 response [N(IPCOMP_SUPPORTED)], 6349 [N(USE_TRANSPORT_MODE)], 6350 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 6351 [N(NON_FIRST_FRAGMENTS_ALSO)], 6352 SA, Nr, [KEr], TSi, TSr, 6353 [N(ADDITIONAL_TS_POSSIBLE)] 6354 [V+][N+] 6356 error case <-- N(error) 6358 different Diffie- <-- N(INVALID_KE_PAYLOAD), 6359 Hellman group [V+][N+] 6360 wanted 6362 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA 6364 request --> SA, Ni, KEi 6365 [V+][N+] 6367 response <-- SA, Nr, KEr 6368 [V+][N+] 6370 C.6. INFORMATIONAL Exchange 6372 request --> [N+], 6373 [D+], 6374 [CP(CFG_REQUEST)] 6376 response <-- [N+], 6377 [D+], 6378 [CP(CFG_REPLY)] 6380 Authors' Addresses 6382 Charlie Kaufman 6383 Microsoft 6384 1 Microsoft Way 6385 Redmond, WA 98052 6386 US 6388 Phone: 1-425-707-3335 6389 EMail: charliek@microsoft.com 6391 Paul Hoffman 6392 VPN Consortium 6393 127 Segre Place 6394 Santa Cruz, CA 95060 6395 US 6397 Phone: 1-831-426-9827 6398 EMail: paul.hoffman@vpnc.org 6400 Yoav Nir 6401 Check Point Software Technologies Ltd. 6402 5 Hasolelim St. 6403 Tel Aviv 6789735 6404 Israel 6406 EMail: ynir@checkpoint.com 6408 Pasi Eronen 6409 Independent 6411 EMail: pe@iki.fi 6413 Tero Kivinen 6414 INSIDE Secure 6415 Eerikinkatu 28 6416 HELSINKI FI-00180 6417 FI 6419 EMail: kivinen@iki.fi