idnits 2.17.1 draft-ietf-ipsecme-ikev2bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 23 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC4306, but the abstract doesn't seem to directly say this. It does mention RFC4306 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC4718, but the abstract doesn't seem to directly say this. It does mention RFC4718 though, so this could be OK. -- The abstract seems to indicate that this document updates RFC4306, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: ID_FQDN 2 A fully-qualified domain name string. An example of a ID_FQDN is, "example.com". The string MUST not contain any terminators (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; for an "internationalized domain name", the syntax is as defined in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net". == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: ID_RFC822_ADDR 3 A fully-qualified RFC822 email address string, An example of a ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not contain any terminators. Because of [EAI], implementations would be wise to treat this field as UTF-8 encoded text, not as pure ASCII. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 24, 2009) is 5473 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CERTREQ' is mentioned on line 2242, but not defined == Missing Reference: 'KEi' is mentioned on line 5830, but not defined == Missing Reference: 'KEr' is mentioned on line 6199, but not defined == Missing Reference: 'CP' is mentioned on line 749, but not defined -- Looks like a reference, but probably isn't: '0' on line 3851 -- Looks like a reference, but probably isn't: '1' on line 3852 == Missing Reference: 'IDr' is mentioned on line 5774, but not defined ** Obsolete normative reference: RFC 3447 (ref. 'PKCS1') (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 3280 (ref. 'PKIX') (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 4718 (ref. 'Clarif') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 2407 (ref. 'DOI') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 5335 (ref. 'EAI') (Obsoleted by RFC 6532) -- Obsolete informational reference (is this intentional?): RFC 3490 (ref. 'IDNA') (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. 'IKEV1') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. 'IKEV2') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'IPSECARCH-OLD') (Obsoleted by RFC 4301) -- Duplicate reference: RFC4291, mentioned in 'IPV6ADDR', was also mentioned in 'ADDRIPV6'. -- Obsolete informational reference (is this intentional?): RFC 2408 (ref. 'ISAKMP') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2822 (ref. 'MAILFORMAT') (Obsoleted by RFC 5322) -- 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) -- Obsolete informational reference (is this intentional?): RFC 2138 (ref. 'RADIUS') (Obsoleted by RFC 2865) Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Kaufman 3 Internet-Draft Microsoft 4 Obsoletes: 4306, 4718 P. Hoffman 5 (if approved) VPN Consortium 6 Intended status: Standards Track Y. Nir 7 Expires: October 26, 2009 Check Point 8 P. Eronen 9 Nokia 10 April 24, 2009 12 Internet Key Exchange Protocol: IKEv2 13 draft-ietf-ipsecme-ikev2bis-03 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. This document may contain material 19 from IETF Documents or IETF Contributions published or made publicly 20 available before November 10, 2008. The person(s) controlling the 21 copyright in some of this material may not have granted the IETF 22 Trust the right to allow modifications of such material outside the 23 IETF Standards Process. Without obtaining an adequate license from 24 the person(s) controlling the copyright in such materials, this 25 document may not be modified outside the IETF Standards Process, and 26 derivative works of it may not be created outside the IETF Standards 27 Process, except to format it for publication as an RFC or to 28 translate it into languages other than English. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 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 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on October 26, 2009. 48 Copyright Notice 49 Copyright (c) 2009 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents in effect on the date of 54 publication of this document (http://trustee.ietf.org/license-info). 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. 58 Abstract 60 This document describes version 2 of the Internet Key Exchange (IKE) 61 protocol. IKE is a component of IPsec used for performing mutual 62 authentication and establishing and maintaining security associations 63 (SAs). It replaces and updates RFC 4306, and includes all of the 64 clarifications from RFC 4718. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 69 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 7 70 1.1.1. Security Gateway to Security Gateway Tunnel Mode . . 7 71 1.1.2. Endpoint-to-Endpoint Transport Mode . . . . . . . . . 8 72 1.1.3. Endpoint to Security Gateway Tunnel Mode . . . . . . 9 73 1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 9 74 1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 10 75 1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 13 76 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA 77 Exchange . . . . . . . . . . . . . . . . . . . . . . 14 78 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange . 16 79 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA 80 Exchange . . . . . . . . . . . . . . . . . . . . . . 16 81 1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 17 82 1.4.1. Deleting an SA with INFORMATIONAL Exchanges . . . . . 18 83 1.5. Informational Messages outside of an IKE SA . . . . . . . 18 84 1.6. Requirements Terminology . . . . . . . . . . . . . . . . 19 85 1.7. Differences Between RFC 4306 and This Document . . . . . 20 86 2. IKE Protocol Details and Variations . . . . . . . . . . . . . 21 87 2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 22 88 2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 23 89 2.3. Window Size for Overlapping Requests . . . . . . . . . . 24 90 2.4. State Synchronization and Connection Timeouts . . . . . . 25 91 2.5. Version Numbers and Forward Compatibility . . . . . . . . 27 92 2.6. IKE SA SPIs and Cookies . . . . . . . . . . . . . . . . . 29 93 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 32 94 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 32 95 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 34 96 2.8.1. Simultaneous Child SA rekeying . . . . . . . . . . . 36 97 2.8.2. Simultaneous IKE SA Rekeying . . . . . . . . . . . . 38 98 2.8.3. Rekeying the IKE SA Versus Reauthentication . . . . . 39 99 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 39 100 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 42 101 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 43 102 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 43 103 2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 43 104 2.13. Generating Keying Material . . . . . . . . . . . . . . . 44 105 2.14. Generating Keying Material for the IKE SA . . . . . . . . 45 106 2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 46 107 2.16. Extensible Authentication Protocol Methods . . . . . . . 48 108 2.17. Generating Keying Material for Child SAs . . . . . . . . 50 109 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . . 51 110 2.19. Requesting an Internal Address on a Remote Network . . . 52 111 2.19.1. Configuration Payloads . . . . . . . . . . . . . . . 53 112 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 55 113 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 55 114 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 56 115 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 58 116 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 61 117 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 62 118 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 62 119 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 65 120 3.3. Security Association Payload . . . . . . . . . . . . . . 67 121 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 69 122 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 71 123 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 74 124 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 74 125 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 75 126 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 77 127 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 78 128 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 79 129 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 81 130 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 83 131 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 85 132 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 87 133 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 87 134 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 88 135 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 91 136 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 93 137 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 94 138 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 95 139 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 97 140 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 99 141 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 100 142 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 103 143 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 105 144 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 106 145 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 106 146 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 108 147 5. Security Considerations . . . . . . . . . . . . . . . . . . . 110 148 5.1. Traffic selector authorization . . . . . . . . . . . . . 113 149 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 114 150 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 114 151 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 115 152 8.1. Normative References . . . . . . . . . . . . . . . . . . 115 153 8.2. Informative References . . . . . . . . . . . . . . . . . 116 154 Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 120 155 Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 121 156 B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 122 157 B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 122 158 Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 122 159 C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 123 160 C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 124 161 C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 125 162 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying 163 Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 126 164 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 126 165 C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 126 166 Appendix D. Significant Changes from RFC 4306 . . . . . . . . . 126 167 Appendix E. Changes Between Internet Draft Versions . . . . . . 127 168 E.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 127 169 E.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 127 170 E.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 129 171 E.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 130 172 E.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 131 173 E.6. Changes from draft -03 to 174 draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 132 175 E.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to 176 draft-ietf-ipsecme-ikev2bis-01 . . . . . . . . . . . . . 133 177 E.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to 178 draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 137 179 E.9. Changes from draft-ietf-ipsecme-ikev2bis-01 to 180 draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 139 181 E.10. Changes from draft-ietf-ipsecme-ikev2bis-02 to 182 draft-ietf-ipsecme-ikev2bis-03 . . . . . . . . . . . . . 140 183 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 140 185 1. Introduction 187 {{ An introduction to the differences between RFC 4306 [IKEV2] and 188 this document is given at the end of Section 1. It is put there 189 (instead of here) to preserve the section numbering of RFC 4306. }} 191 IP Security (IPsec) provides confidentiality, data integrity, access 192 control, and data source authentication to IP datagrams. These 193 services are provided by maintaining shared state between the source 194 and the sink of an IP datagram. This state defines, among other 195 things, the specific services provided to the datagram, which 196 cryptographic algorithms will be used to provide the services, and 197 the keys used as input to the cryptographic algorithms. 199 Establishing this shared state in a manual fashion does not scale 200 well. Therefore, a protocol to establish this state dynamically is 201 needed. This memo describes such a protocol -- the Internet Key 202 Exchange (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI], 203 2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 replaced all of those RFCs. 204 IKEv2 was defined in [IKEV2] (RFC 4306) and was clarified in [Clarif] 205 (RFC 4718). This document replaces and updates RFC 4306 and RFC 206 4718. 208 IKE performs mutual authentication between two parties and 209 establishes an IKE security association (SA) that includes shared 210 secret information that can be used to efficiently establish SAs for 211 Encapsulating Security Payload (ESP) [ESP] or Authentication Header 212 (AH) [AH] and a set of cryptographic algorithms to be used by the SAs 213 to protect the traffic that they carry. In this document, the term 214 "suite" or "cryptographic suite" refers to a complete set of 215 algorithms used to protect an SA. An initiator proposes one or more 216 suites by listing supported algorithms that can be combined into 217 suites in a mix-and-match fashion. IKE can also negotiate use of IP 218 Compression (IPComp) [IP-COMP] in connection with an ESP or AH SA. 219 The SAs for ESP or AH that get set up through that IKE SA we call 220 "Child SAs". 222 All IKE communications consist of pairs of messages: a request and a 223 response. The pair is called an "exchange". We call the first 224 messages establishing an IKE SA IKE_SA_INIT and IKE_AUTH exchanges 225 and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL 226 exchanges. In the common case, there is a single IKE_SA_INIT 227 exchange and a single IKE_AUTH exchange (a total of four messages) to 228 establish the IKE SA and the first Child SA. In exceptional cases, 229 there may be more than one of each of these exchanges. In all cases, 230 all IKE_SA_INIT exchanges MUST complete before any other exchange 231 type, then all IKE_AUTH exchanges MUST complete, and following that 232 any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur 233 in any order. In some scenarios, only a single Child SA is needed 234 between the IPsec endpoints, and therefore there would be no 235 additional exchanges. Subsequent exchanges MAY be used to establish 236 additional Child SAs between the same authenticated pair of endpoints 237 and to perform housekeeping functions. 239 IKE message flow always consists of a request followed by a response. 240 It is the responsibility of the requester to ensure reliability. If 241 the response is not received within a timeout interval, the requester 242 needs to retransmit the request (or abandon the connection). 244 The first request/response of an IKE session (IKE_SA_INIT) negotiates 245 security parameters for the IKE SA, sends nonces, and sends Diffie- 246 Hellman values. 248 The second request/response (IKE_AUTH) transmits identities, proves 249 knowledge of the secrets corresponding to the two identities, and 250 sets up an SA for the first (and often only) AH or ESP Child SA 251 (unless there is failure setting up the AH or ESP Child SA, in which 252 case the IKE SA is still established without IPsec SA). 254 The types of subsequent exchanges are CREATE_CHILD_SA (which creates 255 a Child SA) and INFORMATIONAL (which deletes an SA, reports error 256 conditions, or does other housekeeping). Every request requires a 257 response. An INFORMATIONAL request with no payloads (other than the 258 empty Encrypted payload required by the syntax) is commonly used as a 259 check for liveness. These subsequent exchanges cannot be used until 260 the initial exchanges have completed. 262 In the description that follows, we assume that no errors occur. 263 Modifications to the flow should errors occur are described in 264 Section 2.21. 266 1.1. Usage Scenarios 268 IKE is expected to be used to negotiate ESP or AH SAs in a number of 269 different scenarios, each with its own special requirements. 271 1.1.1. Security Gateway to Security Gateway Tunnel Mode 273 +-+-+-+-+-+ +-+-+-+-+-+ 274 | | IPsec | | 275 Protected |Tunnel | tunnel |Tunnel | Protected 276 Subnet <-->|Endpoint |<---------->|Endpoint |<--> Subnet 277 | | | | 278 +-+-+-+-+-+ +-+-+-+-+-+ 280 Figure 1: Security Gateway to Security Gateway Tunnel 282 In this scenario, neither endpoint of the IP connection implements 283 IPsec, but network nodes between them protect traffic for part of the 284 way. Protection is transparent to the endpoints, and depends on 285 ordinary routing to send packets through the tunnel endpoints for 286 processing. Each endpoint would announce the set of addresses 287 "behind" it, and packets would be sent in tunnel mode where the inner 288 IP header would contain the IP addresses of the actual endpoints. 290 1.1.2. Endpoint-to-Endpoint Transport Mode 292 +-+-+-+-+-+ +-+-+-+-+-+ 293 | | IPsec transport | | 294 |Protected| or tunnel mode SA |Protected| 295 |Endpoint |<---------------------------------------->|Endpoint | 296 | | | | 297 +-+-+-+-+-+ +-+-+-+-+-+ 299 Figure 2: Endpoint to Endpoint 301 In this scenario, both endpoints of the IP connection implement 302 IPsec, as required of hosts in [IPSECARCH]. Transport mode will 303 commonly be used with no inner IP header. A single pair of addresses 304 will be negotiated for packets to be protected by this SA. These 305 endpoints MAY implement application layer access controls based on 306 the IPsec authenticated identities of the participants. This 307 scenario enables the end-to-end security that has been a guiding 308 principle for the Internet since [ARCHPRINC], [TRANSPARENCY], and a 309 method of limiting the inherent problems with complexity in networks 310 noted by [ARCHGUIDEPHIL]. Although this scenario may not be fully 311 applicable to the IPv4 Internet, it has been deployed successfully in 312 specific scenarios within intranets using IKEv1. It should be more 313 broadly enabled during the transition to IPv6 and with the adoption 314 of IKEv2. 316 It is possible in this scenario that one or both of the protected 317 endpoints will be behind a network address translation (NAT) node, in 318 which case the tunneled packets will have to be UDP encapsulated so 319 that port numbers in the UDP headers can be used to identify 320 individual endpoints "behind" the NAT (see Section 2.23). 322 1.1.3. Endpoint to Security Gateway Tunnel Mode 324 +-+-+-+-+-+ +-+-+-+-+-+ 325 | | IPsec | | Protected 326 |Protected| tunnel |Tunnel | Subnet 327 |Endpoint |<------------------------>|Endpoint |<--- and/or 328 | | | | Internet 329 +-+-+-+-+-+ +-+-+-+-+-+ 331 Figure 3: Endpoint to Security Gateway Tunnel 333 In this scenario, a protected endpoint (typically a portable roaming 334 computer) connects back to its corporate network through an IPsec- 335 protected tunnel. It might use this tunnel only to access 336 information on the corporate network, or it might tunnel all of its 337 traffic back through the corporate network in order to take advantage 338 of protection provided by a corporate firewall against Internet-based 339 attacks. In either case, the protected endpoint will want an IP 340 address associated with the security gateway so that packets returned 341 to it will go to the security gateway and be tunneled back. This IP 342 address may be static or may be dynamically allocated by the security 343 gateway. {{ Clarif-6.1 }} In support of the latter case, IKEv2 344 includes a mechanism (namely, configuration payloads) for the 345 initiator to request an IP address owned by the security gateway for 346 use for the duration of its SA. 348 In this scenario, packets will use tunnel mode. On each packet from 349 the protected endpoint, the outer IP header will contain the source 350 IP address associated with its current location (i.e., the address 351 that will get traffic routed to the endpoint directly), while the 352 inner IP header will contain the source IP address assigned by the 353 security gateway (i.e., the address that will get traffic routed to 354 the security gateway for forwarding to the endpoint). The outer 355 destination address will always be that of the security gateway, 356 while the inner destination address will be the ultimate destination 357 for the packet. 359 In this scenario, it is possible that the protected endpoint will be 360 behind a NAT. In that case, the IP address as seen by the security 361 gateway will not be the same as the IP address sent by the protected 362 endpoint, and packets will have to be UDP encapsulated in order to be 363 routed properly. 365 1.1.4. Other Scenarios 367 Other scenarios are possible, as are nested combinations of the 368 above. One notable example combines aspects of 1.1.1 and 1.1.3. A 369 subnet may make all external accesses through a remote security 370 gateway using an IPsec tunnel, where the addresses on the subnet are 371 routed to the security gateway by the rest of the Internet. An 372 example would be someone's home network being virtually on the 373 Internet with static IP addresses even though connectivity is 374 provided by an ISP that assigns a single dynamically assigned IP 375 address to the user's security gateway (where the static IP addresses 376 and an IPsec relay are provided by a third party located elsewhere). 378 1.2. The Initial Exchanges 380 Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH 381 exchanges (known in IKEv1 as Phase 1). These initial exchanges 382 normally consist of four messages, though in some scenarios that 383 number can grow. All communications using IKE consist of request/ 384 response pairs. We'll describe the base exchange first, followed by 385 variations. The first pair of messages (IKE_SA_INIT) negotiate 386 cryptographic algorithms, exchange nonces, and do a Diffie-Hellman 387 exchange [DH]. 389 The second pair of messages (IKE_AUTH) authenticate the previous 390 messages, exchange identities and certificates, and establish the 391 first Child SA. Parts of these messages are encrypted and integrity 392 protected with keys established through the IKE_SA_INIT exchange, so 393 the identities are hidden from eavesdroppers and all fields in all 394 the messages are authenticated. (See Section 2.14 for information on 395 how the encyrption keys are generated.) 397 All messages following the initial exchange are cryptographically 398 protected using the cryptographic algorithms and keys negotiated in 399 the the IKE_SA_INIT exchange. These subsequent messages use the 400 syntax of the Encrypted Payload described in Section 3.14, encrypted 401 with keys that are derived as described in Section 2.14. All 402 subsequent messages include an Encrypted Payload, even if they are 403 referred to in the text as "empty". For the CREATE_CHILD_SA, 404 IKE_AUTH, or IKE_INFORMATIONAL exchanges, the message following the 405 header is encrypted and the message including the header is integrity 406 protected using the cryptographic algorithms negotiated for the IKE 407 SA. 409 In the following descriptions, the payloads contained in the message 410 are indicated by names as listed below. 412 Notation Payload 413 ----------------------------------------- 414 AUTH Authentication 415 CERT Certificate 416 CERTREQ Certificate Request 417 CP Configuration 418 D Delete 419 E Encrypted 420 EAP Extensible Authentication 421 HDR IKE Header 422 IDi Identification - Initiator 423 IDr Identification - Responder 424 KE Key Exchange 425 Ni, Nr Nonce 426 N Notify 427 SA Security Association 428 TSi Traffic Selector - Initiator 429 TSr Traffic Selector - Responder 430 V Vendor ID 432 The details of the contents of each payload are described in section 433 3. Payloads that may optionally appear will be shown in brackets, 434 such as [CERTREQ], indicate that optionally a certificate request 435 payload can be included. 437 The initial exchanges are as follows: 439 Initiator Responder 440 ------------------------------------------------------------------- 441 HDR, SAi1, KEi, Ni --> 443 HDR contains the Security Parameter Indexes (SPIs), version numbers, 444 and flags of various sorts. The SAi1 payload states the 445 cryptographic algorithms the initiator supports for the IKE SA. The 446 KE payload sends the initiator's Diffie-Hellman value. Ni is the 447 initiator's nonce. 449 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 451 The responder chooses a cryptographic suite from the initiator's 452 offered choices and expresses that choice in the SAr1 payload, 453 completes the Diffie-Hellman exchange with the KEr payload, and sends 454 its nonce in the Nr payload. 456 At this point in the negotiation, each party can generate SKEYSEED, 457 from which all keys are derived for that IKE SA. The messages that 458 follow are encrypted and integrity protected in their entirety, with 459 the exception of the message headers. The keys used for the 460 encryption and integrity protection are derived from SKEYSEED and are 461 known as SK_e (encryption) and SK_a (authentication, a.k.a. integrity 462 protection). A separate SK_e and SK_a is computed for each 463 direction. In addition to the keys SK_e and SK_a derived from the DH 464 value for protection of the IKE SA, another quantity SK_d is derived 465 and used for derivation of further keying material for Child SAs. 466 The notation SK { ... } indicates that these payloads are encrypted 467 and integrity protected using that direction's SK_e and SK_a. 469 HDR, SK {IDi, [CERT,] [CERTREQ,] 470 [IDr,] AUTH, SAi2, 471 TSi, TSr} --> 473 The initiator asserts its identity with the IDi payload, proves 474 knowledge of the secret corresponding to IDi and integrity protects 475 the contents of the first message using the AUTH payload (see 476 Section 2.15). It might also send its certificate(s) in CERT 477 payload(s) and a list of its trust anchors in CERTREQ payload(s). If 478 any CERT payloads are included, the first certificate provided MUST 479 contain the public key used to verify the AUTH field. 481 The optional payload IDr enables the initiator to specify which of 482 the responder's identities it wants to talk to. This is useful when 483 the machine on which the responder is running is hosting multiple 484 identities at the same IP address. If the IDr proposed by the 485 initiator is not acceptable to the responder, the responder might use 486 some other IDr to finish the exchange. If the initiator then does 487 not accept that fact that responder used different IDr than the one 488 that was requested, the initiator can close the SA after noticing the 489 fact. 491 The initiator begins negotiation of a Child SA using the SAi2 492 payload. The final fields (starting with SAi2) are described in the 493 description of the CREATE_CHILD_SA exchange. 495 <-- HDR, SK {IDr, [CERT,] AUTH, 496 SAr2, TSi, TSr} 498 The responder asserts its identity with the IDr payload, optionally 499 sends one or more certificates (again with the certificate containing 500 the public key used to verify AUTH listed first), authenticates its 501 identity and protects the integrity of the second message with the 502 AUTH payload, and completes negotiation of a Child SA with the 503 additional fields described below in the CREATE_CHILD_SA exchange. 505 The recipients of messages 3 and 4 MUST verify that all signatures 506 and MACs are computed correctly and that the names in the ID payloads 507 correspond to the keys used to generate the AUTH payload. 509 {{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH exchange 510 fails for some reason, the IKE SA is still created as usual. The 511 list of responses in the IKE_AUTH exchange that do not prevent an IKE 512 SA from being set up include at least the following: 513 NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, 514 INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. 516 {{ Clarif-4.3 }} Note that IKE_AUTH messages do not contain KEi/KEr 517 or Ni/Nr payloads. Thus, the SA payloads in the IKE_AUTH exchange 518 cannot contain Transform Type 4 (Diffie-Hellman Group) with any value 519 other than NONE. Implementations SHOULD omit the whole transform 520 substructure instead of sending value NONE. 522 1.3. The CREATE_CHILD_SA Exchange 524 {{ This is a heavy rewrite of most of this section. The major 525 organization changes are described in Clarif-4.1 and Clarif-5.1. }} 527 The CREATE_CHILD_SA exchange is used to create new Child SAs and to 528 rekey both IKE SAs and Child SAs. This exchange consists of a single 529 request/response pair, and some of its function was referred to as a 530 phase 2 exchange in IKEv1. It MAY be initiated by either end of the 531 IKE SA after the initial exchanges are completed. 533 All messages following the initial exchange are cryptographically 534 protected using the cryptographic algorithms and keys negotiated in 535 the first two messages of the IKE exchange. These subsequent 536 messages use the syntax of the Encrypted Payload described in 537 Section 3.14, encrypted with keys that are derived as described in 538 Section 2.14. All subsequent messages include an Encrypted Payload, 539 even if they are referred to in the text as "empty". For both 540 messages in the CREATE_CHILD_SA, the message following the header is 541 encrypted and the message including the header is integrity protected 542 using the cryptographic algorithms negotiated for the IKE SA. 544 The CREATE_CHILD_SA is also used for rekeying IKE SAs and Child SAs. 545 An SA is rekeyed by creating a new SA and then deleting the old one. 546 This section describes the first part of rekeying, the creation of 547 new SAs; Section 2.8 covers the mechanics of rekeying, including 548 moving traffic from old to new SAs and the deletion of the old SAs. 549 The two sections must be read together to understand the entire 550 process of rekeying. 552 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this 553 section the term initiator refers to the endpoint initiating this 554 exchange. An implementation MAY refuse all CREATE_CHILD_SA requests 555 within an IKE SA. 557 The CREATE_CHILD_SA request MAY optionally contain a KE payload for 558 an additional Diffie-Hellman exchange to enable stronger guarantees 559 of forward secrecy for the Child SA. The keying material for the 560 Child SA is a function of SK_d established during the establishment 561 of the IKE SA, the nonces exchanged during the CREATE_CHILD_SA 562 exchange, and the Diffie-Hellman value (if KE payloads are included 563 in the CREATE_CHILD_SA exchange). 565 If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of 566 the SA offers MUST include the Diffie-Hellman group of the KEi. The 567 Diffie-Hellman group of the KEi MUST be an element of the group the 568 initiator expects the responder to accept (additional Diffie-Hellman 569 groups can be proposed). If the responder selects a proposal using a 570 different Diffie-Hellman group (other than NONE), the responder MUST 571 reject the request and indicate its preferred Diffie-Hellman group in 572 the INVALID_KE_PAYLOAD Notification payload. {{ 3.10.1-17 }} There 573 are two octets of data associated with this notification: the 574 accepted D-H Group number in big endian order. In the case of such a 575 rejection, the CREATE_CHILD_SA exchange fails, and the initiator will 576 probably retry the exchange with a Diffie-Hellman proposal and KEi in 577 the group that the responder gave in the INVALID_KE_PAYLOAD. 579 {{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS notification 580 to indicate that a CREATE_CHILD_SA request is unacceptable because 581 the responder is unwilling to accept any more Child SAs on this IKE 582 SA. Some minimal implementations may only accept a single Child SA 583 setup in the context of an initial IKE exchange and reject any 584 subsequent attempts to add more. 586 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA Exchange 588 A Child SA may be created by sending a CREATE_CHILD_SA request. The 589 CREATE_CHILD_SA request for creating a new Child SA is: 591 Initiator Responder 592 ------------------------------------------------------------------- 593 HDR, SK {SA, Ni, [KEi], 594 TSi, TSr} --> 596 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 597 payload, optionally a Diffie-Hellman value in the KEi payload, and 598 the proposed traffic selectors for the proposed Child SA in the TSi 599 and TSr payloads. 601 The CREATE_CHILD_SA response for creating a new Child SA is: 603 <-- HDR, SK {SA, Nr, [KEr], 604 TSi, TSr} 606 The responder replies (using the same Message ID to respond) with the 607 accepted offer in an SA payload, and a Diffie-Hellman value in the 608 KEr payload if KEi was included in the request and the selected 609 cryptographic suite includes that group. 611 The traffic selectors for traffic to be sent on that SA are specified 612 in the TS payloads in the response, which may be a subset of what the 613 initiator of the Child SA proposed. 615 {{ 3.10.1-16391 }} The USE_TRANSPORT_MODE notification MAY be 616 included in a request message that also includes an SA payload 617 requesting a Child SA. It requests that the Child SA use transport 618 mode rather than tunnel mode for the SA created. If the request is 619 accepted, the response MUST also include a notification of type 620 USE_TRANSPORT_MODE. If the responder declines the request, the Child 621 SA will be established in tunnel mode. If this is unacceptable to 622 the initiator, the initiator MUST delete the SA. Note: Except when 623 using this option to negotiate transport mode, all Child SAs will use 624 tunnel mode. 626 {{ 3.10.1-16394 }} The ESP_TFC_PADDING_NOT_SUPPORTED notification 627 asserts that the sending endpoint will NOT accept packets that 628 contain Traffic Flow Confidentiality (TFC) padding over the Child SA 629 being negotiated. {{ Clarif-4.5 }} If neither endpoint accepts TFC 630 padding, this notification is included in both the request and the 631 response. If this notification is included in only one of the 632 messages, TFC padding can still be sent in the other direction. 634 {{ 3.10.1-16395 }} The NON_FIRST_FRAGMENTS_ALSO notification is used 635 for fragmentation control. See [IPSECARCH] for a fuller explanation. 636 {{ Clarif-4.6 }} Both parties need to agree to sending non-first 637 fragments before either party does so. It is enabled only if 638 NON_FIRST_FRAGMENTS_ALSO notification is included in both the request 639 proposing an SA and the response accepting it. If the responder does 640 not want to send or receive non-first fragments, it only omits 641 NON_FIRST_FRAGMENTS_ALSO notification from its response, but does not 642 reject the whole Child SA creation. 644 Failure of an attempt to create a CHILD SA SHOULD NOT tear down the 645 IKE SA: there is no reason to lose the work done to set up the IKE 646 SA. When an IKE SA is not created, the error message return SHOULD 647 NOT be encrypted because the other party will not be able to 648 authenticate that message. [[ Note: this text may be changed in the 649 future. ]] 651 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange 653 The CREATE_CHILD_SA request for rekeying an IKE SA is: 655 Initiator Responder 656 ------------------------------------------------------------------- 657 HDR, SK {SA, Ni, KEi} --> 659 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 660 payload, and a Diffie-Hellman value in the KEi payload. The KEi 661 payload MUST be included. New initiator and responder SPIs are 662 supplied in the SPI fields of the SA payload. 664 The CREATE_CHILD_SA response for rekeying an IKE SA is: 666 <-- HDR, SK {SA, Nr,[KEr]} 668 The responder replies (using the same Message ID to respond) with the 669 accepted offer in an SA payload, and a Diffie-Hellman value in the 670 KEr payload if the selected cryptographic suite includes that group. 672 The new IKE SA has its message counters set to 0, regardless of what 673 they were in the earlier IKE SA. The first IKE requests from both 674 sides on the new IKE SA will have message ID 0. The old IKE SA 675 retains its numbering, so any further requests (for example, to 676 delete the IKE SA) will have consecutive numbering. The new IKE SA 677 also has its window size reset to 1, and the initiator in this rekey 678 exchange is the new "original initiator" of the new IKE SA. 680 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange 682 The CREATE_CHILD_SA request for rekeying a Child SA is: 684 Initiator Responder 685 ------------------------------------------------------------------- 686 HDR, SK {N, SA, Ni, [KEi], 687 TSi, TSr} --> 689 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 690 payload, optionally a Diffie-Hellman value in the KEi payload, and 691 the proposed traffic selectors for the proposed Child SA in the TSi 692 and TSr payloads. 694 {{ 3.10.1-16393 }} The REKEY_SA notification MUST be included in a 695 CREATE_CHILD_SA exchange if the purpose of the exchange is to replace 696 an existing ESP or AH SA. {{ Clarif-5.4 }} The SA being rekeyed is 697 identified by the SPI field in the Notify payload; this is the SPI 698 the exchange initiator would expect in inbound ESP or AH packets. 700 There is no data associated with this Notify type. The Protocol ID 701 field of the REKEY_SA notification is set to match the protocol of 702 the SA we are rekeying, for example, 3 for ESP and 2 for AH. 704 The CREATE_CHILD_SA response for rekeying a Child SA is: 706 <-- HDR, SK {SA, Nr, [KEr], 707 TSi, TSr} 709 The responder replies (using the same Message ID to respond) with the 710 accepted offer in an SA payload, and a Diffie-Hellman value in the 711 KEr payload if KEi was included in the request and the selected 712 cryptographic suite includes that group. 714 The traffic selectors for traffic to be sent on that SA are specified 715 in the TS payloads in the response, which may be a subset of what the 716 initiator of the Child SA proposed. 718 1.4. The INFORMATIONAL Exchange 720 At various points during the operation of an IKE SA, peers may desire 721 to convey control messages to each other regarding errors or 722 notifications of certain events. To accomplish this, IKE defines an 723 INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur 724 after the initial exchanges and are cryptographically protected with 725 the negotiated keys. 727 Control messages that pertain to an IKE SA MUST be sent under that 728 IKE SA. Control messages that pertain to Child SAs MUST be sent 729 under the protection of the IKE SA which generated them (or its 730 successor if the IKE SA was rekeyed). 732 Messages in an INFORMATIONAL exchange contain zero or more 733 Notification, Delete, and Configuration payloads. The Recipient of 734 an INFORMATIONAL exchange request MUST send some response (else the 735 Sender will assume the message was lost in the network and will 736 retransmit it). That response MAY be a message with no payloads. 737 The request message in an INFORMATIONAL exchange MAY also contain no 738 payloads. This is the expected way an endpoint can ask the other 739 endpoint to verify that it is alive. 741 The INFORMATIONAL exchange is defined as: 743 Initiator Responder 744 ------------------------------------------------------------------- 745 HDR, SK {[N,] [D,] 746 [CP,] ...} --> 747 <-- HDR, SK {[N,] [D,] 749 [CP], ...} 751 The processing of an INFORMATIONAL exchange is determined by its 752 component payloads. 754 1.4.1. Deleting an SA with INFORMATIONAL Exchanges 756 {{ Clarif-5.6 }} ESP and AH SAs always exist in pairs, with one SA in 757 each direction. When an SA is closed, both members of the pair MUST 758 be closed (that is, deleted). Each endpoint MUST close its incoming 759 SAs and allow the other endpoint to close the other SA in each pair. 760 To delete an SA, an INFORMATIONAL exchange with one or more delete 761 payloads is sent listing the SPIs (as they would be expected in the 762 headers of inbound packets) of the SAs to be deleted. The recipient 763 MUST close the designated SAs. {{ Clarif-5.7 }} Note that one never 764 sends delete payloads for the two sides of an SA in a single message. 765 If there are many SAs to delete at the same time, one includes delete 766 payloads for the inbound half of each SA pair in your Informational 767 exchange. 769 Normally, the reply in the INFORMATIONAL exchange will contain delete 770 payloads for the paired SAs going in the other direction. There is 771 one exception. If by chance both ends of a set of SAs independently 772 decide to close them, each may send a delete payload and the two 773 requests may cross in the network. If a node receives a delete 774 request for SAs for which it has already issued a delete request, it 775 MUST delete the outgoing SAs while processing the request and the 776 incoming SAs while processing the response. In that case, the 777 responses MUST NOT include delete payloads for the deleted SAs, since 778 that would result in duplicate deletion and could in theory delete 779 the wrong SA. 781 {{ Demoted the SHOULD }} Half-closed ESP or AH connections are 782 anomalous, and a node with auditing capability should probably audit 783 their existence if they persist. Note that this specification 784 nowhere specifies time periods, so it is up to individual endpoints 785 to decide how long to wait. A node MAY refuse to accept incoming 786 data on half-closed connections but MUST NOT unilaterally close them 787 and reuse the SPIs. If connection state becomes sufficiently messed 788 up, a node MAY close the IKE SA; doing so will implicitly close all 789 SAs negotiated under it. It can then rebuild the SAs it needs on a 790 clean base under a new IKE SA. {{ Clarif-5.8 }} The response to a 791 request that deletes the IKE SA is an empty Informational response. 793 1.5. Informational Messages outside of an IKE SA 795 If an encrypted IKE request packet arrives on port 500 or 4500 with 796 an unrecognized SPI, it could be because the receiving node has 797 recently crashed and lost state or because of some other system 798 malfunction or attack. If the receiving node has an active IKE SA to 799 the IP address from whence the packet came, it MAY send a 800 notification of the wayward packet over that IKE SA in an 801 INFORMATIONAL exchange. If it does not have such an IKE SA, it MAY 802 send an Informational message without cryptographic protection to the 803 source IP address. Such a message is not part of an informational 804 exchange, and the receiving node MUST NOT respond to it. Doing so 805 could cause a message loop. 807 {{ 3.10.1-11 }} The INVALID_SPI notification MAY be sent in an IKE 808 INFORMATIONAL exchange when a node receives an ESP or AH packet with 809 an invalid SPI. The Notification Data contains the SPI of the 810 invalid packet. This usually indicates a node has rebooted and 811 forgotten an SA. If this Informational Message is sent outside the 812 context of an IKE SA, it should only be used by the recipient as a 813 "hint" that something might be wrong (because it could easily be 814 forged). 816 {{ Clarif-7.7 }} There are two cases when such a one-way notification 817 is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are 818 sent outside of an IKE SA. Note that such notifications are 819 explicitly not Informational exchanges; these are one-way messages 820 that must not be responded to. 822 In case of INVALID_IKE_SPI, the message sent is a response message, 823 and thus it is sent to the IP address and port from whence it came 824 with the same IKE SPIs and the Message ID is copied. The Response 825 bit is set to 1, and the version flags are set in the normal fashion. 826 For a one-way INVALID_IKE_SPI notification for an unrecognized SPI, 827 the responder SHOULD copy the Exchange Type from the request. 829 In case of INVALID_SPI, however, there are no IKE SPI values that 830 would be meaningful to the recipient of such a notification. Using 831 zero values or random values are both acceptable. The Initiator flag 832 is set, the Response bit is set to 0, and the version flags are set 833 in the normal fashion. 835 1.6. Requirements Terminology 837 Definitions of the primitive terms in this document (such as Security 838 Association or SA) can be found in [IPSECARCH]. {{ Clarif-7.2 }} It 839 should be noted that parts of IKEv2 rely on some of the processing 840 rules in [IPSECARCH], as described in various sections of this 841 document. 843 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 844 "MAY" that appear in this document are to be interpreted as described 845 in [MUSTSHOULD]. 847 1.7. Differences Between RFC 4306 and This Document 849 {{ Added this entire section, including this recursive remark. }} 851 This document contains clarifications and amplifications to IKEv2 852 [IKEV2]. The clarifications are mostly based on [Clarif]. The 853 changes listed in that document were discussed in the IPsec Working 854 Group and, after the Working Group was disbanded, on the IPsec 855 mailing list. That document contains detailed explanations of areas 856 that were unclear in IKEv2, and is thus useful to implementers of 857 IKEv2. 859 The protocol described in this document retains the same major 860 version number (2) and minor version number (0) as was used in RFC 861 4306. That is, the version number is *not* changed from RFC 4306. 863 This document makes the figures and references a bit more regular 864 than in [IKEV2]. 866 IKEv2 developers have noted that the SHOULD-level requirements are 867 often unclear in that they don't say when it is OK to not obey the 868 requirements. They also have noted that there are MUST-level 869 requirements that are not related to interoperability. This document 870 has more explanation of some of these requirements. All non- 871 capitalized uses of the words SHOULD and MUST now mean their normal 872 English sense, not the interoperability sense of [MUSTSHOULD]. 874 IKEv2 (and IKEv1) developers have noted that there is a great deal of 875 material in the tables of codes in Section 3.10.1. This leads to 876 implementers not having all the needed information in the main body 877 of the document. Much of the material from those tables has been 878 moved into the associated parts of the main body of the document. 880 In the body of this document, notes that are enclosed in double curly 881 braces {{ such as this }} point out changes from IKEv2. Changes that 882 come from [Clarif] are marked with the section from that document, 883 such as "{{ Clarif-2.10 }}". Changes that come from moving 884 descriptive text out of the tables in Section 3.10.1 are marked with 885 that number and the message type that contained the text, such as "{{ 886 3.10.1-16384 }}". 888 This document removes discussion of nesting AH and ESP. This was a 889 mistake in RFC 4306 caused by the lag between finishing RFC 4306 and 890 RFC 4301. Basically, IKEv2 is based on RFC 4301, which does not 891 include "SA bundles" that were part of RFC 2401. While a single 892 packet can go through IPsec processing multiple times, each of these 893 passes uses a separate SA, and the passes are coordinated by the 894 forwarding tables. In IKEv2, each of these SAs has to be created 895 using a separate CREATE_CHILD_SA exchange. 897 This document removes discussion of the INTERNAL_ADDRESS_EXPIRY 898 configuration attribute because its implementation was very 899 problematic. Implementations that conform to this document MUST 900 ignore proposals that have configuration attribute type 5, the old 901 value for INTERNAL_ADDRESS_EXPIRY. 903 This document adds the restriction in Section 2.13 that all PRFs used 904 with IKEv2 MUST take variable-sized keys. This should not affect any 905 implementations because there were no standardized PRFs that have 906 fixed-size keys. 908 A later version of this document may have all the {{ }} comments 909 removed from the body of the document and instead appear in an 910 appendix. 912 2. IKE Protocol Details and Variations 914 IKE normally listens and sends on UDP port 500, though IKE messages 915 may also be received on UDP port 4500 with a slightly different 916 format (see Section 2.23). Since UDP is a datagram (unreliable) 917 protocol, IKE includes in its definition recovery from transmission 918 errors, including packet loss, packet replay, and packet forgery. 919 IKE is designed to function so long as (1) at least one of a series 920 of retransmitted packets reaches its destination before timing out; 921 and (2) the channel is not so full of forged and replayed packets so 922 as to exhaust the network or CPU capacities of either endpoint. Even 923 in the absence of those minimum performance requirements, IKE is 924 designed to fail cleanly (as though the network were broken). 926 Although IKEv2 messages are intended to be short, they contain 927 structures with no hard upper bound on size (in particular, X.509 928 certificates), and IKEv2 itself does not have a mechanism for 929 fragmenting large messages. IP defines a mechanism for fragmentation 930 of oversize UDP messages, but implementations vary in the maximum 931 message size supported. Furthermore, use of IP fragmentation opens 932 an implementation to denial of service attacks [DOSUDPPROT]. 933 Finally, some NAT and/or firewall implementations may block IP 934 fragments. 936 All IKEv2 implementations MUST be able to send, receive, and process 937 IKE messages that are up to 1280 octets long, and they SHOULD be able 938 to send, receive, and process messages that are up to 3000 octets 939 long. {{ Demoted the SHOULD }} IKEv2 implementations need to be aware 940 of the maximum UDP message size supported and MAY shorten messages by 941 leaving out some certificates or cryptographic suite proposals if 942 that will keep messages below the maximum. Use of the "Hash and URL" 943 formats rather than including certificates in exchanges where 944 possible can avoid most problems. {{ Demoted the SHOULD }} 945 Implementations and configuration need to keep in mind, however, that 946 if the URL lookups are possible only after the IPsec SA is 947 established, recursion issues could prevent this technique from 948 working. 950 {{ Clarif-7.5 }} The UDP payload of all packets containing IKE 951 messages sent on port 4500 MUST begin with the prefix of four zeros; 952 otherwise, the receiver won't know how to handle them. 954 2.1. Use of Retransmission Timers 956 All messages in IKE exist in pairs: a request and a response. The 957 setup of an IKE SA normally consists of two request/response pairs. 958 Once the IKE SA is set up, either end of the security association may 959 initiate requests at any time, and there can be many requests and 960 responses "in flight" at any given moment. But each message is 961 labeled as either a request or a response, and for each request/ 962 response pair one end of the security association is the initiator 963 and the other is the responder. 965 For every pair of IKE messages, the initiator is responsible for 966 retransmission in the event of a timeout. The responder MUST never 967 retransmit a response unless it receives a retransmission of the 968 request. In that event, the responder MUST ignore the retransmitted 969 request except insofar as it triggers a retransmission of the 970 response. The initiator MUST remember each request until it receives 971 the corresponding response. The responder MUST remember each 972 response until it receives a request whose sequence number is larger 973 than or equal to the sequence number in the response plus its window 974 size (see Section 2.3). In order to allow saving memory, responders 975 are allowed to forget response after a timeout of several minutes. 976 If the responder receives a retransmitted request for which it has 977 already forgotten the response, it MUST ignore the request (and not, 978 for example, attempt constructing a new response). 980 IKE is a reliable protocol, in the sense that the initiator MUST 981 retransmit a request until either it receives a corresponding reply 982 OR it deems the IKE security association to have failed and it 983 discards all state associated with the IKE SA and any Child SAs 984 negotiated using that IKE SA. A retransmission from the initiator 985 MUST be bitwise identical to the original request. That is, 986 everything starting from the IKE Header (the IKE SA Initiator's SPI 987 onwards) must be bitwise identical; items before it (such as the IP 988 and UDP headers, and the zero non-ESP marker) do not have to be 989 identical. 991 {{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require 992 some special handling. When a responder receives an IKE_SA_INIT 993 request, it has to determine whether the packet is a retransmission 994 belonging to an existing "half-open" IKE SA (in which case the 995 responder retransmits the same response), or a new request (in which 996 case the responder creates a new IKE SA and sends a fresh response), 997 or it belongs to an existing IKE SA where the IKE_AUTH request has 998 been already received (in which case the responder ignores it). 1000 It is not sufficient to use the initiator's SPI and/or IP address to 1001 differentiate between these three cases because two different peers 1002 behind a single NAT could choose the same initiator SPI. Instead, a 1003 robust responder will do the IKE SA lookup using the whole packet, 1004 its hash, or the Ni payload. 1006 2.2. Use of Sequence Numbers for Message ID 1008 Every IKE message contains a Message ID as part of its fixed header. 1009 This Message ID is used to match up requests and responses, and to 1010 identify retransmissions of messages. 1012 The Message ID is a 32-bit quantity, which is zero for the 1013 IKE_SA_INIT messages (including retries of the message due to 1014 responses such as COOKIE and INVALID_KE_PAYLOAD {{ Clarif-2.2 }}), 1015 and incremented for each subsequent exchange. Rekeying an IKE SA 1016 resets the sequence numbers. Thus, the first pair of IKE_AUTH 1017 messages will have ID of 1, the second (when EAP is used) will be 2, 1018 and so on. {{ Clarif-3.10 }} 1020 Each endpoint in the IKE Security Association maintains two "current" 1021 Message IDs: the next one to be used for a request it initiates and 1022 the next one it expects to see in a request from the other end. 1023 These counters increment as requests are generated and received. 1024 Responses always contain the same message ID as the corresponding 1025 request. That means that after the initial exchange, each integer n 1026 may appear as the message ID in four distinct messages: the nth 1027 request from the original IKE initiator, the corresponding response, 1028 the nth request from the original IKE responder, and the 1029 corresponding response. If the two ends make very different numbers 1030 of requests, the Message IDs in the two directions can be very 1031 different. There is no ambiguity in the messages, however, because 1032 the (I)nitiator and (R)esponse bits in the message header specify 1033 which of the four messages a particular one is. 1035 {{ Clarif-5.9 }} Throughout this document, "initiator" refers to the 1036 party who initiated the exchange being described, and "original 1037 initiator" refers to the party who initiated the whole IKE SA. The 1038 "original initiator" always refers to the party who initiated the 1039 exchange which resulted in the current IKE SA. In other words, if 1040 the "original responder" starts rekeying the IKE SA, that party 1041 becomes the "original initiator" of the new IKE SA. 1043 Note that Message IDs are cryptographically protected and provide 1044 protection against message replays. In the unlikely event that 1045 Message IDs grow too large to fit in 32 bits, the IKE SA MUST be 1046 closed or rekeyed. 1048 2.3. Window Size for Overlapping Requests 1050 {{ 3.10.1-16385 }} The SET_WINDOW_SIZE notification asserts that the 1051 sending endpoint is capable of keeping state for multiple outstanding 1052 exchanges, permitting the recipient to send multiple requests before 1053 getting a response to the first. The data associated with a 1054 SET_WINDOW_SIZE notification MUST be 4 octets long and contain the 1055 big endian representation of the number of messages the sender 1056 promises to keep. The window size is always one until the initial 1057 exchanges complete. 1059 An IKE endpoint MUST wait for a response to each of its messages 1060 before sending a subsequent message unless it has received a 1061 SET_WINDOW_SIZE Notify message from its peer informing it that the 1062 peer is prepared to maintain state for multiple outstanding messages 1063 in order to allow greater throughput. 1065 After an IKE SA is set up, in order to maximize IKE throughput, an 1066 IKE endpoint MAY issue multiple requests before getting a response to 1067 any of them, up to the limit set by its peer's SET_WINDOW_SIZE. 1068 These requests may pass one another over the network. An IKE 1069 endpoint MUST be prepared to accept and process a request while it 1070 has a request outstanding in order to avoid a deadlock in this 1071 situation. {{ Downgraded the SHOULD }} An IKE endpoint may also 1072 accept and process multiple requests while it has a request 1073 outstanding. 1075 An IKE endpoint MUST NOT exceed the peer's stated window size for 1076 transmitted IKE requests. In other words, if the responder stated 1077 its window size is N, then when the initiator needs to make a request 1078 X, it MUST wait until it has received responses to all requests up 1079 through request X-N. An IKE endpoint MUST keep a copy of (or be able 1080 to regenerate exactly) each request it has sent until it receives the 1081 corresponding response. An IKE endpoint MUST keep a copy of (or be 1082 able to regenerate exactly) the number of previous responses equal to 1083 its declared window size in case its response was lost and the 1084 initiator requests its retransmission by retransmitting the request. 1086 An IKE endpoint supporting a window size greater than one ought to be 1087 capable of processing incoming requests out of order to maximize 1088 performance in the event of network failures or packet reordering. 1090 {{ Clarif-7.3 }} The window size is normally a (possibly 1091 configurable) property of a particular implementation, and is not 1092 related to congestion control (unlike the window size in TCP, for 1093 example). In particular, it is not defined what the responder should 1094 do when it receives a SET_WINDOW_SIZE notification containing a 1095 smaller value than is currently in effect. Thus, there is currently 1096 no way to reduce the window size of an existing IKE SA; you can only 1097 increase it. When rekeying an IKE SA, the new IKE SA starts with 1098 window size 1 until it is explicitly increased by sending a new 1099 SET_WINDOW_SIZE notification. 1101 {{ 3.10.1-9 }}The INVALID_MESSAGE_ID notification is sent when an IKE 1102 message ID outside the supported window is received. This Notify 1103 MUST NOT be sent in a response; the invalid request MUST NOT be 1104 acknowledged. Instead, inform the other side by initiating an 1105 INFORMATIONAL exchange with Notification data containing the four 1106 octet invalid message ID. Sending this notification is optional, and 1107 notifications of this type MUST be rate limited. 1109 2.4. State Synchronization and Connection Timeouts 1111 An IKE endpoint is allowed to forget all of its state associated with 1112 an IKE SA and the collection of corresponding Child SAs at any time. 1113 This is the anticipated behavior in the event of an endpoint crash 1114 and restart. It is important when an endpoint either fails or 1115 reinitializes its state that the other endpoint detect those 1116 conditions and not continue to waste network bandwidth by sending 1117 packets over discarded SAs and having them fall into a black hole. 1119 {{ 3.10.1-16384 }} The INITIAL_CONTACT notification asserts that this 1120 IKE SA is the only IKE SA currently active between the authenticated 1121 identities. It MAY be sent when an IKE SA is established after a 1122 crash, and the recipient MAY use this information to delete any other 1123 IKE SAs it has to the same authenticated identity without waiting for 1124 a timeout. This notification MUST NOT be sent by an entity that may 1125 be replicated (e.g., a roaming user's credentials where the user is 1126 allowed to connect to the corporate firewall from two remote systems 1127 at the same time). {{ Clarif-7.9 }} The INITIAL_CONTACT notification, 1128 if sent, MUST be in the first IKE_AUTH request or response, not as a 1129 separate exchange afterwards; however, receiving parties MAY ignore 1130 it in other messages. 1132 Since IKE is designed to operate in spite of Denial of Service (DoS) 1133 attacks from the network, an endpoint MUST NOT conclude that the 1134 other endpoint has failed based on any routing information (e.g., 1135 ICMP messages) or IKE messages that arrive without cryptographic 1136 protection (e.g., Notify messages complaining about unknown SPIs). 1137 An endpoint MUST conclude that the other endpoint has failed only 1138 when repeated attempts to contact it have gone unanswered for a 1139 timeout period or when a cryptographically protected INITIAL_CONTACT 1140 notification is received on a different IKE SA to the same 1141 authenticated identity. {{ Demoted the SHOULD }} An endpoint should 1142 suspect that the other endpoint has failed based on routing 1143 information and initiate a request to see whether the other endpoint 1144 is alive. To check whether the other side is alive, IKE specifies an 1145 empty INFORMATIONAL message that (like all IKE requests) requires an 1146 acknowledgement (note that within the context of an IKE SA, an 1147 "empty" message consists of an IKE header followed by an Encrypted 1148 payload that contains no payloads). If a cryptographically protected 1149 (fresh, i.e. not retransmitted) message has been received from the 1150 other side recently, unprotected notifications MAY be ignored. 1151 Implementations MUST limit the rate at which they take actions based 1152 on unprotected messages. 1154 Numbers of retries and lengths of timeouts are not covered in this 1155 specification because they do not affect interoperability. It is 1156 suggested that messages be retransmitted at least a dozen times over 1157 a period of at least several minutes before giving up on an SA, but 1158 different environments may require different rules. To be a good 1159 network citizen, retranmission times MUST increase exponentially to 1160 avoid flooding the network and making an existing congestion 1161 situation worse. If there has only been outgoing traffic on all of 1162 the SAs associated with an IKE SA, it is essential to confirm 1163 liveness of the other endpoint to avoid black holes. If no 1164 cryptographically protected messages have been received on an IKE SA 1165 or any of its Child SAs recently, the system needs to perform a 1166 liveness check in order to prevent sending messages to a dead peer. 1167 (This is sometimes called "dead peer detection" or "DPD", although it 1168 is really detecting live peers, not dead ones.) Receipt of a fresh 1169 cryptographically protected message on an IKE SA or any of its Child 1170 SAs ensures liveness of the IKE SA and all of its Child SAs. Note 1171 that this places requirements on the failure modes of an IKE 1172 endpoint. An implementation MUST NOT continue sending on any SA if 1173 some failure prevents it from receiving on all of the associated SAs. 1174 If Child SAs can fail independently from one another without the 1175 associated IKE SA being able to send a delete message, then they MUST 1176 be negotiated by separate IKE SAs. 1178 There is a Denial of Service attack on the initiator of an IKE SA 1179 that can be avoided if the initiator takes the proper care. Since 1180 the first two messages of an SA setup are not cryptographically 1181 protected, an attacker could respond to the initiator's message 1182 before the genuine responder and poison the connection setup attempt. 1183 To prevent this, the initiator MAY be willing to accept multiple 1184 responses to its first message, treat each as potentially legitimate, 1185 respond to it, and then discard all the invalid half-open connections 1186 when it receives a valid cryptographically protected response to any 1187 one of its requests. Once a cryptographically valid response is 1188 received, all subsequent responses should be ignored whether or not 1189 they are cryptographically valid. 1191 Note that with these rules, there is no reason to negotiate and agree 1192 upon an SA lifetime. If IKE presumes the partner is dead, based on 1193 repeated lack of acknowledgement to an IKE message, then the IKE SA 1194 and all Child SAs set up through that IKE SA are deleted. 1196 An IKE endpoint may at any time delete inactive Child SAs to recover 1197 resources used to hold their state. If an IKE endpoint chooses to 1198 delete Child SAs, it MUST send Delete payloads to the other end 1199 notifying it of the deletion. It MAY similarly time out the IKE SA. 1200 {{ Clarified the SHOULD }} Closing the IKE SA implicitly closes all 1201 associated Child SAs. In this case, an IKE endpoint SHOULD send a 1202 Delete payload indicating that it has closed the IKE SA unless the 1203 other endpoint is no longer responding. 1205 2.5. Version Numbers and Forward Compatibility 1207 This document describes version 2.0 of IKE, meaning the major version 1208 number is 2 and the minor version number is 0. {{ Restated the 1209 relationship to RFC 4306 }} This document is a replacement for 1210 [IKEV2]. It is likely that some implementations will want to support 1211 version 1.0 and version 2.0, and in the future, other versions. 1213 The major version number should be incremented only if the packet 1214 formats or required actions have changed so dramatically that an 1215 older version node would not be able to interoperate with a newer 1216 version node if it simply ignored the fields it did not understand 1217 and took the actions specified in the older specification. The minor 1218 version number indicates new capabilities, and MUST be ignored by a 1219 node with a smaller minor version number, but used for informational 1220 purposes by the node with the larger minor version number. For 1221 example, it might indicate the ability to process a newly defined 1222 notification message. The node with the larger minor version number 1223 would simply note that its correspondent would not be able to 1224 understand that message and therefore would not send it. 1226 {{ 3.10.1-5 }} If an endpoint receives a message with a higher major 1227 version number, it MUST drop the message and SHOULD send an 1228 unauthenticated notification message of type INVALID_MAJOR_VERSION 1229 containing the highest (closest) version number it supports. If an 1230 endpoint supports major version n, and major version m, it MUST 1231 support all versions between n and m. If it receives a message with 1232 a major version that it supports, it MUST respond with that version 1233 number. In order to prevent two nodes from being tricked into 1234 corresponding with a lower major version number than the maximum that 1235 they both support, IKE has a flag that indicates that the node is 1236 capable of speaking a higher major version number. 1238 Thus, the major version number in the IKE header indicates the 1239 version number of the message, not the highest version number that 1240 the transmitter supports. If the initiator is capable of speaking 1241 versions n, n+1, and n+2, and the responder is capable of speaking 1242 versions n and n+1, then they will negotiate speaking n+1, where the 1243 initiator will set a flag indicating its ability to speak a higher 1244 version. If they mistakenly (perhaps through an active attacker 1245 sending error messages) negotiate to version n, then both will notice 1246 that the other side can support a higher version number, and they 1247 MUST break the connection and reconnect using version n+1. 1249 Note that IKEv1 does not follow these rules, because there is no way 1250 in v1 of noting that you are capable of speaking a higher version 1251 number. So an active attacker can trick two v2-capable nodes into 1252 speaking v1. {{ Demoted the SHOULD }} When a v2-capable node 1253 negotiates down to v1, it should note that fact in its logs. 1255 Also for forward compatibility, all fields marked RESERVED MUST be 1256 set to zero by an implementation running version 2.0, and their 1257 content MUST be ignored by an implementation running version 2.0 ("Be 1258 conservative in what you send and liberal in what you receive"). In 1259 this way, future versions of the protocol can use those fields in a 1260 way that is guaranteed to be ignored by implementations that do not 1261 understand them. Similarly, payload types that are not defined are 1262 reserved for future use; implementations of a version where they are 1263 undefined MUST skip over those payloads and ignore their contents. 1265 IKEv2 adds a "critical" flag to each payload header for further 1266 flexibility for forward compatibility. If the critical flag is set 1267 and the payload type is unrecognized, the message MUST be rejected 1268 and the response to the IKE request containing that payload MUST 1269 include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an 1270 unsupported critical payload was included. {{ 3.10.1-1 }} In that 1271 Notify payload, the notification data contains the one-octet payload 1272 type. If the critical flag is not set and the payload type is 1273 unsupported, that payload MUST be ignored. Payloads sent in IKE 1274 response messages MUST NOT have the critical flag set. Note that the 1275 critical flag applies only to the payload type, not the contents. If 1276 the payload type is recognized, but the payload contains something 1277 which is not (such as an unknown transform inside an SA payload, or 1278 an unknown Notify Message Type inside a Notify payload), the critical 1279 flag is ignored. 1281 {{ Demoted the SHOULD in the second clause }}Although new payload 1282 types may be added in the future and may appear interleaved with the 1283 fields defined in this specification, implementations MUST send the 1284 payloads defined in this specification in the order shown in the 1285 figures in Section 2; implementations are explicitly allowed to 1286 reject as invalid a message with those payloads in any other order. 1288 2.6. IKE SA SPIs and Cookies 1290 The term "cookies" originates with Karn and Simpson [PHOTURIS] in 1291 Photuris, an early proposal for key management with IPsec, and it has 1292 persisted. The Internet Security Association and Key Management 1293 Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight- 1294 octet fields titled "cookies", and that syntax is used by both IKEv1 1295 and IKEv2, although in IKEv2 they are referred to as the "IKE SPI" 1296 and there is a new separate field in a Notify payload holding the 1297 cookie. The initial two eight-octet fields in the header are used as 1298 a connection identifier at the beginning of IKE packets. Each 1299 endpoint chooses one of the two SPIs and MUST choose them so as to be 1300 unique identifiers of an IKE SA. An SPI value of zero is special and 1301 indicates that the remote SPI value is not yet known by the sender. 1303 Incoming IKE packets are mapped to an IKE SA only using the packet's 1304 SPI, not using (for example) the source IP address of the packet. 1306 Unlike ESP and AH where only the recipient's SPI appears in the 1307 header of a message, in IKE the sender's SPI is also sent in every 1308 message. Since the SPI chosen by the original initiator of the IKE 1309 SA is always sent first, an endpoint with multiple IKE SAs open that 1310 wants to find the appropriate IKE SA using the SPI it assigned must 1311 look at the I(nitiator) Flag bit in the header to determine whether 1312 it assigned the first or the second eight octets. 1314 In the first message of an initial IKE exchange, the initiator will 1315 not know the responder's SPI value and will therefore set that field 1316 to zero. 1318 An expected attack against IKE is state and CPU exhaustion, where the 1319 target is flooded with session initiation requests from forged IP 1320 addresses. This attack can be made less effective if an 1321 implementation of a responder uses minimal CPU and commits no state 1322 to an SA until it knows the initiator can receive packets at the 1323 address from which it claims to be sending them. 1325 When a responder detects a large number of half-open IKE SAs, it 1326 SHOULD reply to IKE_SA_INIT requests with a response containing the 1327 COOKIE notification. {{ 3.10.1-16390 }} The data associated with this 1328 notification MUST be between 1 and 64 octets in length (inclusive), 1329 and its generation is described later in this section. If the 1330 IKE_SA_INIT response includes the COOKIE notification, the initiator 1331 MUST then retry the IKE_SA_INIT request, and include the COOKIE 1332 notification containing the received data as the first payload, and 1333 all other payloads unchanged. The initial exchange will then be as 1334 follows: 1336 Initiator Responder 1337 ------------------------------------------------------------------- 1338 HDR(A,0), SAi1, KEi, Ni --> 1339 <-- HDR(A,0), N(COOKIE) 1340 HDR(A,0), N(COOKIE), SAi1, 1341 KEi, Ni --> 1342 <-- HDR(A,B), SAr1, KEr, 1343 Nr, [CERTREQ] 1344 HDR(A,B), SK {IDi, [CERT,] 1345 [CERTREQ,] [IDr,] AUTH, 1346 SAi2, TSi, TSr} --> 1347 <-- HDR(A,B), SK {IDr, [CERT,] 1348 AUTH, SAr2, TSi, TSr} 1350 The first two messages do not affect any initiator or responder state 1351 except for communicating the cookie. In particular, the message 1352 sequence numbers in the first four messages will all be zero and the 1353 message sequence numbers in the last two messages will be one. 'A' 1354 is the SPI assigned by the initiator, while 'B' is the SPI assigned 1355 by the responder. 1357 {{ Demoted the SHOULD }} An IKE implementation can implement its 1358 responder cookie generation in such a way as to not require any saved 1359 state to recognize its valid cookie when the second IKE_SA_INIT 1360 message arrives. The exact algorithms and syntax they use to 1361 generate cookies do not affect interoperability and hence are not 1362 specified here. The following is an example of how an endpoint could 1363 use cookies to implement limited DOS protection. 1365 A good way to do this is to set the responder cookie to be: 1367 Cookie = | Hash(Ni | IPi | SPIi | ) 1369 where is a randomly generated secret known only to the 1370 responder and periodically changed and | indicates concatenation. 1371 should be changed whenever is 1372 regenerated. The cookie can be recomputed when the IKE_SA_INIT 1373 arrives the second time and compared to the cookie in the received 1374 message. If it matches, the responder knows that the cookie was 1375 generated since the last change to and that IPi must be the 1376 same as the source address it saw the first time. Incorporating SPIi 1377 into the calculation ensures that if multiple IKE SAs are being set 1378 up in parallel they will all get different cookies (assuming the 1379 initiator chooses unique SPIi's). Incorporating Ni in the hash 1380 ensures that an attacker who sees only message 2 can't successfully 1381 forge a message 3. Also, incorporating Ni in the hash prevents an 1382 attacker from fetching one one cookie from the other end, and then 1383 initiating many IKE_SA_INIT exchanges all with different initiator 1384 SPIs (and perhaps port numbers) so that the responder thinks that 1385 there are lots of machines behind one NAT box who are all trying to 1386 connect. 1388 If a new value for is chosen while there are connections in 1389 the process of being initialized, an IKE_SA_INIT might be returned 1390 with other than the current . The responder in 1391 that case MAY reject the message by sending another response with a 1392 new cookie or it MAY keep the old value of around for a 1393 short time and accept cookies computed from either one. {{ Demoted 1394 the SHOULD NOT }} The responder should not accept cookies 1395 indefinitely after is changed, since that would defeat part 1396 of the denial of service protection. {{ Demoted the SHOULD }} The 1397 responder should change the value of frequently, especially 1398 if under attack. 1400 {{ Clarif-2.1 }} In addition to cookies, there are several cases 1401 where the IKE_SA_INIT exchange does not result in the creation of an 1402 IKE SA (such as INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). In such a 1403 case, sending a zero value for the Responder's SPI is correct. If 1404 the responder sends a non-zero responder SPI, the initiator should 1405 not reject the response for only that reason. 1407 {{ Clarif-2.5 }} When one party receives an IKE_SA_INIT request 1408 containing a cookie whose contents do not match the value expected, 1409 that party MUST ignore the cookie and process the message as if no 1410 cookie had been included; usually this means sending a response 1411 containing a new cookie. The initiator should limit the number of 1412 cookie exchanges it tries before giving up. An attacker can forge 1413 multiple cookie responses to the initiator's IKE_SA_INIT message, and 1414 each of those forged cookie reply will trigger two packets: one 1415 packet from the initiator to the responder (which will reject those 1416 cookies), and one reply from responder to initiator that includes the 1417 correct cookie. 1419 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD 1421 {{ This section added by Clarif-2.4 }} 1423 There are two common reasons why the initiator may have to retry the 1424 IKE_SA_INIT exchange: the responder requests a cookie or wants a 1425 different Diffie-Hellman group than was included in the KEi payload. 1426 If the initiator receives a cookie from the responder, the initiator 1427 needs to decide whether or not to include the cookie in only the next 1428 retry of the IKE_SA_INIT request, or in all subsequent retries as 1429 well. 1431 If the initiator includes the cookie only in the next retry, one 1432 additional roundtrip may be needed in some cases. An additional 1433 roundtrip is needed also if the initiator includes the cookie in all 1434 retries, but the responder does not support this. For instance, if 1435 the responder includes the SAi1 and KEi payloads in cookie 1436 calculation, it will reject the request by sending a new cookie. 1438 If both peers support including the cookie in all retries, a slightly 1439 shorter exchange can happen. 1441 Initiator Responder 1442 ----------------------------------------------------------- 1443 HDR(A,0), SAi1, KEi, Ni --> 1444 <-- HDR(A,0), N(COOKIE) 1445 HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> 1446 <-- HDR(A,0), N(INVALID_KE_PAYLOAD) 1447 HDR(A,0), N(COOKIE), SAi1, KEi', Ni --> 1448 <-- HDR(A,B), SAr1, KEr, Nr 1450 Implementations SHOULD support this shorter exchange, but MUST NOT 1451 fail if other implementations do not support this shorter exchange. 1453 2.7. Cryptographic Algorithm Negotiation 1455 The payload type known as "SA" indicates a proposal for a set of 1456 choices of IPsec protocols (IKE, ESP, or AH) for the SA as well as 1457 cryptographic algorithms associated with each protocol. 1459 An SA payload consists of one or more proposals. {{ Clarif-7.13 }} 1460 Each proposal includes one protocol. Each protocol contains one or 1461 more transforms -- each specifying a cryptographic algorithm. Each 1462 transform contains zero or more attributes (attributes are needed 1463 only if the transform identifier does not completely specify the 1464 cryptographic algorithm). 1466 This hierarchical structure was designed to efficiently encode 1467 proposals for cryptographic suites when the number of supported 1468 suites is large because multiple values are acceptable for multiple 1469 transforms. The responder MUST choose a single suite, which may be 1470 any subset of the SA proposal following the rules below: 1472 {{ Clarif-7.13 }} Each proposal contains one protocol. If a proposal 1473 is accepted, the SA response MUST contain the same protocol. The 1474 responder MUST accept a single proposal or reject them all and return 1475 an error. {{ 3.10.1-14 }} The error is given in a notification of 1476 type NO_PROPOSAL_CHOSEN. 1478 Each IPsec protocol proposal contains one or more transforms. Each 1479 transform contains a transform type. The accepted cryptographic 1480 suite MUST contain exactly one transform of each type included in the 1481 proposal. For example: if an ESP proposal includes transforms 1482 ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, 1483 AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one 1484 of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six 1485 combinations are acceptable. 1487 If an initiator proposes both normal ciphers with integrity 1488 protection as well as combined-mode ciphers, then two proposals are 1489 needed. One of the proposals includes the normal ciphers with the 1490 integrity algoritms for them, and the other proposal includes all the 1491 combined mode ciphers without the integrity algorithms (because 1492 combined mode ciphers are not allowed to have any integrity algorithm 1493 other than "none"). 1495 Since the initiator sends its Diffie-Hellman value in the 1496 IKE_SA_INIT, it must guess the Diffie-Hellman group that the 1497 responder will select from its list of supported groups. If the 1498 initiator guesses wrong, the responder will respond with a Notify 1499 payload of type INVALID_KE_PAYLOAD indicating the selected group. In 1500 this case, the initiator MUST retry the IKE_SA_INIT with the 1501 corrected Diffie-Hellman group. The initiator MUST again propose its 1502 full set of acceptable cryptographic suites because the rejection 1503 message was unauthenticated and otherwise an active attacker could 1504 trick the endpoints into negotiating a weaker suite than a stronger 1505 one that they both prefer. 1507 {{ Clarif-2.1 }} When the IKE_SA_INIT exchange does not result in the 1508 creation of an IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, 1509 or COOKIE (see Section 2.6), the responder's SPI will be zero. 1510 However, if the responder sends a non-zero responder SPI, the 1511 initiator should not reject the response for only that reason. 1513 2.8. Rekeying 1515 {{ Demoted the SHOULD }} IKE, ESP, and AH security associations use 1516 secret keys that should be used only for a limited amount of time and 1517 to protect a limited amount of data. This limits the lifetime of the 1518 entire security association. When the lifetime of a security 1519 association expires, the security association MUST NOT be used. If 1520 there is demand, new security associations MAY be established. 1521 Reestablishment of security associations to take the place of ones 1522 that expire is referred to as "rekeying". 1524 To allow for minimal IPsec implementations, the ability to rekey SAs 1525 without restarting the entire IKE SA is optional. An implementation 1526 MAY refuse all CREATE_CHILD_SA requests within an IKE SA. If an SA 1527 has expired or is about to expire and rekeying attempts using the 1528 mechanisms described here fail, an implementation MUST close the IKE 1529 SA and any associated Child SAs and then MAY start new ones. {{ 1530 Demoted the SHOULD }} Implementations may wish to support in-place 1531 rekeying of SAs, since doing so offers better performance and is 1532 likely to reduce the number of packets lost during the transition. 1534 To rekey a Child SA within an existing IKE SA, create a new, 1535 equivalent SA (see Section 2.17 below), and when the new one is 1536 established, delete the old one. To rekey an IKE SA, establish a new 1537 equivalent IKE SA (see Section 2.18 below) with the peer to whom the 1538 old IKE SA is shared using a CREATE_CHILD_SA within the existing IKE 1539 SA. An IKE SA so created inherits all of the original IKE SA's Child 1540 SAs, and the new IKE SA is used for all control messages needed to 1541 maintain those Child SAs. The old IKE SA is then deleted, and the 1542 Delete payload to delete itself MUST be the last request sent over 1543 the old IKE SA. Note that, when rekeying, the new Child SA MAY have 1544 different traffic selectors and algorithms than the old one. 1546 {{ Demoted the SHOULD }} SAs should be rekeyed proactively, i.e., the 1547 new SA should be established before the old one expires and becomes 1548 unusable. Enough time should elapse between the time the new SA is 1549 established and the old one becomes unusable so that traffic can be 1550 switched over to the new SA. 1552 A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes 1553 were negotiated. In IKEv2, each end of the SA is responsible for 1554 enforcing its own lifetime policy on the SA and rekeying the SA when 1555 necessary. If the two ends have different lifetime policies, the end 1556 with the shorter lifetime will end up always being the one to request 1557 the rekeying. If an SA has been inactive for a long time and if an 1558 endpoint would not initiate the SA in the absence of traffic, the 1559 endpoint MAY choose to close the SA instead of rekeying it when its 1560 lifetime expires. {{ Demoted the SHOULD }} It should do so if there 1561 has been no traffic since the last time the SA was rekeyed. 1563 Note that IKEv2 deliberately allows parallel SAs with the same 1564 traffic selectors between common endpoints. One of the purposes of 1565 this is to support traffic quality of service (QoS) differences among 1566 the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and section 4.1 of 1567 [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints 1568 and the traffic selectors may not uniquely identify an SA between 1569 those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on 1570 the basis of duplicate traffic selectors SHOULD NOT be used. 1572 {{ Demoted the SHOULD }} The node that initiated the surviving 1573 rekeyed SA should delete the replaced SA after the new one is 1574 established. 1576 There are timing windows -- particularly in the presence of lost 1577 packets -- where endpoints may not agree on the state of an SA. The 1578 responder to a CREATE_CHILD_SA MUST be prepared to accept messages on 1579 an SA before sending its response to the creation request, so there 1580 is no ambiguity for the initiator. The initiator MAY begin sending 1581 on an SA as soon as it processes the response. The initiator, 1582 however, cannot receive on a newly created SA until it receives and 1583 processes the response to its CREATE_CHILD_SA request. How, then, is 1584 the responder to know when it is OK to send on the newly created SA? 1586 From a technical correctness and interoperability perspective, the 1587 responder MAY begin sending on an SA as soon as it sends its response 1588 to the CREATE_CHILD_SA request. In some situations, however, this 1589 could result in packets unnecessarily being dropped, so an 1590 implementation MAY defer such sending. 1592 The responder can be assured that the initiator is prepared to 1593 receive messages on an SA if either (1) it has received a 1594 cryptographically valid message on the new SA, or (2) the new SA 1595 rekeys an existing SA and it receives an IKE request to close the 1596 replaced SA. When rekeying an SA, the responder continues to send 1597 traffic on the old SA until one of those events occurs. When 1598 establishing a new SA, the responder MAY defer sending messages on a 1599 new SA until either it receives one or a timeout has occurred. {{ 1600 Demoted the SHOULD }} If an initiator receives a message on an SA for 1601 which it has not received a response to its CREATE_CHILD_SA request, 1602 it interprets that as a likely packet loss and retransmits the 1603 CREATE_CHILD_SA request. An initiator MAY send a dummy message on a 1604 newly created SA if it has no messages queued in order to assure the 1605 responder that the initiator is ready to receive messages. 1607 2.8.1. Simultaneous Child SA rekeying 1609 {{ The first two paragraphs were moved, and the rest was added, based 1610 on Clarif-5.11 }} 1612 If the two ends have the same lifetime policies, it is possible that 1613 both will initiate a rekeying at the same time (which will result in 1614 redundant SAs). To reduce the probability of this happening, the 1615 timing of rekeying requests SHOULD be jittered (delayed by a random 1616 amount of time after the need for rekeying is noticed). 1618 This form of rekeying may temporarily result in multiple similar SAs 1619 between the same pairs of nodes. When there are two SAs eligible to 1620 receive packets, a node MUST accept incoming packets through either 1621 SA. If redundant SAs are created though such a collision, the SA 1622 created with the lowest of the four nonces used in the two exchanges 1623 SHOULD be closed by the endpoint that created it. {{ Clarif-5.10 }} 1624 "Lowest" means an octet-by-octet, lexicographical comparison (instead 1625 of, for instance, comparing the nonces as large integers). In other 1626 words, start by comparing the first octet; if they're equal, move to 1627 the next octet, and so on. If you reach the end of one nonce, that 1628 nonce is the lower one. 1630 The following is an explanation on the impact this has on 1631 implementations. Assume that hosts A and B have an existing IPsec SA 1632 pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same 1633 time: 1635 Host A Host B 1636 ------------------------------------------------------------------- 1637 send req1: N(REKEY_SA,SPIa1), 1638 SA(..,SPIa2,..),Ni1,.. --> 1639 <-- send req2: N(REKEY_SA,SPIb1), 1640 SA(..,SPIb2,..),Ni2 1641 recv req2 <-- 1643 At this point, A knows there is a simultaneous rekeying going on. 1644 However, it cannot yet know which of the exchanges will have the 1645 lowest nonce, so it will just note the situation and respond as 1646 usual. 1648 send resp2: SA(..,SPIa3,..), 1649 Nr1,.. --> 1650 --> recv req1 1652 Now B also knows that simultaneous rekeying is going on. It responds 1653 as usual. 1655 <-- send resp1: SA(..,SPIb3,..), 1656 Nr2,.. 1657 recv resp1 <-- 1658 --> recv resp2 1660 At this point, there are three Child SA pairs between A and B (the 1661 old one and two new ones). A and B can now compare the nonces. 1662 Suppose that the lowest nonce was Nr1 in message resp2; in this case, 1663 B (the sender of req2) deletes the redundant new SA, and A (the node 1664 that initiated the surviving rekeyed SA), deletes the old one. 1666 send req3: D(SPIa1) --> 1667 <-- send req4: D(SPIb2) 1668 --> recv req3 1669 <-- send resp3: D(SPIb1) 1670 recv req4 <-- 1671 send resp4: D(SPIa3) --> 1673 The rekeying is now finished. 1675 However, there is a second possible sequence of events that can 1676 happen if some packets are lost in the network, resulting in 1677 retransmissions. The rekeying begins as usual, but A's first packet 1678 (req1) is lost. 1680 Host A Host B 1681 ------------------------------------------------------------------- 1682 send req1: N(REKEY_SA,SPIa1), 1683 SA(..,SPIa2,..), 1684 Ni1,.. --> (lost) 1685 <-- send req2: N(REKEY_SA,SPIb1), 1686 SA(..,SPIb2,..),Ni2 1687 recv req2 <-- 1688 send resp2: SA(..,SPIa3,..), 1689 Nr1,.. --> 1690 --> recv resp2 1691 <-- send req3: D(SPIb1) 1692 recv req3 <-- 1693 send resp3: D(SPIa1) --> 1694 --> recv resp3 1696 From B's point of view, the rekeying is now completed, and since it 1697 has not yet received A's req1, it does not even know that there was 1698 simultaneous rekeying. However, A will continue retransmitting the 1699 message, and eventually it will reach B. 1701 resend req1 --> 1702 --> recv req1 1704 To B, it looks like A is trying to rekey an SA that no longer exists; 1705 thus, B responds to the request with something non-fatal such as 1706 NO_PROPOSAL_CHOSEN. 1708 <-- send resp1: N(NO_PROPOSAL_CHOSEN) 1709 recv resp1 <-- 1711 When A receives this error, it already knows there was simultaneous 1712 rekeying, so it can ignore the error message. 1714 2.8.2. Simultaneous IKE SA Rekeying 1716 Probably the most complex case occurs when both peers try to rekey 1717 the IKE_SA at the same time. Basically, the text in Section 2.8 1718 applies to this case as well; however, it is important to ensure that 1719 the CHILD_SAs are inherited by the right IKE_SA. 1721 The case where both endpoints notice the simultaneous rekeying works 1722 the same way as with CHILD_SAs. After the CREATE_CHILD_SA exchanges, 1723 three IKE_SAs exist between A and B; the one containing the lowest 1724 nonce inherits the CHILD_SAs. 1726 However, there is a twist to the other case where one rekeying 1727 finishes first: 1729 Host A Host B 1730 ------------------------------------------------------------------- 1731 send req1: 1732 SA(..,SPIa1,..),Ni1,.. --> 1733 <-- send req2: SA(..,SPIb1,..),Ni2,.. 1734 --> recv req1 1735 <-- send resp1: SA(..,SPIb2,..),Nr2,.. 1736 recv resp1 <-- 1737 send req3: D() --> 1738 --> recv req3 1740 At this point, host B sees a request to close the IKE_SA. There's 1741 not much more to do than to reply as usual. However, at this point 1742 host B should stop retransmitting req2, since once host A receives 1743 resp3, it will delete all the state associated with the old IKE_SA 1744 and will not be able to reply to it. 1746 <-- send resp3: () 1748 2.8.3. Rekeying the IKE SA Versus Reauthentication 1750 {{ Added this section from Clarif-5.2 }} 1752 Rekeying the IKE SA and reauthentication are different concepts in 1753 IKEv2. Rekeying the IKE SA establishes new keys for the IKE SA and 1754 resets the Message ID counters, but it does not authenticate the 1755 parties again (no AUTH or EAP payloads are involved). 1757 Although rekeying the IKE SA may be important in some environments, 1758 reauthentication (the verification that the parties still have access 1759 to the long-term credentials) is often more important. 1761 IKEv2 does not have any special support for reauthentication. 1762 Reauthentication is done by creating a new IKE SA from scratch (using 1763 IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify 1764 payloads), creating new Child SAs within the new IKE SA (without 1765 REKEY_SA notify payloads), and finally deleting the old IKE SA (which 1766 deletes the old Child SAs as well). 1768 This means that reauthentication also establishes new keys for the 1769 IKE SA and Child SAs. Therefore, while rekeying can be performed 1770 more often than reauthentication, the situation where "authentication 1771 lifetime" is shorter than "key lifetime" does not make sense. 1773 While creation of a new IKE SA can be initiated by either party 1774 (initiator or responder in the original IKE SA), the use of EAP 1775 authentication and/or configuration payloads means in practice that 1776 reauthentication has to be initiated by the same party as the 1777 original IKE SA. IKEv2 does not currently allow the responder to 1778 request reauthentication in this case; however, there are extensions 1779 that add this functionality such as [REAUTH]. 1781 2.9. Traffic Selector Negotiation 1783 {{ Clarif-7.2 }} When an RFC4301-compliant IPsec subsystem receives 1784 an IP packet that matches a "protect" selector in its Security Policy 1785 Database (SPD), the subsystem protects that packet with IPsec. When 1786 no SA exists yet, it is the task of IKE to create it. Maintenance of 1787 a system's SPD is outside the scope of IKE (see [PFKEY] for an 1788 example protocol, although it only applies to IKEv1), though some 1789 implementations might update their SPD in connection with the running 1790 of IKE (for an example scenario, see Section 1.1.3). 1792 Traffic Selector (TS) payloads allow endpoints to communicate some of 1793 the information from their SPD to their peers. TS payloads specify 1794 the selection criteria for packets that will be forwarded over the 1795 newly set up SA. This can serve as a consistency check in some 1796 scenarios to assure that the SPDs are consistent. In others, it 1797 guides the dynamic update of the SPD. 1799 Two TS payloads appear in each of the messages in the exchange that 1800 creates a Child SA pair. Each TS payload contains one or more 1801 Traffic Selectors. Each Traffic Selector consists of an address 1802 range (IPv4 or IPv6), a port range, and an IP protocol ID. 1804 The first of the two TS payloads is known as TSi (Traffic Selector- 1805 initiator). The second is known as TSr (Traffic Selector-responder). 1806 TSi specifies the source address of traffic forwarded from (or the 1807 destination address of traffic forwarded to) the initiator of the 1808 Child SA pair. TSr specifies the destination address of the traffic 1809 forwarded to (or the source address of the traffic forwarded from) 1810 the responder of the Child SA pair. For example, if the original 1811 initiator requests the creation of a Child SA pair, and wishes to 1812 tunnel all traffic from subnet 192.0.1.* on the initiator's side to 1813 subnet 192.0.2.* on the responder's side, the initiator would include 1814 a single traffic selector in each TS payload. TSi would specify the 1815 address range (192.0.1.0 - 192.0.1.255) and TSr would specify the 1816 address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was 1817 acceptable to the responder, it would send identical TS payloads 1818 back. (Note: The IP address range 192.0.2.* has been reserved for 1819 use in examples in RFCs and similar documents. This document needed 1820 two such ranges, and so also used 192.0.1.*. This should not be 1821 confused with any actual address.) 1823 IKEv2 allows the responder to choose a subset of the traffic proposed 1824 by the initiator. This could happen when the configurations of the 1825 two endpoints are being updated but only one end has received the new 1826 information. Since the two endpoints may be configured by different 1827 people, the incompatibility may persist for an extended period even 1828 in the absence of errors. It also allows for intentionally different 1829 configurations, as when one end is configured to tunnel all addresses 1830 and depends on the other end to have the up-to-date list. 1832 When the responder chooses a subset of the traffic proposed by the 1833 initiator, it narrows the traffic selectors to some subset of the 1834 initiator's proposal (provided the set does not become the null set). 1835 If the type of traffic selector proposed is unknown, the responder 1836 ignores that traffic selector, so that the unknown type is not be 1837 returned in the narrowed set. 1839 To enable the responder to choose the appropriate range in this case, 1840 if the initiator has requested the SA due to a data packet, the 1841 initiator SHOULD include as the first traffic selector in each of TSi 1842 and TSr a very specific traffic selector including the addresses in 1843 the packet triggering the request. In the example, the initiator 1844 would include in TSi two traffic selectors: the first containing the 1845 address range (192.0.1.43 - 192.0.1.43) and the source port and IP 1846 protocol from the packet and the second containing (192.0.1.0 - 1847 192.0.1.255) with all ports and IP protocols. The initiator would 1848 similarly include two traffic selectors in TSr. If the initiator 1849 creates the Child SA pair not in response to an arriving packet, but 1850 rather, say, upon startup, then there may be no specific addresses 1851 the initiator prefers for the initial tunnel over any other. In that 1852 case, the first values in TSi and TSr can be ranges rather than 1853 specific values. 1855 The responder performs the narrowing as follows: {{ Clarif-4.10 }} 1857 o If the responder's policy does not allow it to accept any part of 1858 the proposed traffic selectors, it responds with TS_UNACCEPTABLE. 1860 o If the responder's policy allows the entire set of traffic covered 1861 by TSi and TSr, no narrowing is necessary, and the responder can 1862 return the same TSi and TSr values. 1864 o If the responder's policy allows it to accept the first selector 1865 of TSi and TSr, then the responder MUST narrow the traffic 1866 selectors to a subset that includes the initiator's first choices. 1867 In this example above, the responder might respond with TSi being 1868 (192.0.1.43 - 192.0.1.43) with all ports and IP protocols. 1870 o If the responder's policy does not allow it to accept the first 1871 selector of TSi and TSr, the responder narrows to an acceptable 1872 subset of TSi and TSr. 1874 When narrowing is done, there may be several subsets that are 1875 acceptable but their union is not. In this case, the responder 1876 arbitrarily chooses one of them, and MAY include an 1877 ADDITIONAL_TS_POSSIBLE notification in the response. {{ 3.10.1-16386 1878 }} The ADDITIONAL_TS_POSSIBLE notification asserts that the responder 1879 narrowed the proposed traffic selectors but that other traffic 1880 selectors would also have been acceptable, though only in a separate 1881 SA. There is no data associated with this Notify type. This case 1882 will occur only when the initiator and responder are configured 1883 differently from one another. If the initiator and responder agree 1884 on the granularity of tunnels, the initiator will never request a 1885 tunnel wider than the responder will accept. {{ Demoted the SHOULD }} 1886 Such misconfigurations should be recorded in error logs. 1888 It is possible for the responder's policy to contain multiple smaller 1889 ranges, all encompassed by the initiator's traffic selector, and with 1890 the responder's policy being that each of those ranges should be sent 1891 over a different SA. Continuing the example above, the responder 1892 might have a policy of being willing to tunnel those addresses to and 1893 from the initiator, but might require that each address pair be on a 1894 separately negotiated Child SA. If the initiator generated its 1895 request in response to an incoming packet from 192.0.1.43 to 1896 192.0.2.123, there would be no way for the responder to determine 1897 which pair of addresses should be included in this tunnel, and it 1898 would have to make a guess or reject the request with a status of 1899 SINGLE_PAIR_REQUIRED. 1901 {{ 3.10.1-34 }} The SINGLE_PAIR_REQUIRED error indicates that a 1902 CREATE_CHILD_SA request is unacceptable because its sender is only 1903 willing to accept traffic selectors specifying a single pair of 1904 addresses. The requestor is expected to respond by requesting an SA 1905 for only the specific traffic it is trying to forward. 1907 {{ Clarif-4.11 }} Few implementations will have policies that require 1908 separate SAs for each address pair. Because of this, if only some 1909 parts of the TSi and TSr proposed by the initiator are acceptable to 1910 the responder, responders SHOULD narrow the selectors to an 1911 acceptable subset rather than use SINGLE_PAIR_REQUIRED. 1913 2.9.1. Traffic Selectors Violating Own Policy 1915 {{ Clarif-4.12 }} 1917 When creating a new SA, the initiator needs to avoid proposing 1918 traffic selectors that violate its own policy. If this rule is not 1919 followed, valid traffic may be dropped. If you use decorrelated 1920 policies from [IPSECARCH], this kind of policy violations cannot 1921 happen. 1923 This is best illustrated by an example. Suppose that host A has a 1924 policy whose effect is that traffic to 192.0.1.66 is sent via host B 1925 encrypted using AES, and traffic to all other hosts in 192.0.1.0/24 1926 is also sent via B, but must use 3DES. Suppose also that host B 1927 accepts any combination of AES and 3DES. 1929 If host A now proposes an SA that uses 3DES, and includes TSr 1930 containing (192.0.1.0-192.0.1.255), this will be accepted by host B. 1931 Now, host B can also use this SA to send traffic from 192.0.1.66, but 1932 those packets will be dropped by A since it requires the use of AES 1933 for those traffic. Even if host A creates a new SA only for 1934 192.0.1.66 that uses AES, host B may freely continue to use the first 1935 SA for the traffic. In this situation, when proposing the SA, host A 1936 should have followed its own policy, and included a TSr containing 1937 ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead. 1939 In general, if (1) the initiator makes a proposal "for traffic X 1940 (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator 1941 does not actually accept traffic X' with SA, and (3) the initiator 1942 would be willing to accept traffic X' with some SA' (!=SA), valid 1943 traffic can be unnecessarily dropped since the responder can apply 1944 either SA or SA' to traffic X'. 1946 2.10. Nonces 1948 The IKE_SA_INIT messages each contain a nonce. These nonces are used 1949 as inputs to cryptographic functions. The CREATE_CHILD_SA request 1950 and the CREATE_CHILD_SA response also contain nonces. These nonces 1951 are used to add freshness to the key derivation technique used to 1952 obtain keys for Child SA, and to ensure creation of strong pseudo- 1953 random bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST 1954 be randomly chosen, MUST be at least 128 bits in size, and MUST be at 1955 least half the key size of the negotiated prf. ("prf" refers to 1956 "pseudo-random function", one of the cryptographic algorithms 1957 negotiated in the IKE exchange.) {{ Clarif-7.4 }} However, the 1958 initiator chooses the nonce before the outcome of the negotiation is 1959 known. Because of that, the nonce has to be long enough for all the 1960 PRFs being proposed. If the same random number source is used for 1961 both keys and nonces, care must be taken to ensure that the latter 1962 use does not compromise the former. 1964 2.11. Address and Port Agility 1966 IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and 1967 AH associations for the same IP addresses it runs over. The IP 1968 addresses and ports in the outer header are, however, not themselves 1969 cryptographically protected, and IKE is designed to work even through 1970 Network Address Translation (NAT) boxes. An implementation MUST 1971 accept incoming requests even if the source port is not 500 or 4500, 1972 and MUST respond to the address and port from which the request was 1973 received. It MUST specify the address and port at which the request 1974 was received as the source address and port in the response. IKE 1975 functions identically over IPv4 or IPv6. 1977 2.12. Reuse of Diffie-Hellman Exponentials 1979 IKE generates keying material using an ephemeral Diffie-Hellman 1980 exchange in order to gain the property of "perfect forward secrecy". 1981 This means that once a connection is closed and its corresponding 1982 keys are forgotten, even someone who has recorded all of the data 1983 from the connection and gets access to all of the long-term keys of 1984 the two endpoints cannot reconstruct the keys used to protect the 1985 conversation without doing a brute force search of the session key 1986 space. 1988 Achieving perfect forward secrecy requires that when a connection is 1989 closed, each endpoint MUST forget not only the keys used by the 1990 connection but also any information that could be used to recompute 1991 those keys. 1993 Since the computing of Diffie-Hellman exponentials is computationally 1994 expensive, an endpoint may find it advantageous to reuse those 1995 exponentials for multiple connection setups. There are several 1996 reasonable strategies for doing this. An endpoint could choose a new 1997 exponential only periodically though this could result in less-than- 1998 perfect forward secrecy if some connection lasts for less than the 1999 lifetime of the exponential. Or it could keep track of which 2000 exponential was used for each connection and delete the information 2001 associated with the exponential only when some corresponding 2002 connection was closed. This would allow the exponential to be reused 2003 without losing perfect forward secrecy at the cost of maintaining 2004 more state. 2006 Decisions as to whether and when to reuse Diffie-Hellman exponentials 2007 is a private decision in the sense that it will not affect 2008 interoperability. An implementation that reuses exponentials MAY 2009 choose to remember the exponential used by the other endpoint on past 2010 exchanges and if one is reused to avoid the second half of the 2011 calculation. See [REUSE] for a security analysis of this practice 2012 and for additional security considerations when reusing ephemeral DH 2013 keys. 2015 2.13. Generating Keying Material 2017 In the context of the IKE SA, four cryptographic algorithms are 2018 negotiated: an encryption algorithm, an integrity protection 2019 algorithm, a Diffie-Hellman group, and a pseudo-random function 2020 (prf). The pseudo-random function is used for the construction of 2021 keying material for all of the cryptographic algorithms used in both 2022 the IKE SA and the Child SAs. 2024 We assume that each encryption algorithm and integrity protection 2025 algorithm uses a fixed-size key and that any randomly chosen value of 2026 that fixed size can serve as an appropriate key. For algorithms that 2027 accept a variable length key, a fixed key size MUST be specified as 2028 part of the cryptographic transform negotiated (see Section 3.3.5 for 2029 the defintion of the Key Length transform attribute). For algorithms 2030 for which not all values are valid keys (such as DES or 3DES with key 2031 parity), the algorithm by which keys are derived from arbitrary 2032 values MUST be specified by the cryptographic transform. For 2033 integrity protection functions based on Hashed Message Authentication 2034 Code (HMAC), the fixed key size is the size of the output of the 2035 underlying hash function. 2037 It is assumed that pseudo-random functions (PRFs) accept keys of any 2038 length, but have a preferred key size. The preferred key size is 2039 used as the length of SK_d, SK_pi, and SK_pr (see Section 2.14). For 2040 PRFs based on the HMAC construction, the preferred key size is equal 2041 to the length of the output of the underlying hash function. Other 2042 types of PRFs MUST specify their preferred key size. 2044 Keying material will always be derived as the output of the 2045 negotiated prf algorithm. Since the amount of keying material needed 2046 may be greater than the size of the output of the prf algorithm, we 2047 will use the prf iteratively. We will use the terminology prf+ to 2048 describe the function that outputs a pseudo-random stream based on 2049 the inputs to a prf as follows: (where | indicates concatenation) 2051 prf+ (K,S) = T1 | T2 | T3 | T4 | ... 2053 where: 2054 T1 = prf (K, S | 0x01) 2055 T2 = prf (K, T1 | S | 0x02) 2056 T3 = prf (K, T2 | S | 0x03) 2057 T4 = prf (K, T3 | S | 0x04) 2059 continuing as needed to compute all required keys. The keys are 2060 taken from the output string without regard to boundaries (e.g., if 2061 the required keys are a 256-bit Advanced Encryption Standard (AES) 2062 key and a 160-bit HMAC key, and the prf function generates 160 bits, 2063 the AES key will come from T1 and the beginning of T2, while the HMAC 2064 key will come from the rest of T2 and the beginning of T3). 2066 The constant concatenated to the end of each string feeding the prf 2067 is a single octet. prf+ in this document is not defined beyond 255 2068 times the size of the prf output. 2070 2.14. Generating Keying Material for the IKE SA 2072 The shared keys are computed as follows. A quantity called SKEYSEED 2073 is calculated from the nonces exchanged during the IKE_SA_INIT 2074 exchange and the Diffie-Hellman shared secret established during that 2075 exchange. SKEYSEED is used to calculate seven other secrets: SK_d 2076 used for deriving new keys for the Child SAs established with this 2077 IKE SA; SK_ai and SK_ar used as a key to the integrity protection 2078 algorithm for authenticating the component messages of subsequent 2079 exchanges; SK_ei and SK_er used for encrypting (and of course 2080 decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are 2081 used when generating an AUTH payload. The lengths of SK_d, SK_pi, 2082 and SK_pr are the preferred key length of the agreed-to PRF. 2084 SKEYSEED and its derivatives are computed as follows: 2086 SKEYSEED = prf(Ni | Nr, g^ir) 2088 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } 2089 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) 2091 (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, 2092 SK_pi, and SK_pr are taken in order from the generated bits of the 2093 prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman 2094 exchange. g^ir is represented as a string of octets in big endian 2095 order padded with zeros if necessary to make it the length of the 2096 modulus. Ni and Nr are the nonces, stripped of any headers. For 2097 historical backwards-compatibility reasons, there are two PRFs that 2098 are treated specially in this calculation. If the negotiated PRF is 2099 AES-XCBC-PRF-128 [RFC4434] or AES-CMAC-PRF-128 [RFC4615], only the 2100 first 64 bits of Ni and the first 64 bits of Nr are used in the 2101 calculation. 2103 The two directions of traffic flow use different keys. The keys used 2104 to protect messages from the original initiator are SK_ai and SK_ei. 2105 The keys used to protect messages in the other direction are SK_ar 2106 and SK_er. 2108 2.15. Authentication of the IKE SA 2110 When not using extensible authentication (see Section 2.16), the 2111 peers are authenticated by having each sign (or MAC using a shared 2112 secret as the key) a block of data. For the responder, the octets to 2113 be signed start with the first octet of the first SPI in the header 2114 of the second message (IKE_SA_INIT response) and end with the last 2115 octet of the last payload in the second message. Appended to this 2116 (for purposes of computing the signature) are the initiator's nonce 2117 Ni (just the value, not the payload containing it), and the value 2118 prf(SK_pr,IDr') where IDr' is the responder's ID payload excluding 2119 the fixed header. Note that neither the nonce Ni nor the value 2120 prf(SK_pr,IDr') are transmitted. Similarly, the initiator signs the 2121 first message (IKE_SA_INIT request), starting with the first octet of 2122 the first SPI in the header and ending with the last octet of the 2123 last payload. Appended to this (for purposes of computing the 2124 signature) are the responder's nonce Nr, and the value 2125 prf(SK_pi,IDi'). In the above calculation, IDi' and IDr' are the 2126 entire ID payloads excluding the fixed header. It is critical to the 2127 security of the exchange that each side sign the other side's nonce. 2129 {{ Clarif-3.1 }} 2131 The initiator's signed octets can be described as: 2133 InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI 2134 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 2135 RealIKEHDR = SPIi | SPIr | . . . | Length 2136 RealMessage1 = RealIKEHDR | RestOfMessage1 2137 NonceRPayload = PayloadHeader | NonceRData 2138 InitiatorIDPayload = PayloadHeader | RestOfIDPayload 2139 RestOfInitIDPayload = IDType | RESERVED | InitIDData 2140 MACedIDForI = prf(SK_pi, RestOfInitIDPayload) 2142 The responder's signed octets can be described as: 2144 ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR 2145 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 2146 RealIKEHDR = SPIi | SPIr | . . . | Length 2147 RealMessage2 = RealIKEHDR | RestOfMessage2 2148 NonceIPayload = PayloadHeader | NonceIData 2149 ResponderIDPayload = PayloadHeader | RestOfIDPayload 2150 RestOfRespIDPayload = IDType | RESERVED | RespIDData 2151 MACedIDForR = prf(SK_pr, RestOfRespIDPayload) 2153 Note that all of the payloads are included under the signature, 2154 including any payload types not defined in this document. If the 2155 first message of the exchange is sent multiple times (such as with a 2156 responder cookie and/or a different Diffie-Hellman group), it is the 2157 latest version of the message that is signed. 2159 Optionally, messages 3 and 4 MAY include a certificate, or 2160 certificate chain providing evidence that the key used to compute a 2161 digital signature belongs to the name in the ID payload. The 2162 signature or MAC will be computed using algorithms dictated by the 2163 type of key used by the signer, and specified by the Auth Method 2164 field in the Authentication payload. There is no requirement that 2165 the initiator and responder sign with the same cryptographic 2166 algorithms. The choice of cryptographic algorithms depends on the 2167 type of key each has. In particular, the initiator may be using a 2168 shared key while the responder may have a public signature key and 2169 certificate. It will commonly be the case (but it is not required) 2170 that if a shared secret is used for authentication that the same key 2171 is used in both directions. 2173 Note that it is a common but typically insecure practice to have a 2174 shared key derived solely from a user-chosen password without 2175 incorporating another source of randomness. This is typically 2176 insecure because user-chosen passwords are unlikely to have 2177 sufficient unpredictability to resist dictionary attacks and these 2178 attacks are not prevented in this authentication method. 2179 (Applications using password-based authentication for bootstrapping 2180 and IKE SA should use the authentication method in Section 2.16, 2181 which is designed to prevent off-line dictionary attacks.) {{ Demoted 2182 the SHOULD }} The pre-shared key needs to contain as much 2183 unpredictability as the strongest key being negotiated. In the case 2184 of a pre-shared key, the AUTH value is computed as: 2186 For the initiator: 2187 AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"), 2188 ) 2189 For the responder: 2190 AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"), 2191 ) 2193 where the string "Key Pad for IKEv2" is 17 ASCII characters without 2194 null termination. The shared secret can be variable length. The pad 2195 string is added so that if the shared secret is derived from a 2196 password, the IKE implementation need not store the password in 2197 cleartext, but rather can store the value prf(Shared Secret,"Key Pad 2198 for IKEv2"), which could not be used as a password equivalent for 2199 protocols other than IKEv2. As noted above, deriving the shared 2200 secret from a password is not secure. This construction is used 2201 because it is anticipated that people will do it anyway. The 2202 management interface by which the Shared Secret is provided MUST 2203 accept ASCII strings of at least 64 octets and MUST NOT add a null 2204 terminator before using them as shared secrets. It MUST also accept 2205 a hex encoding of the Shared Secret. The management interface MAY 2206 accept other encodings if the algorithm for translating the encoding 2207 to a binary string is specified. 2209 2.16. Extensible Authentication Protocol Methods 2211 In addition to authentication using public key signatures and shared 2212 secrets, IKE supports authentication using methods defined in RFC 2213 3748 [EAP]. Typically, these methods are asymmetric (designed for a 2214 user authenticating to a server), and they may not be mutual. For 2215 this reason, these protocols are typically used to authenticate the 2216 initiator to the responder and MUST be used in conjunction with a 2217 public key signature based authentication of the responder to the 2218 initiator. These methods are often associated with mechanisms 2219 referred to as "Legacy Authentication" mechanisms. 2221 While this memo references [EAP] with the intent that new methods can 2222 be added in the future without updating this specification, some 2223 simpler variations are documented here and in Section 3.16. [EAP] 2224 defines an authentication protocol requiring a variable number of 2225 messages. Extensible Authentication is implemented in IKE as 2226 additional IKE_AUTH exchanges that MUST be completed in order to 2227 initialize the IKE SA. 2229 An initiator indicates a desire to use extensible authentication by 2230 leaving out the AUTH payload from message 3. By including an IDi 2231 payload but not an AUTH payload, the initiator has declared an 2232 identity but has not proven it. If the responder is willing to use 2233 an extensible authentication method, it will place an Extensible 2234 Authentication Protocol (EAP) payload in message 4 and defer sending 2235 SAr2, TSi, and TSr until initiator authentication is complete in a 2236 subsequent IKE_AUTH exchange. In the case of a minimal extensible 2237 authentication, the initial SA establishment will appear as follows: 2239 Initiator Responder 2240 ------------------------------------------------------------------- 2241 HDR, SAi1, KEi, Ni --> 2242 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 2243 HDR, SK {IDi, [CERTREQ,] 2244 [IDr,] SAi2, 2245 TSi, TSr} --> 2246 <-- HDR, SK {IDr, [CERT,] AUTH, 2247 EAP } 2248 HDR, SK {EAP} --> 2249 <-- HDR, SK {EAP (success)} 2250 HDR, SK {AUTH} --> 2251 <-- HDR, SK {AUTH, SAr2, TSi, TSr } 2253 {{ Clarif-3.10 }} As described in Section 2.2, when EAP is used, each 2254 pair of IKE SA initial setup messages will have their message numbers 2255 incremented; the first pair of AUTH messages will have an ID of 1, 2256 the second will be 2, and so on. 2258 For EAP methods that create a shared key as a side effect of 2259 authentication, that shared key MUST be used by both the initiator 2260 and responder to generate AUTH payloads in messages 7 and 8 using the 2261 syntax for shared secrets specified in Section 2.15. The shared key 2262 from EAP is the field from the EAP specification named MSK. This 2263 shared key generated during an IKE exchange MUST NOT be used for any 2264 other purpose. 2266 EAP methods that do not establish a shared key SHOULD NOT be used, as 2267 they are subject to a number of man-in-the-middle attacks [EAPMITM] 2268 if these EAP methods are used in other protocols that do not use a 2269 server-authenticated tunnel. Please see the Security Considerations 2270 section for more details. If EAP methods that do not generate a 2271 shared key are used, the AUTH payloads in messages 7 and 8 MUST be 2272 generated using SK_pi and SK_pr, respectively. 2274 {{ Demoted the SHOULD }} The initiator of an IKE SA using EAP needs 2275 to be capable of extending the initial protocol exchange to at least 2276 ten IKE_AUTH exchanges in the event the responder sends notification 2277 messages and/or retries the authentication prompt. Once the protocol 2278 exchange defined by the chosen EAP authentication method has 2279 successfully terminated, the responder MUST send an EAP payload 2280 containing the Success message. Similarly, if the authentication 2281 method has failed, the responder MUST send an EAP payload containing 2282 the Failure message. The responder MAY at any time terminate the IKE 2283 exchange by sending an EAP payload containing the Failure message. 2285 Following such an extended exchange, the EAP AUTH payloads MUST be 2286 included in the two messages following the one containing the EAP 2287 Success message. 2289 {{ Clarif-3.5 }} When the initiator authentication uses EAP, it is 2290 possible that the contents of the IDi payload is used only for AAA 2291 routing purposes and selecting which EAP method to use. This value 2292 may be different from the identity authenticated by the EAP method. 2293 It is important that policy lookups and access control decisions use 2294 the actual authenticated identity. Often the EAP server is 2295 implemented in a separate AAA server that communicates with the IKEv2 2296 responder. In this case, the authenticated identity has to be sent 2297 from the AAA server to the IKEv2 responder. 2299 2.17. Generating Keying Material for Child SAs 2301 A single Child SA is created by the IKE_AUTH exchange, and additional 2302 Child SAs can optionally be created in CREATE_CHILD_SA exchanges. 2303 Keying material for them is generated as follows: 2305 KEYMAT = prf+(SK_d, Ni | Nr) 2307 Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this 2308 request is the first Child SA created or the fresh Ni and Nr from the 2309 CREATE_CHILD_SA exchange if this is a subsequent creation. 2311 For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman 2312 exchange, the keying material is defined as: 2314 KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) 2316 where g^ir (new) is the shared secret from the ephemeral Diffie- 2317 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 2318 octet string in big endian order padded with zeros in the high-order 2319 bits if necessary to make it the length of the modulus). 2321 For ESP and AH, a single Child SA negotiation results in two security 2322 associations (one in each direction). Keying material MUST be taken 2323 from the expanded KEYMAT in the following order: 2325 o The encryption key (if any) for the SA carrying data from the 2326 initiator to the responder. 2328 o The authentication key (if any) for the SA carrying data from the 2329 initiator to the responder. 2331 o The encryption key (if any) for the SA carrying data from the 2332 responder to the initiator. 2334 o The authentication key (if any) for the SA carrying data from the 2335 responder to the initiator. 2337 Each cryptographic algorithm takes a fixed number of bits of keying 2338 material specified as part of the algorithm, or negotiated in SA 2339 payloads (see Section 2.13 for description of key lengths, and 2340 Section 3.3.5 for the definition of the Key Length transform 2341 attribute). 2343 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange 2345 The CREATE_CHILD_SA exchange can be used to rekey an existing IKE SA 2346 (see Section 2.8). {{ Clarif-5.3 }} New initiator and responder SPIs 2347 are supplied in the SPI fields in the Proposal structures inside the 2348 Security Association (SA) payloads (not the SPI fields in the IKE 2349 header). The TS payloads are omitted when rekeying an IKE SA. 2350 SKEYSEED for the new IKE SA is computed using SK_d from the existing 2351 IKE SA as follows: 2353 SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr) 2355 where g^ir (new) is the shared secret from the ephemeral Diffie- 2356 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 2357 octet string in big endian order padded with zeros if necessary to 2358 make it the length of the modulus) and Ni and Nr are the two nonces 2359 stripped of any headers. 2361 {{ Clarif-5.5 }} The old and new IKE SA may have selected a different 2362 PRF. Because the rekeying exchange belongs to the old IKE SA, it is 2363 the old IKE SA's PRF that is used. 2365 {{ Clarif-5.12}} The main reason for rekeying the IKE SA is to ensure 2366 that the compromise of old keying material does not provide 2367 information about the current keys, or vice versa. Therefore, 2368 implementations MUST perform a new Diffie-Hellman exchange when 2369 rekeying the IKE SA. In other words, an initiator MUST NOT propose 2370 the value "NONE" for the D-H transform, and a responder MUST NOT 2371 accept such a proposal. This means that a succesful exchange 2372 rekeying the IKE SA always includes the KEi/KEr payloads. 2374 The new IKE SA MUST reset its message counters to 0. 2376 SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as 2377 specified in Section 2.14. 2379 2.19. Requesting an Internal Address on a Remote Network 2381 Most commonly occurring in the endpoint-to-security-gateway scenario, 2382 an endpoint may need an IP address in the network protected by the 2383 security gateway and may need to have that address dynamically 2384 assigned. A request for such a temporary address can be included in 2385 any request to create a Child SA (including the implicit request in 2386 message 3) by including a CP payload. Note, however, it is usual to 2387 only assign one IP address during the IKE_AUTH exchange. That 2388 address persists at least until the deletion of the IKE SA. 2390 This function provides address allocation to an IPsec Remote Access 2391 Client (IRAC) trying to tunnel into a network protected by an IPsec 2392 Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an 2393 IKE SA and a Child SA, the IRAC MUST request the IRAS-controlled 2394 address (and optionally other information concerning the protected 2395 network) in the IKE_AUTH exchange. The IRAS may procure an address 2396 for the IRAC from any number of sources such as a DHCP/BOOTP server 2397 or its own address pool. 2399 Initiator Responder 2400 ------------------------------------------------------------------- 2401 HDR, SK {IDi, [CERT,] 2402 [CERTREQ,] [IDr,] AUTH, 2403 CP(CFG_REQUEST), SAi2, 2404 TSi, TSr} --> 2405 <-- HDR, SK {IDr, [CERT,] AUTH, 2406 CP(CFG_REPLY), SAr2, 2407 TSi, TSr} 2409 In all cases, the CP payload MUST be inserted before the SA payload. 2410 In variations of the protocol where there are multiple IKE_AUTH 2411 exchanges, the CP payloads MUST be inserted in the messages 2412 containing the SA payloads. 2414 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute 2415 (either IPv4 or IPv6) but MAY contain any number of additional 2416 attributes the initiator wants returned in the response. 2418 For example, message from initiator to responder: 2420 CP(CFG_REQUEST)= 2421 INTERNAL_ADDRESS() 2422 TSi = (0, 0-65535,0.0.0.0-255.255.255.255) 2423 TSr = (0, 0-65535,0.0.0.0-255.255.255.255) 2425 NOTE: Traffic Selectors contain (protocol, port range, address 2426 range). 2428 Message from responder to initiator: 2430 CP(CFG_REPLY)= 2431 INTERNAL_ADDRESS(192.0.2.202) 2432 INTERNAL_NETMASK(255.255.255.0) 2433 INTERNAL_SUBNET(192.0.2.0/255.255.255.0) 2434 TSi = (0, 0-65535,192.0.2.202-192.0.2.202) 2435 TSr = (0, 0-65535,192.0.2.0-192.0.2.255) 2437 All returned values will be implementation dependent. As can be seen 2438 in the above example, the IRAS MAY also send other attributes that 2439 were not included in CP(CFG_REQUEST) and MAY ignore the non- 2440 mandatory attributes that it does not support. 2442 {{ 3.10.1-37 }} The FAILED_CP_REQUIRED notification is sent by 2443 responder in the case where CP(CFG_REQUEST) was expected but not 2444 received, and so is a conflict with locally configured policy. There 2445 is no associated data. 2447 The responder MUST NOT send a CFG_REPLY without having first received 2448 a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS 2449 to perform an unnecessary configuration lookup if the IRAC cannot 2450 process the REPLY. In the case where the IRAS's configuration 2451 requires that CP be used for a given identity IDi, but IRAC has 2452 failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and 2453 terminate the IKE exchange with a FAILED_CP_REQUIRED error. The 2454 FAILED_CP_REQUIRED is not fatal to the IKE SA; it simply causes the 2455 Child SA creation fail. The initiator can fix this by later starting 2456 a new configuration payload request. 2458 2.19.1. Configuration Payloads 2460 Editor's note: some of this sub-section is redundant and will go away 2461 in the next version of the document. 2463 In support of the scenario described in Section 1.1.3, an initiator 2464 may request that the responder assign an IP address and tell the 2465 initiator what it is. {{ Clarif-6.1 }} That request is done using 2466 configuration payloads, not traffic selectors. An address in a TSi 2467 payload in a response does not mean that the responder has assigned 2468 that address to the initiator: it only means that if packets matching 2469 these traffic selectors are sent by the initiator, IPsec processing 2470 can be performed as agreed for this SA. 2472 Configuration payloads are of type CFG_REQUEST/CFG_REPLY or CFG_SET/ 2473 CFG_ACK (see CFG Type in the payload description below). CFG_REQUEST 2474 and CFG_SET payloads may optionally be added to any IKE request. The 2475 IKE response MUST include either a corresponding CFG_REPLY or CFG_ACK 2476 or a Notify payload with an error type indicating why the request 2477 could not be honored. An exception is that a minimal implementation 2478 MAY ignore all CFG_REQUEST and CFG_SET payloads, so a response 2479 message without a corresponding CFG_REPLY or CFG_ACK MUST be accepted 2480 as an indication that the request was not supported. 2482 "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information 2483 from its peer. If an attribute in the CFG_REQUEST Configuration 2484 Payload is not zero-length, it is taken as a suggestion for that 2485 attribute. The CFG_REPLY Configuration Payload MAY return that 2486 value, or a new one. It MAY also add new attributes and not include 2487 some requested ones. Requestors MUST ignore returned attributes that 2488 they do not recognize. 2490 Some attributes MAY be multi-valued, in which case multiple attribute 2491 values of the same type are sent and/or returned. Generally, all 2492 values of an attribute are returned when the attribute is requested. 2493 For some attributes (in this version of the specification only 2494 internal addresses), multiple requests indicates a request that 2495 multiple values be assigned. For these attributes, the number of 2496 values returned SHOULD NOT exceed the number requested. 2498 If the data type requested in a CFG_REQUEST is not recognized or not 2499 supported, the responder MUST NOT return an error type but rather 2500 MUST either send a CFG_REPLY that MAY be empty or a reply not 2501 containing a CFG_REPLY payload at all. Error returns are reserved 2502 for cases where the request is recognized but cannot be performed as 2503 requested or the request is badly formatted. 2505 "CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data 2506 to its peer. In this case, the CFG_SET Configuration Payload 2507 contains attributes the initiator wants its peer to alter. The 2508 responder MUST return a Configuration Payload if it accepted any of 2509 the configuration data and it MUST contain the attributes that the 2510 responder accepted with zero-length data. Those attributes that it 2511 did not accept MUST NOT be in the CFG_ACK Configuration Payload. If 2512 no attributes were accepted, the responder MUST return either an 2513 empty CFG_ACK payload or a response message without a CFG_ACK 2514 payload. There are currently no defined uses for the CFG_SET/CFG_ACK 2515 exchange, though they may be used in connection with extensions based 2516 on Vendor IDs. An minimal implementation of this specification MAY 2517 ignore CFG_SET payloads. 2519 {{ Demoted the SHOULD }} Extensions via the CP payload should not be 2520 used for general purpose management. Its main intent is to provide a 2521 bootstrap mechanism to exchange information within IPsec from IRAS to 2522 IRAC. While it MAY be useful to use such a method to exchange 2523 information between some Security Gateways (SGW) or small networks, 2524 existing management protocols such as DHCP [DHCP], RADIUS [RADIUS], 2525 SNMP, or LDAP [LDAP] should be preferred for enterprise management as 2526 well as subsequent information exchanges. 2528 2.20. Requesting the Peer's Version 2530 An IKE peer wishing to inquire about the other peer's IKE software 2531 version information MAY use the method below. This is an example of 2532 a configuration request within an INFORMATIONAL exchange, after the 2533 IKE SA and first Child SA have been created. 2535 An IKE implementation MAY decline to give out version information 2536 prior to authentication or even after authentication to prevent 2537 trolling in case some implementation is known to have some security 2538 weakness. In that case, it MUST either return an empty string or no 2539 CP payload if CP is not supported. 2541 Initiator Responder 2542 ------------------------------------------------------------------- 2543 HDR, SK{CP(CFG_REQUEST)} --> 2544 <-- HDR, SK{CP(CFG_REPLY)} 2546 CP(CFG_REQUEST)= 2547 APPLICATION_VERSION("") 2549 CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar 2550 Inc.") 2552 2.21. Error Handling 2554 There are many kinds of errors that can occur during IKE processing. 2555 If a request is received that is badly formatted or unacceptable for 2556 reasons of policy (e.g., no matching cryptographic algorithms), the 2557 response MUST contain a Notify payload indicating the error. If an 2558 error occurs outside the context of an IKE request (e.g., the node is 2559 getting ESP messages on a nonexistent SPI), the node SHOULD initiate 2560 an INFORMATIONAL exchange with a Notify payload describing the 2561 problem. 2563 Errors that occur before a cryptographically protected IKE SA is 2564 established must be handled very carefully. There is a trade-off 2565 between wanting to be helpful in diagnosing a problem and responding 2566 to it and wanting to avoid being a dupe in a denial of service attack 2567 based on forged messages. 2569 If a node receives a message on UDP port 500 or 4500 outside the 2570 context of an IKE SA known to it (and not a request to start one), it 2571 may be the result of a recent crash of the node. If the message is 2572 marked as a response, the node MAY audit the suspicious event but 2573 MUST NOT respond. If the message is marked as a request, the node 2574 MAY audit the suspicious event and MAY send a response. If a 2575 response is sent, the response MUST be sent to the IP address and 2576 port from whence it came with the same IKE SPIs and the Message ID 2577 copied. The response MUST NOT be cryptographically protected and 2578 MUST contain a Notify payload indicating INVALID_IKE_SPI. {{ 3.10.1-4 2579 }} The INVALID_IKE_SPI notification indicates an IKE message was 2580 received with an unrecognized destination SPI; this usually indicates 2581 that the recipient has rebooted and forgotten the existence of an IKE 2582 SA. 2584 A node receiving such an unprotected Notify payload MUST NOT respond 2585 and MUST NOT change the state of any existing SAs. The message might 2586 be a forgery or might be a response the genuine correspondent was 2587 tricked into sending. {{ Demoted two SHOULDs }} A node should treat 2588 such a message (and also a network message like ICMP destination 2589 unreachable) as a hint that there might be problems with SAs to that 2590 IP address and should initiate a liveness test for any such IKE SA. 2591 An implementation SHOULD limit the frequency of such tests to avoid 2592 being tricked into participating in a denial of service attack. 2594 A node receiving a suspicious message from an IP address with which 2595 it has an IKE SA MAY send an IKE Notify payload in an IKE 2596 INFORMATIONAL exchange over that SA. {{ Demoted the SHOULD }} The 2597 recipient MUST NOT change the state of any SAs as a result, but may 2598 wish to audit the event to aid in diagnosing malfunctions. A node 2599 MUST limit the rate at which it will send messages in response to 2600 unprotected messages. 2602 2.22. IPComp 2604 Use of IP compression [IP-COMP] can be negotiated as part of the 2605 setup of a Child SA. While IP compression involves an extra header 2606 in each packet and a compression parameter index (CPI), the virtual 2607 "compression association" has no life outside the ESP or AH SA that 2608 contains it. Compression associations disappear when the 2609 corresponding ESP or AH SA goes away. It is not explicitly mentioned 2610 in any DELETE payload. 2612 Negotiation of IP compression is separate from the negotiation of 2613 cryptographic parameters associated with a Child SA. A node 2614 requesting a Child SA MAY advertise its support for one or more 2615 compression algorithms through one or more Notify payloads of type 2616 IPCOMP_SUPPORTED. This notification may be included only in a 2617 message containing an SA payload negotiating a Child SA and indicates 2618 a willingness by its sender to use IPComp on this SA. The response 2619 MAY indicate acceptance of a single compression algorithm with a 2620 Notify payload of type IPCOMP_SUPPORTED. These payloads MUST NOT 2621 occur in messages that do not contain SA payloads. 2623 {{ 3.10.1-16387 }}The data associated with this notification includes 2624 a two-octet IPComp CPI followed by a one-octet transform ID 2625 optionally followed by attributes whose length and format are defined 2626 by that transform ID. A message proposing an SA may contain multiple 2627 IPCOMP_SUPPORTED notifications to indicate multiple supported 2628 algorithms. A message accepting an SA may contain at most one. 2630 The transform IDs currently defined are: 2632 Name Number Defined In 2633 ------------------------------------- 2634 RESERVED 0 2635 IPCOMP_OUI 1 2636 IPCOMP_DEFLATE 2 RFC 2394 2637 IPCOMP_LZS 3 RFC 2395 2638 IPCOMP_LZJH 4 RFC 3051 2639 RESERVED TO IANA 5-240 2640 PRIVATE USE 241-255 2642 Although there has been discussion of allowing multiple compression 2643 algorithms to be accepted and to have different compression 2644 algorithms available for the two directions of a Child SA, 2645 implementations of this specification MUST NOT accept an IPComp 2646 algorithm that was not proposed, MUST NOT accept more than one, and 2647 MUST NOT compress using an algorithm other than one proposed and 2648 accepted in the setup of the Child SA. 2650 A side effect of separating the negotiation of IPComp from 2651 cryptographic parameters is that it is not possible to propose 2652 multiple cryptographic suites and propose IP compression with some of 2653 them but not others. 2655 In some cases, Robust Header Compression (ROHC) may be more 2656 appropriate than IP Compression. [ROHCV2] defines the use of ROHC 2657 with IKEv2 and IPsec. 2659 2.23. NAT Traversal 2661 Network Address Translation (NAT) gateways are a controversial 2662 subject. This section briefly describes what they are and how they 2663 are likely to act on IKE traffic. Many people believe that NATs are 2664 evil and that we should not design our protocols so as to make them 2665 work better. IKEv2 does specify some unintuitive processing rules in 2666 order that NATs are more likely to work. 2668 NATs exist primarily because of the shortage of IPv4 addresses, 2669 though there are other rationales. IP nodes that are "behind" a NAT 2670 have IP addresses that are not globally unique, but rather are 2671 assigned from some space that is unique within the network behind the 2672 NAT but that are likely to be reused by nodes behind other NATs. 2673 Generally, nodes behind NATs can communicate with other nodes behind 2674 the same NAT and with nodes with globally unique addresses, but not 2675 with nodes behind other NATs. There are exceptions to that rule. 2676 When those nodes make connections to nodes on the real Internet, the 2677 NAT gateway "translates" the IP source address to an address that 2678 will be routed back to the gateway. Messages to the gateway from the 2679 Internet have their destination addresses "translated" to the 2680 internal address that will route the packet to the correct endnode. 2682 NATs are designed to be "transparent" to endnodes. Neither software 2683 on the node behind the NAT nor the node on the Internet requires 2684 modification to communicate through the NAT. Achieving this 2685 transparency is more difficult with some protocols than with others. 2686 Protocols that include IP addresses of the endpoints within the 2687 payloads of the packet will fail unless the NAT gateway understands 2688 the protocol and modifies the internal references as well as those in 2689 the headers. Such knowledge is inherently unreliable, is a network 2690 layer violation, and often results in subtle problems. 2692 Opening an IPsec connection through a NAT introduces special 2693 problems. If the connection runs in transport mode, changing the IP 2694 addresses on packets will cause the checksums to fail and the NAT 2695 cannot correct the checksums because they are cryptographically 2696 protected. Even in tunnel mode, there are routing problems because 2697 transparently translating the addresses of AH and ESP packets 2698 requires special logic in the NAT and that logic is heuristic and 2699 unreliable in nature. For that reason, IKEv2 will use UDP 2700 encapsulation of IKE and ESP packets. This encoding is slightly less 2701 efficient but is easier for NATs to process. In addition, firewalls 2702 may be configured to pass IPsec traffic over UDP but not ESP/AH or 2703 vice versa. 2705 It is a common practice of NATs to translate TCP and UDP port numbers 2706 as well as addresses and use the port numbers of inbound packets to 2707 decide which internal node should get a given packet. For this 2708 reason, even though IKE packets MUST be sent from and to UDP port 500 2709 or 4500, they MUST be accepted coming from any port and responses 2710 MUST be sent to the port from whence they came. This is because the 2711 ports may be modified as the packets pass through NATs. Similarly, 2712 IP addresses of the IKE endpoints are generally not included in the 2713 IKE payloads because the payloads are cryptographically protected and 2714 could not be transparently modified by NATs. 2716 Port 4500 is reserved for UDP-encapsulated ESP and IKE. {{ Clarif-7.6 2717 }} An IPsec endpoint that discovers a NAT between it and its 2718 correspondent MUST send all subsequent traffic from port 4500, which 2719 NATs should not treat specially (as they might with port 500). 2721 An initiator can float to port 4500, regardless whether or not there 2722 is NAT, even at the beginning of IKE. When either side is using port 2723 4500, sending with UDP encapsulation is not required, but 2724 understanding received packets with UDP encapsulation is required. 2725 UDP encapsulation MUST NOT be done on port 500. If NAT-T is 2726 supported (that is, if NAT_DETECTION_*_IP payloads were exchanged 2727 during IKE_SA_INIT), all devices MUST be able to receive and process 2728 both UDP encapsulated and non-UDP encapsulated packets at any time. 2729 Either side can decide whether or not to use UDP encapsulation 2730 irrespective of the choice made by the other side. However, if a NAT 2731 is detected, both devices MUST send UDP encapsulated packets. 2733 The specific requirements for supporting NAT traversal [NATREQ] are 2734 listed below. Support for NAT traversal is optional. In this 2735 section only, requirements listed as MUST apply only to 2736 implementations supporting NAT traversal. 2738 o IKE MUST listen on port 4500 as well as port 500. IKE MUST 2739 respond to the IP address and port from which packets arrived. 2741 o Both IKE initiator and responder MUST include in their IKE_SA_INIT 2742 packets Notify payloads of type NAT_DETECTION_SOURCE_IP and 2743 NAT_DETECTION_DESTINATION_IP. Those payloads can be used to 2744 detect if there is NAT between the hosts, and which end is behind 2745 the NAT. The location of the payloads in the IKE_SA_INIT packets 2746 is just after the Ni and Nr payloads (before the optional CERTREQ 2747 payload). 2749 o {{ 3.10.1-16388 }} The data associated with the 2750 NAT_DETECTION_SOURCE_IP notification is a SHA-1 digest of the SPIs 2751 (in the order they appear in the header), IP address, and port on 2752 which this packet was sent. There MAY be multiple 2753 NAT_DETECTION_SOURCE_IP payloads in a message if the sender does 2754 not know which of several network attachments will be used to send 2755 the packet. 2757 o {{ 3.10.1-16389 }} The data associated with the 2758 NAT_DETECTION_DESTINATION_IP notification is a SHA-1 digest of the 2759 SPIs (in the order they appear in the header), IP address, and 2760 port to which this packet was sent. 2762 o {{ 3.10.1-16388 }} {{ 3.10.1-16389 }} The recipient of either the 2763 NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP 2764 notification MAY compare the supplied value to a SHA-1 hash of the 2765 SPIs, source IP address, and port, and if they don't match it 2766 SHOULD enable NAT traversal. In the case of a mismatching 2767 NAT_DETECTION_SOURCE_IP hash, the recipient MAY reject the 2768 connection attempt if NAT traversal is not supported. In the case 2769 of a mismatching NAT_DETECTION_DESTINATION_IP hash, it means that 2770 the system receiving the NAT_DETECTION_DESTINATION_IP payload is 2771 behind a NAT and that system SHOULD start sending keepalive 2772 packets as defined in [UDPENCAPS]; alternately, it MAY reject the 2773 connection attempt if NAT traversal is not supported. 2775 o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches 2776 the expected value of the source IP and port found from the IP 2777 header of the packet containing the payload, it means that the 2778 system sending those payloads is behind NAT (i.e., someone along 2779 the route changed the source address of the original packet to 2780 match the address of the NAT box). In this case, the system 2781 receiving the payloads should allow dynamic update of the other 2782 systems' IP address, as described later. 2784 o If the NAT_DETECTION_DESTINATION_IP payload received does not 2785 match the hash of the destination IP and port found from the IP 2786 header of the packet containing the payload, it means that the 2787 system receiving the NAT_DETECTION_DESTINATION_IP payload is 2788 behind a NAT. In this case, that system SHOULD start sending 2789 keepalive packets as explained in [UDPENCAPS]. 2791 o The IKE initiator MUST check these payloads if present and if they 2792 do not match the addresses in the outer packet MUST tunnel all 2793 future IKE and ESP packets associated with this IKE SA over UDP 2794 port 4500. 2796 o To tunnel IKE packets over UDP port 4500, the IKE header has four 2797 octets of zero prepended and the result immediately follows the 2798 UDP header. To tunnel ESP packets over UDP port 4500, the ESP 2799 header immediately follows the UDP header. Since the first four 2800 octets of the ESP header contain the SPI, and the SPI cannot 2801 validly be zero, it is always possible to distinguish ESP and IKE 2802 messages. 2804 o Implementations MUST process received UDP-encapsulated ESP packets 2805 even when no NAT was detected. 2807 o The original source and destination IP address required for the 2808 transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) 2809 are obtained from the Traffic Selectors associated with the 2810 exchange. In the case of NAT traversal, the Traffic Selectors 2811 MUST contain exactly one IP address, which is then used as the 2812 original IP address. 2814 o There are cases where a NAT box decides to remove mappings that 2815 are still alive (for example, the keepalive interval is too long, 2816 or the NAT box is rebooted). To recover in these cases, hosts 2817 that are not behind a NAT SHOULD send all packets (including 2818 retransmission packets) to the IP address and port from the last 2819 valid authenticated packet from the other end (i.e., dynamically 2820 update the address). A host behind a NAT SHOULD NOT do this 2821 because it opens a DoS attack possibility. Any authenticated IKE 2822 packet or any authenticated UDP-encapsulated ESP packet can be 2823 used to detect that the IP address or the port has changed. 2825 o There are cases where a NAT box decides to remove mappings that 2826 are still alive (for example, the keepalive interval is too long, 2827 or the NAT box is rebooted). To recover in these cases, hosts 2828 that do not support other methods of recovery such as MOBIKE 2829 [MOBIKE], and that are not behind a NAT, SHOULD send all packets 2830 (including retransmission packets) to the IP address and port from 2831 the last valid authenticated packet from the other end (that is, 2832 they should dynamically update the address). A host behind a NAT 2833 SHOULD NOT do this because it opens a possible denial-of-service 2834 attack. Any authenticated IKE packet or any authenticated UDP- 2835 encapsulated ESP packet can be used to detect that the IP address 2836 or the port has changed. When IKEv2 is used with MOBIKE, 2837 dynamically updating the addresses described above interferes with 2838 MOBIKE's way of recovering from the same situation, so this method 2839 MUST NOT be used when MOBIKE is used. See Section 3.8 of [MOBIKE] 2840 for more information. 2842 2.24. Explicit Congestion Notification (ECN) 2844 When IPsec tunnels behave as originally specified in [IPSECARCH-OLD], 2845 ECN usage is not appropriate for the outer IP headers because tunnel 2846 decapsulation processing discards ECN congestion indications to the 2847 detriment of the network. ECN support for IPsec tunnels for IKEv1- 2848 based IPsec requires multiple operating modes and negotiation (see 2849 [ECN]). IKEv2 simplifies this situation by requiring that ECN be 2850 usable in the outer IP headers of all tunnel-mode IPsec SAs created 2851 by IKEv2. Specifically, tunnel encapsulators and decapsulators for 2852 all tunnel-mode SAs created by IKEv2 MUST support the ECN full- 2853 functionality option for tunnels specified in [ECN] and MUST 2854 implement the tunnel encapsulation and decapsulation processing 2855 specified in [IPSECARCH] to prevent discarding of ECN congestion 2856 indications. 2858 3. Header and Payload Formats 2860 In the tables in this section, some cryptographic primitives and 2861 configuation attributes are marked as "UNSPECIFIED". These are items 2862 for which there are no known specifications and therefore 2863 interoperability is currently impossible. A future specification may 2864 describe their use, but until such specification is made, 2865 implementations SHOULD NOT attempt to use items marked as 2866 "UNSPECIFIED" in implementations that are meant to be interoperable. 2868 3.1. The IKE Header 2870 IKE messages use UDP ports 500 and/or 4500, with one IKE message per 2871 UDP datagram. Information from the beginning of the packet through 2872 the UDP header is largely ignored except that the IP addresses and 2873 UDP ports from the headers are reversed and used for return packets. 2874 When sent on UDP port 500, IKE messages begin immediately following 2875 the UDP header. When sent on UDP port 4500, IKE messages have 2876 prepended four octets of zero. These four octets of zero are not 2877 part of the IKE message and are not included in any of the length 2878 fields or checksums defined by IKE. Each IKE message begins with the 2879 IKE header, denoted HDR in this memo. Following the header are one 2880 or more IKE payloads each identified by a "Next Payload" field in the 2881 preceding payload. Payloads are processed in the order in which they 2882 appear in an IKE message by invoking the appropriate processing 2883 routine according to the "Next Payload" field in the IKE header and 2884 subsequently according to the "Next Payload" field in the IKE payload 2885 itself until a "Next Payload" field of zero indicates that no 2886 payloads follow. If a payload of type "Encrypted" is found, that 2887 payload is decrypted and its contents parsed as additional payloads. 2888 An Encrypted payload MUST be the last payload in a packet and an 2889 Encrypted payload MUST NOT contain another Encrypted payload. 2891 The Recipient SPI in the header identifies an instance of an IKE 2892 security association. It is therefore possible for a single instance 2893 of IKE to multiplex distinct sessions with multiple peers. 2895 All multi-octet fields representing integers are laid out in big 2896 endian order (also known as "most significant byte first", or 2897 "network byte order"). 2899 The format of the IKE header is shown in Figure 4. 2901 1 2 3 2902 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 2903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2904 | IKE SA Initiator's SPI | 2905 | | 2906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2907 | IKE SA Responder's SPI | 2908 | | 2909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2910 | Next Payload | MjVer | MnVer | Exchange Type | Flags | 2911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2912 | Message ID | 2913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2914 | Length | 2915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2917 Figure 4: IKE Header Format 2919 o Initiator's SPI (8 octets) - A value chosen by the initiator to 2920 identify a unique IKE security association. This value MUST NOT 2921 be zero. 2923 o Responder's SPI (8 octets) - A value chosen by the responder to 2924 identify a unique IKE security association. This value MUST be 2925 zero in the first message of an IKE Initial Exchange (including 2926 repeats of that message including a cookie). {{ The phrase "and 2927 MUST NOT be zero in any other message" was removed; Clarif-2.1 }} 2929 o Next Payload (1 octet) - Indicates the type of payload that 2930 immediately follows the header. The format and value of each 2931 payload are defined below. 2933 o Major Version (4 bits) - Indicates the major version of the IKE 2934 protocol in use. Implementations based on this version of IKE 2935 MUST set the Major Version to 2. Implementations based on 2936 previous versions of IKE and ISAKMP MUST set the Major Version to 2937 1. Implementations based on this version of IKE MUST reject or 2938 ignore messages containing a version number greater than 2 with an 2939 INVALID_MAJOR_VERSION notification message as described in Section 2940 2.5. 2942 o Minor Version (4 bits) - Indicates the minor version of the IKE 2943 protocol in use. Implementations based on this version of IKE 2944 MUST set the Minor Version to 0. They MUST ignore the minor 2945 version number of received messages. 2947 o Exchange Type (1 octet) - Indicates the type of exchange being 2948 used. This constrains the payloads sent in each message in an 2949 exchange. 2951 Exchange Type Value 2952 ---------------------------------- 2953 RESERVED 0-33 2954 IKE_SA_INIT 34 2955 IKE_AUTH 35 2956 CREATE_CHILD_SA 36 2957 INFORMATIONAL 37 2958 RESERVED TO IANA 38-239 2959 PRIVATE USE 240-255 2961 o Flags (1 octet) - Indicates specific options that are set for the 2962 message. Presence of options is indicated by the appropriate bit 2963 in the flags field being set. The bits are defined LSB first, so 2964 bit 0 would be the least significant bit of the Flags octet. In 2965 the description below, a bit being 'set' means its value is '1', 2966 while 'cleared' means its value is '0'. 2968 * X(reserved) (bits 0-2) - These bits MUST be cleared when 2969 sending and MUST be ignored on receipt. 2971 * I(nitiator) (bit 3 of Flags) - This bit MUST be set in messages 2972 sent by the original initiator of the IKE SA and MUST be 2973 cleared in messages sent by the original responder. It is used 2974 by the recipient to determine which eight octets of the SPI 2975 were generated by the recipient. This bit changes to reflect 2976 who initiated the last rekey of the IKE SA. 2978 * V(ersion) (bit 4 of Flags) - This bit indicates that the 2979 transmitter is capable of speaking a higher major version 2980 number of the protocol than the one indicated in the major 2981 version number field. Implementations of IKEv2 MUST clear this 2982 bit when sending and MUST ignore it in incoming messages. 2984 * R(esponse) (bit 5 of Flags) - This bit indicates that this 2985 message is a response to a message containing the same message 2986 ID. This bit MUST be cleared in all request messages and MUST 2987 be set in all responses. An IKE endpoint MUST NOT generate a 2988 response to a message that is marked as being a response. 2990 * X(reserved) (bits 6-7 of Flags) - These bits MUST be cleared 2991 when sending and MUST be ignored on receipt. 2993 o Message ID (4 octets) - Message identifier used to control 2994 retransmission of lost packets and matching of requests and 2995 responses. It is essential to the security of the protocol 2996 because it is used to prevent message replay attacks. See 2997 Section 2.1 and Section 2.2. 2999 o Length (4 octets) - Length of total message (header + payloads) in 3000 octets. 3002 3.2. Generic Payload Header 3004 Each IKE payload defined in Section 3.3 through Section 3.16 begins 3005 with a generic payload header, shown in Figure 5. Figures for each 3006 payload below will include the generic payload header, but for 3007 brevity the description of each field will be omitted. 3009 1 2 3 3010 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 3011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3012 | Next Payload |C| RESERVED | Payload Length | 3013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3015 Figure 5: Generic Payload Header 3017 The Generic Payload Header fields are defined as follows: 3019 o Next Payload (1 octet) - Identifier for the payload type of the 3020 next payload in the message. If the current payload is the last 3021 in the message, then this field will be 0. This field provides a 3022 "chaining" capability whereby additional payloads can be added to 3023 a message by appending it to the end of the message and setting 3024 the "Next Payload" field of the preceding payload to indicate the 3025 new payload's type. An Encrypted payload, which must always be 3026 the last payload of a message, is an exception. It contains data 3027 structures in the format of additional payloads. In the header of 3028 an Encrypted payload, the Next Payload field is set to the payload 3029 type of the first contained payload (instead of 0). The payload 3030 type values are: 3032 Next Payload Type Notation Value 3033 -------------------------------------------------- 3034 No Next Payload 0 3035 RESERVED 1-32 3036 Security Association SA 33 3037 Key Exchange KE 34 3038 Identification - Initiator IDi 35 3039 Identification - Responder IDr 36 3040 Certificate CERT 37 3041 Certificate Request CERTREQ 38 3042 Authentication AUTH 39 3043 Nonce Ni, Nr 40 3044 Notify N 41 3045 Delete D 42 3046 Vendor ID V 43 3047 Traffic Selector - Initiator TSi 44 3048 Traffic Selector - Responder TSr 45 3049 Encrypted E 46 3050 Configuration CP 47 3051 Extensible Authentication EAP 48 3052 RESERVED TO IANA 49-127 3053 PRIVATE USE 128-255 3055 (Payload type values 1-32 should not be assigned in the 3056 future so that there is no overlap with the code assignments 3057 for IKEv1.) 3059 o Critical (1 bit) - MUST be set to zero if the sender wants the 3060 recipient to skip this payload if it does not understand the 3061 payload type code in the Next Payload field of the previous 3062 payload. MUST be set to one if the sender wants the recipient to 3063 reject this entire message if it does not understand the payload 3064 type. MUST be ignored by the recipient if the recipient 3065 understands the payload type code. MUST be set to zero for 3066 payload types defined in this document. Note that the critical 3067 bit applies to the current payload rather than the "next" payload 3068 whose type code appears in the first octet. The reasoning behind 3069 not setting the critical bit for payloads defined in this document 3070 is that all implementations MUST understand all payload types 3071 defined in this document and therefore must ignore the Critical 3072 bit's value. Skipped payloads are expected to have valid Next 3073 Payload and Payload Length fields. 3075 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on 3076 receipt. 3078 o Payload Length (2 octets) - Length in octets of the current 3079 payload, including the generic payload header. 3081 {{ Clarif-7.10 }} Many payloads contain fields marked as "RESERVED". 3082 Some payloads in IKEv2 (and historically in IKEv1) are not aligned to 3083 4-octet boundaries. 3085 3.3. Security Association Payload 3087 The Security Association Payload, denoted SA in this memo, is used to 3088 negotiate attributes of a security association. Assembly of Security 3089 Association Payloads requires great peace of mind. An SA payload MAY 3090 contain multiple proposals. If there is more than one, they MUST be 3091 ordered from most preferred to least preferred. Each proposal 3092 contains a single IPsec protocol (where a protocol is IKE, ESP, or 3093 AH), each protocol MAY contain multiple transforms, and each 3094 transform MAY contain multiple attributes. When parsing an SA, an 3095 implementation MUST check that the total Payload Length is consistent 3096 with the payload's internal lengths and counts. Proposals, 3097 Transforms, and Attributes each have their own variable length 3098 encodings. They are nested such that the Payload Length of an SA 3099 includes the combined contents of the SA, Proposal, Transform, and 3100 Attribute information. The length of a Proposal includes the lengths 3101 of all Transforms and Attributes it contains. The length of a 3102 Transform includes the lengths of all Attributes it contains. 3104 The syntax of Security Associations, Proposals, Transforms, and 3105 Attributes is based on ISAKMP; however the semantics are somewhat 3106 different. The reason for the complexity and the hierarchy is to 3107 allow for multiple possible combinations of algorithms to be encoded 3108 in a single SA. Sometimes there is a choice of multiple algorithms, 3109 whereas other times there is a combination of algorithms. For 3110 example, an initiator might want to propose using ESP with either 3111 (3DES and HMAC_MD5) or (AES and HMAC_SHA1). 3113 One of the reasons the semantics of the SA payload has changed from 3114 ISAKMP and IKEv1 is to make the encodings more compact in common 3115 cases. 3117 The Proposal structure contains within it a Proposal # and an IPsec 3118 protocol ID. Each structure MUST have a proposal number one (1) 3119 greater than the previous structure. The first Proposal in the 3120 initiator's SA payload MUST have a Proposal # of one (1). One reason 3121 to use multiple proposals is to propose both standard crypto ciphers 3122 and combined-mode ciphers. Combined-mode ciphers include both 3123 integrity and encryption in a single encryption algorithm, and are 3124 not allowed to be offered with a separate integrity algorithm other 3125 than "none". If an initiator wants to propose both combined-mode 3126 ciphers and normal ciphers, it must include two proposals: one will 3127 have all the combined-mode ciphers, and the other will have all the 3128 normal ciphers with the integrity algorithms. For example, one such 3129 proposal would have two proposal structures: ESP with ENCR_AES-CCM_8, 3130 ENCR_AES-CCM_12, and ENCR_AES-CCM_16 as Proposal #1, and ESP with 3131 ENCR_AES_CBC, ENCR_3DES, AUTH_AES_XCBC_96, and AUTH_HMAC_SHA1_96 as 3132 Proposal #2. 3134 Each Proposal/Protocol structure is followed by one or more transform 3135 structures. The number of different transforms is generally 3136 determined by the Protocol. AH generally has two transforms: 3137 Extended Sequence Numbers (ESN) and an integrity check algorithm. 3138 ESP generally has three: ESN, an encryption algorithm and an 3139 integrity check algorithm. IKE generally has four transforms: a 3140 Diffie-Hellman group, an integrity check algorithm, a prf algorithm, 3141 and an encryption algorithm. If an algorithm that combines 3142 encryption and integrity protection is proposed, it MUST be proposed 3143 as an encryption algorithm and an integrity protection algorithm MUST 3144 NOT be proposed. For each Protocol, the set of permissible 3145 transforms is assigned transform ID numbers, which appear in the 3146 header of each transform. 3148 If there are multiple transforms with the same Transform Type, the 3149 proposal is an OR of those transforms. If there are multiple 3150 Transforms with different Transform Types, the proposal is an AND of 3151 the different groups. For example, to propose ESP with (3DES or AES- 3152 CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two 3153 Transform Type 1 candidates (one for 3DES and one for AEC-CBC) and 3154 two Transform Type 3 candidates (one for HMAC_MD5 and one for 3155 HMAC_SHA). This effectively proposes four combinations of 3156 algorithms. If the initiator wanted to propose only a subset of 3157 those, for example (3DES and HMAC_MD5) or (IDEA and HMAC_SHA), there 3158 is no way to encode that as multiple transforms within a single 3159 Proposal. Instead, the initiator would have to construct two 3160 different Proposals, each with two transforms. 3162 A given transform MAY have one or more Attributes. Attributes are 3163 necessary when the transform can be used in more than one way, as 3164 when an encryption algorithm has a variable key size. The transform 3165 would specify the algorithm and the attribute would specify the key 3166 size. Most transforms do not have attributes. A transform MUST NOT 3167 have multiple attributes of the same type. To propose alternate 3168 values for an attribute (for example, multiple key sizes for the AES 3169 encryption algorithm), and implementation MUST include multiple 3170 Transforms with the same Transform Type each with a single Attribute. 3172 Note that the semantics of Transforms and Attributes are quite 3173 different from those in IKEv1. In IKEv1, a single Transform carried 3174 multiple algorithms for a protocol with one carried in the Transform 3175 and the others carried in the Attributes. 3177 1 2 3 3178 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 3179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3180 | Next Payload |C| RESERVED | Payload Length | 3181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3182 | | 3183 ~ ~ 3184 | | 3185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3187 Figure 6: Security Association Payload 3189 o Proposals (variable) - One or more proposal substructures. 3191 The payload type for the Security Association Payload is thirty three 3192 (33). 3194 3.3.1. Proposal Substructure 3196 1 2 3 3197 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 3198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3199 | 0 (last) or 2 | RESERVED | Proposal Length | 3200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3201 | Proposal # | Protocol ID | SPI Size |# of Transforms| 3202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3203 ~ SPI (variable) ~ 3204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3205 | | 3206 ~ ~ 3207 | | 3208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3210 Figure 7: Proposal Substructure 3212 o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the 3213 last Proposal Substructure in the SA. This syntax is inherited 3214 from ISAKMP, but is unnecessary because the last Proposal could be 3215 identified from the length of the SA. The value (2) corresponds 3216 to a Payload Type of Proposal in IKEv1, and the first four octets 3217 of the Proposal structure are designed to look somewhat like the 3218 header of a Payload. 3220 o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on 3221 receipt. 3223 o Proposal Length (2 octets) - Length of this proposal, including 3224 all transforms and attributes that follow. 3226 o Proposal # (1 octet) - When a proposal is made, the first proposal 3227 in an SA payload MUST be #1, and subsequent proposals MUST be one 3228 more than the previous proposal (indicating an OR of the two 3229 proposals). When a proposal is accepted, the proposal number in 3230 the SA payload MUST match the number on the proposal sent that was 3231 accepted. 3233 o Protocol ID (1 octet) - Specifies the IPsec protocol identifier 3234 for the current negotiation. The defined values are: 3236 Protocol Protocol ID 3237 ----------------------------------- 3238 RESERVED 0 3239 IKE 1 3240 AH 2 3241 ESP 3 3242 RESERVED TO IANA 4-200 3243 PRIVATE USE 201-255 3245 o SPI Size (1 octet) - For an initial IKE SA negotiation, this field 3246 MUST be zero; the SPI is obtained from the outer header. During 3247 subsequent negotiations, it is equal to the size, in octets, of 3248 the SPI of the corresponding protocol (8 for IKE, 4 for ESP and 3249 AH). 3251 o # of Transforms (1 octet) - Specifies the number of transforms in 3252 this proposal. 3254 o SPI (variable) - The sending entity's SPI. Even if the SPI Size 3255 is not a multiple of 4 octets, there is no padding applied to the 3256 payload. When the SPI Size field is zero, this field is not 3257 present in the Security Association payload. 3259 o Transforms (variable) - One or more transform substructures. 3261 3.3.2. Transform Substructure 3263 1 2 3 3264 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 3265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3266 | 0 (last) or 3 | RESERVED | Transform Length | 3267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3268 |Transform Type | RESERVED | Transform ID | 3269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3270 | | 3271 ~ Transform Attributes ~ 3272 | | 3273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3275 Figure 8: Transform Substructure 3277 o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the 3278 last Transform Substructure in the Proposal. This syntax is 3279 inherited from ISAKMP, but is unnecessary because the last 3280 transform could be identified from the length of the proposal. 3281 The value (3) corresponds to a Payload Type of Transform in IKEv1, 3282 and the first four octets of the Transform structure are designed 3283 to look somewhat like the header of a Payload. 3285 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 3287 o Transform Length - The length (in octets) of the Transform 3288 Substructure including Header and Attributes. 3290 o Transform Type (1 octet) - The type of transform being specified 3291 in this transform. Different protocols support different 3292 transform types. For some protocols, some of the transforms may 3293 be optional. If a transform is optional and the initiator wishes 3294 to propose that the transform be omitted, no transform of the 3295 given type is included in the proposal. If the initiator wishes 3296 to make use of the transform optional to the responder, it 3297 includes a transform substructure with transform ID = 0 as one of 3298 the options. 3300 o Transform ID (2 octets) - The specific instance of the transform 3301 type being proposed. 3303 The transform type values are: 3305 Description Trans. Used In 3306 Type 3307 ------------------------------------------------------------------ 3308 RESERVED 0 3309 Encryption Algorithm (ENCR) 1 IKE and ESP 3310 Pseudo-random Function (PRF) 2 IKE 3311 Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP 3312 Diffie-Hellman Group (D-H) 4 IKE, optional in AH & ESP 3313 Extended Sequence Numbers (ESN) 5 AH and ESP 3314 RESERVED TO IANA 6-240 3315 PRIVATE USE 241-255 3317 (*) Negotiating an integrity algorithm is mandatory for the 3318 Encrypted payload format specified in this document. For example, 3319 [AEAD] specifies additional formats based on authenticated 3320 encryption, in which a separate integrity algorithm is not 3321 negotiated. 3323 For Transform Type 1 (Encryption Algorithm), defined Transform IDs 3324 are: 3326 Name Number Defined In 3327 --------------------------------------------------- 3328 RESERVED 0 3329 ENCR_DES_IV64 1 (UNSPECIFIED) 3330 ENCR_DES 2 (RFC2405), [DES] 3331 ENCR_3DES 3 (RFC2451) 3332 ENCR_RC5 4 (RFC2451) 3333 ENCR_IDEA 5 (RFC2451), [IDEA] 3334 ENCR_CAST 6 (RFC2451) 3335 ENCR_BLOWFISH 7 (RFC2451) 3336 ENCR_3IDEA 8 (UNSPECIFIED) 3337 ENCR_DES_IV32 9 (UNSPECIFIED) 3338 RESERVED 10 3339 ENCR_NULL 11 (RFC2410) 3340 ENCR_AES_CBC 12 (RFC3602) 3341 ENCR_AES_CTR 13 (RFC3686) 3342 RESERVED TO IANA 14-1023 3343 PRIVATE USE 1024-65535 3345 For Transform Type 2 (Pseudo-random Function), defined Transform IDs 3346 are: 3348 Name Number Defined In 3349 ------------------------------------------------------ 3350 RESERVED 0 3351 PRF_HMAC_MD5 1 (RFC2104), [MD5] 3352 PRF_HMAC_SHA1 2 (RFC2104), [SHA] 3353 PRF_HMAC_TIGER 3 (RFC2104) 3354 PRF_AES128_XCBC 4 (RFC4434) 3355 RESERVED TO IANA 5-1023 3356 PRIVATE USE 1024-65535 3358 For Transform Type 3 (Integrity Algorithm), defined Transform IDs 3359 are: 3361 Name Number Defined In 3362 ---------------------------------------- 3363 NONE 0 3364 AUTH_HMAC_MD5_96 1 (RFC2403) 3365 AUTH_HMAC_SHA1_96 2 (RFC2404) 3366 AUTH_DES_MAC 3 (UNSPECIFIED) 3367 AUTH_KPDK_MD5 4 (UNSPECIFIED) 3368 AUTH_AES_XCBC_96 5 (RFC3566) 3369 RESERVED TO IANA 6-1023 3370 PRIVATE USE 1024-65535 3372 For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs 3373 are: 3375 Name Number Defined in 3376 ---------------------------------------- 3377 NONE 0 3378 768 Bit MODP 1 Appendix B 3379 1024 Bit MODP 2 Appendix B 3380 RESERVED TO IANA 3-4 3381 1536-bit MODP 5 [ADDGROUP] 3382 RESERVED TO IANA 6-13 3383 2048-bit MODP 14 [ADDGROUP] 3384 3072-bit MODP 15 [ADDGROUP] 3385 4096-bit MODP 16 [ADDGROUP] 3386 6144-bit MODP 17 [ADDGROUP] 3387 8192-bit MODP 18 [ADDGROUP] 3388 RESERVED TO IANA 19-1023 3389 PRIVATE USE 1024-65535 3391 For Transform Type 5 (Extended Sequence Numbers), defined Transform 3392 IDs are: 3394 Name Number 3395 -------------------------------------------- 3396 No Extended Sequence Numbers 0 3397 Extended Sequence Numbers 1 3398 RESERVED 2 - 65535 3400 {{ Clarif-4.4 }} Note that an initiator who supports ESNs will 3401 usually include two ESN transforms, with values "0" and "1", in its 3402 proposals. A proposal containing a single ESN transform with value 3403 "1" means that using normal (non-extended) sequence numbers is not 3404 acceptable. 3406 Numerous additional transform types have been defined since the 3407 publication of RFC 4306. Please refer to the IANA IKEv2 registry for 3408 details. 3410 3.3.3. Valid Transform Types by Protocol 3412 The number and type of transforms that accompany an SA payload are 3413 dependent on the protocol in the SA itself. An SA payload proposing 3414 the establishment of an SA has the following mandatory and optional 3415 transform types. A compliant implementation MUST understand all 3416 mandatory and optional types for each protocol it supports (though it 3417 need not accept proposals with unacceptable suites). A proposal MAY 3418 omit the optional types if the only value for them it will accept is 3419 NONE. 3421 Protocol Mandatory Types Optional Types 3422 --------------------------------------------------- 3423 IKE ENCR, PRF, INTEG*, D-H 3424 ESP ENCR, ESN INTEG, D-H 3425 AH INTEG, ESN D-H 3427 (*) Negotiating an integrity algorithm is mandatory for the 3428 Encrypted payload format specified in this document. For example, 3429 [AEAD] specifies additional formats based on authenticated 3430 encryption, in which a separate integrity algorithm is not 3431 negotiated. 3433 3.3.4. Mandatory Transform IDs 3435 The specification of suites that MUST and SHOULD be supported for 3436 interoperability has been removed from this document because they are 3437 likely to change more rapidly than this document evolves. 3439 An important lesson learned from IKEv1 is that no system should only 3440 implement the mandatory algorithms and expect them to be the best 3441 choice for all customers. 3443 It is likely that IANA will add additional transforms in the future, 3444 and some users may want to use private suites, especially for IKE 3445 where implementations should be capable of supporting different 3446 parameters, up to certain size limits. In support of this goal, all 3447 implementations of IKEv2 SHOULD include a management facility that 3448 allows specification (by a user or system administrator) of Diffie- 3449 Hellman (DH) parameters (the generator, modulus, and exponent lengths 3450 and values) for new DH groups. Implementations SHOULD provide a 3451 management interface through which these parameters and the 3452 associated transform IDs may be entered (by a user or system 3453 administrator), to enable negotiating such groups. 3455 All implementations of IKEv2 MUST include a management facility that 3456 enables a user or system administrator to specify the suites that are 3457 acceptable for use with IKE. Upon receipt of a payload with a set of 3458 transform IDs, the implementation MUST compare the transmitted 3459 transform IDs against those locally configured via the management 3460 controls, to verify that the proposed suite is acceptable based on 3461 local policy. The implementation MUST reject SA proposals that are 3462 not authorized by these IKE suite controls. Note that cryptographic 3463 suites that MUST be implemented need not be configured as acceptable 3464 to local policy. 3466 3.3.5. Transform Attributes 3468 Each transform in a Security Association payload may include 3469 attributes that modify or complete the specification of the 3470 transform. The set of valid attributes depends on the transform. 3471 Currently, only a single attribute type is defined: the Key Length 3472 attribute is used by certain encryption transforms with variable- 3473 length keys (see below for details). 3475 The attributes are type/value pairs and are defined below. 3476 Attributes can have a value with a fixed two-octet length or a 3477 variable-length value. For the latter, the attribute is encoded as 3478 type/length/value. 3480 1 2 3 3481 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 3482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3483 |A| Attribute Type | AF=0 Attribute Length | 3484 |F| | AF=1 Attribute Value | 3485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3486 | AF=0 Attribute Value | 3487 | AF=1 Not Transmitted | 3488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3490 Figure 9: Data Attributes 3492 o Attribute Format (AF) (1 bit) - Indicates whether the data 3493 attribute follow the Type/Length/Value (TLV) format or a shortened 3494 Type/Value (TV) format. If the AF bit is zero (0), then the 3495 attribute uses TLV format; if the AF bit is one (1), the TV format 3496 (with two-byte value) is used. 3498 o Attribute Type (15 bits) - Unique identifier for each type of 3499 attribute (see below). 3501 o Attribute Value (variable length) - Value of the Attribute 3502 associated with the Attribute Type. If the AF bit is a zero (0), 3503 this field has a variable length defined by the Attribute Length 3504 field. If the AF bit is a one (1), the Attribute Value has a 3505 length of 2 octets. 3507 Note that the only currently defined attribute type (Key Length) is 3508 fixed length; the variable-length encoding specification is included 3509 only for future extensions. Attributes described as fixed length 3510 MUST NOT be encoded using the variable-length encoding. Variable- 3511 length attributes MUST NOT be encoded as fixed-length even if their 3512 value can fit into two octets. NOTE: This is a change from IKEv1, 3513 where increased flexibility may have simplified the composer of 3514 messages but certainly complicated the parser. 3516 Attribute Type Value Attribute Format 3517 ------------------------------------------------------------ 3518 RESERVED 0-13 3519 Key Length (in bits) 14 TV 3520 RESERVED 15-17 3521 RESERVED TO IANA 18-16383 3522 PRIVATE USE 16384-32767 3524 Values 0-13 and 15-17 were used in a similar context in IKEv1, and 3525 should not be assigned except to matching values. 3527 The Key Length attribute specifies the key length in bits (MUST use 3528 network byte order) for certain transforms as follows: {{ Clarif-7.11 3529 }} 3531 o The Key Length attribute MUST NOT be used with transforms that use 3532 a fixed length key. This includes, e.g., ENCR_DES, ENCR_IDEA, and 3533 all the Type 2 (Pseudo-random function) and Type 3 (Integrity 3534 Algorithm) transforms specified in this document. It is 3535 recommended that future Type 2 or 3 transforms do not use this 3536 attribute. 3538 o Some transforms specify that the Key Length attribute MUST be 3539 always included (omitting the attribute is not allowed, and 3540 proposals not containing it MUST be rejected). This includes, 3541 e.g., ENCR_AES_CBC and ENCR_AES_CTR. 3543 o Some transforms allow variable-length keys, but also specify a 3544 default key length if the attribute is not included. These 3545 transforms include, e.g., ENCR_RC5 and ENCR_BLOWFISH. 3547 Implementation note: To further interoperability and to support 3548 upgrading endpoints independently, implementers of this protocol 3549 SHOULD accept values that they deem to supply greater security. For 3550 instance, if a peer is configured to accept a variable-length cipher 3551 with a key length of X bits and is offered that cipher with a larger 3552 key length, the implementation SHOULD accept the offer if it supports 3553 use of the longer key. 3555 Support of this capability allows a responder to express a concept of 3556 "at least" a certain level of security -- "a key length of _at least_ 3557 X bits for cipher Y". However, as the attribute is always returned 3558 unchanged (see the next section), an initiator willing to accept 3559 multiple key lengths has to include multiple transforms with the same 3560 Transform Type, each with different Key Length attribute. 3562 3.3.6. Attribute Negotiation 3564 During security association negotiation initiators present offers to 3565 responders. Responders MUST select a single complete set of 3566 parameters from the offers (or reject all offers if none are 3567 acceptable). If there are multiple proposals, the responder MUST 3568 choose a single proposal. If the selected proposal has multiple 3569 Transforms with the same type, the responder MUST choose a single 3570 one. Any attributes of a selected transform MUST be returned 3571 unmodified. The initiator of an exchange MUST check that the 3572 accepted offer is consistent with one of its proposals, and if not 3573 that response MUST be rejected. 3575 If the responder receives a proposal that contains a Transform Type 3576 it does not understand, or a proposal that is missing a mandatory 3577 Transform Type, it MUST consider this proposal unacceptable; however, 3578 other proposals in the same SA payload are processed as usual. 3579 Similarly, if the responder receives a transform that contains a 3580 Transform Attribute it does not understand, it MUST consider this 3581 transform unacceptable; other transforms with the same Transform Type 3582 are processed as usual. This allows new Transform Types and 3583 Transform Attributes to be defined in the future. An exception is 3584 the case where one of the proposals offered is for the Diffie-Hellman 3585 group of NONE. In this case, the responder MUST ignore the 3586 initiator's KE payload and omit the KE payload from the response. 3588 Negotiating Diffie-Hellman groups presents some special challenges. 3589 SA offers include proposed attributes and a Diffie-Hellman public 3590 number (KE) in the same message. If in the initial exchange the 3591 initiator offers to use one of several Diffie-Hellman groups, it 3592 SHOULD pick the one the responder is most likely to accept and 3593 include a KE corresponding to that group. If the responder selects a 3594 proposal using a different Diffie-Hellman group (other than NONE), 3595 the responder will indicate the correct group in the response and the 3596 initiator SHOULD pick an element of that group for its KE value when 3597 retrying the first message. It SHOULD, however, continue to propose 3598 its full supported set of groups in order to prevent a man-in-the- 3599 middle downgrade attack. 3601 3.4. Key Exchange Payload 3603 The Key Exchange Payload, denoted KE in this memo, is used to 3604 exchange Diffie-Hellman public numbers as part of a Diffie-Hellman 3605 key exchange. The Key Exchange Payload consists of the IKE generic 3606 payload header followed by the Diffie-Hellman public value itself. 3608 1 2 3 3609 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 3610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3611 | Next Payload |C| RESERVED | Payload Length | 3612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3613 | DH Group # | RESERVED | 3614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3615 | | 3616 ~ Key Exchange Data ~ 3617 | | 3618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3620 Figure 10: Key Exchange Payload Format 3622 A key exchange payload is constructed by copying one's Diffie-Hellman 3623 public value into the "Key Exchange Data" portion of the payload. 3624 The length of the Diffie-Hellman public value MUST be equal to the 3625 length of the prime modulus over which the exponentiation was 3626 performed, prepending zero bits to the value if necessary. 3628 The DH Group # identifies the Diffie-Hellman group in which the Key 3629 Exchange Data was computed (see Section 3.3.2). This Group # MUST 3630 match a DH Group specified in a proposal in the SA payload that is 3631 sent in the same message, and SHOULD match the DH group in the first 3632 group in the first proposal, if such exists. If none of the 3633 proposals in that SA payload specifies a DH Group, the KE payload 3634 MUST NOT be present. If the selected proposal uses a different 3635 Diffie-Hellman group (other than NONE), the message MUST be rejected 3636 with a Notify payload of type INVALID_KE_PAYLOAD. 3638 The payload type for the Key Exchange payload is thirty four (34). 3640 3.5. Identification Payloads 3642 The Identification Payloads, denoted IDi and IDr in this memo, allow 3643 peers to assert an identity to one another. This identity may be 3644 used for policy lookup, but does not necessarily have to match 3645 anything in the CERT payload; both fields may be used by an 3646 implementation to perform access control decisions. {{ Clarif-7.1 }} 3647 When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr 3648 payloads, IKEv2 does not require this address to match the address in 3649 the IP header of IKEv2 packets, or anything in the TSi/TSr payloads. 3650 The contents of IDi/IDr is used purely to fetch the policy and 3651 authentication data related to the other party. 3653 NOTE: In IKEv1, two ID payloads were used in each direction to hold 3654 Traffic Selector (TS) information for data passing over the SA. In 3655 IKEv2, this information is carried in TS payloads (see Section 3.13). 3657 The Identification Payload consists of the IKE generic payload header 3658 followed by identification fields as follows: 3660 1 2 3 3661 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 3662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3663 | Next Payload |C| RESERVED | Payload Length | 3664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3665 | ID Type | RESERVED | 3666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3667 | | 3668 ~ Identification Data ~ 3669 | | 3670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3672 Figure 11: Identification Payload Format 3674 o ID Type (1 octet) - Specifies the type of Identification being 3675 used. 3677 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 3679 o Identification Data (variable length) - Value, as indicated by the 3680 Identification Type. The length of the Identification Data is 3681 computed from the size in the ID payload header. 3683 The payload types for the Identification Payload are thirty five (35) 3684 for IDi and thirty six (36) for IDr. 3686 The following table lists the assigned values for the Identification 3687 Type field: 3689 ID Type Value 3690 ------------------------------------------------------------------- 3691 RESERVED 0 3693 ID_IPV4_ADDR 1 3694 A single four (4) octet IPv4 address. 3696 ID_FQDN 2 3697 A fully-qualified domain name string. An example of a ID_FQDN 3698 is, "example.com". The string MUST not contain any terminators 3699 (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; 3700 for an "internationalized domain name", the syntax is as defined 3701 in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net". 3703 ID_RFC822_ADDR 3 3704 A fully-qualified RFC822 email address string, An example of a 3705 ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not 3706 contain any terminators. Because of [EAI], implementations would 3707 be wise to treat this field as UTF-8 encoded text, not as 3708 pure ASCII. 3710 RESERVED TO IANA 4 3712 ID_IPV6_ADDR 5 3713 A single sixteen (16) octet IPv6 address. 3715 RESERVED TO IANA 6 - 8 3717 ID_DER_ASN1_DN 9 3718 The binary Distinguished Encoding Rules (DER) encoding of an 3719 ASN.1 X.500 Distinguished Name [X.501]. 3721 ID_DER_ASN1_GN 10 3722 The binary DER encoding of an ASN.1 X.500 GeneralName [X.509]. 3724 ID_KEY_ID 11 3725 An opaque octet stream which may be used to pass vendor- 3726 specific information necessary to do certain proprietary 3727 types of identification. 3729 RESERVED TO IANA 12-200 3731 PRIVATE USE 201-255 3732 Two implementations will interoperate only if each can generate a 3733 type of ID acceptable to the other. To assure maximum 3734 interoperability, implementations MUST be configurable to send at 3735 least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and 3736 MUST be configurable to accept all of these types. Implementations 3737 SHOULD be capable of generating and accepting all of these types. 3738 IPv6-capable implementations MUST additionally be configurable to 3739 accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable 3740 to send only ID_IPV6_ADDR. 3742 {{ Clarif-3.4 }} EAP [EAP] does not mandate the use of any particular 3743 type of identifier, but often EAP is used with Network Access 3744 Identifiers (NAIs) defined in [NAI]. Although NAIs look a bit like 3745 email addresses (e.g., "joe@example.com"), the syntax is not exactly 3746 the same as the syntax of email address in [MAILFORMAT]. For those 3747 NAIs that include the realm component, the ID_RFC822_ADDR 3748 identification type SHOULD be used. Responder implementations should 3749 not attempt to verify that the contents actually conform to the exact 3750 syntax given in [MAILFORMAT], but instead should accept any 3751 reasonable-looking NAI. For NAIs that do not include the realm 3752 component,the ID_KEY_ID identification type SHOULD be used. 3754 3.6. Certificate Payload 3756 The Certificate Payload, denoted CERT in this memo, provides a means 3757 to transport certificates or other authentication-related information 3758 via IKE. Certificate payloads SHOULD be included in an exchange if 3759 certificates are available to the sender unless the peer has 3760 indicated an ability to retrieve this information from elsewhere 3761 using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the 3762 term "Certificate Payload" is somewhat misleading, because not all 3763 authentication mechanisms use certificates and data other than 3764 certificates may be passed in this payload. 3766 The Certificate Payload is defined as follows: 3768 1 2 3 3769 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 3770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3771 | Next Payload |C| RESERVED | Payload Length | 3772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3773 | Cert Encoding | | 3774 +-+-+-+-+-+-+-+-+ | 3775 ~ Certificate Data ~ 3776 | | 3777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3779 Figure 12: Certificate Payload Format 3781 o Certificate Encoding (1 octet) - This field indicates the type of 3782 certificate or certificate-related information contained in the 3783 Certificate Data field. 3785 Certificate Encoding Value 3786 ---------------------------------------------------- 3787 RESERVED 0 3788 PKCS #7 wrapped X.509 certificate 1 UNSPECIFIED 3789 PGP Certificate 2 UNSPECIFIED 3790 DNS Signed Key 3 UNSPECIFIED 3791 X.509 Certificate - Signature 4 3792 Kerberos Token 6 UNSPECIFIED 3793 Certificate Revocation List (CRL) 7 3794 Authority Revocation List (ARL) 8 UNSPECIFIED 3795 SPKI Certificate 9 UNSPECIFIED 3796 X.509 Certificate - Attribute 10 UNSPECIFIED 3797 Raw RSA Key 11 3798 Hash and URL of X.509 certificate 12 3799 Hash and URL of X.509 bundle 13 3800 RESERVED to IANA 14 - 200 3801 PRIVATE USE 201 - 255 3803 o Certificate Data (variable length) - Actual encoding of 3804 certificate data. The type of certificate is indicated by the 3805 Certificate Encoding field. 3807 The payload type for the Certificate Payload is thirty seven (37). 3809 Specific syntax for some of the certificate type codes above is not 3810 defined in this document. The types whose syntax is defined in this 3811 document are: 3813 o X.509 Certificate - Signature (4) contains a DER encoded X.509 3814 certificate whose public key is used to validate the sender's AUTH 3815 payload. 3817 o Certificate Revocation List (7) contains a DER encoded X.509 3818 certificate revocation list. 3820 o {{ Added "DER-encoded RSAPublicKey structure" from Clarif-3.6 }} 3821 Raw RSA Key (11) contains a PKCS #1 encoded RSA key, that is, a 3822 DER-encoded RSAPublicKey structure (see [RSA] and [PKCS1]). 3824 o Hash and URL encodings (12-13) allow IKE messages to remain short 3825 by replacing long data structures with a 20 octet SHA-1 hash (see 3826 [SHA]) of the replaced value followed by a variable-length URL 3827 that resolves to the DER encoded data structure itself. This 3828 improves efficiency when the endpoints have certificate data 3829 cached and makes IKE less subject to denial of service attacks 3830 that become easier to mount when IKE messages are large enough to 3831 require IP fragmentation [DOSUDPPROT]. 3833 Use the following ASN.1 definition for an X.509 bundle: 3835 CertBundle 3836 { iso(1) identified-organization(3) dod(6) internet(1) 3837 security(5) mechanisms(5) pkix(7) id-mod(0) 3838 id-mod-cert-bundle(34) } 3840 DEFINITIONS EXPLICIT TAGS ::= 3841 BEGIN 3843 IMPORTS 3844 Certificate, CertificateList 3845 FROM PKIX1Explicit88 3846 { iso(1) identified-organization(3) dod(6) 3847 internet(1) security(5) mechanisms(5) pkix(7) 3848 id-mod(0) id-pkix1-explicit(18) } ; 3850 CertificateOrCRL ::= CHOICE { 3851 cert [0] Certificate, 3852 crl [1] CertificateList } 3854 CertificateBundle ::= SEQUENCE OF CertificateOrCRL 3856 END 3858 Implementations MUST be capable of being configured to send and 3859 accept up to four X.509 certificates in support of authentication, 3860 and also MUST be capable of being configured to send and accept the 3861 two Hash and URL formats (with HTTP URLs). Implementations SHOULD be 3862 capable of being configured to send and accept Raw RSA keys. If 3863 multiple certificates are sent, the first certificate MUST contain 3864 the public key used to sign the AUTH payload. The other certificates 3865 may be sent in any order. 3867 3.7. Certificate Request Payload 3869 The Certificate Request Payload, denoted CERTREQ in this memo, 3870 provides a means to request preferred certificates via IKE and can 3871 appear in the IKE_INIT_SA response and/or the IKE_AUTH request. 3872 Certificate Request payloads MAY be included in an exchange when the 3873 sender needs to get the certificate of the receiver. If multiple CAs 3874 are trusted and the certificate encoding does not allow a list, then 3875 multiple Certificate Request payloads would need to be transmitted. 3877 The Certificate Request Payload is defined as follows: 3879 1 2 3 3880 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 3881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3882 | Next Payload |C| RESERVED | Payload Length | 3883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3884 | Cert Encoding | | 3885 +-+-+-+-+-+-+-+-+ | 3886 ~ Certification Authority ~ 3887 | | 3888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3890 Figure 13: Certificate Request Payload Format 3892 o Certificate Encoding (1 octet) - Contains an encoding of the type 3893 or format of certificate requested. Values are listed in 3894 Section 3.6. 3896 o Certification Authority (variable length) - Contains an encoding 3897 of an acceptable certification authority for the type of 3898 certificate requested. 3900 The payload type for the Certificate Request Payload is thirty eight 3901 (38). 3903 The Certificate Encoding field has the same values as those defined 3904 in Section 3.6. The Certification Authority field contains an 3905 indicator of trusted authorities for this certificate type. The 3906 Certification Authority value is a concatenated list of SHA-1 hashes 3907 of the public keys of trusted Certification Authorities (CAs). Each 3908 is encoded as the SHA-1 hash of the Subject Public Key Info element 3909 (see section 4.1.2.7 of [PKIX]) from each Trust Anchor certificate. 3910 The twenty-octet hashes are concatenated and included with no other 3911 formatting. 3913 {{ Clarif-3.6 }} The contents of the "Certification Authority" field 3914 are defined only for X.509 certificates, which are types 4, 10, 12, 3915 and 13. Other values SHOULD NOT be used until standards-track 3916 specifications that specify their use are published. 3918 Note that the term "Certificate Request" is somewhat misleading, in 3919 that values other than certificates are defined in a "Certificate" 3920 payload and requests for those values can be present in a Certificate 3921 Request Payload. The syntax of the Certificate Request payload in 3922 such cases is not defined in this document. 3924 The Certificate Request Payload is processed by inspecting the "Cert 3925 Encoding" field to determine whether the processor has any 3926 certificates of this type. If so, the "Certification Authority" 3927 field is inspected to determine if the processor has any certificates 3928 that can be validated up to one of the specified certification 3929 authorities. This can be a chain of certificates. 3931 If an end-entity certificate exists that satisfies the criteria 3932 specified in the CERTREQ, a certificate or certificate chain SHOULD 3933 be sent back to the certificate requestor if the recipient of the 3934 CERTREQ: 3936 o is configured to use certificate authentication, 3938 o is allowed to send a CERT payload, 3940 o has matching CA trust policy governing the current negotiation, 3941 and 3943 o has at least one time-wise and usage appropriate end-entity 3944 certificate chaining to a CA provided in the CERTREQ. 3946 Certificate revocation checking must be considered during the 3947 chaining process used to select a certificate. Note that even if two 3948 peers are configured to use two different CAs, cross-certification 3949 relationships should be supported by appropriate selection logic. 3951 The intent is not to prevent communication through the strict 3952 adherence of selection of a certificate based on CERTREQ, when an 3953 alternate certificate could be selected by the sender that would 3954 still enable the recipient to successfully validate and trust it 3955 through trust conveyed by cross-certification, CRLs, or other out-of- 3956 band configured means. Thus, the processing of a CERTREQ should be 3957 seen as a suggestion for a certificate to select, not a mandated one. 3958 If no certificates exist, then the CERTREQ is ignored. This is not 3959 an error condition of the protocol. There may be cases where there 3960 is a preferred CA sent in the CERTREQ, but an alternate might be 3961 acceptable (perhaps after prompting a human operator). 3963 {{ 3.10.1-16392 }} The HTTP_CERT_LOOKUP_SUPPORTED notification MAY be 3964 included in any message that can include a CERTREQ payload and 3965 indicates that the sender is capable of looking up certificates based 3966 on an HTTP-based URL (and hence presumably would prefer to receive 3967 certificate specifications in that format). 3969 3.8. Authentication Payload 3971 The Authentication Payload, denoted AUTH in this memo, contains data 3972 used for authentication purposes. The syntax of the Authentication 3973 data varies according to the Auth Method as specified below. 3975 The Authentication Payload is defined as follows: 3977 1 2 3 3978 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 3979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3980 | Next Payload |C| RESERVED | Payload Length | 3981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3982 | Auth Method | RESERVED | 3983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3984 | | 3985 ~ Authentication Data ~ 3986 | | 3987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3989 Figure 14: Authentication Payload Format 3991 o Auth Method (1 octet) - Specifies the method of authentication 3992 used. Values defined are: 3994 * RSA Digital Signature (1) - Computed as specified in 3995 Section 2.15 using an RSA private key with RSASSA-PKCS1-v1_5 3996 signature scheme specified in [PKCS1] (implementors should note 3997 that IKEv1 used a different method for RSA signatures) {{ 3998 Clarif-3.3 }}. {{ Clarif-3.2 }} To promote interoperability, 3999 implementations that support this type SHOULD support 4000 signatures that use SHA-1 as the hash function and SHOULD use 4001 SHA-1 as the default hash function when generating signatures. 4003 * Shared Key Message Integrity Code (2) - Computed as specified 4004 in Section 2.15 using the shared key associated with the 4005 identity in the ID payload and the negotiated prf function 4007 * DSS Digital Signature (3) - Computed as specified in 4008 Section 2.15 using a DSS private key (see [DSS]) over a SHA-1 4009 hash. 4011 * The values 0 and 4-200 are reserved to IANA. The values 201- 4012 255 are available for private use. 4014 o Authentication Data (variable length) - see Section 2.15. 4016 The payload type for the Authentication Payload is thirty nine (39). 4018 3.9. Nonce Payload 4020 The Nonce Payload, denoted Ni and Nr in this memo for the initiator's 4021 and responder's nonce respectively, contains random data used to 4022 guarantee liveness during an exchange and protect against replay 4023 attacks. 4025 The Nonce Payload is defined as follows: 4027 1 2 3 4028 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 4029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4030 | Next Payload |C| RESERVED | Payload Length | 4031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4032 | | 4033 ~ Nonce Data ~ 4034 | | 4035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4037 Figure 15: Nonce Payload Format 4039 o Nonce Data (variable length) - Contains the random data generated 4040 by the transmitting entity. 4042 The payload type for the Nonce Payload is forty (40). 4044 The size of a Nonce MUST be between 16 and 256 octets inclusive. 4045 Nonce values MUST NOT be reused. 4047 3.10. Notify Payload 4049 The Notify Payload, denoted N in this document, is used to transmit 4050 informational data, such as error conditions and state transitions, 4051 to an IKE peer. A Notify Payload may appear in a response message 4052 (usually specifying why a request was rejected), in an INFORMATIONAL 4053 Exchange (to report an error not in an IKE request), or in any other 4054 message to indicate sender capabilities or to modify the meaning of 4055 the request. 4057 The Notify Payload is defined as follows: 4059 1 2 3 4060 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 4061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4062 | Next Payload |C| RESERVED | Payload Length | 4063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4064 | Protocol ID | SPI Size | Notify Message Type | 4065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4066 | | 4067 ~ Security Parameter Index (SPI) ~ 4068 | | 4069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4070 | | 4071 ~ Notification Data ~ 4072 | | 4073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4075 Figure 16: Notify Payload Format 4077 o Protocol ID (1 octet) - If this notification concerns an existing 4078 SA whose SPI is given the SPI field, this field indicates the type 4079 of that SA. For notifications concerning IPsec SAs this field 4080 MUST contain either (2) to indicate AH or (3) to indicate ESP. {{ 4081 Clarif-7.8 }} Of the notifications defined in this document, the 4082 SPI is included only with INVALID_SELECTORS and REKEY_SA. If the 4083 SPI field is empty, this field MUST be sent as zero and MUST be 4084 ignored on receipt. All other values for this field are reserved 4085 to IANA for future assignment. 4087 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 4088 IPsec protocol ID or zero if no SPI is applicable. For a 4089 notification concerning the IKE SA, the SPI Size MUST be zero and 4090 the field must be empty. 4092 o Notify Message Type (2 octets) - Specifies the type of 4093 notification message. 4095 o SPI (variable length) - Security Parameter Index. 4097 o Notification Data (variable length) - Informational or error data 4098 transmitted in addition to the Notify Message Type. Values for 4099 this field are type specific (see below). 4101 The payload type for the Notify Payload is forty one (41). 4103 3.10.1. Notify Message Types 4105 Notification information can be error messages specifying why an SA 4106 could not be established. It can also be status data that a process 4107 managing an SA database wishes to communicate with a peer process. 4108 The table below lists the Notification messages and their 4109 corresponding values. The number of different error statuses was 4110 greatly reduced from IKEv1 both for simplification and to avoid 4111 giving configuration information to probers. 4113 Types in the range 0 - 16383 are intended for reporting errors. An 4114 implementation receiving a Notify payload with one of these types 4115 that it does not recognize in a response MUST assume that the 4116 corresponding request has failed entirely. {{ Demoted the SHOULD }} 4117 Unrecognized error types in a request and status types in a request 4118 or response MUST be ignored, and they should be logged. 4120 Notify payloads with status types MAY be added to any message and 4121 MUST be ignored if not recognized. They are intended to indicate 4122 capabilities, and as part of SA negotiation are used to negotiate 4123 non-cryptographic parameters. 4125 NOTIFY messages: error types Value 4126 ------------------------------------------------------------------- 4128 RESERVED 0 4130 UNSUPPORTED_CRITICAL_PAYLOAD 1 4131 See Section 2.5. 4133 INVALID_IKE_SPI 4 4134 See Section 2.21. 4136 INVALID_MAJOR_VERSION 5 4137 See Section 2.5. 4139 INVALID_SYNTAX 7 4140 Indicates the IKE message that was received was invalid because 4141 some type, length, or value was out of range or because the 4142 request was rejected for policy reasons. To avoid a denial of 4143 service attack using forged messages, this status may only be 4144 returned for and in an encrypted packet if the message ID and 4145 cryptographic checksum were valid. To avoid leaking information 4146 to someone probing a node, this status MUST be sent in response 4147 to any error not covered by one of the other status types. 4148 {{ Demoted the SHOULD }} To aid debugging, more detailed error 4149 information should be written to a console or log. 4151 INVALID_MESSAGE_ID 9 4152 See Section 2.3. 4154 INVALID_SPI 11 4155 See Section 1.5. 4157 NO_PROPOSAL_CHOSEN 14 4158 None of the proposed crypto suites was acceptable. This can be 4159 sent in any case where the offered proposal (including but not 4160 limited to SA payload values, USE_TRANSPORT_MODE notify, 4161 IPCOMP_SUPPORTED notify) are not acceptable for the responder. 4162 This can also be used as "generic" Child SA error when Child SA 4163 cannot be created for some other reason. See also Section 2.7. 4165 INVALID_KE_PAYLOAD 17 4166 See Section 1.3. 4168 AUTHENTICATION_FAILED 24 4169 Sent in the response to an IKE_AUTH message when for some reason 4170 the authentication failed. There is no associated data. 4172 SINGLE_PAIR_REQUIRED 34 4173 See Section 2.9. 4175 NO_ADDITIONAL_SAS 35 4176 See Section 1.3. 4178 INTERNAL_ADDRESS_FAILURE 36 4179 See Section 3.15.4. 4181 FAILED_CP_REQUIRED 37 4182 See Section 2.19. 4184 TS_UNACCEPTABLE 38 4185 See Section 2.9. 4187 INVALID_SELECTORS 39 4188 MAY be sent in an IKE INFORMATIONAL exchange when a node receives 4189 an ESP or AH packet whose selectors do not match those of the SA 4190 on which it was delivered (and that caused the packet to be 4191 dropped). The Notification Data contains the start of the 4192 offending packet (as in ICMP messages) and the SPI field of the 4193 notification is set to match the SPI of the IPsec SA. 4195 RESERVED TO IANA 40-8191 4197 PRIVATE USE 8192-16383 4198 NOTIFY messages: status types Value 4199 ------------------------------------------------------------------- 4201 INITIAL_CONTACT 16384 4202 See Section 2.4. 4204 SET_WINDOW_SIZE 16385 4205 See Section 2.3. 4207 ADDITIONAL_TS_POSSIBLE 16386 4208 See Section 2.9. 4210 IPCOMP_SUPPORTED 16387 4211 See Section 2.22. 4213 NAT_DETECTION_SOURCE_IP 16388 4214 See Section 2.23. 4216 NAT_DETECTION_DESTINATION_IP 16389 4217 See Section 2.23. 4219 COOKIE 16390 4220 See Section 2.6. 4222 USE_TRANSPORT_MODE 16391 4223 See Section 1.3.1. 4225 HTTP_CERT_LOOKUP_SUPPORTED 16392 4226 See Section 3.6. 4228 REKEY_SA 16393 4229 See Section 1.3.3. 4231 ESP_TFC_PADDING_NOT_SUPPORTED 16394 4232 See Section 1.3.1. 4234 NON_FIRST_FRAGMENTS_ALSO 16395 4235 See Section 1.3.1. 4237 RESERVED TO IANA 16396-40959 4239 PRIVATE USE 40960-65535 4241 3.11. Delete Payload 4243 The Delete Payload, denoted D in this memo, contains a protocol 4244 specific security association identifier that the sender has removed 4245 from its security association database and is, therefore, no longer 4246 valid. Figure 17 shows the format of the Delete Payload. It is 4247 possible to send multiple SPIs in a Delete payload; however, each SPI 4248 MUST be for the same protocol. Mixing of protocol identifiers MUST 4249 NOT be performed in the Delete payload. It is permitted, however, to 4250 include multiple Delete payloads in a single INFORMATIONAL exchange 4251 where each Delete payload lists SPIs for a different protocol. 4253 Deletion of the IKE SA is indicated by a protocol ID of 1 (IKE) but 4254 no SPIs. Deletion of a Child SA, such as ESP or AH, will contain the 4255 IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI 4256 is the SPI the sending endpoint would expect in inbound ESP or AH 4257 packets. 4259 The Delete Payload is defined as follows: 4261 1 2 3 4262 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 4263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4264 | Next Payload |C| RESERVED | Payload Length | 4265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4266 | Protocol ID | SPI Size | # of SPIs | 4267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4268 | | 4269 ~ Security Parameter Index(es) (SPI) ~ 4270 | | 4271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4273 Figure 17: Delete Payload Format 4275 o Protocol ID (1 octet) - Must be 1 for an IKE SA, 2 for AH, or 3 4276 for ESP. 4278 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 4279 protocol ID. It MUST be zero for IKE (SPI is in message header) 4280 or four for AH and ESP. 4282 o # of SPIs (2 octets) - The number of SPIs contained in the Delete 4283 payload. The size of each SPI is defined by the SPI Size field. 4285 o Security Parameter Index(es) (variable length) - Identifies the 4286 specific security association(s) to delete. The length of this 4287 field is determined by the SPI Size and # of SPIs fields. 4289 The payload type for the Delete Payload is forty two (42). 4291 3.12. Vendor ID Payload 4293 The Vendor ID Payload, denoted V in this memo, contains a vendor 4294 defined constant. The constant is used by vendors to identify and 4295 recognize remote instances of their implementations. This mechanism 4296 allows a vendor to experiment with new features while maintaining 4297 backward compatibility. 4299 A Vendor ID payload MAY announce that the sender is capable of 4300 accepting certain extensions to the protocol, or it MAY simply 4301 identify the implementation as an aid in debugging. A Vendor ID 4302 payload MUST NOT change the interpretation of any information defined 4303 in this specification (i.e., the critical bit MUST be set to 0). 4304 Multiple Vendor ID payloads MAY be sent. An implementation is NOT 4305 REQUIRED to send any Vendor ID payload at all. 4307 A Vendor ID payload may be sent as part of any message. Reception of 4308 a familiar Vendor ID payload allows an implementation to make use of 4309 Private USE numbers described throughout this memo-- private 4310 payloads, private exchanges, private notifications, etc. Unfamiliar 4311 Vendor IDs MUST be ignored. 4313 Writers of Internet-Drafts who wish to extend this protocol MUST 4314 define a Vendor ID payload to announce the ability to implement the 4315 extension in the Internet-Draft. It is expected that Internet-Drafts 4316 that gain acceptance and are standardized will be given "magic 4317 numbers" out of the Future Use range by IANA, and the requirement to 4318 use a Vendor ID will go away. 4320 The Vendor ID Payload fields are defined as follows: 4322 1 2 3 4323 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 4324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4325 | Next Payload |C| RESERVED | Payload Length | 4326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4327 | | 4328 ~ Vendor ID (VID) ~ 4329 | | 4330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4332 Figure 18: Vendor ID Payload Format 4334 o Vendor ID (variable length) - It is the responsibility of the 4335 person choosing the Vendor ID to assure its uniqueness in spite of 4336 the absence of any central registry for IDs. Good practice is to 4337 include a company name, a person name, or some such. If you want 4338 to show off, you might include the latitude and longitude and time 4339 where you were when you chose the ID and some random input. A 4340 message digest of a long unique string is preferable to the long 4341 unique string itself. 4343 The payload type for the Vendor ID Payload is forty three (43). 4345 3.13. Traffic Selector Payload 4347 The Traffic Selector Payload, denoted TS in this memo, allows peers 4348 to identify packet flows for processing by IPsec security services. 4349 The Traffic Selector Payload consists of the IKE generic payload 4350 header followed by individual traffic selectors as follows: 4352 1 2 3 4353 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 4354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4355 | Next Payload |C| RESERVED | Payload Length | 4356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4357 | Number of TSs | RESERVED | 4358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4359 | | 4360 ~ ~ 4361 | | 4362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4364 Figure 19: Traffic Selectors Payload Format 4366 o Number of TSs (1 octet) - Number of traffic selectors being 4367 provided. 4369 o RESERVED - This field MUST be sent as zero and MUST be ignored on 4370 receipt. 4372 o Traffic Selectors (variable length) - One or more individual 4373 traffic selectors. 4375 The length of the Traffic Selector payload includes the TS header and 4376 all the traffic selectors. 4378 The payload type for the Traffic Selector payload is forty four (44) 4379 for addresses at the initiator's end of the SA and forty five (45) 4380 for addresses at the responder's end. 4382 {{ Clarif-4.7 }} There is no requirement that TSi and TSr contain the 4383 same number of individual traffic selectors. Thus, they are 4384 interpreted as follows: a packet matches a given TSi/TSr if it 4385 matches at least one of the individual selectors in TSi, and at least 4386 one of the individual selectors in TSr. 4388 For instance, the following traffic selectors: 4390 TSi = ((17, 100, 192.0.1.66-192.0.1.66), 4391 (17, 200, 192.0.1.66-192.0.1.66)) 4392 TSr = ((17, 300, 0.0.0.0-255.255.255.255), 4393 (17, 400, 0.0.0.0-255.255.255.255)) 4395 would match UDP packets from 192.0.1.66 to anywhere, with any of the 4396 four combinations of source/destination ports (100,300), (100,400), 4397 (200,300), and (200, 400). 4399 Thus, some types of policies may require several Child SA pairs. For 4400 instance, a policy matching only source/destination ports (100,300) 4401 and (200,400), but not the other two combinations, cannot be 4402 negotiated as a single Child SA pair. 4404 3.13.1. Traffic Selector 4406 1 2 3 4407 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 4408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4409 | TS Type |IP Protocol ID*| Selector Length | 4410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4411 | Start Port* | End Port* | 4412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4413 | | 4414 ~ Starting Address* ~ 4415 | | 4416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4417 | | 4418 ~ Ending Address* ~ 4419 | | 4420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4422 Figure 20: Traffic Selector 4424 *Note: All fields other than TS Type and Selector Length depend on 4425 the TS Type. The fields shown are for TS Types 7 and 8, the only two 4426 values currently defined. 4428 o TS Type (one octet) - Specifies the type of traffic selector. 4430 o IP protocol ID (1 octet) - Value specifying an associated IP 4431 protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that the 4432 protocol ID is not relevant to this traffic selector-- the SA can 4433 carry all protocols. 4435 o Selector Length - Specifies the length of this Traffic Selector 4436 Substructure including the header. 4438 o Start Port (2 octets) - Value specifying the smallest port number 4439 allowed by this Traffic Selector. For protocols for which port is 4440 undefined (including protocol 0), or if all ports are allowed, 4441 this field MUST be zero. For the ICMP protocol, the two one-octet 4442 fields Type and Code are treated as a single 16-bit integer (with 4443 Type in the most significant eight bits and Code in the least 4444 significant eight bits) port number for the purposes of filtering 4445 based on this field. 4447 o End Port (2 octets) - Value specifying the largest port number 4448 allowed by this Traffic Selector. For protocols for which port is 4449 undefined (including protocol 0), or if all ports are allowed, 4450 this field MUST be 65535. For the ICMP protocol, the two one- 4451 octet fields Type and Code are treated as a single 16-bit integer 4452 (with Type in the most significant eight bits and Code in the 4453 least significant eight bits) port number for the purposed of 4454 filtering based on this field. 4456 o Starting Address - The smallest address included in this Traffic 4457 Selector (length determined by TS type). 4459 o Ending Address - The largest address included in this Traffic 4460 Selector (length determined by TS type). 4462 Systems that are complying with [IPSECARCH] that wish to indicate 4463 "ANY" ports MUST set the start port to 0 and the end port to 65535; 4464 note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems 4465 working with [IPSECARCH] that wish to indicate "OPAQUE" ports, but 4466 not "ANY" ports, MUST set the start port to 65535 and the end port to 4467 0. 4469 {{ Added from Clarif-4.8 }} The traffic selector types 7 and 8 can 4470 also refer to ICMP type and code fields. Note, however, that ICMP 4471 packets do not have separate source and destination port fields. The 4472 method for specifying the traffic selectors for ICMP is shown by 4473 example in Section 4.4.1.3 of [IPSECARCH]. 4475 {{ Added from Clarif-4.9 }} Traffic selectors can use IP Protocol ID 4476 135 to match the IPv6 mobility header [MIPV6]. This document does 4477 not specify how to represent the "MH Type" field in traffic 4478 selectors, although it is likely that a different document will 4479 specify this in the future. Note that [IPSECARCH] says that the IPv6 4480 mobility header (MH) message type is placed in the most significant 4481 eight bits of the 16-bit local port selector. The direction 4482 semantics of TSi/TSr port fields are the same as for ICMP. 4484 The following table lists the assigned values for the Traffic 4485 Selector Type field and the corresponding Address Selector Data. 4487 TS Type Value 4488 ------------------------------------------------------------------- 4489 RESERVED 0-6 4491 TS_IPV4_ADDR_RANGE 7 4493 A range of IPv4 addresses, represented by two four-octet 4494 values. The first value is the beginning IPv4 address 4495 (inclusive) and the second value is the ending IPv4 address 4496 (inclusive). All addresses falling between the two specified 4497 addresses are considered to be within the list. 4499 TS_IPV6_ADDR_RANGE 8 4501 A range of IPv6 addresses, represented by two sixteen-octet 4502 values. The first value is the beginning IPv6 address 4503 (inclusive) and the second value is the ending IPv6 address 4504 (inclusive). All addresses falling between the two specified 4505 addresses are considered to be within the list. 4507 RESERVED TO IANA 9-240 4508 PRIVATE USE 241-255 4510 3.14. Encrypted Payload 4512 The Encrypted Payload, denoted SK{...} or E in this memo, contains 4513 other payloads in encrypted form. The Encrypted Payload, if present 4514 in a message, MUST be the last payload in the message. Often, it is 4515 the only payload in the message. 4517 The algorithms for encryption and integrity protection are negotiated 4518 during IKE SA setup, and the keys are computed as specified in 4519 Section 2.14 and Section 2.18. 4521 This document specifies the cryptographic processing of Encrypted 4522 payloads using a block cipher in CBC mode and an integrity check 4523 algorithm that computes a fixed-length checksum over a variable size 4524 message. The design is modeled after the ESP algorithms described in 4525 RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document 4526 completely specifies the cryptographic processing of IKE data, but 4527 those documents should be consulted for design rationale. Future 4528 documents may specify the processing of Encrypted payloads for other 4529 types of transforms, such as counter mode encryption and 4530 authenticated encryption algorithms. Peers MUST NOT negotiate 4531 transforms for which no such specification exists. 4533 The payload type for an Encrypted payload is forty six (46). The 4534 Encrypted Payload consists of the IKE generic payload header followed 4535 by individual fields as follows: 4537 1 2 3 4538 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 4539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4540 | Next Payload |C| RESERVED | Payload Length | 4541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4542 | Initialization Vector | 4543 | (length is block size for encryption algorithm) | 4544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4545 ~ Encrypted IKE Payloads ~ 4546 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4547 | | Padding (0-255 octets) | 4548 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 4549 | | Pad Length | 4550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4551 ~ Integrity Checksum Data ~ 4552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4554 Figure 21: Encrypted Payload Format 4556 o Next Payload - The payload type of the first embedded payload. 4557 Note that this is an exception in the standard header format, 4558 since the Encrypted payload is the last payload in the message and 4559 therefore the Next Payload field would normally be zero. But 4560 because the content of this payload is embedded payloads and there 4561 was no natural place to put the type of the first one, that type 4562 is placed here. 4564 o Payload Length - Includes the lengths of the header, IV, Encrypted 4565 IKE Payloads, Padding, Pad Length, and Integrity Checksum Data. 4567 o Initialization Vector - For CBC mode ciphers, the length of the 4568 initialization vector (IV) is equal to the block length of the 4569 underlying encryption algorithm. Senders MUST select a new 4570 unpredictable IV for every message; recipients MUST accept any 4571 value. The reader is encouraged to consult [MODES] for advice on 4572 IV generation. In particular, using the final ciphertext block of 4573 the previous message is not considered unpredictable. For modes 4574 other than CBC, the IV format and processing is specified in the 4575 document specifying the encryption algorithm and mode. 4577 o IKE Payloads are as specified earlier in this section. This field 4578 is encrypted with the negotiated cipher. 4580 o Padding MAY contain any value chosen by the sender, and MUST have 4581 a length that makes the combination of the Payloads, the Padding, 4582 and the Pad Length to be a multiple of the encryption block size. 4583 This field is encrypted with the negotiated cipher. 4585 o Pad Length is the length of the Padding field. The sender SHOULD 4586 set the Pad Length to the minimum value that makes the combination 4587 of the Payloads, the Padding, and the Pad Length a multiple of the 4588 block size, but the recipient MUST accept any length that results 4589 in proper alignment. This field is encrypted with the negotiated 4590 cipher. 4592 o Integrity Checksum Data is the cryptographic checksum of the 4593 entire message starting with the Fixed IKE Header through the Pad 4594 Length. The checksum MUST be computed over the encrypted message. 4595 Its length is determined by the integrity algorithm negotiated. 4597 3.15. Configuration Payload 4599 The Configuration payload, denoted CP in this document, is used to 4600 exchange configuration information between IKE peers. The exchange 4601 is for an IRAC to request an internal IP address from an IRAS and to 4602 exchange other information of the sort that one would acquire with 4603 Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly 4604 connected to a LAN. 4606 The Configuration Payload is defined as follows: 4608 1 2 3 4609 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 4610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4611 | Next Payload |C| RESERVED | Payload Length | 4612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4613 | CFG Type | RESERVED | 4614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4615 | | 4616 ~ Configuration Attributes ~ 4617 | | 4618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4620 Figure 22: Configuration Payload Format 4622 The payload type for the Configuration Payload is forty seven (47). 4624 o CFG Type (1 octet) - The type of exchange represented by the 4625 Configuration Attributes. 4627 CFG Type Value 4628 -------------------------- 4629 RESERVED 0 4630 CFG_REQUEST 1 4631 CFG_REPLY 2 4632 CFG_SET 3 4633 CFG_ACK 4 4634 RESERVED TO IANA 5-127 4635 PRIVATE USE 128-255 4637 o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on 4638 receipt. 4640 o Configuration Attributes (variable length) - These are type length 4641 values specific to the Configuration Payload and are defined 4642 below. There may be zero or more Configuration Attributes in this 4643 payload. 4645 3.15.1. Configuration Attributes 4647 1 2 3 4648 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 4649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4650 |R| Attribute Type | Length | 4651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4652 | | 4653 ~ Value ~ 4654 | | 4655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4657 Figure 23: Configuration Attribute Format 4659 o Reserved (1 bit) - This bit MUST be set to zero and MUST be 4660 ignored on receipt. 4662 o Attribute Type (15 bits) - A unique identifier for each of the 4663 Configuration Attribute Types. 4665 o Length (2 octets) - Length in octets of Value. 4667 o Value (0 or more octets) - The variable-length value of this 4668 Configuration Attribute. The following attribute types have been 4669 defined: 4671 Multi- 4672 Attribute Type Value Valued Length 4673 ------------------------------------------------------- 4674 RESERVED 0 4675 INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets 4676 INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets 4677 INTERNAL_IP4_DNS 3 YES 0 or 4 octets 4678 INTERNAL_IP4_NBNS 4 YES 0 or 4 octets 4679 RESERVED 5 4680 INTERNAL_IP4_DHCP 6 YES 0 or 4 octets 4681 APPLICATION_VERSION 7 NO 0 or more 4682 INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets 4683 RESERVED 9 4684 INTERNAL_IP6_DNS 10 YES 0 or 16 octets 4685 INTERNAL_IP6_NBNS 11 YES 0 or 16 octets 4686 INTERNAL_IP6_DHCP 12 YES 0 or 16 octets 4687 INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets 4688 SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 4689 INTERNAL_IP6_SUBNET 15 YES 17 octets 4690 RESERVED TO IANA 16-16383 4691 PRIVATE USE 16384-32767 4693 * These attributes may be multi-valued on return only if 4694 multiple values were requested. 4696 o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the 4697 internal network, sometimes called a red node address or private 4698 address and MAY be a private address on the Internet. {{ 4699 Clarif-6.2}} In a request message, the address specified is a 4700 requested address (or a zero-length address if no specific address 4701 is requested). If a specific address is requested, it likely 4702 indicates that a previous connection existed with this address and 4703 the requestor would like to reuse that address. With IPv6, a 4704 requestor MAY supply the low-order address octets it wants to use. 4705 Multiple internal addresses MAY be requested by requesting 4706 multiple internal address attributes. The responder MAY only send 4707 up to the number of addresses requested. The INTERNAL_IP6_ADDRESS 4708 is made up of two fields: the first is a 16-octet IPv6 address, 4709 and the second is a one-octet prefix-length as defined in 4710 [ADDRIPV6]. The requested address is valid until there are no IKE 4711 SAs between the peers. This is described in more detail in 4712 Section 3.15.3. 4714 o INTERNAL_IP4_NETMASK - The internal network's netmask. Only one 4715 netmask is allowed in the request and reply messages (e.g., 4716 255.255.255.0), and it MUST be used only with an 4717 INTERNAL_IP4_ADDRESS attribute. {{ Clarif-6.4 }} 4718 INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the same thing 4719 as INTERNAL_IP4_SUBNET containing the same information ("send 4720 traffic to these addresses through me"), but also implies a link 4721 boundary. For instance, the client could use its own address and 4722 the netmask to calculate the broadcast address of the link. An 4723 empty INTERNAL_IP4_NETMASK attribute can be included in a 4724 CFG_REQUEST to request this information (although the gateway can 4725 send the information even when not requested). Non-empty values 4726 for this attribute in a CFG_REQUEST do not make sense and thus 4727 MUST NOT be included. 4729 o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS 4730 server within the network. Multiple DNS servers MAY be requested. 4731 The responder MAY respond with zero or more DNS server attributes. 4733 o INTERNAL_IP4_NBNS - Specifies an address of a NetBios Name Server 4734 (WINS) within the network. Multiple NBNS servers MAY be 4735 requested. The responder MAY respond with zero or more NBNS 4736 server attributes. 4738 o INTERNAL_IP6_NBNS - {{ Clarif-6.6 }} NetBIOS is not defined for 4739 IPv6; therefore, INTERNAL_IP6_NBNS is also unspecified and is only 4740 retained for compatibility with RFC 4306. 4742 o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send 4743 any internal DHCP requests to the address contained within the 4744 attribute. Multiple DHCP servers MAY be requested. The responder 4745 MAY respond with zero or more DHCP server attributes. 4747 o APPLICATION_VERSION - The version or application information of 4748 the IPsec host. This is a string of printable ASCII characters 4749 that is NOT null terminated. 4751 o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge- 4752 device protects. This attribute is made up of two fields: the 4753 first being an IP address and the second being a netmask. 4754 Multiple sub-networks MAY be requested. The responder MAY respond 4755 with zero or more sub-network attributes. This is discussed in 4756 more detail in Section 3.15.2. 4758 o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute 4759 MUST be zero-length and specifies a query to the responder to 4760 reply back with all of the attributes that it supports. The 4761 response contains an attribute that contains a set of attribute 4762 identifiers each in 2 octets. The length divided by 2 (octets) 4763 would state the number of supported attributes contained in the 4764 response. 4766 o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge- 4767 device protects. This attribute is made up of two fields: the 4768 first is a 16-octet IPv6 address, and the second is a one-octet 4769 prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY 4770 be requested. The responder MAY respond with zero or more sub- 4771 network attributes. This is discussed in more detail in Section 4772 3.15.2. 4774 Note that no recommendations are made in this document as to how an 4775 implementation actually figures out what information to send in a 4776 reply. That is, we do not recommend any specific method of an IRAS 4777 determining which DNS server should be returned to a requesting IRAC. 4779 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET 4781 {{ Section added based on Clarif-6.3 }} 4783 INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets, 4784 ones that need one or more separate SAs, that can be reached through 4785 the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET 4786 attributes may also express the gateway's policy about what traffic 4787 should be sent through the gateway; the client can choose whether 4788 other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is 4789 sent through the gateway or directly to the destination. Thus, 4790 traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET 4791 attributes should be sent through the gateway that announces the 4792 attributes. If there are no existing IPsec SAs whose traffic 4793 selectors cover the address in question, new SAs need to be created. 4795 For instance, if there are two subnets, 192.0.1.0/26 and 4796 192.0.2.0/24, and the client's request contains the following: 4798 CP(CFG_REQUEST) = 4799 INTERNAL_IP4_ADDRESS() 4800 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) 4801 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) 4803 then a valid response could be the following (in which TSr and 4804 INTERNAL_IP4_SUBNET contain the same information): 4806 CP(CFG_REPLY) = 4807 INTERNAL_IP4_ADDRESS(192.0.1.234) 4808 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 4809 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 4810 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 4811 TSr = ((0, 0-65535, 192.0.1.0-192.0.1.63), 4812 (0, 0-65535, 192.0.2.0-192.0.2.255)) 4814 In these cases, the INTERNAL_IP4_SUBNET does not really carry any 4815 useful information. 4817 A different possible reply would have been this: 4819 CP(CFG_REPLY) = 4820 INTERNAL_IP4_ADDRESS(192.0.1.234) 4821 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 4822 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 4823 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 4824 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) 4826 That reply would mean that the client can send all its traffic 4827 through the gateway, but the gateway does not mind if the client 4828 sends traffic not included by INTERNAL_IP4_SUBNET directly to the 4829 destination (without going through the gateway). 4831 A different situation arises if the gateway has a policy that 4832 requires the traffic for the two subnets to be carried in separate 4833 SAs. Then a response like this would indicate to the client that if 4834 it wants access to the second subnet, it needs to create a separate 4835 SA: 4837 CP(CFG_REPLY) = 4838 INTERNAL_IP4_ADDRESS(192.0.1.234) 4839 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 4840 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 4841 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 4842 TSr = (0, 0-65535, 192.0.1.0-192.0.1.63) 4844 INTERNAL_IP4_SUBNET can also be useful if the client's TSr included 4845 only part of the address space. For instance, if the client requests 4846 the following: 4848 CP(CFG_REQUEST) = 4849 INTERNAL_IP4_ADDRESS() 4850 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) 4851 TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) 4853 then the gateway's reply might be: 4855 CP(CFG_REPLY) = 4856 INTERNAL_IP4_ADDRESS(192.0.1.234) 4857 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 4858 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 4859 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 4860 TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) 4861 Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET is in 4862 CFG_REQUESTs is unclear, they cannot be used reliably in 4863 CFG_REQUESTs. 4865 3.15.3. Configuration payloads for IPv6 4867 {{ Added this section from Clarif-6.5 }} 4869 The configuration payloads for IPv6 are based on the corresponding 4870 IPv4 payloads, and do not fully follow the "normal IPv6 way of doing 4871 things". In particular, IPv6 stateless autoconfiguration or router 4872 advertisement messages are not used; neither is neighbor discovery. 4874 A client can be assigned an IPv6 address using the 4875 INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange might 4876 look like this: 4878 CP(CFG_REQUEST) = 4879 INTERNAL_IP6_ADDRESS() 4880 INTERNAL_IP6_DNS() 4881 TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 4882 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 4884 CP(CFG_REPLY) = 4885 INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) 4886 INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) 4887 TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) 4888 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 4890 The client MAY send a non-empty INTERNAL_IP6_ADDRESS attribute in the 4891 CFG_REQUEST to request a specific address or interface identifier. 4892 The gateway first checks if the specified address is acceptable, and 4893 if it is, returns that one. If the address was not acceptable, the 4894 gateway attempts to use the interface identifier with some other 4895 prefix; if even that fails, the gateway selects another interface 4896 identifier. 4898 The INTERNAL_IP6_ADDRESS attribute also contains a prefix length 4899 field. When used in a CFG_REPLY, this corresponds to the 4900 INTERNAL_IP4_NETMASK attribute in the IPv4 case. 4902 Although this approach to configuring IPv6 addresses is reasonably 4903 simple, it has some limitations. IPsec tunnels configured using 4904 IKEv2 are not fully-featured "interfaces" in the IPv6 addressing 4905 architecture sense [IPV6ADDR]. In particular, they do not 4906 necessarily have link-local addresses, and this may complicate the 4907 use of protocols that assume them, such as [MLDV2]. 4909 3.15.4. Address Assignment Failures 4911 {{ Added this section from Clarif-6.8 }} 4913 If the responder encounters an error while attempting to assign an IP 4914 address to the initiator during the processing of a Configuration 4915 Payload, it responds with an INTERNAL_ADDRESS_FAILURE notification. 4916 The IKE SA is still created even if the initial Child SA cannot be 4917 created because of this failure. {{ 3.10.1-36 }} If this error is 4918 generated within an IKE_AUTH exchange, no Child SA will be created. 4919 However, there are some more complex error cases. 4921 If the responder does not support configuration payloads at all, it 4922 can simply ignore all configuration payloads. This type of 4923 implementation never sends INTERNAL_ADDRESS_FAILURE notifications. 4924 If the initiator requires the assignment of an IP address, it will 4925 treat a response without CFG_REPLY as an error. 4927 The initiator may request a particular type of address (IPv4 or IPv6) 4928 that the responder does not support, even though the responder 4929 supports configuration payloads. In this case, the responder simply 4930 ignores the type of address it does not support and processes the 4931 rest of the request as usual. 4933 If the initiator requests multiple addresses of a type that the 4934 responder supports, and some (but not all) of the requests fail, the 4935 responder replies with the successful addresses only. The responder 4936 sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned. 4938 3.16. Extensible Authentication Protocol (EAP) Payload 4940 The Extensible Authentication Protocol Payload, denoted EAP in this 4941 memo, allows IKE SAs to be authenticated using the protocol defined 4942 in RFC 3748 [EAP] and subsequent extensions to that protocol. The 4943 full set of acceptable values for the payload is defined elsewhere, 4944 but a short summary of RFC 3748 is included here to make this 4945 document stand alone in the common cases. 4947 1 2 3 4948 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 4949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4950 | Next Payload |C| RESERVED | Payload Length | 4951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4952 | | 4953 ~ EAP Message ~ 4954 | | 4955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4956 Figure 24: EAP Payload Format 4958 The payload type for an EAP Payload is forty eight (48). 4960 1 2 3 4961 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 4962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4963 | Code | Identifier | Length | 4964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4965 | Type | Type_Data... 4966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 4968 Figure 25: EAP Message Format 4970 o Code (1 octet) indicates whether this message is a Request (1), 4971 Response (2), Success (3), or Failure (4). 4973 o Identifier (1 octet) is used in PPP to distinguish replayed 4974 messages from repeated ones. Since in IKE, EAP runs over a 4975 reliable protocol, it serves no function here. In a response 4976 message, this octet MUST be set to match the identifier in the 4977 corresponding request. In other messages, this field MAY be set 4978 to any value. 4980 o Length (2 octets) is the length of the EAP message and MUST be 4981 four less than the Payload Length of the encapsulating payload. 4983 o Type (1 octet) is present only if the Code field is Request (1) or 4984 Response (2). For other codes, the EAP message length MUST be 4985 four octets and the Type and Type_Data fields MUST NOT be present. 4986 In a Request (1) message, Type indicates the data being requested. 4987 In a Response (2) message, Type MUST either be Nak or match the 4988 type of the data requested. The following types are defined in 4989 RFC 3748: 4991 1 Identity 4992 2 Notification 4993 3 Nak (Response Only) 4994 4 MD5-Challenge 4995 5 One-Time Password (OTP) 4996 6 Generic Token Card 4998 o Type_Data (Variable Length) varies with the Type of Request and 4999 the associated Response. For the documentation of the EAP 5000 methods, see [EAP]. 5002 {{ Demoted the SHOULD NOT and SHOULD }} Note that since IKE passes an 5003 indication of initiator identity in message 3 of the protocol, the 5004 responder should not send EAP Identity requests. The initiator may, 5005 however, respond to such requests if it receives them. 5007 4. Conformance Requirements 5009 In order to assure that all implementations of IKEv2 can 5010 interoperate, there are "MUST support" requirements in addition to 5011 those listed elsewhere. Of course, IKEv2 is a security protocol, and 5012 one of its major functions is to allow only authorized parties to 5013 successfully complete establishment of SAs. So a particular 5014 implementation may be configured with any of a number of restrictions 5015 concerning algorithms and trusted authorities that will prevent 5016 universal interoperability. 5018 IKEv2 is designed to permit minimal implementations that can 5019 interoperate with all compliant implementations. There are a series 5020 of optional features that can easily be ignored by a particular 5021 implementation if it does not support that feature. Those features 5022 include: 5024 o Ability to negotiate SAs through a NAT and tunnel the resulting 5025 ESP SA over UDP. 5027 o Ability to request (and respond to a request for) a temporary IP 5028 address on the remote end of a tunnel. 5030 o Ability to support various types of legacy authentication. 5032 o Ability to support window sizes greater than one. 5034 o Ability to establish multiple ESP or AH SAs within a single IKE 5035 SA. 5037 o Ability to rekey SAs. 5039 To assure interoperability, all implementations MUST be capable of 5040 parsing all payload types (if only to skip over them) and to ignore 5041 payload types that it does not support unless the critical bit is set 5042 in the payload header. If the critical bit is set in an unsupported 5043 payload header, all implementations MUST reject the messages 5044 containing those payloads. 5046 Every implementation MUST be capable of doing four-message 5047 IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, 5048 one for ESP or AH). Implementations MAY be initiate-only or respond- 5049 only if appropriate for their platform. Every implementation MUST be 5050 capable of responding to an INFORMATIONAL exchange, but a minimal 5051 implementation MAY respond to any INFORMATIONAL message with an empty 5052 INFORMATIONAL reply (note that within the context of an IKE SA, an 5053 "empty" message consists of an IKE header followed by an Encrypted 5054 payload with no payloads contained in it). A minimal implementation 5055 MAY support the CREATE_CHILD_SA exchange only in so far as to 5056 recognize requests and reject them with a Notify payload of type 5057 NO_ADDITIONAL_SAS. A minimal implementation need not be able to 5058 initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA 5059 expires (based on locally configured values of either lifetime or 5060 octets passed), and implementation MAY either try to renew it with a 5061 CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and 5062 create a new one. If the responder rejects the CREATE_CHILD_SA 5063 request with a NO_ADDITIONAL_SAS notification, the implementation 5064 MUST be capable of instead deleting the old SA and creating a new 5065 one. 5067 Implementations are not required to support requesting temporary IP 5068 addresses or responding to such requests. If an implementation does 5069 support issuing such requests, it MUST include a CP payload in 5070 message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or 5071 INTERNAL_IP6_ADDRESS. All other fields are optional. If an 5072 implementation supports responding to such requests, it MUST parse 5073 the CP payload of type CFG_REQUEST in message 3 and recognize a field 5074 of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports 5075 leasing an address of the appropriate type, it MUST return a CP 5076 payload of type CFG_REPLY containing an address of the requested 5077 type. {{ Demoted the SHOULD }} The responder may include any other 5078 related attributes. 5080 A minimal IPv4 responder implementation will ignore the contents of 5081 the CP payload except to determine that it includes an 5082 INTERNAL_IP4_ADDRESS attribute and will respond with the address and 5083 other related attributes regardless of whether the initiator 5084 requested them. 5086 A minimal IPv4 initiator will generate a CP payload containing only 5087 an INTERNAL_IP4_ADDRESS attribute and will parse the response 5088 ignoring attributes it does not know how to use. 5090 For an implementation to be called conforming to this specification, 5091 it MUST be possible to configure it to accept the following: 5093 o PKIX Certificates containing and signed by RSA keys of size 1024 5094 or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, 5095 ID_RFC822_ADDR, or ID_DER_ASN1_DN. 5097 o Shared key authentication where the ID passed is any of ID_KEY_ID, 5098 ID_FQDN, or ID_RFC822_ADDR. 5100 o Authentication where the responder is authenticated using PKIX 5101 Certificates and the initiator is authenticated using shared key 5102 authentication. 5104 5. Security Considerations 5106 While this protocol is designed to minimize disclosure of 5107 configuration information to unauthenticated peers, some such 5108 disclosure is unavoidable. One peer or the other must identify 5109 itself first and prove its identity first. To avoid probing, the 5110 initiator of an exchange is required to identify itself first, and 5111 usually is required to authenticate itself first. The initiator can, 5112 however, learn that the responder supports IKE and what cryptographic 5113 protocols it supports. The responder (or someone impersonating the 5114 responder) can probe the initiator not only for its identity, but 5115 using CERTREQ payloads may be able to determine what certificates the 5116 initiator is willing to use. 5118 Use of EAP authentication changes the probing possibilities somewhat. 5119 When EAP authentication is used, the responder proves its identity 5120 before the initiator does, so an initiator that knew the name of a 5121 valid initiator could probe the responder for both its name and 5122 certificates. 5124 Repeated rekeying using CREATE_CHILD_SA without additional Diffie- 5125 Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a 5126 single key or overrun of either endpoint. Implementers should take 5127 note of this fact and set a limit on CREATE_CHILD_SA exchanges 5128 between exponentiations. This memo does not prescribe such a limit. 5130 The strength of a key derived from a Diffie-Hellman exchange using 5131 any of the groups defined here depends on the inherent strength of 5132 the group, the size of the exponent used, and the entropy provided by 5133 the random number generator used. Due to these inputs, it is 5134 difficult to determine the strength of a key for any of the defined 5135 groups. Diffie-Hellman group number two, when used with a strong 5136 random number generator and an exponent no less than 200 bits, is 5137 common for use with 3DES. Group five provides greater security than 5138 group two. Group one is for historic purposes only and does not 5139 provide sufficient strength except for use with DES, which is also 5140 for historic use only. Implementations should make note of these 5141 estimates when establishing policy and negotiating security 5142 parameters. 5144 Note that these limitations are on the Diffie-Hellman groups 5145 themselves. There is nothing in IKE that prohibits using stronger 5146 groups nor is there anything that will dilute the strength obtained 5147 from stronger groups (limited by the strength of the other algorithms 5148 negotiated including the prf function). In fact, the extensible 5149 framework of IKE encourages the definition of more groups; use of 5150 elliptical curve groups may greatly increase strength using much 5151 smaller numbers. 5153 It is assumed that all Diffie-Hellman exponents are erased from 5154 memory after use. 5156 The IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator 5157 has been authenticated. As a result, an implementation of this 5158 protocol needs to be completely robust when deployed on any insecure 5159 network. Implementation vulnerabilities, particularly denial-of- 5160 service attacks, can be exploited by unauthenticated peers. This 5161 issue is particularly worrisome because of the unlimited number of 5162 messages in EAP-based authentication. 5164 The strength of all keys is limited by the size of the output of the 5165 negotiated prf function. For this reason, a prf function whose 5166 output is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with 5167 this protocol. 5169 The security of this protocol is critically dependent on the 5170 randomness of the randomly chosen parameters. These should be 5171 generated by a strong random or properly seeded pseudo-random source 5172 (see [RANDOMNESS]). Implementers should take care to ensure that use 5173 of random numbers for both keys and nonces is engineered in a fashion 5174 that does not undermine the security of the keys. 5176 For information on the rationale of many of the cryptographic design 5177 choices in this protocol, see [SIGMA] and [SKEME]. Though the 5178 security of negotiated Child SAs does not depend on the strength of 5179 the encryption and integrity protection negotiated in the IKE SA, 5180 implementations MUST NOT negotiate NONE as the IKE integrity 5181 protection algorithm or ENCR_NULL as the IKE encryption algorithm. 5183 When using pre-shared keys, a critical consideration is how to assure 5184 the randomness of these secrets. The strongest practice is to ensure 5185 that any pre-shared key contain as much randomness as the strongest 5186 key being negotiated. Deriving a shared secret from a password, 5187 name, or other low-entropy source is not secure. These sources are 5188 subject to dictionary and social engineering attacks, among others. 5190 The NAT_DETECTION_*_IP notifications contain a hash of the addresses 5191 and ports in an attempt to hide internal IP addresses behind a NAT. 5192 Since the IPv4 address space is only 32 bits, and it is usually very 5193 sparse, it would be possible for an attacker to find out the internal 5194 address used behind the NAT box by trying all possible IP addresses 5195 and trying to find the matching hash. The port numbers are normally 5196 fixed to 500, and the SPIs can be extracted from the packet. This 5197 reduces the number of hash calculations to 2^32. With an educated 5198 guess of the use of private address space, the number of hash 5199 calculations is much smaller. Designers should therefore not assume 5200 that use of IKE will not leak internal address information. 5202 When using an EAP authentication method that does not generate a 5203 shared key for protecting a subsequent AUTH payload, certain man-in- 5204 the-middle and server impersonation attacks are possible [EAPMITM]. 5205 These vulnerabilities occur when EAP is also used in protocols that 5206 are not protected with a secure tunnel. Since EAP is a general- 5207 purpose authentication protocol, which is often used to provide 5208 single-signon facilities, a deployed IPsec solution that relies on an 5209 EAP authentication method that does not generate a shared key (also 5210 known as a non-key-generating EAP method) can become compromised due 5211 to the deployment of an entirely unrelated application that also 5212 happens to use the same non-key-generating EAP method, but in an 5213 unprotected fashion. Note that this vulnerability is not limited to 5214 just EAP, but can occur in other scenarios where an authentication 5215 infrastructure is reused. For example, if the EAP mechanism used by 5216 IKEv2 utilizes a token authenticator, a man-in-the-middle attacker 5217 could impersonate the web server, intercept the token authentication 5218 exchange, and use it to initiate an IKEv2 connection. For this 5219 reason, use of non-key-generating EAP methods SHOULD be avoided where 5220 possible. Where they are used, it is extremely important that all 5221 usages of these EAP methods SHOULD utilize a protected tunnel, where 5222 the initiator validates the responder's certificate before initiating 5223 the EAP authentication. {{ Demoted the SHOULD }} Implementers should 5224 describe the vulnerabilities of using non-key-generating EAP methods 5225 in the documentation of their implementations so that the 5226 administrators deploying IPsec solutions are aware of these dangers. 5228 An implementation using EAP MUST also use strong authentication of 5229 the server to the client before the EAP authentication begins, even 5230 if the EAP method offers mutual authentication. This avoids having 5231 additional IKEv2 protocol variations and protects the EAP data from 5232 active attackers. 5234 If the messages of IKEv2 are long enough that IP-level fragmentation 5235 is necessary, it is possible that attackers could prevent the 5236 exchange from completing by exhausting the reassembly buffers. The 5237 chances of this can be minimized by using the Hash and URL encodings 5238 instead of sending certificates (see Section 3.6). Additional 5239 mitigations are discussed in [DOSUDPPROT]. 5241 Admission control is critical to the security of the protocol. For 5242 example, trust anchors used for identifying IKE peers should probably 5243 be different than those used for other forms of trust, such as those 5244 used to identify public web servers. Moreover, although IKE provides 5245 a great deal of leeway in defining the security policy for a trusted 5246 peer's identity, credentials, and the correlation between them, 5247 having such security policy defined explicitly is essential to a 5248 secure implementation. 5250 5.1. Traffic selector authorization 5252 {{ Added this section from Clarif-4.13 }} 5254 IKEv2 relies on information in the Peer Authorization Database (PAD) 5255 when determining what kind of IPsec SAs a peer is allowed to create. 5256 This process is described in [IPSECARCH] Section 4.4.3. When a peer 5257 requests the creation of an IPsec SA with some traffic selectors, the 5258 PAD must contain "Child SA Authorization Data" linking the identity 5259 authenticated by IKEv2 and the addresses permitted for traffic 5260 selectors. 5262 For example, the PAD might be configured so that authenticated 5263 identity "sgw23.example.com" is allowed to create IPsec SAs for 5264 192.0.2.0/24, meaning this security gateway is a valid 5265 "representative" for these addresses. Host-to-host IPsec requires 5266 similar entries, linking, for example, "fooserver4.example.com" with 5267 192.0.1.66/32, meaning this identity a valid "owner" or 5268 "representative" of the address in question. 5270 As noted in [IPSECARCH], "It is necessary to impose these constraints 5271 on creation of child SAs to prevent an authenticated peer from 5272 spoofing IDs associated with other, legitimate peers." In the 5273 example given above, a correct configuration of the PAD prevents 5274 sgw23 from creating IPsec SAs with address 192.0.1.66, and prevents 5275 fooserver4 from creating IPsec SAs with addresses from 192.0.2.0/24. 5277 It is important to note that simply sending IKEv2 packets using some 5278 particular address does not imply a permission to create IPsec SAs 5279 with that address in the traffic selectors. For example, even if 5280 sgw23 would be able to spoof its IP address as 192.0.1.66, it could 5281 not create IPsec SAs matching fooserver4's traffic. 5283 The IKEv2 specification does not specify how exactly IP address 5284 assignment using configuration payloads interacts with the PAD. Our 5285 interpretation is that when a security gateway assigns an address 5286 using configuration payloads, it also creates a temporary PAD entry 5287 linking the authenticated peer identity and the newly allocated inner 5288 address. 5290 It has been recognized that configuring the PAD correctly may be 5291 difficult in some environments. For instance, if IPsec is used 5292 between a pair of hosts whose addresses are allocated dynamically 5293 using DHCP, it is extremely difficult to ensure that the PAD 5294 specifies the correct "owner" for each IP address. This would 5295 require a mechanism to securely convey address assignments from the 5296 DHCP server, and link them to identities authenticated using IKEv2. 5298 Due to this limitation, some vendors have been known to configure 5299 their PADs to allow an authenticated peer to create IPsec SAs with 5300 traffic selectors containing the same address that was used for the 5301 IKEv2 packets. In environments where IP spoofing is possible (i.e., 5302 almost everywhere) this essentially allows any peer to create IPsec 5303 SAs with any traffic selectors. This is not an appropriate or secure 5304 configuration in most circumstances. See [H2HIPSEC] for an extensive 5305 discussion about this issue, and the limitations of host-to-host 5306 IPsec in general. 5308 6. IANA Considerations 5310 {{ This section was changed to not re-define any new IANA registries. 5311 }} 5313 [IKEV2] defined many field types and values. IANA has already 5314 registered those types and values, so the are not listed here again. 5315 No new types or values are registered in this document. However, 5316 IANA should update all references to RFC 4306 to point to this 5317 document. 5319 7. Acknowledgements 5321 The individuals on the IPsec mailing list was very helpful in both 5322 pointing out where clarifications and changes were needed, as well as 5323 in reviewing the clarifications suggested by others. 5325 The acknowledgements from the IKEv2 document were: 5327 This document is a collaborative effort of the entire IPsec WG. If 5328 there were no limit to the number of authors that could appear on an 5329 RFC, the following, in alphabetical order, would have been listed: 5330 Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt 5331 Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John 5332 Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero 5333 Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer 5334 Reingold, and Michael Richardson. Many other people contributed to 5335 the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, 5336 each of which has its own list of authors. Hugh Daniel suggested the 5337 feature of having the initiator, in message 3, specify a name for the 5338 responder, and gave the feature the cute name "You Tarzan, Me Jane". 5339 David Faucher and Valery Smyzlov helped refine the design of the 5340 traffic selector negotiation. 5342 This paragraph lists references that appear only in figures. The 5343 section is only here to keep the 'xml2rfc' program happy, and needs 5344 to be removed when the document is published. The RFC Editor will 5345 remove it before publication. [AEAD] [EAI] [DES] [IDEA] [MD5] 5346 [X.501] [X.509] 5348 8. References 5350 8.1. Normative References 5352 [ADDGROUP] 5353 Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 5354 Diffie-Hellman groups for Internet Key Exchange (IKE)", 5355 RFC 3526, May 2003. 5357 [ADDRIPV6] 5358 Hinden, R. and S. Deering, "Internet Protocol Version 6 5359 (IPv6) Addressing Architecture", RFC 4291, February 2006. 5361 [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 5362 Levkowetz, "Extensible Authentication Protocol (EAP)", 5363 RFC 3748, June 2004. 5365 [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 5366 of Explicit Congestion Notification (ECN) to IP", 5367 RFC 3168, September 2001. 5369 [ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 5370 Algorithms", RFC 2451, November 1998. 5372 [IPSECARCH] 5373 Kent, S. and K. Seo, "Security Architecture for the 5374 Internet Protocol", RFC 4301, December 2005. 5376 [MUSTSHOULD] 5377 Bradner, S., "Key Words for use in RFCs to indicate 5378 Requirement Levels", BCP 14, RFC 2119, March 1997. 5380 [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 5381 Standards (PKCS) #1: RSA Cryptography Specifications 5382 Version 2.1", RFC 3447, February 2003. 5384 [PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 5385 X.509 Public Key Infrastructure Certificate and 5386 Certificate Revocation List (CRL) Profile", RFC 3280, 5387 April 2002. 5389 [RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the 5390 Internet Key Exchange Protocol (IKE)", RFC 4434, 5391 February 2006. 5393 [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 5394 Advanced Encryption Standard-Cipher-based Message 5395 Authentication Code-Pseudo-Random Function-128 (AES-CMAC- 5396 PRF-128) Algorithm for the Internet Key Exchange Protocol 5397 (IKE)", RFC 4615, August 2006. 5399 [UDPENCAPS] 5400 Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 5401 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 5402 RFC 3948, January 2005. 5404 8.2. Informative References 5406 [AEAD] McGrew, D., "An Interface and Algorithms for Authenticated 5407 Encryption", RFC 5116, January 2008. 5409 [AH] Kent, S., "IP Authentication Header", RFC 4302, 5410 December 2005. 5412 [ARCHGUIDEPHIL] 5413 Bush, R. and D. Meyer, "Some Internet Architectural 5414 Guidelines and Philosophy", RFC 3439, December 2002. 5416 [ARCHPRINC] 5417 Carpenter, B., "Architectural Principles of the Internet", 5418 RFC 1958, June 1996. 5420 [Clarif] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 5421 Implementation Guidelines", RFC 4718, October 2006. 5423 [DES] American National Standards Institute, "American National 5424 Standard for Information Systems-Data Link Encryption", 5425 ANSI X3.106, 1983. 5427 [DH] Diffie, W. and M. Hellman, "New Directions in 5428 Cryptography", IEEE Transactions on Information Theory, 5429 V.IT-22 n. 6, June 1977. 5431 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", 5432 RFC 2131, March 1997. 5434 [DIFFSERVARCH] 5435 Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 5436 and W. Weiss, "An Architecture for Differentiated 5437 Services", RFC 2475. 5439 [DIFFSERVFIELD] 5440 Nichols, K., Blake, S., Baker, F., and D. Black, 5441 "Definition of the Differentiated Services Field (DS 5442 Field) in the IPv4 and IPv6 Headers", RFC 2474, 5443 December 1998. 5445 [DIFFTUNNEL] 5446 Black, D., "Differentiated Services and Tunnels", 5447 RFC 2983, October 2000. 5449 [DOI] Piper, D., "The Internet IP Security Domain of 5450 Interpretation for ISAKMP", RFC 2407, November 1998. 5452 [DOSUDPPROT] 5453 C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection 5454 for UDP-based protocols", ACM Conference on Computer and 5455 Communications Security , October 2003. 5457 [DSS] National Institute of Standards and Technology, U.S. 5458 Department of Commerce, "Digital Signature Standard", 5459 Draft FIPS 186-3, June 2008. 5461 [EAI] Abel, Y., "Internationalized Email Headers", RFC 5335, 5462 September 2008. 5464 [EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, "Man-in-the-Middle in 5465 Tunneled Authentication Protocols", November 2002, 5466 . 5468 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 5469 RFC 4303, December 2005. 5471 [EXCHANGEANALYSIS] 5472 R. Perlman and C. Kaufman, "Analysis of the IPsec key 5473 exchange Standard", WET-ICE Security Conference, MIT , 5474 2001, 5475 . 5477 [H2HIPSEC] 5478 Aura, T., Roe, M., and A. Mohammed, "Experiences with 5479 Host-to-Host IPsec", 13th International Workshop on 5480 Security Protocols, Cambridge, UK, April 2005. 5482 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 5483 Hashing for Message Authentication", RFC 2104, 5484 February 1997. 5486 [IDEA] X. Lai, "On the Design and Security of Block Ciphers", ETH 5487 Series in Information Processing, v. 1, Konstanz: Hartung- 5488 Gorre Verlag, 1992. 5490 [IDNA] Faltstrom, P., Hoffman, P., and A. Costello, 5491 "Internationalizing Domain Names in Applications (IDNA)", 5492 RFC 3490, March 2003. 5494 [IKEV1] Harkins, D. and D. Carrel, "The Internet Key Exchange 5495 (IKE)", RFC 2409, November 1998. 5497 [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 5498 RFC 4306, December 2005. 5500 [IP-COMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP 5501 Payload Compression Protocol (IPComp)", RFC 3173, 5502 September 2001. 5504 [IPSECARCH-OLD] 5505 Kent, S. and R. Atkinson, "Security Architecture for the 5506 Internet Protocol", RFC 2401, November 1998. 5508 [IPV6ADDR] 5509 Hinden, R. and S. Deering, "Internet Protocol Version 6 5510 (IPv6) Addressing Architecture", RFC 4291, February 2006. 5512 [ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet 5513 Security Association and Key Management Protocol 5514 (ISAKMP)", RFC 2408, November 1998. 5516 [LDAP] Sermersheim, J., "Lightweight Directory Access Protocol 5517 (v3)", RFC 4511, June 2006. 5519 [MAILFORMAT] 5520 Resnick, P., "Internet Message Format", RFC 2822, 5521 April 2001. 5523 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 5524 April 1992. 5526 [MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 5527 in IPv6", RFC 3775, June 2004. 5529 [MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery 5530 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 5532 [MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 5533 (MOBIKE)", RFC 4555, June 2006. 5535 [MODES] National Institute of Standards and Technology, U.S. 5536 Department of Commerce, "Recommendation for Block Cipher 5537 Modes of Operation", SP 800-38A, 2001. 5539 [NAI] Aboba, B., Beadles, M., Eronen, P., and J. Arkko, "The 5540 Network Access Identifier", RFC 4282, December 2005. 5542 [NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 5543 (NAT) Compatibility Requirements", RFC 3715, March 2004. 5545 [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", 5546 RFC 2412, November 1998. 5548 [PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 5549 Management API, Version 2", RFC 2367, July 1998. 5551 [PHOTURIS] 5552 Karn, P. and W. Simpson, "Photuris: Session-Key Management 5553 Protocol", RFC 2522, March 1999. 5555 [RADIUS] Rigney, C., Rubens, A., Simpson, W., and S. Willens, 5556 "Remote Authentication Dial In User Service (RADIUS)", 5557 RFC 2138, April 1997. 5559 [RANDOMNESS] 5560 Eastlake, D., Schiller, J., and S. Crocker, "Randomness 5561 Requirements for Security", BCP 106, RFC 4086, June 2005. 5563 [REAUTH] Nir, Y., "Repeated Authentication in Internet Key Exchange 5564 (IKEv2) Protocol", RFC 4478, April 2006. 5566 [REUSE] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In 5567 Diffie-Hellman Key Agreement Protocols", December 2008, 5568 . 5571 [ROHCV2] Ertekin, et. al., E., "IKEv2 Extensions to Support Robust 5572 Header Compression over IPsec (ROHCoIPsec)", 5573 draft-ietf-rohc-ikev2-extensions-hcoipsec (work in 5574 progress), October 2008. 5576 [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for 5577 Obtaining Digital Signatures and Public-Key 5578 Cryptosystems", February 1978. 5580 [SHA] National Institute of Standards and Technology, U.S. 5581 Department of Commerce, "Secure Hash Standard", 5582 FIPS 180-3, October 2008. 5584 [SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to 5585 Authenticated Diffie-Hellman and its Use in the IKE 5586 Protocols", Advances in Cryptography - CRYPTO 2003 5587 Proceedings LNCS 2729, 2003, . 5591 [SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange 5592 Mechanism for Internet", IEEE Proceedings of the 1996 5593 Symposium on Network and Distributed Systems Security , 5594 1996. 5596 [TRANSPARENCY] 5597 Carpenter, B., "Internet Transparency", RFC 2775, 5598 February 2000. 5600 [X.501] ITU-T, "Recommendation X.501: Information Technology - 5601 Open Systems Interconnection - The Directory: Models", 5602 1993. 5604 [X.509] ITU-T, "Recommendation X.509 (1997 E): Information 5605 Technology - Open Systems Interconnection - The Directory: 5606 Authentication Framework", 1997. 5608 Appendix A. Summary of changes from IKEv1 5610 The goals of this revision to IKE are: 5612 1. To define the entire IKE protocol in a single document, 5613 replacing RFCs 2407, 2408, and 2409 and incorporating subsequent 5614 changes to support NAT Traversal, Extensible Authentication, and 5615 Remote Address acquisition; 5617 2. To simplify IKE by replacing the eight different initial 5618 exchanges with a single four-message exchange (with changes in 5619 authentication mechanisms affecting only a single AUTH payload 5620 rather than restructuring the entire exchange) see 5621 [EXCHANGEANALYSIS]; 5623 3. To remove the Domain of Interpretation (DOI), Situation (SIT), 5624 and Labeled Domain Identifier fields, and the Commit and 5625 Authentication only bits; 5627 4. To decrease IKE's latency in the common case by making the 5628 initial exchange be 2 round trips (4 messages), and allowing the 5629 ability to piggyback setup of a Child SA on that exchange; 5631 5. To replace the cryptographic syntax for protecting the IKE 5632 messages themselves with one based closely on ESP to simplify 5633 implementation and security analysis; 5635 6. To reduce the number of possible error states by making the 5636 protocol reliable (all messages are acknowledged) and sequenced. 5637 This allows shortening CREATE_CHILD_SA exchanges from 3 messages 5638 to 2; 5640 7. To increase robustness by allowing the responder to not do 5641 significant processing until it receives a message proving that 5642 the initiator can receive messages at its claimed IP address; 5644 8. To fix cryptographic weaknesses such as the problem with 5645 symmetries in hashes used for authentication documented by Tero 5646 Kivinen; 5648 9. To specify Traffic Selectors in their own payloads type rather 5649 than overloading ID payloads, and making more flexible the 5650 Traffic Selectors that may be specified; 5652 10. To specify required behavior under certain error conditions or 5653 when data that is not understood is received in order to make it 5654 easier to make future revisions in a way that does not break 5655 backwards compatibility; 5657 11. To simplify and clarify how shared state is maintained in the 5658 presence of network failures and Denial of Service attacks; and 5660 12. To maintain existing syntax and magic numbers to the extent 5661 possible to make it likely that implementations of IKEv1 can be 5662 enhanced to support IKEv2 with minimum effort. 5664 Appendix B. Diffie-Hellman Groups 5666 There are two Diffie-Hellman groups defined here for use in IKE. 5667 These groups were generated by Richard Schroeppel at the University 5668 of Arizona. Properties of these primes are described in [OAKLEY]. 5670 The strength supplied by group one may not be sufficient for the 5671 mandatory-to-implement encryption algorithm and is here for historic 5672 reasons. 5674 Additional Diffie-Hellman groups have been defined in [ADDGROUP]. 5676 B.1. Group 1 - 768 Bit MODP 5678 This group is assigned id 1 (one). 5680 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 5681 Its hexadecimal value is: 5683 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 5684 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 5685 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 5686 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF 5688 The generator is 2. 5690 B.2. Group 2 - 1024 Bit MODP 5692 This group is assigned id 2 (two). 5694 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 5695 Its hexadecimal value is: 5697 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 5698 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 5699 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 5700 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 5701 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 5702 FFFFFFFF FFFFFFFF 5704 The generator is 2. 5706 Appendix C. Exchanges and Payloads 5708 {{ Clarif-AppA }} 5710 This appendix contains a short summary of the IKEv2 exchanges, and 5711 what payloads can appear in which message. This appendix is purely 5712 informative; if it disagrees with the body of this document, the 5713 other text is considered correct. 5715 Vendor-ID (V) payloads may be included in any place in any message. 5716 This sequence here shows what are the most logical places for them. 5718 C.1. IKE_SA_INIT Exchange 5720 request --> [N(COOKIE)], 5721 SA, KE, Ni, 5722 [N(NAT_DETECTION_SOURCE_IP)+, 5723 N(NAT_DETECTION_DESTINATION_IP)], 5724 [V+][N+] 5726 normal response <-- SA, KE, Nr, 5727 (no cookie) [N(NAT_DETECTION_SOURCE_IP), 5728 N(NAT_DETECTION_DESTINATION_IP)], 5729 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 5730 [V+][N+] 5732 cookie response <-- N(COOKIE), 5733 [V+][N+] 5735 different D-H <-- N(INVALID_KE_PAYLOAD), 5736 group wanted [V+][N+] 5738 C.2. IKE_AUTH Exchange without EAP 5740 request --> IDi, [CERT+], 5741 [N(INITIAL_CONTACT)], 5742 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 5743 [IDr], 5744 AUTH, 5745 [CP(CFG_REQUEST)], 5746 [N(IPCOMP_SUPPORTED)+], 5747 [N(USE_TRANSPORT_MODE)], 5748 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5749 [N(NON_FIRST_FRAGMENTS_ALSO)], 5750 SA, TSi, TSr, 5751 [V+][N+] 5753 response <-- IDr, [CERT+], 5754 AUTH, 5755 [CP(CFG_REPLY)], 5756 [N(IPCOMP_SUPPORTED)], 5757 [N(USE_TRANSPORT_MODE)], 5758 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5759 [N(NON_FIRST_FRAGMENTS_ALSO)], 5760 SA, TSi, TSr, 5761 [N(ADDITIONAL_TS_POSSIBLE)], 5762 [V+][N+] 5764 error in Child SA <-- IDr, [CERT+], 5765 creation AUTH, 5766 N(error), 5767 [V+][N+] 5769 C.3. IKE_AUTH Exchange with EAP 5771 first request --> IDi, 5772 [N(INITIAL_CONTACT)], 5773 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 5774 [IDr], 5775 [CP(CFG_REQUEST)], 5776 [N(IPCOMP_SUPPORTED)+], 5777 [N(USE_TRANSPORT_MODE)], 5778 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5779 [N(NON_FIRST_FRAGMENTS_ALSO)], 5780 SA, TSi, TSr, 5781 [V+][N+] 5783 first response <-- IDr, [CERT+], AUTH, 5784 EAP, 5785 [V+][N+] 5787 / --> EAP 5788 repeat 1..N times | 5789 \ <-- EAP 5791 last request --> AUTH 5793 last response <-- AUTH, 5794 [CP(CFG_REPLY)], 5795 [N(IPCOMP_SUPPORTED)], 5796 [N(USE_TRANSPORT_MODE)], 5797 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5798 [N(NON_FIRST_FRAGMENTS_ALSO)], 5799 SA, TSi, TSr, 5800 [N(ADDITIONAL_TS_POSSIBLE)], 5801 [V+][N+] 5803 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying Child SAs 5805 request --> [N(REKEY_SA)], 5806 [CP(CFG_REQUEST)], 5807 [N(IPCOMP_SUPPORTED)+], 5808 [N(USE_TRANSPORT_MODE)], 5809 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5810 [N(NON_FIRST_FRAGMENTS_ALSO)], 5811 SA, Ni, [KEi], TSi, TSr 5812 [V+][N+] 5814 normal <-- [CP(CFG_REPLY)], 5815 response [N(IPCOMP_SUPPORTED)], 5816 [N(USE_TRANSPORT_MODE)], 5817 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5818 [N(NON_FIRST_FRAGMENTS_ALSO)], 5819 SA, Nr, [KEr], TSi, TSr, 5820 [N(ADDITIONAL_TS_POSSIBLE)] 5821 [V+][N+] 5823 error case <-- N(error) 5825 different D-H <-- N(INVALID_KE_PAYLOAD), 5826 group wanted [V+][N+] 5828 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA 5830 request --> SA, Ni, [KEi] 5831 [V+][N+] 5833 response <-- SA, Nr, [KEr] 5834 [V+][N+] 5836 C.6. INFORMATIONAL Exchange 5838 request --> [N+], 5839 [D+], 5840 [CP(CFG_REQUEST)] 5842 response <-- [N+], 5843 [D+], 5844 [CP(CFG_REPLY)] 5846 Appendix D. Significant Changes from RFC 4306 5848 This is a placeholder that will be filled in. The WG needs to decide 5849 what level of specificity is most useful here. For example, it might 5850 only be changes that involve SHOULD-level or MUST-level requirements, 5851 or it might also include additional "significant" advice that was 5852 added. 5854 Appendix E. Changes Between Internet Draft Versions 5856 This section will be removed before publication as an RFC, but should 5857 be left intact until then so that reviewers can follow what has 5858 changed. 5860 E.1. Changes from IKEv2 to draft -00 5862 There were a zillion additions from RFC 4718. These are noted with 5863 "{{ Clarif-nn }}". 5865 Cleaned up many of the figures. Made the table headings consistent. 5866 Made some tables easier to read by removing blank spaces. Removed 5867 the "reserved to IANA" and "private use" text wording and moved it 5868 into the tables. 5870 Changed many SHOULD requirements to better match RFC 2119. These are 5871 also marked with comments such as "{{ Demoted the SHOULD }}". 5873 In Section 2.16, changed the MUST requirement of authenticating the 5874 responder from "public key signature based" to "strong" because that 5875 is what most current IKEv2 implementations do, and it better matches 5876 the actual security requirement. 5878 E.2. Changes from draft -00 to draft -01 5880 The most significant technical change was to make KE optional but 5881 strongly recommended in Section 1.3.2. 5883 Updated all references to the IKEv2 Clarifications document to RFC 5884 4718. 5886 Moved a lot of the protocol description out of the long tables in 5887 Section 3.10.1 into the body of the document. These are noted with 5888 "{{ 3.10.1-nnnn }}", where "nnnn" is the notification type number. 5890 Made some table changes based on suggestions from Alfred Hoenes. 5892 Changed "byte" to "octet" in many places. 5894 Removed discussion of ESP+AH bundles in many places, and added a 5895 paragraph about it in Section 1.7. 5897 Removed the discussion of INTERNAL_ADDRESS_EXPIRY in many places, and 5898 added a paragraph about it in Section 1.7. 5900 Moved Clarif-7.10 from Section 1.2 to Section 3.2. 5902 In the figure in Section 1.3.2, made KEi optional, and added text 5903 saying "The KEi payload SHOULD be included." 5905 In the figure in Section 1.3.2, maked KEr optional, and removed text 5906 saying "KEi and KEr are required for rekeying an IKE SA." 5908 In Section 1.4, clarified that the half-closed connections being 5909 discussed are AH and ESP. 5911 Rearranged the end of Section 1.7, and added the new notation for 5912 moving text out of 3.10.1. 5914 Clarified the wording in the second paragraph of Section 2.2. This 5915 allowd the removal of the fourth paragraph, which previously had 5916 Clarif-2.2 in it. 5918 In section 2.5, removed "or later" from "version 2.0". 5920 Added the question for implementers about payload order at the end of 5921 Section 2.5. 5923 Corrected Section 2.7 based on Clarif-7-13 to say that you can't do 5924 ESP and AH at one time. 5926 In Section 2.8, clarified the wording about how to replace an IKE SA. 5928 Clarified the text in the last many paragraphs in Section 2.9. Also 5929 moved some text from near the beginning of 2.9 to the beginning of 5930 2.9.1. 5932 Removed some redundant text in Section 2.9 concerning creating a 5933 Child SA pair not in response to an arriving packet. 5935 Added the following to the end of the first paragraph of Section 5936 2.14: "The lengths of SK_d, SK_pi, and SK_pr are the key length of 5937 the agreed-to PRF." 5939 Added the restriction in Section 2.15 that all PRFs used with IKEv2 5940 MUST take variable-sized keys. 5942 In Section 2.17, removed "If multiple IPsec protocols are negotiated, 5943 keying material is taken in the order in which the protocol headers 5944 will appear in the encapsulated packet" because multiple IPsec 5945 protocols cannot be negotiated at one time. 5947 Added the material from Clarif-5.12 to Section 2.18. 5949 Changed "hash of" to "expected value of" in Section 2.23. 5951 In the bulleted list in Section 2.23, replaced "this end" with a 5952 clearer description of which system is being discussed. 5954 Added the paragraph at the beginning of Section 3 about 5955 interoperability and UNSPECIFIED values ("In the tables in this 5956 section..."). 5958 Fixed Section 3.3 to not include proposal that include both AH and 5959 ESP. Ditto for the "Proposal #" bullet in Section 3.3.1. 5961 In the description of ID_FQDN in Section 3.5, added "All characters 5962 in the ID_FQDN are ASCII; this follows that for an "internationalized 5963 domain name" as defined in [IDNA]." 5965 In Section 3.8, shortened and clarified the description of "RSA 5966 Digital Signature". 5968 In Section 3.10, shortened and clarified the description of "Protocol 5969 ID". 5971 In Section 3.15, "The requested address is valid until the expiry 5972 time defined with the INTERNAL_ADDRESS_EXPIRY attribute or there are 5973 no IKE SAs between the peers" is shortened to just "The requested 5974 address is valid until there are no IKE SAs between the peers." 5976 In Section 3.15.1, changed "INTERNAL_IP6_NBNS" to unspecified. 5978 Made [ADDRIPV6] an informative reference instead of a normative 5979 reference and updated it. 5981 Made [PKCS1] a normative reference instead of an informative 5982 reference and changed the pointer to RFC 3447. 5984 E.3. Changes from draft -00 to draft -01 5986 In Section 1.5, added "request" to first sentence to make it "If an 5987 encrypted IKE request packet arrives on port 500 or 4500 with an 5988 unrecognized SPI...". 5990 In Section 3.3, fifth paragraph, upped the number of transforms for 5991 AH and ESP by one each to account for ESN, which is now mandatory. 5993 In Section 2.1, added "or equal to" in "The responder MUST remember 5994 each response until it receives a request whose sequence number is 5995 larger than or equal to the sequence number in the response plus its 5996 window size." 5998 In Section 2.18, removed " Note that this may not work if the new IKE 5999 SA's PRF has a fixed key size because the output of the PRF may not 6000 be of the correct size." because it is no longer relevant. 6002 E.4. Changes from draft -01 to draft -02 6004 Many grammatical fixes. 6006 In Section 1.2, reworded Clarif-4.3 to be clearer. 6008 In Section 1.3.3, reworded 3.10.1-16393 and Clarif-5.4 to remove 6009 redundant text. 6011 In Section 2.13, replaced text about variable length keys with 6012 clearer explanation and requirement on non-HMAC PRFs. Also added 6013 "preferred" to Section 2.14 for the key length, and removed redundant 6014 text. 6016 In Section 2.14, removed the "half and half" description and replaced 6017 it with exceptions for RFC4434 and RFC4615. 6019 Removed the now-redundant "All PRFs used with IKEv2 MUST take 6020 variable-sized keys" from Section 2.15. 6022 In Section 2.15, added "(IKE_SA_INIT response)" after "of the second 6023 message" and "(IKE_SA_INIT request)" after "the first message". 6025 In Section 2.17, simplified because there are no more bundles. "A 6026 single Child SA negotiation may result in multiple security 6027 associations. ESP and AH SAs exist in pairs (one in each 6028 direction)." becomes "For ESP and AH, a single Child SA negotiation 6029 results in two security associations (one in each direction)." 6031 In section 3.3, made the example of combinations of algorithms and 6032 the contents of the first proposal clearer. 6034 Added Clarif-4.4 to the end of Section 3.3.2. 6036 Reordered Section 3.3.5 and added Clarif-7.11. 6038 Clarified Section 3.3.6 about choosing a single proposal. Also added 6039 second paragraph about transforms not understood, and clarified third 6040 paragraph about picking D-H groups. 6042 Moved 3.10.1-16392 from Section 3.6 to 3.7. 6044 In Section 3.10, clarified 3.10.1-16394. 6046 Updated Section 6 to indicate that there is nothing new for IANA in 6047 this spec. Also removed the definition of "Expert Review" from 6048 Section 1.6 for the same reason. 6050 In Appendix A, removed "and not commit any state to an exchange until 6051 the initiator can be cryptographically authenticated" because that 6052 was only true in an earlier version of IKEv2. 6054 E.5. Changes from draft -02 to draft -03 6056 In Section 1.3, changed "If the responder rejects the Diffie-Hellman 6057 group of the KEi payload, the responder MUST reject the request and 6058 indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD 6059 Notification payload." to "If the responder selects a proposal using 6060 a different Diffie-Hellman group (other than NONE), the responder 6061 MUST reject the request and indicate its preferred Diffie-Hellman 6062 group in the INVALID_KE_PAYLOAD Notification payload. 6064 In Section 2.3, added the last two paragraphs covering why you 6065 initiator's SPI and/or IP to differentiate if this is a "half-open" 6066 IKE SA or a new request. Also removed similar text from Section 2.2. 6068 In Section 2.5, added "Payloads sent in IKE response messages MUST 6069 NOT have the critical flag set. Note that the critical flag applies 6070 only to the payload type, not the contents. If the payload type is 6071 recognized, but the payload contains something which is not (such as 6072 an unknown transform inside an SA payload, or an unknown Notify 6073 Message Type inside a Notify payload), the critical flag is ignored." 6075 In Section 2.6, moved the text about {{ 3.10.1-16390 }} later in the 6076 section. Also reworded the text to make it clearer what the COOKIE 6077 is for. 6079 Moved text from {{ Clarif-2.1 }} from Section 2.6 to Section 2.7. 6081 In Section 2.13, added "(see Section 3.3.5 for the defintion of the 6082 Key Length transform attribute)". 6084 In Section 2.17, change the description of the keying material from 6085 the list with two bullets to a clearer list. 6087 In Section 2.23, added "Implementations MUST process received UDP- 6088 encapsulated ESP packets even when no NAT was detected." 6089 In Section 3.3, changed "Each proposal may contain a" to "Each 6090 proposal contains a". 6092 Added the asterisks to the transform type table in Section 3.3.2 and 6093 the types table in 3.3.3 to foreshadow future developments. 6095 In Section 3.3.2, changed the following algorithms to (UNSPECIFIED) 6096 because the RFCs listed didn't really specify how to implement them 6097 in an interoperable fashion: 6099 Encryption Algorithms 6100 ENCR_DES_IV64 1 (RFC1827) 6101 ENCR_3IDEA 8 (RFC2451) 6102 ENCR_DES_IV32 9 6103 Pseudo-random Functions 6104 PRF_HMAC_TIGER 3 (RFC2104) 6105 Integrity Algorithms 6106 AUTH_DES_MAC 3 6107 AUTH_KPDK_MD5 4 (RFC1826) 6109 In Section 3.4, added "(other than NONE)" to the second-to-last 6110 paragraph. 6112 Rewrote the third paragraph of Section 3.14 to talk about other 6113 modes, and to clarify which encryption and integrity protection we 6114 are talking about. 6116 Changed the "Initialization Vector" bullet in Section 3.14 to specify 6117 better what is needed for the IV. Upgraded the SHOULDs to MUSTs. 6118 Also added the reference for [MODES]. 6120 In Section 5, in the second-to-last paragraph, changed "a public-key- 6121 based" to "strong" to match the wording in Section 2.16. 6123 E.6. Changes from draft -03 to draft-ietf-ipsecme-ikev2bis-00 6125 Changed the document's filename to draft-ietf-ipsecme-ikev2bis-00. 6126 Added Yoav Nir as a co-author. 6128 In many places in the document, changed "and/or" to "or" when talking 6129 about combinations of ESP and AH SAs. For example, in the intro, it 6130 said "can be used to efficiently establish SAs for Encapsulating 6131 Security Payload (ESP) and/or Authentication Header (AH)". This is 6132 changed to "or" to indicate that you can only establish one type of 6133 SA at a time. 6135 In Section 1, clarified that RFC 4306 already replaced IKEv1, and 6136 that this document replaces RFC 4306. Also fixed Section 2.5 for 6137 similar issue. Also updated the Abstract to cover this. 6139 In Section 2.15, in the responder's signed octets, changed: 6141 RestOfRespIDPayload = IDType | RESERVED | InitIDData 6142 to 6143 RestOfRespIDPayload = IDType | RESERVED | RespIDData 6145 In 2.16, changed "strong" back to "public key signature based" to 6146 make it the same as 4306. 6148 In section 3.10, added "and the field must be empty" to make it clear 6149 that a zero-length SPI is really empty. 6151 E.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to 6152 draft-ietf-ipsecme-ikev2bis-01 6154 Throughout, changed "IKE_SA" to "IKE SA", and changed "CHILD_SA" to 6155 "Child SA" (except left "CREATE_CHILD_SA" alone). 6157 Added the middle sentence in the Abstract to say what IKE actually 6158 does. 6160 Added in section 1 "(unless there is failure setting up the AH or ESP 6161 Child SA, in which case the IKE SA is still established without IPsec 6162 SA)". 6164 Clarified the titles of 1.1.1, 1.1.2, and 1.1.3. 6166 In 1.1.2, changed "If there is an inner IP header, the inner 6167 addresses will be the same as the outer addresses." because we are 6168 talking about transport mode here. 6170 Added reference to section 2.14 to setion 1.2 and 1.3. 6172 In 1.2, clarified what is and isn't encrypted in a message. 6174 Added the following to 1.2: "If the IDr proposed by the initiator is 6175 not acceptable to the responder, the responder might use some other 6176 IDr to finish the exchange. If the initiator then does not accept 6177 that fact that responder used different IDr than the one that was 6178 requested, the initiator can close the SA after noticing the fact." 6180 Moved the paragraph beginning "All messages following..." from 1.3 up 6181 to 1.2, and reworded it to apply to all the cases it covers. 6183 At the end of section 1.3.1, clarified that the responder is the one 6184 who controls whether non-first-fragments will be sent, and reworded 6185 the paragraph. 6187 In section 1.3.3, added "The Protocol ID field of the REKEY_SA 6188 notification is set to match the protocol of the SA we are rekeying, 6189 for example, 3 for ESP and 2 for AH." [Issue #10] 6191 In 1.3.2, added "of the SA payload" to "New initiator and responder 6192 SPIs are supplied in the SPI fields." 6194 In 1.3.3, fixed the art. 6196 <-- HDR, SK {SA, Nr, [KEr], 6197 Si, TSr} 6198 becomes 6199 <-- HDR, SK {SA, Nr, [KEr], 6200 TSi, TSr} 6202 In 1.4 and 2.18, changed "replaced for the purpose of rekeying" to 6203 "rekeyed". 6205 Split out the SA deletion material from section 1.4 into its own 6206 subsection, 1.4.1. 6208 Clarified which bits are set at the end of Section 1.5. 6210 In 1.7, added "That is, the version number is *not* changed from RFC 6211 4306.". 6213 In 2.1, added wording about retransmissions needing to be identical. 6215 In 2.2, added "or rekeyed" to "In the unlikely event that Message IDs 6216 grow too large to fit in 32 bits, the IKE SA MUST be closed" 6218 In 2.2, moved the sentence "Rekeying an IKE SA resets the sequence 6219 numbers." up higher so it would be more likely to be seen. [Issue 6220 #15] 6222 Moved the definition of "original initiator" from 2.8 into 2.2 6223 because that is where it is first used. 6225 In 2.4, added "fresh (i.e., not retransmitted)" to "If a 6226 cryptographically protected message has been received from the other 6227 side recently". Also added the sentence saying that liveness checks 6228 are sometimes call dead peer detection. 6230 Removed the question to implementers about payload order in 2.5. 6232 Changed the title of 2.6 to "IKE SA SPIs and Cookies". Also, in the 6233 paragraph that describes how to implement the responder, changed the 6234 lower-case "should" to "can" to emphasize that this is a choice. 6236 Added the second paragraph in 2.6 to make it clear that the SPI is 6237 used for mapping. 6239 In section 2.6, upgraded "needs to choose them so as to be unique 6240 identifiers of an IKE_SA" to a MUST. 6242 Added sentences at the end of 2.6 eplaining wny the initiator should 6243 limit the number of responses it sends out. 6245 In 2.6.1, added the example of the shorter exchange; this is copied 6246 from RFC 4718 but was dropped in early drafts of this document. 6248 Added the paragraph to 2.7 that describes needing two proposals if 6249 you are having both normal ciphers and combined-mode ciphers. [Issue 6250 #20]. 6252 In section 2.8, added "Note that, when rekeying, the new Child SA MAY 6253 have different traffic selectors and algorithms than the old one." 6255 Added a note in 2.9 that PFKEY applies only to IKEv1. Also added 6256 that unknown traffic selector types are not returned in narrowed 6257 responses. 6259 Added note in the first paragraph of Setion 2.9.1 about decorrelated 6260 policies preventing the problem mentioned. 6262 In 2.12, removed "In particular, it MUST forget the secrets used in 6263 the Diffie-Hellman calculation and any state that may persist in the 6264 state of a pseudo-random number generator that could be used to 6265 recompute the Diffie-Hellman secrets." 6267 In 2.15, noted that the retry could happen multiple times for 6268 different reasons. 6270 In section 2.16, changed "This shared key generated during an IKE 6271 exchange" to "This key". 6273 At the end of 2.19, added statement that FAILED_CP_REQUIRED is not 6274 fatal to the IKE SA. 6276 Added the reference to ROHCV2 to the end of 2.22. 6278 In 2.23, changed "can negotiate" to "will use". for UDP 6279 encapsulation. Added "or 4500" to "...MUST be sent from and to UDP 6280 port 500". Also removed the text about why not to do NAT-traversal 6281 over port 500 because we later say you can't do that anyway. [Issue 6282 #27] Also removed the last paragraph, which obliquely pointed to 6283 MOBIKE. More will be added later on MOBIKE. 6285 In 3.1, removed "and orderings of messages" from "Exchange type". 6286 [Issue #29] 6288 In 3.1, added "This bit changes to reflect who initiated the last 6289 rekey of the IKE SA." to the description of the Initiator bit. 6291 In 3.3, added a long example of why you might use a Proposal 6292 structure because of combined-mode algorithms. [Issue #42] 6294 In 3.3.2, changed "is unnecessary because the last Proposal could be 6295 identified from the length of the SA" to "is unnecessary because the 6296 last transform could be identified from the length of the proposal." 6298 Added reference to AEAD to 3.3.2 and 3.3.3. 6300 Added the reference to RFC 2104 back for PRF_HMAC_TIGER in 3.3.2. 6301 [Issue #33] 6303 Added note at the bottom of 3.3.2 to see the IANA registry. 6305 In 3.3.4, removed all the "this could happen in the future" stuff 6306 because it already happened. 6308 Added a reference to email address internationalization to 3.5, 6309 making the address binary (not ASCII). 6311 In the table in 3.6, made "Authority Revocation List (ARL) 8" and 6312 "X.509 Certificate - Attribute 10" unspecified. 6314 In 3.7, changed the last sentence of the first paragraph to eliminate 6315 the non-protocol SHOULD. 6317 In 3.13.1, added "(including protocol 0)" for the start port and end 6318 port. 6320 In 3.14, updated the discussion of initialization modes to reflect 6321 that it is only about CBC, and that other specs have to specify their 6322 own IVs. 6324 In 3.15.1, added a pointer to 3.15.3. In the entries for 6325 INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET, added a pointer to 6326 3.15.2. 6328 In 3.15.4, added "The IKE SA is still created even if the initial 6329 Child SA cannot be created because of this failure." 6331 Changed "EAP exchange" to "EAP authentication" in 5. 6333 Removed "In particular, these exponents MUST NOT be derived from 6334 long-lived secrets like the seed to a pseudo-random generator that is 6335 not erased after use." from section 5 because it is not possible in 6336 most implementations to do so. 6338 Updated a bunch of reference to their newer versions. 6340 Added "[V+]" to the end of the exchanges in C.4 and C.5. 6342 Added two more response templates to Appendix C.1. Added another 6343 response template in Appendix C.2. Added two more responses in 6344 Appendix C.4. 6346 E.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to 6347 draft-ietf-ipsecme-ikev2bis-02 6349 In section 1.3.1, added "Failure of an attempt to create a CHILD SA 6350 SHOULD NOT tear down the IKE SA: there is no reason to lose the work 6351 done to set up the IKE SA. When an IKE SA is not created, the error 6352 message return SHOULD NOT be encrypted because the other party will 6353 not be able to authenticate that message." This may be changed again 6354 in the future. [Issue #9] 6356 In section 1.3.2, changed "The KEi payload SHOULD be included" to be 6357 "The KEi payload MUST be included". This also lead to changes in 6358 section 2.18. The square brackets around "g^ir (new)" in the 6359 SKEYSEED calculation are eliminated, and the requirement language in 6360 the paragraph starting "The main rekeying" is changed from SHOULD to 6361 MUST. [Issue #50] 6363 In section 1.3.2, changed "The window size starts at 1 for any new 6364 IKE SA." to "The first IKE requests from both sides on the new IKE SA 6365 will have message ID 0. The old IKE SA retains its numbering, so any 6366 further requests (for example, to delete the IKE SA) will have 6367 consecutive numbering. The new IKE SA also has its window size reset 6368 to 1, and the initiator in this rekey exchange is the new "original 6369 initiator" of the new IKE SA." [Issue #65] 6371 Added to section 1.5: For a one-way INVALID_IKE_SPI notification for 6372 an unrecognized SPI, the responder SHOULD copy the Exchange Type from 6373 the request. [Issue #46] 6375 In 2.1, at the end of the paragraph about retransmission timers, 6376 added "In order to allow saving memory, responders are allowed to 6377 forget response after a timeout of several minutes. If the responder 6378 receives a retransmitted request for which it has already forgotten 6379 the response, it MUST ignore the request (and not, for example, 6380 attempt constructing a new response)." [Issue #14] 6382 In 2.6, added: "Also, incorporating Ni in the hash prevents an 6383 attacker from fetching one one cookie from the other end, and then 6384 initiating many IKE_SA_INIT exchanges all with different initiator 6385 SPIs (and perhaps port numbers) so that the responder thinks that 6386 there are lots of machines behind one NAT box who are all trying to 6387 connect." [Issue #19] 6389 Added text for the new 2.8.2, and bumped the section number of the 6390 old 2.8.2 to 2.8.3. [Issue #22] 6392 Added a reference to the end of 2.12 on key reuse. 6394 Added to the end of the first paragraph in 2.19: Note, however, it is 6395 usual to only assign one IP address during the IKE_AUTH exchange. 6396 That address persists at least until the deletion of the IKE SA. 6397 [Issue #79] 6399 Added the following to 2.23: An initiator can float to port 4500, 6400 regardless whether or not there is NAT, even at the beginning of IKE. 6401 When either side is using port 4500, sending with UDP encapsulation 6402 is not required, but understanding received packets with UDP 6403 encapsulation is required. UDP encapsulation MUST NOT be done on 6404 port 500. If NAT-T is supported (that is, if NAT_DETECTION_*_IP 6405 payloads were exchanged during IKE_SA_INIT), all devices MUST be able 6406 to receive and process both UDP encapsulated and non-UDP encapsulated 6407 packets at any time. Either side can decide whether or not to use 6408 UDP encapsulation irrespective of the choice made by the other side. 6409 However, if a NAT is detected, both devices MUST send UDP 6410 encapsulated packets. [Issue #40] 6412 The second-to-last paragraph in section 3.4 is changed to: The DH 6413 Group # identifies the Diffie-Hellman group in which the Key Exchange 6414 Data was computed (see Section 3.3.2. This Group # MUST match a DH 6415 Group specified in a proposal in the SA payload that is sent in the 6416 same message, and SHOULD match the DH group in the first group in the 6417 first proposal, if such exists. If none of the proposals in that SA 6418 payload specifies a DH Group, the KE payload MUST NOT be present. If 6419 the selected proposal uses a different Diffie-Hellman group (other 6420 than NONE), the message MUST be rejected with a Notify payload of 6421 type INVALID_KE_PAYLOAD. [Issue #30] 6423 In 3.10.1, changed the definition of NO_PROPOSAL_CHOSEN, 14, to: None 6424 of the proposed crypto suites was acceptable. This can be sent in 6425 any case where the offered proposal (including but not limited to SA 6426 payload values, USE_TRANSPORT_MODE notify, IPCOMP_SUPPORTED notify) 6427 are not acceptable for the responder. This can also be used as 6428 "generic" Child SA error when Child SA cannot be created for some 6429 other reason. See also Section 2.7. [Issue #81] 6431 In the description of IVs in 3.14, reorganized the text a bit to 6432 emphasize when we are and are not talking about CBC. [Issue #68] 6434 Added the following to section 5 (Security Considerations): "The 6435 IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator has 6436 been authenticated. As a result, an implementation of this protocol 6437 needs to be completely robust when deployed on any insecure network. 6438 Implementation vulnerabilities, particularly denial-of-service 6439 attacks, can be exploited by unauthenticated peers. This issue is 6440 particularly worrisome because of the unlimited number of messages in 6441 EAP-based authentication." [Issue #62] 6443 Added new Appendix D, "Significant Changes from RFC 4306", as a 6444 placeholder for now. [Issue #3] 6446 E.9. Changes from draft-ietf-ipsecme-ikev2bis-01 to 6447 draft-ietf-ipsecme-ikev2bis-02 6449 Near the end of 1.3, changed "If the guess turns out to be wrong, the 6450 responder will indicate the correct group in the response and the 6451 initiator SHOULD pick an element of that group for its KE value when 6452 retrying the first message." to "If the responder selects a proposal 6453 using a different Diffie-Hellman group (other than NONE), the 6454 responder will indicate the correct group in the response and the 6455 initiator SHOULD pick an element of that group for its KE value when 6456 retrying the first message." [Issue #6] 6458 In the figures in 1.3.2, changed the diagrams from "HDR, SK {SA, Ni, 6459 [KEi]}" to "HDR, SK {SA, Ni, KEi}", and "HDR, SK {SA, Nr,[KEr]}" to 6460 "HDR, SK {SA, Nr,KEr}". This matches the text in the section, which 6461 was updated in the last revision. [Issue #50] 6463 Reorganized the beginning of section 2.3 and clarified some of the 6464 logic. [Issue #52] 6466 Clarified the octets to be signed in setion 2.15. Changed 6468 AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), ) 6470 to 6471 For the initiator: 6472 AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"), 6473 ) 6474 For the responder: 6475 AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"), 6476 ) 6478 [Issue #72] 6480 Changed the last bullet item in section 2.23 to discuss MOBIKE in 6481 more detail. [Issue #41] 6483 In section 3.1, the bullet about bit 4, changed "must" to "MUST". 6485 In section 3.3.6, added two sentences at the end of the second 6486 paragraph to indicate that there is an exception for when the 6487 proposal is a DH group of NONE. [Issue #6] 6489 E.10. Changes from draft-ietf-ipsecme-ikev2bis-02 to 6490 draft-ietf-ipsecme-ikev2bis-03 6492 In section 2.4, change "The INITIAL_CONTACT notification, if sent, 6493 MUST be in the first IKE_AUTH request, not as a separate exchange 6494 afterwards; however, receiving parties need to deal with it in other 6495 requests." to "The INITIAL_CONTACT notification, if sent, MUST be in 6496 the first IKE_AUTH request or response, not as a separate exchange 6497 afterwards; however, receiving parties MAY ignore it in other 6498 messages." [Issue #53] 6500 Added to the security considerations: "Admission control is critical 6501 to the security of the protocol. For example, trust anchors used for 6502 identifying IKE peers should probably be different than those used 6503 for other forms of trust, such as those used to identify public web 6504 servers. Moreover, although IKE provides a great deal of leeway in 6505 defining the security policy for a trusted peer's identity, 6506 credentials, and the correlation between them, having such security 6507 policy defined explicitly is essential to a secure implementation." 6508 [Issue #61] 6510 Changed "[V+]" to "[V+][N+]" throughout Appendix C. [Issue #63] 6512 Authors' Addresses 6514 Charlie Kaufman 6515 Microsoft 6516 1 Microsoft Way 6517 Redmond, WA 98052 6518 US 6520 Phone: 1-425-707-3335 6521 Email: charliek@microsoft.com 6523 Paul Hoffman 6524 VPN Consortium 6525 127 Segre Place 6526 Santa Cruz, CA 95060 6527 US 6529 Phone: 1-831-426-9827 6530 Email: paul.hoffman@vpnc.org 6532 Yoav Nir 6533 Check Point Software Technologies Ltd. 6534 5 Hasolelim St. 6535 Tel Aviv 67897 6536 Israel 6538 Email: ynir@checkpoint.com 6540 Pasi Eronen 6541 Nokia Research Center 6542 P.O. Box 407 6543 FIN-00045 Nokia Group 6544 Finland 6546 Email: pasi.eronen@nokia.com