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