idnits 2.17.1 draft-ietf-ipsecme-ikev2bis-02.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 (February 26, 2009) is 5536 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 2240, but not defined == Missing Reference: 'KEi' is mentioned on line 5796, but not defined == Missing Reference: 'KEr' is mentioned on line 6165, but not defined == Missing Reference: 'CP' is mentioned on line 745, but not defined -- Looks like a reference, but probably isn't: '0' on line 3829 -- Looks like a reference, but probably isn't: '1' on line 3830 == Missing Reference: 'IDr' is mentioned on line 5740, 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: August 30, 2009 Check Point 8 P. Eronen 9 Nokia 10 February 26, 2009 12 Internet Key Exchange Protocol: IKEv2 13 draft-ietf-ipsecme-ikev2bis-02 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 August 30, 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 . . . . . . . . . . . . . . . . . . . . . . 57 116 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 61 117 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 61 118 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 61 119 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 64 120 3.3. Security Association Payload . . . . . . . . . . . . . . 66 121 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 68 122 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 70 123 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 73 124 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 73 125 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 74 126 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 76 127 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 77 128 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 78 129 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 80 130 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 82 131 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 84 132 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 85 133 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 86 134 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 87 135 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 90 136 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 92 137 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 93 138 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 94 139 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 96 140 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 98 141 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 99 142 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 102 143 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 104 144 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 105 145 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 105 146 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 107 147 5. Security Considerations . . . . . . . . . . . . . . . . . . . 109 148 5.1. Traffic selector authorization . . . . . . . . . . . . . 112 149 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 113 150 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 113 151 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 114 152 8.1. Normative References . . . . . . . . . . . . . . . . . . 114 153 8.2. Informative References . . . . . . . . . . . . . . . . . 115 154 Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 119 155 Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 120 156 B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 120 157 B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 121 158 Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 121 159 C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 122 160 C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 123 161 C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 124 162 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying 163 Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 125 164 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 125 165 C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 125 166 Appendix D. Significant Changes from RFC 4306 . . . . . . . . . 125 167 Appendix E. Changes Between Internet Draft Versions . . . . . . 126 168 E.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 126 169 E.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 126 170 E.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 128 171 E.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 129 172 E.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 130 173 E.6. Changes from draft -03 to 174 draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 131 175 E.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to 176 draft-ietf-ipsecme-ikev2bis-01 . . . . . . . . . . . . . 132 177 E.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to 178 draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 136 179 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 138 181 1. Introduction 183 {{ An introduction to the differences between RFC 4306 [IKEV2] and 184 this document is given at the end of Section 1. It is put there 185 (instead of here) to preserve the section numbering of RFC 4306. }} 187 IP Security (IPsec) provides confidentiality, data integrity, access 188 control, and data source authentication to IP datagrams. These 189 services are provided by maintaining shared state between the source 190 and the sink of an IP datagram. This state defines, among other 191 things, the specific services provided to the datagram, which 192 cryptographic algorithms will be used to provide the services, and 193 the keys used as input to the cryptographic algorithms. 195 Establishing this shared state in a manual fashion does not scale 196 well. Therefore, a protocol to establish this state dynamically is 197 needed. This memo describes such a protocol -- the Internet Key 198 Exchange (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI], 199 2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 replaced all of those RFCs. 200 IKEv2 was defined in [IKEV2] (RFC 4306) and was clarified in [Clarif] 201 (RFC 4718). This document replaces and updates RFC 4306 and RFC 202 4718. 204 IKE performs mutual authentication between two parties and 205 establishes an IKE security association (SA) that includes shared 206 secret information that can be used to efficiently establish SAs for 207 Encapsulating Security Payload (ESP) [ESP] or Authentication Header 208 (AH) [AH] and a set of cryptographic algorithms to be used by the SAs 209 to protect the traffic that they carry. In this document, the term 210 "suite" or "cryptographic suite" refers to a complete set of 211 algorithms used to protect an SA. An initiator proposes one or more 212 suites by listing supported algorithms that can be combined into 213 suites in a mix-and-match fashion. IKE can also negotiate use of IP 214 Compression (IPComp) [IP-COMP] in connection with an ESP or AH SA. 215 The SAs for ESP or AH that get set up through that IKE SA we call 216 "Child SAs". 218 All IKE communications consist of pairs of messages: a request and a 219 response. The pair is called an "exchange". We call the first 220 messages establishing an IKE SA IKE_SA_INIT and IKE_AUTH exchanges 221 and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL 222 exchanges. In the common case, there is a single IKE_SA_INIT 223 exchange and a single IKE_AUTH exchange (a total of four messages) to 224 establish the IKE SA and the first Child SA. In exceptional cases, 225 there may be more than one of each of these exchanges. In all cases, 226 all IKE_SA_INIT exchanges MUST complete before any other exchange 227 type, then all IKE_AUTH exchanges MUST complete, and following that 228 any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur 229 in any order. In some scenarios, only a single Child SA is needed 230 between the IPsec endpoints, and therefore there would be no 231 additional exchanges. Subsequent exchanges MAY be used to establish 232 additional Child SAs between the same authenticated pair of endpoints 233 and to perform housekeeping functions. 235 IKE message flow always consists of a request followed by a response. 236 It is the responsibility of the requester to ensure reliability. If 237 the response is not received within a timeout interval, the requester 238 needs to retransmit the request (or abandon the connection). 240 The first request/response of an IKE session (IKE_SA_INIT) negotiates 241 security parameters for the IKE SA, sends nonces, and sends Diffie- 242 Hellman values. 244 The second request/response (IKE_AUTH) transmits identities, proves 245 knowledge of the secrets corresponding to the two identities, and 246 sets up an SA for the first (and often only) AH or ESP Child SA 247 (unless there is failure setting up the AH or ESP Child SA, in which 248 case the IKE SA is still established without IPsec SA). 250 The types of subsequent exchanges are CREATE_CHILD_SA (which creates 251 a Child SA) and INFORMATIONAL (which deletes an SA, reports error 252 conditions, or does other housekeeping). Every request requires a 253 response. An INFORMATIONAL request with no payloads (other than the 254 empty Encrypted payload required by the syntax) is commonly used as a 255 check for liveness. These subsequent exchanges cannot be used until 256 the initial exchanges have completed. 258 In the description that follows, we assume that no errors occur. 259 Modifications to the flow should errors occur are described in 260 Section 2.21. 262 1.1. Usage Scenarios 264 IKE is expected to be used to negotiate ESP or AH SAs in a number of 265 different scenarios, each with its own special requirements. 267 1.1.1. Security Gateway to Security Gateway Tunnel Mode 269 +-+-+-+-+-+ +-+-+-+-+-+ 270 | | IPsec | | 271 Protected |Tunnel | tunnel |Tunnel | Protected 272 Subnet <-->|Endpoint |<---------->|Endpoint |<--> Subnet 273 | | | | 274 +-+-+-+-+-+ +-+-+-+-+-+ 276 Figure 1: Security Gateway to Security Gateway Tunnel 278 In this scenario, neither endpoint of the IP connection implements 279 IPsec, but network nodes between them protect traffic for part of the 280 way. Protection is transparent to the endpoints, and depends on 281 ordinary routing to send packets through the tunnel endpoints for 282 processing. Each endpoint would announce the set of addresses 283 "behind" it, and packets would be sent in tunnel mode where the inner 284 IP header would contain the IP addresses of the actual endpoints. 286 1.1.2. Endpoint-to-Endpoint Transport Mode 288 +-+-+-+-+-+ +-+-+-+-+-+ 289 | | IPsec transport | | 290 |Protected| or tunnel mode SA |Protected| 291 |Endpoint |<---------------------------------------->|Endpoint | 292 | | | | 293 +-+-+-+-+-+ +-+-+-+-+-+ 295 Figure 2: Endpoint to Endpoint 297 In this scenario, both endpoints of the IP connection implement 298 IPsec, as required of hosts in [IPSECARCH]. Transport mode will 299 commonly be used with no inner IP header. A single pair of addresses 300 will be negotiated for packets to be protected by this SA. These 301 endpoints MAY implement application layer access controls based on 302 the IPsec authenticated identities of the participants. This 303 scenario enables the end-to-end security that has been a guiding 304 principle for the Internet since [ARCHPRINC], [TRANSPARENCY], and a 305 method of limiting the inherent problems with complexity in networks 306 noted by [ARCHGUIDEPHIL]. Although this scenario may not be fully 307 applicable to the IPv4 Internet, it has been deployed successfully in 308 specific scenarios within intranets using IKEv1. It should be more 309 broadly enabled during the transition to IPv6 and with the adoption 310 of IKEv2. 312 It is possible in this scenario that one or both of the protected 313 endpoints will be behind a network address translation (NAT) node, in 314 which case the tunneled packets will have to be UDP encapsulated so 315 that port numbers in the UDP headers can be used to identify 316 individual endpoints "behind" the NAT (see Section 2.23). 318 1.1.3. Endpoint to Security Gateway Tunnel Mode 320 +-+-+-+-+-+ +-+-+-+-+-+ 321 | | IPsec | | Protected 322 |Protected| tunnel |Tunnel | Subnet 323 |Endpoint |<------------------------>|Endpoint |<--- and/or 324 | | | | Internet 325 +-+-+-+-+-+ +-+-+-+-+-+ 327 Figure 3: Endpoint to Security Gateway Tunnel 329 In this scenario, a protected endpoint (typically a portable roaming 330 computer) connects back to its corporate network through an IPsec- 331 protected tunnel. It might use this tunnel only to access 332 information on the corporate network, or it might tunnel all of its 333 traffic back through the corporate network in order to take advantage 334 of protection provided by a corporate firewall against Internet-based 335 attacks. In either case, the protected endpoint will want an IP 336 address associated with the security gateway so that packets returned 337 to it will go to the security gateway and be tunneled back. This IP 338 address may be static or may be dynamically allocated by the security 339 gateway. {{ Clarif-6.1 }} In support of the latter case, IKEv2 340 includes a mechanism (namely, configuration payloads) for the 341 initiator to request an IP address owned by the security gateway for 342 use for the duration of its SA. 344 In this scenario, packets will use tunnel mode. On each packet from 345 the protected endpoint, the outer IP header will contain the source 346 IP address associated with its current location (i.e., the address 347 that will get traffic routed to the endpoint directly), while the 348 inner IP header will contain the source IP address assigned by the 349 security gateway (i.e., the address that will get traffic routed to 350 the security gateway for forwarding to the endpoint). The outer 351 destination address will always be that of the security gateway, 352 while the inner destination address will be the ultimate destination 353 for the packet. 355 In this scenario, it is possible that the protected endpoint will be 356 behind a NAT. In that case, the IP address as seen by the security 357 gateway will not be the same as the IP address sent by the protected 358 endpoint, and packets will have to be UDP encapsulated in order to be 359 routed properly. 361 1.1.4. Other Scenarios 363 Other scenarios are possible, as are nested combinations of the 364 above. One notable example combines aspects of 1.1.1 and 1.1.3. A 365 subnet may make all external accesses through a remote security 366 gateway using an IPsec tunnel, where the addresses on the subnet are 367 routed to the security gateway by the rest of the Internet. An 368 example would be someone's home network being virtually on the 369 Internet with static IP addresses even though connectivity is 370 provided by an ISP that assigns a single dynamically assigned IP 371 address to the user's security gateway (where the static IP addresses 372 and an IPsec relay are provided by a third party located elsewhere). 374 1.2. The Initial Exchanges 376 Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH 377 exchanges (known in IKEv1 as Phase 1). These initial exchanges 378 normally consist of four messages, though in some scenarios that 379 number can grow. All communications using IKE consist of request/ 380 response pairs. We'll describe the base exchange first, followed by 381 variations. The first pair of messages (IKE_SA_INIT) negotiate 382 cryptographic algorithms, exchange nonces, and do a Diffie-Hellman 383 exchange [DH]. 385 The second pair of messages (IKE_AUTH) authenticate the previous 386 messages, exchange identities and certificates, and establish the 387 first Child SA. Parts of these messages are encrypted and integrity 388 protected with keys established through the IKE_SA_INIT exchange, so 389 the identities are hidden from eavesdroppers and all fields in all 390 the messages are authenticated. (See Section 2.14 for information on 391 how the encyrption keys are generated.) 393 All messages following the initial exchange are cryptographically 394 protected using the cryptographic algorithms and keys negotiated in 395 the the IKE_SA_INIT exchange. These subsequent messages use the 396 syntax of the Encrypted Payload described in Section 3.14, encrypted 397 with keys that are derived as described in Section 2.14. All 398 subsequent messages include an Encrypted Payload, even if they are 399 referred to in the text as "empty". For the CREATE_CHILD_SA, 400 IKE_AUTH, or IKE_INFORMATIONAL exchanges, the message following the 401 header is encrypted and the message including the header is integrity 402 protected using the cryptographic algorithms negotiated for the IKE 403 SA. 405 In the following descriptions, the payloads contained in the message 406 are indicated by names as listed below. 408 Notation Payload 409 ----------------------------------------- 410 AUTH Authentication 411 CERT Certificate 412 CERTREQ Certificate Request 413 CP Configuration 414 D Delete 415 E Encrypted 416 EAP Extensible Authentication 417 HDR IKE Header 418 IDi Identification - Initiator 419 IDr Identification - Responder 420 KE Key Exchange 421 Ni, Nr Nonce 422 N Notify 423 SA Security Association 424 TSi Traffic Selector - Initiator 425 TSr Traffic Selector - Responder 426 V Vendor ID 428 The details of the contents of each payload are described in section 429 3. Payloads that may optionally appear will be shown in brackets, 430 such as [CERTREQ], indicate that optionally a certificate request 431 payload can be included. 433 The initial exchanges are as follows: 435 Initiator Responder 436 ------------------------------------------------------------------- 437 HDR, SAi1, KEi, Ni --> 439 HDR contains the Security Parameter Indexes (SPIs), version numbers, 440 and flags of various sorts. The SAi1 payload states the 441 cryptographic algorithms the initiator supports for the IKE SA. The 442 KE payload sends the initiator's Diffie-Hellman value. Ni is the 443 initiator's nonce. 445 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 447 The responder chooses a cryptographic suite from the initiator's 448 offered choices and expresses that choice in the SAr1 payload, 449 completes the Diffie-Hellman exchange with the KEr payload, and sends 450 its nonce in the Nr payload. 452 At this point in the negotiation, each party can generate SKEYSEED, 453 from which all keys are derived for that IKE SA. The messages that 454 follow are encrypted and integrity protected in their entirety, with 455 the exception of the message headers. The keys used for the 456 encryption and integrity protection are derived from SKEYSEED and are 457 known as SK_e (encryption) and SK_a (authentication, a.k.a. integrity 458 protection). A separate SK_e and SK_a is computed for each 459 direction. In addition to the keys SK_e and SK_a derived from the DH 460 value for protection of the IKE SA, another quantity SK_d is derived 461 and used for derivation of further keying material for Child SAs. 462 The notation SK { ... } indicates that these payloads are encrypted 463 and integrity protected using that direction's SK_e and SK_a. 465 HDR, SK {IDi, [CERT,] [CERTREQ,] 466 [IDr,] AUTH, SAi2, 467 TSi, TSr} --> 469 The initiator asserts its identity with the IDi payload, proves 470 knowledge of the secret corresponding to IDi and integrity protects 471 the contents of the first message using the AUTH payload (see 472 Section 2.15). It might also send its certificate(s) in CERT 473 payload(s) and a list of its trust anchors in CERTREQ payload(s). If 474 any CERT payloads are included, the first certificate provided MUST 475 contain the public key used to verify the AUTH field. 477 The optional payload IDr enables the initiator to specify which of 478 the responder's identities it wants to talk to. This is useful when 479 the machine on which the responder is running is hosting multiple 480 identities at the same IP address. If the IDr proposed by the 481 initiator is not acceptable to the responder, the responder might use 482 some other IDr to finish the exchange. If the initiator then does 483 not accept that fact that responder used different IDr than the one 484 that was requested, the initiator can close the SA after noticing the 485 fact. 487 The initiator begins negotiation of a Child SA using the SAi2 488 payload. The final fields (starting with SAi2) are described in the 489 description of the CREATE_CHILD_SA exchange. 491 <-- HDR, SK {IDr, [CERT,] AUTH, 492 SAr2, TSi, TSr} 494 The responder asserts its identity with the IDr payload, optionally 495 sends one or more certificates (again with the certificate containing 496 the public key used to verify AUTH listed first), authenticates its 497 identity and protects the integrity of the second message with the 498 AUTH payload, and completes negotiation of a Child SA with the 499 additional fields described below in the CREATE_CHILD_SA exchange. 501 The recipients of messages 3 and 4 MUST verify that all signatures 502 and MACs are computed correctly and that the names in the ID payloads 503 correspond to the keys used to generate the AUTH payload. 505 {{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH exchange 506 fails for some reason, the IKE SA is still created as usual. The 507 list of responses in the IKE_AUTH exchange that do not prevent an IKE 508 SA from being set up include at least the following: 509 NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, 510 INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. 512 {{ Clarif-4.3 }} Note that IKE_AUTH messages do not contain KEi/KEr 513 or Ni/Nr payloads. Thus, the SA payloads in the IKE_AUTH exchange 514 cannot contain Transform Type 4 (Diffie-Hellman Group) with any value 515 other than NONE. Implementations SHOULD omit the whole transform 516 substructure instead of sending value NONE. 518 1.3. The CREATE_CHILD_SA Exchange 520 {{ This is a heavy rewrite of most of this section. The major 521 organization changes are described in Clarif-4.1 and Clarif-5.1. }} 523 The CREATE_CHILD_SA exchange is used to create new Child SAs and to 524 rekey both IKE SAs and Child SAs. This exchange consists of a single 525 request/response pair, and some of its function was referred to as a 526 phase 2 exchange in IKEv1. It MAY be initiated by either end of the 527 IKE SA after the initial exchanges are completed. 529 All messages following the initial exchange are cryptographically 530 protected using the cryptographic algorithms and keys negotiated in 531 the first two messages of the IKE exchange. These subsequent 532 messages use the syntax of the Encrypted Payload described in 533 Section 3.14, encrypted with keys that are derived as described in 534 Section 2.14. All subsequent messages include an Encrypted Payload, 535 even if they are referred to in the text as "empty". For both 536 messages in the CREATE_CHILD_SA, the message following the header is 537 encrypted and the message including the header is integrity protected 538 using the cryptographic algorithms negotiated for the IKE SA. 540 The CREATE_CHILD_SA is also used for rekeying IKE SAs and Child SAs. 541 An SA is rekeyed by creating a new SA and then deleting the old one. 542 This section describes the first part of rekeying, the creation of 543 new SAs; Section 2.8 covers the mechanics of rekeying, including 544 moving traffic from old to new SAs and the deletion of the old SAs. 545 The two sections must be read together to understand the entire 546 process of rekeying. 548 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this 549 section the term initiator refers to the endpoint initiating this 550 exchange. An implementation MAY refuse all CREATE_CHILD_SA requests 551 within an IKE SA. 553 The CREATE_CHILD_SA request MAY optionally contain a KE payload for 554 an additional Diffie-Hellman exchange to enable stronger guarantees 555 of forward secrecy for the Child SA. The keying material for the 556 Child SA is a function of SK_d established during the establishment 557 of the IKE SA, the nonces exchanged during the CREATE_CHILD_SA 558 exchange, and the Diffie-Hellman value (if KE payloads are included 559 in the CREATE_CHILD_SA exchange). 561 If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of 562 the SA offers MUST include the Diffie-Hellman group of the KEi. The 563 Diffie-Hellman group of the KEi MUST be an element of the group the 564 initiator expects the responder to accept (additional Diffie-Hellman 565 groups can be proposed). If the responder selects a proposal using a 566 different Diffie-Hellman group (other than NONE), the responder MUST 567 reject the request and indicate its preferred Diffie-Hellman group in 568 the INVALID_KE_PAYLOAD Notification payload. {{ 3.10.1-17 }} There 569 are two octets of data associated with this notification: the 570 accepted D-H Group number in big endian order. In the case of such a 571 rejection, the CREATE_CHILD_SA exchange fails, and the initiator will 572 probably retry the exchange with a Diffie-Hellman proposal and KEi in 573 the group that the responder gave in the INVALID_KE_PAYLOAD. 575 {{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS notification 576 to indicate that a CREATE_CHILD_SA request is unacceptable because 577 the responder is unwilling to accept any more Child SAs on this IKE 578 SA. Some minimal implementations may only accept a single Child SA 579 setup in the context of an initial IKE exchange and reject any 580 subsequent attempts to add more. 582 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA Exchange 584 A Child SA may be created by sending a CREATE_CHILD_SA request. The 585 CREATE_CHILD_SA request for creating a new Child SA is: 587 Initiator Responder 588 ------------------------------------------------------------------- 589 HDR, SK {SA, Ni, [KEi], 590 TSi, TSr} --> 592 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 593 payload, optionally a Diffie-Hellman value in the KEi payload, and 594 the proposed traffic selectors for the proposed Child SA in the TSi 595 and TSr payloads. 597 The CREATE_CHILD_SA response for creating a new Child SA is: 599 <-- HDR, SK {SA, Nr, [KEr], 600 TSi, TSr} 602 The responder replies (using the same Message ID to respond) with the 603 accepted offer in an SA payload, and a Diffie-Hellman value in the 604 KEr payload if KEi was included in the request and the selected 605 cryptographic suite includes that group. 607 The traffic selectors for traffic to be sent on that SA are specified 608 in the TS payloads in the response, which may be a subset of what the 609 initiator of the Child SA proposed. 611 {{ 3.10.1-16391 }} The USE_TRANSPORT_MODE notification MAY be 612 included in a request message that also includes an SA payload 613 requesting a Child SA. It requests that the Child SA use transport 614 mode rather than tunnel mode for the SA created. If the request is 615 accepted, the response MUST also include a notification of type 616 USE_TRANSPORT_MODE. If the responder declines the request, the Child 617 SA will be established in tunnel mode. If this is unacceptable to 618 the initiator, the initiator MUST delete the SA. Note: Except when 619 using this option to negotiate transport mode, all Child SAs will use 620 tunnel mode. 622 {{ 3.10.1-16394 }} The ESP_TFC_PADDING_NOT_SUPPORTED notification 623 asserts that the sending endpoint will NOT accept packets that 624 contain Traffic Flow Confidentiality (TFC) padding over the Child SA 625 being negotiated. {{ Clarif-4.5 }} If neither endpoint accepts TFC 626 padding, this notification is included in both the request and the 627 response. If this notification is included in only one of the 628 messages, TFC padding can still be sent in the other direction. 630 {{ 3.10.1-16395 }} The NON_FIRST_FRAGMENTS_ALSO notification is used 631 for fragmentation control. See [IPSECARCH] for a fuller explanation. 632 {{ Clarif-4.6 }} Both parties need to agree to sending non-first 633 fragments before either party does so. It is enabled only if 634 NON_FIRST_FRAGMENTS_ALSO notification is included in both the request 635 proposing an SA and the response accepting it. If the responder does 636 not want to send or receive non-first fragments, it only omits 637 NON_FIRST_FRAGMENTS_ALSO notification from its response, but does not 638 reject the whole Child SA creation. 640 Failure of an attempt to create a CHILD SA SHOULD NOT tear down the 641 IKE SA: there is no reason to lose the work done to set up the IKE 642 SA. When an IKE SA is not created, the error message return SHOULD 643 NOT be encrypted because the other party will not be able to 644 authenticate that message. [[ Note: this text may be changed in the 645 future. ]] 647 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange 649 The CREATE_CHILD_SA request for rekeying an IKE SA is: 651 Initiator Responder 652 ------------------------------------------------------------------- 653 HDR, SK {SA, Ni, [KEi]} --> 655 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 656 payload, and a Diffie-Hellman value in the KEi payload. The KEi 657 payload MUST be included. New initiator and responder SPIs are 658 supplied in the SPI fields of the SA payload. 660 The CREATE_CHILD_SA response for rekeying an IKE SA is: 662 <-- HDR, SK {SA, Nr,[KEr]} 664 The responder replies (using the same Message ID to respond) with the 665 accepted offer in an SA payload, and a Diffie-Hellman value in the 666 KEr payload if the selected cryptographic suite includes that group. 668 The new IKE SA has its message counters set to 0, regardless of what 669 they were in the earlier IKE SA. The first IKE requests from both 670 sides on the new IKE SA will have message ID 0. The old IKE SA 671 retains its numbering, so any further requests (for example, to 672 delete the IKE SA) will have consecutive numbering. The new IKE SA 673 also has its window size reset to 1, and the initiator in this rekey 674 exchange is the new "original initiator" of the new IKE SA. 676 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange 678 The CREATE_CHILD_SA request for rekeying a Child SA is: 680 Initiator Responder 681 ------------------------------------------------------------------- 682 HDR, SK {N, SA, Ni, [KEi], 683 TSi, TSr} --> 685 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 686 payload, optionally a Diffie-Hellman value in the KEi payload, and 687 the proposed traffic selectors for the proposed Child SA in the TSi 688 and TSr payloads. 690 {{ 3.10.1-16393 }} The REKEY_SA notification MUST be included in a 691 CREATE_CHILD_SA exchange if the purpose of the exchange is to replace 692 an existing ESP or AH SA. {{ Clarif-5.4 }} The SA being rekeyed is 693 identified by the SPI field in the Notify payload; this is the SPI 694 the exchange initiator would expect in inbound ESP or AH packets. 696 There is no data associated with this Notify type. The Protocol ID 697 field of the REKEY_SA notification is set to match the protocol of 698 the SA we are rekeying, for example, 3 for ESP and 2 for AH. 700 The CREATE_CHILD_SA response for rekeying a Child SA is: 702 <-- HDR, SK {SA, Nr, [KEr], 703 TSi, TSr} 705 The responder replies (using the same Message ID to respond) with the 706 accepted offer in an SA payload, and a Diffie-Hellman value in the 707 KEr payload if KEi was included in the request and the selected 708 cryptographic suite includes that group. 710 The traffic selectors for traffic to be sent on that SA are specified 711 in the TS payloads in the response, which may be a subset of what the 712 initiator of the Child SA proposed. 714 1.4. The INFORMATIONAL Exchange 716 At various points during the operation of an IKE SA, peers may desire 717 to convey control messages to each other regarding errors or 718 notifications of certain events. To accomplish this, IKE defines an 719 INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur 720 after the initial exchanges and are cryptographically protected with 721 the negotiated keys. 723 Control messages that pertain to an IKE SA MUST be sent under that 724 IKE SA. Control messages that pertain to Child SAs MUST be sent 725 under the protection of the IKE SA which generated them (or its 726 successor if the IKE SA was rekeyed). 728 Messages in an INFORMATIONAL exchange contain zero or more 729 Notification, Delete, and Configuration payloads. The Recipient of 730 an INFORMATIONAL exchange request MUST send some response (else the 731 Sender will assume the message was lost in the network and will 732 retransmit it). That response MAY be a message with no payloads. 733 The request message in an INFORMATIONAL exchange MAY also contain no 734 payloads. This is the expected way an endpoint can ask the other 735 endpoint to verify that it is alive. 737 The INFORMATIONAL exchange is defined as: 739 Initiator Responder 740 ------------------------------------------------------------------- 741 HDR, SK {[N,] [D,] 742 [CP,] ...} --> 743 <-- HDR, SK {[N,] [D,] 745 [CP], ...} 747 The processing of an INFORMATIONAL exchange is determined by its 748 component payloads. 750 1.4.1. Deleting an SA with INFORMATIONAL Exchanges 752 {{ Clarif-5.6 }} ESP and AH SAs always exist in pairs, with one SA in 753 each direction. When an SA is closed, both members of the pair MUST 754 be closed (that is, deleted). Each endpoint MUST close its incoming 755 SAs and allow the other endpoint to close the other SA in each pair. 756 To delete an SA, an INFORMATIONAL exchange with one or more delete 757 payloads is sent listing the SPIs (as they would be expected in the 758 headers of inbound packets) of the SAs to be deleted. The recipient 759 MUST close the designated SAs. {{ Clarif-5.7 }} Note that one never 760 sends delete payloads for the two sides of an SA in a single message. 761 If there are many SAs to delete at the same time, one includes delete 762 payloads for the inbound half of each SA pair in your Informational 763 exchange. 765 Normally, the reply in the INFORMATIONAL exchange will contain delete 766 payloads for the paired SAs going in the other direction. There is 767 one exception. If by chance both ends of a set of SAs independently 768 decide to close them, each may send a delete payload and the two 769 requests may cross in the network. If a node receives a delete 770 request for SAs for which it has already issued a delete request, it 771 MUST delete the outgoing SAs while processing the request and the 772 incoming SAs while processing the response. In that case, the 773 responses MUST NOT include delete payloads for the deleted SAs, since 774 that would result in duplicate deletion and could in theory delete 775 the wrong SA. 777 {{ Demoted the SHOULD }} Half-closed ESP or AH connections are 778 anomalous, and a node with auditing capability should probably audit 779 their existence if they persist. Note that this specification 780 nowhere specifies time periods, so it is up to individual endpoints 781 to decide how long to wait. A node MAY refuse to accept incoming 782 data on half-closed connections but MUST NOT unilaterally close them 783 and reuse the SPIs. If connection state becomes sufficiently messed 784 up, a node MAY close the IKE SA; doing so will implicitly close all 785 SAs negotiated under it. It can then rebuild the SAs it needs on a 786 clean base under a new IKE SA. {{ Clarif-5.8 }} The response to a 787 request that deletes the IKE SA is an empty Informational response. 789 1.5. Informational Messages outside of an IKE SA 791 If an encrypted IKE request packet arrives on port 500 or 4500 with 792 an unrecognized SPI, it could be because the receiving node has 793 recently crashed and lost state or because of some other system 794 malfunction or attack. If the receiving node has an active IKE SA to 795 the IP address from whence the packet came, it MAY send a 796 notification of the wayward packet over that IKE SA in an 797 INFORMATIONAL exchange. If it does not have such an IKE SA, it MAY 798 send an Informational message without cryptographic protection to the 799 source IP address. Such a message is not part of an informational 800 exchange, and the receiving node MUST NOT respond to it. Doing so 801 could cause a message loop. 803 {{ 3.10.1-11 }} The INVALID_SPI notification MAY be sent in an IKE 804 INFORMATIONAL exchange when a node receives an ESP or AH packet with 805 an invalid SPI. The Notification Data contains the SPI of the 806 invalid packet. This usually indicates a node has rebooted and 807 forgotten an SA. If this Informational Message is sent outside the 808 context of an IKE SA, it should only be used by the recipient as a 809 "hint" that something might be wrong (because it could easily be 810 forged). 812 {{ Clarif-7.7 }} There are two cases when such a one-way notification 813 is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are 814 sent outside of an IKE SA. Note that such notifications are 815 explicitly not Informational exchanges; these are one-way messages 816 that must not be responded to. 818 In case of INVALID_IKE_SPI, the message sent is a response message, 819 and thus it is sent to the IP address and port from whence it came 820 with the same IKE SPIs and the Message ID is copied. The Response 821 bit is set to 1, and the version flags are set in the normal fashion. 822 For a one-way INVALID_IKE_SPI notification for an unrecognized SPI, 823 the responder SHOULD copy the Exchange Type from the request. 825 In case of INVALID_SPI, however, there are no IKE SPI values that 826 would be meaningful to the recipient of such a notification. Using 827 zero values or random values are both acceptable. The Initiator flag 828 is set, the Response bit is set to 0, and the version flags are set 829 in the normal fashion. 831 1.6. Requirements Terminology 833 Definitions of the primitive terms in this document (such as Security 834 Association or SA) can be found in [IPSECARCH]. {{ Clarif-7.2 }} It 835 should be noted that parts of IKEv2 rely on some of the processing 836 rules in [IPSECARCH], as described in various sections of this 837 document. 839 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 840 "MAY" that appear in this document are to be interpreted as described 841 in [MUSTSHOULD]. 843 1.7. Differences Between RFC 4306 and This Document 845 {{ Added this entire section, including this recursive remark. }} 847 This document contains clarifications and amplifications to IKEv2 848 [IKEV2]. The clarifications are mostly based on [Clarif]. The 849 changes listed in that document were discussed in the IPsec Working 850 Group and, after the Working Group was disbanded, on the IPsec 851 mailing list. That document contains detailed explanations of areas 852 that were unclear in IKEv2, and is thus useful to implementers of 853 IKEv2. 855 The protocol described in this document retains the same major 856 version number (2) and minor version number (0) as was used in RFC 857 4306. That is, the version number is *not* changed from RFC 4306. 859 This document makes the figures and references a bit more regular 860 than in [IKEV2]. 862 IKEv2 developers have noted that the SHOULD-level requirements are 863 often unclear in that they don't say when it is OK to not obey the 864 requirements. They also have noted that there are MUST-level 865 requirements that are not related to interoperability. This document 866 has more explanation of some of these requirements. All non- 867 capitalized uses of the words SHOULD and MUST now mean their normal 868 English sense, not the interoperability sense of [MUSTSHOULD]. 870 IKEv2 (and IKEv1) developers have noted that there is a great deal of 871 material in the tables of codes in Section 3.10.1. This leads to 872 implementers not having all the needed information in the main body 873 of the document. Much of the material from those tables has been 874 moved into the associated parts of the main body of the document. 876 In the body of this document, notes that are enclosed in double curly 877 braces {{ such as this }} point out changes from IKEv2. Changes that 878 come from [Clarif] are marked with the section from that document, 879 such as "{{ Clarif-2.10 }}". Changes that come from moving 880 descriptive text out of the tables in Section 3.10.1 are marked with 881 that number and the message type that contained the text, such as "{{ 882 3.10.1-16384 }}". 884 This document removes discussion of nesting AH and ESP. This was a 885 mistake in RFC 4306 caused by the lag between finishing RFC 4306 and 886 RFC 4301. Basically, IKEv2 is based on RFC 4301, which does not 887 include "SA bundles" that were part of RFC 2401. While a single 888 packet can go through IPsec processing multiple times, each of these 889 passes uses a separate SA, and the passes are coordinated by the 890 forwarding tables. In IKEv2, each of these SAs has to be created 891 using a separate CREATE_CHILD_SA exchange. 893 This document removes discussion of the INTERNAL_ADDRESS_EXPIRY 894 configuration attribute because its implementation was very 895 problematic. Implementations that conform to this document MUST 896 ignore proposals that have configuration attribute type 5, the old 897 value for INTERNAL_ADDRESS_EXPIRY. 899 This document adds the restriction in Section 2.13 that all PRFs used 900 with IKEv2 MUST take variable-sized keys. This should not affect any 901 implementations because there were no standardized PRFs that have 902 fixed-size keys. 904 A later version of this document may have all the {{ }} comments 905 removed from the body of the document and instead appear in an 906 appendix. 908 2. IKE Protocol Details and Variations 910 IKE normally listens and sends on UDP port 500, though IKE messages 911 may also be received on UDP port 4500 with a slightly different 912 format (see Section 2.23). Since UDP is a datagram (unreliable) 913 protocol, IKE includes in its definition recovery from transmission 914 errors, including packet loss, packet replay, and packet forgery. 915 IKE is designed to function so long as (1) at least one of a series 916 of retransmitted packets reaches its destination before timing out; 917 and (2) the channel is not so full of forged and replayed packets so 918 as to exhaust the network or CPU capacities of either endpoint. Even 919 in the absence of those minimum performance requirements, IKE is 920 designed to fail cleanly (as though the network were broken). 922 Although IKEv2 messages are intended to be short, they contain 923 structures with no hard upper bound on size (in particular, X.509 924 certificates), and IKEv2 itself does not have a mechanism for 925 fragmenting large messages. IP defines a mechanism for fragmentation 926 of oversize UDP messages, but implementations vary in the maximum 927 message size supported. Furthermore, use of IP fragmentation opens 928 an implementation to denial of service attacks [DOSUDPPROT]. 929 Finally, some NAT and/or firewall implementations may block IP 930 fragments. 932 All IKEv2 implementations MUST be able to send, receive, and process 933 IKE messages that are up to 1280 octets long, and they SHOULD be able 934 to send, receive, and process messages that are up to 3000 octets 935 long. {{ Demoted the SHOULD }} IKEv2 implementations need to be aware 936 of the maximum UDP message size supported and MAY shorten messages by 937 leaving out some certificates or cryptographic suite proposals if 938 that will keep messages below the maximum. Use of the "Hash and URL" 939 formats rather than including certificates in exchanges where 940 possible can avoid most problems. {{ Demoted the SHOULD }} 941 Implementations and configuration need to keep in mind, however, that 942 if the URL lookups are possible only after the IPsec SA is 943 established, recursion issues could prevent this technique from 944 working. 946 {{ Clarif-7.5 }} The UDP payload of all packets containing IKE 947 messages sent on port 4500 MUST begin with the prefix of four zeros; 948 otherwise, the receiver won't know how to handle them. 950 2.1. Use of Retransmission Timers 952 All messages in IKE exist in pairs: a request and a response. The 953 setup of an IKE SA normally consists of two request/response pairs. 954 Once the IKE SA is set up, either end of the security association may 955 initiate requests at any time, and there can be many requests and 956 responses "in flight" at any given moment. But each message is 957 labeled as either a request or a response, and for each request/ 958 response pair one end of the security association is the initiator 959 and the other is the responder. 961 For every pair of IKE messages, the initiator is responsible for 962 retransmission in the event of a timeout. The responder MUST never 963 retransmit a response unless it receives a retransmission of the 964 request. In that event, the responder MUST ignore the retransmitted 965 request except insofar as it triggers a retransmission of the 966 response. The initiator MUST remember each request until it receives 967 the corresponding response. The responder MUST remember each 968 response until it receives a request whose sequence number is larger 969 than or equal to the sequence number in the response plus its window 970 size (see Section 2.3). In order to allow saving memory, responders 971 are allowed to forget response after a timeout of several minutes. 972 If the responder receives a retransmitted request for which it has 973 already forgotten the response, it MUST ignore the request (and not, 974 for example, attempt constructing a new response). 976 IKE is a reliable protocol, in the sense that the initiator MUST 977 retransmit a request until either it receives a corresponding reply 978 OR it deems the IKE security association to have failed and it 979 discards all state associated with the IKE SA and any Child SAs 980 negotiated using that IKE SA. A retransmission from the initiator 981 MUST be bitwise identical to the original request. That is, 982 everything starting from the IKE Header (the IKE SA Initiator's SPI 983 onwards) must be bitwise identical; items before it (such as the IP 984 and UDP headers, and the zero non-ESP marker) do not have to be 985 identical. 987 {{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require 988 some special handling. When a responder receives an IKE_SA_INIT 989 request, it has to determine whether the packet is a retransmission 990 belonging to an existing "half-open" IKE SA (in which case the 991 responder retransmits the same response), or a new request (in which 992 case the responder creates a new IKE SA and sends a fresh response), 993 or it belongs to an existing IKE SA where the IKE_AUTH request has 994 been already received (in which case the responder ignores it). 996 It is not sufficient to use the initiator's SPI and/or IP address to 997 differentiate between these three cases because two different peers 998 behind a single NAT could choose the same initiator SPI. Instead, a 999 robust responder will do the IKE SA lookup using the whole packet, 1000 its hash, or the Ni payload. 1002 2.2. Use of Sequence Numbers for Message ID 1004 Every IKE message contains a Message ID as part of its fixed header. 1005 This Message ID is used to match up requests and responses, and to 1006 identify retransmissions of messages. 1008 The Message ID is a 32-bit quantity, which is zero for the 1009 IKE_SA_INIT messages (including retries of the message due to 1010 responses such as COOKIE and INVALID_KE_PAYLOAD {{ Clarif-2.2 }}), 1011 and incremented for each subsequent exchange. Rekeying an IKE SA 1012 resets the sequence numbers. Thus, the first pair of IKE_AUTH 1013 messages will have ID of 1, the second (when EAP is used) will be 2, 1014 and so on. {{ Clarif-3.10 }} 1016 Each endpoint in the IKE Security Association maintains two "current" 1017 Message IDs: the next one to be used for a request it initiates and 1018 the next one it expects to see in a request from the other end. 1019 These counters increment as requests are generated and received. 1020 Responses always contain the same message ID as the corresponding 1021 request. That means that after the initial exchange, each integer n 1022 may appear as the message ID in four distinct messages: the nth 1023 request from the original IKE initiator, the corresponding response, 1024 the nth request from the original IKE responder, and the 1025 corresponding response. If the two ends make very different numbers 1026 of requests, the Message IDs in the two directions can be very 1027 different. There is no ambiguity in the messages, however, because 1028 the (I)nitiator and (R)esponse bits in the message header specify 1029 which of the four messages a particular one is. 1031 {{ Clarif-5.9 }} Throughout this document, "initiator" refers to the 1032 party who initiated the exchange being described, and "original 1033 initiator" refers to the party who initiated the whole IKE SA. The 1034 "original initiator" always refers to the party who initiated the 1035 exchange which resulted in the current IKE SA. In other words, if 1036 the "original responder" starts rekeying the IKE SA, that party 1037 becomes the "original initiator" of the new IKE SA. 1039 Note that Message IDs are cryptographically protected and provide 1040 protection against message replays. In the unlikely event that 1041 Message IDs grow too large to fit in 32 bits, the IKE SA MUST be 1042 closed or rekeyed. 1044 2.3. Window Size for Overlapping Requests 1046 In order to maximize IKE throughput, an IKE endpoint MAY issue 1047 multiple requests before getting a response to any of them if the 1048 other endpoint has indicated its ability to handle such requests. 1049 For simplicity, an IKE implementation MAY choose to process requests 1050 strictly in order and/or wait for a response to one request before 1051 issuing another. Certain rules must be followed to ensure 1052 interoperability between implementations using different strategies. 1054 After an IKE SA is set up, either end can initiate one or more 1055 requests. These requests may pass one another over the network. An 1056 IKE endpoint MUST be prepared to accept and process a request while 1057 it has a request outstanding in order to avoid a deadlock in this 1058 situation. {{ Downgraded the SHOULD }} An IKE endpoint may also 1059 accept and process multiple requests while it has a request 1060 outstanding. 1062 {{ 3.10.1-16385 }} The SET_WINDOW_SIZE notification asserts that the 1063 sending endpoint is capable of keeping state for multiple outstanding 1064 exchanges, permitting the recipient to send multiple requests before 1065 getting a response to the first. The data associated with a 1066 SET_WINDOW_SIZE notification MUST be 4 octets long and contain the 1067 big endian representation of the number of messages the sender 1068 promises to keep. The window size is always one until the initial 1069 exchanges complete. 1071 An IKE endpoint MUST wait for a response to each of its messages 1072 before sending a subsequent message unless it has received a 1073 SET_WINDOW_SIZE Notify message from its peer informing it that the 1074 peer is prepared to maintain state for multiple outstanding messages 1075 in order to allow greater throughput. 1077 An IKE endpoint MUST NOT exceed the peer's stated window size for 1078 transmitted IKE requests. In other words, if the responder stated 1079 its window size is N, then when the initiator needs to make a request 1080 X, it MUST wait until it has received responses to all requests up 1081 through request X-N. An IKE endpoint MUST keep a copy of (or be able 1082 to regenerate exactly) each request it has sent until it receives the 1083 corresponding response. An IKE endpoint MUST keep a copy of (or be 1084 able to regenerate exactly) the number of previous responses equal to 1085 its declared window size in case its response was lost and the 1086 initiator requests its retransmission by retransmitting the request. 1088 An IKE endpoint supporting a window size greater than one ought to be 1089 capable of processing incoming requests out of order to maximize 1090 performance in the event of network failures or packet reordering. 1092 {{ Clarif-7.3 }} The window size is normally a (possibly 1093 configurable) property of a particular implementation, and is not 1094 related to congestion control (unlike the window size in TCP, for 1095 example). In particular, it is not defined what the responder should 1096 do when it receives a SET_WINDOW_SIZE notification containing a 1097 smaller value than is currently in effect. Thus, there is currently 1098 no way to reduce the window size of an existing IKE SA; you can only 1099 increase it. When rekeying an IKE SA, the new IKE SA starts with 1100 window size 1 until it is explicitly increased by sending a new 1101 SET_WINDOW_SIZE notification. 1103 {{ 3.10.1-9 }}The INVALID_MESSAGE_ID notification is sent when an IKE 1104 message ID outside the supported window is received. This Notify 1105 MUST NOT be sent in a response; the invalid request MUST NOT be 1106 acknowledged. Instead, inform the other side by initiating an 1107 INFORMATIONAL exchange with Notification data containing the four 1108 octet invalid message ID. Sending this notification is optional, and 1109 notifications of this type MUST be rate limited. 1111 2.4. State Synchronization and Connection Timeouts 1113 An IKE endpoint is allowed to forget all of its state associated with 1114 an IKE SA and the collection of corresponding Child SAs at any time. 1115 This is the anticipated behavior in the event of an endpoint crash 1116 and restart. It is important when an endpoint either fails or 1117 reinitializes its state that the other endpoint detect those 1118 conditions and not continue to waste network bandwidth by sending 1119 packets over discarded SAs and having them fall into a black hole. 1121 {{ 3.10.1-16384 }} The INITIAL_CONTACT notification asserts that this 1122 IKE SA is the only IKE SA currently active between the authenticated 1123 identities. It MAY be sent when an IKE SA is established after a 1124 crash, and the recipient MAY use this information to delete any other 1125 IKE SAs it has to the same authenticated identity without waiting for 1126 a timeout. This notification MUST NOT be sent by an entity that may 1127 be replicated (e.g., a roaming user's credentials where the user is 1128 allowed to connect to the corporate firewall from two remote systems 1129 at the same time). {{ Clarif-7.9 }} The INITIAL_CONTACT notification, 1130 if sent, MUST be in the first IKE_AUTH request, not as a separate 1131 exchange afterwards; however, receiving parties need to deal with it 1132 in other requests. 1134 Since IKE is designed to operate in spite of Denial of Service (DoS) 1135 attacks from the network, an endpoint MUST NOT conclude that the 1136 other endpoint has failed based on any routing information (e.g., 1137 ICMP messages) or IKE messages that arrive without cryptographic 1138 protection (e.g., Notify messages complaining about unknown SPIs). 1139 An endpoint MUST conclude that the other endpoint has failed only 1140 when repeated attempts to contact it have gone unanswered for a 1141 timeout period or when a cryptographically protected INITIAL_CONTACT 1142 notification is received on a different IKE SA to the same 1143 authenticated identity. {{ Demoted the SHOULD }} An endpoint should 1144 suspect that the other endpoint has failed based on routing 1145 information and initiate a request to see whether the other endpoint 1146 is alive. To check whether the other side is alive, IKE specifies an 1147 empty INFORMATIONAL message that (like all IKE requests) requires an 1148 acknowledgement (note that within the context of an IKE SA, an 1149 "empty" message consists of an IKE header followed by an Encrypted 1150 payload that contains no payloads). If a cryptographically protected 1151 (fresh, i.e. not retransmitted) message has been received from the 1152 other side recently, unprotected notifications MAY be ignored. 1153 Implementations MUST limit the rate at which they take actions based 1154 on unprotected messages. 1156 Numbers of retries and lengths of timeouts are not covered in this 1157 specification because they do not affect interoperability. It is 1158 suggested that messages be retransmitted at least a dozen times over 1159 a period of at least several minutes before giving up on an SA, but 1160 different environments may require different rules. To be a good 1161 network citizen, retranmission times MUST increase exponentially to 1162 avoid flooding the network and making an existing congestion 1163 situation worse. If there has only been outgoing traffic on all of 1164 the SAs associated with an IKE SA, it is essential to confirm 1165 liveness of the other endpoint to avoid black holes. If no 1166 cryptographically protected messages have been received on an IKE SA 1167 or any of its Child SAs recently, the system needs to perform a 1168 liveness check in order to prevent sending messages to a dead peer. 1169 (This is sometimes called "dead peer detection" or "DPD", although it 1170 is really detecting live peers, not dead ones.) Receipt of a fresh 1171 cryptographically protected message on an IKE SA or any of its Child 1172 SAs ensures liveness of the IKE SA and all of its Child SAs. Note 1173 that this places requirements on the failure modes of an IKE 1174 endpoint. An implementation MUST NOT continue sending on any SA if 1175 some failure prevents it from receiving on all of the associated SAs. 1177 If Child SAs can fail independently from one another without the 1178 associated IKE SA being able to send a delete message, then they MUST 1179 be negotiated by separate IKE SAs. 1181 There is a Denial of Service attack on the initiator of an IKE SA 1182 that can be avoided if the initiator takes the proper care. Since 1183 the first two messages of an SA setup are not cryptographically 1184 protected, an attacker could respond to the initiator's message 1185 before the genuine responder and poison the connection setup attempt. 1186 To prevent this, the initiator MAY be willing to accept multiple 1187 responses to its first message, treat each as potentially legitimate, 1188 respond to it, and then discard all the invalid half-open connections 1189 when it receives a valid cryptographically protected response to any 1190 one of its requests. Once a cryptographically valid response is 1191 received, all subsequent responses should be ignored whether or not 1192 they are cryptographically valid. 1194 Note that with these rules, there is no reason to negotiate and agree 1195 upon an SA lifetime. If IKE presumes the partner is dead, based on 1196 repeated lack of acknowledgement to an IKE message, then the IKE SA 1197 and all Child SAs set up through that IKE SA are deleted. 1199 An IKE endpoint may at any time delete inactive Child SAs to recover 1200 resources used to hold their state. If an IKE endpoint chooses to 1201 delete Child SAs, it MUST send Delete payloads to the other end 1202 notifying it of the deletion. It MAY similarly time out the IKE SA. 1203 {{ Clarified the SHOULD }} Closing the IKE SA implicitly closes all 1204 associated Child SAs. In this case, an IKE endpoint SHOULD send a 1205 Delete payload indicating that it has closed the IKE SA unless the 1206 other endpoint is no longer responding. 1208 2.5. Version Numbers and Forward Compatibility 1210 This document describes version 2.0 of IKE, meaning the major version 1211 number is 2 and the minor version number is 0. {{ Restated the 1212 relationship to RFC 4306 }} This document is a replacement for 1213 [IKEV2]. It is likely that some implementations will want to support 1214 version 1.0 and version 2.0, and in the future, other versions. 1216 The major version number should be incremented only if the packet 1217 formats or required actions have changed so dramatically that an 1218 older version node would not be able to interoperate with a newer 1219 version node if it simply ignored the fields it did not understand 1220 and took the actions specified in the older specification. The minor 1221 version number indicates new capabilities, and MUST be ignored by a 1222 node with a smaller minor version number, but used for informational 1223 purposes by the node with the larger minor version number. For 1224 example, it might indicate the ability to process a newly defined 1225 notification message. The node with the larger minor version number 1226 would simply note that its correspondent would not be able to 1227 understand that message and therefore would not send it. 1229 {{ 3.10.1-5 }} If an endpoint receives a message with a higher major 1230 version number, it MUST drop the message and SHOULD send an 1231 unauthenticated notification message of type INVALID_MAJOR_VERSION 1232 containing the highest (closest) version number it supports. If an 1233 endpoint supports major version n, and major version m, it MUST 1234 support all versions between n and m. If it receives a message with 1235 a major version that it supports, it MUST respond with that version 1236 number. In order to prevent two nodes from being tricked into 1237 corresponding with a lower major version number than the maximum that 1238 they both support, IKE has a flag that indicates that the node is 1239 capable of speaking a higher major version number. 1241 Thus, the major version number in the IKE header indicates the 1242 version number of the message, not the highest version number that 1243 the transmitter supports. If the initiator is capable of speaking 1244 versions n, n+1, and n+2, and the responder is capable of speaking 1245 versions n and n+1, then they will negotiate speaking n+1, where the 1246 initiator will set a flag indicating its ability to speak a higher 1247 version. If they mistakenly (perhaps through an active attacker 1248 sending error messages) negotiate to version n, then both will notice 1249 that the other side can support a higher version number, and they 1250 MUST break the connection and reconnect using version n+1. 1252 Note that IKEv1 does not follow these rules, because there is no way 1253 in v1 of noting that you are capable of speaking a higher version 1254 number. So an active attacker can trick two v2-capable nodes into 1255 speaking v1. {{ Demoted the SHOULD }} When a v2-capable node 1256 negotiates down to v1, it should note that fact in its logs. 1258 Also for forward compatibility, all fields marked RESERVED MUST be 1259 set to zero by an implementation running version 2.0, and their 1260 content MUST be ignored by an implementation running version 2.0 ("Be 1261 conservative in what you send and liberal in what you receive"). In 1262 this way, future versions of the protocol can use those fields in a 1263 way that is guaranteed to be ignored by implementations that do not 1264 understand them. Similarly, payload types that are not defined are 1265 reserved for future use; implementations of a version where they are 1266 undefined MUST skip over those payloads and ignore their contents. 1268 IKEv2 adds a "critical" flag to each payload header for further 1269 flexibility for forward compatibility. If the critical flag is set 1270 and the payload type is unrecognized, the message MUST be rejected 1271 and the response to the IKE request containing that payload MUST 1272 include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an 1273 unsupported critical payload was included. {{ 3.10.1-1 }} In that 1274 Notify payload, the notification data contains the one-octet payload 1275 type. If the critical flag is not set and the payload type is 1276 unsupported, that payload MUST be ignored. Payloads sent in IKE 1277 response messages MUST NOT have the critical flag set. Note that the 1278 critical flag applies only to the payload type, not the contents. If 1279 the payload type is recognized, but the payload contains something 1280 which is not (such as an unknown transform inside an SA payload, or 1281 an unknown Notify Message Type inside a Notify payload), the critical 1282 flag is ignored. 1284 {{ Demoted the SHOULD in the second clause }}Although new payload 1285 types may be added in the future and may appear interleaved with the 1286 fields defined in this specification, implementations MUST send the 1287 payloads defined in this specification in the order shown in the 1288 figures in Section 2; implementations are explicitly allowed to 1289 reject as invalid a message with those payloads in any other order. 1291 2.6. IKE SA SPIs and Cookies 1293 The term "cookies" originates with Karn and Simpson [PHOTURIS] in 1294 Photuris, an early proposal for key management with IPsec, and it has 1295 persisted. The Internet Security Association and Key Management 1296 Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight- 1297 octet fields titled "cookies", and that syntax is used by both IKEv1 1298 and IKEv2, although in IKEv2 they are referred to as the "IKE SPI" 1299 and there is a new separate field in a Notify payload holding the 1300 cookie. The initial two eight-octet fields in the header are used as 1301 a connection identifier at the beginning of IKE packets. Each 1302 endpoint chooses one of the two SPIs and MUST choose them so as to be 1303 unique identifiers of an IKE SA. An SPI value of zero is special and 1304 indicates that the remote SPI value is not yet known by the sender. 1306 Incoming IKE packets are mapped to an IKE SA only using the packet's 1307 SPI, not using (for example) the source IP address of the packet. 1309 Unlike ESP and AH where only the recipient's SPI appears in the 1310 header of a message, in IKE the sender's SPI is also sent in every 1311 message. Since the SPI chosen by the original initiator of the IKE 1312 SA is always sent first, an endpoint with multiple IKE SAs open that 1313 wants to find the appropriate IKE SA using the SPI it assigned must 1314 look at the I(nitiator) Flag bit in the header to determine whether 1315 it assigned the first or the second eight octets. 1317 In the first message of an initial IKE exchange, the initiator will 1318 not know the responder's SPI value and will therefore set that field 1319 to zero. 1321 An expected attack against IKE is state and CPU exhaustion, where the 1322 target is flooded with session initiation requests from forged IP 1323 addresses. This attack can be made less effective if an 1324 implementation of a responder uses minimal CPU and commits no state 1325 to an SA until it knows the initiator can receive packets at the 1326 address from which it claims to be sending them. 1328 When a responder detects a large number of half-open IKE SAs, it 1329 SHOULD reply to IKE_SA_INIT requests with a response containing the 1330 COOKIE notification. {{ 3.10.1-16390 }} The data associated with this 1331 notification MUST be between 1 and 64 octets in length (inclusive), 1332 and its generation is described later in this section. If the 1333 IKE_SA_INIT response includes the COOKIE notification, the initiator 1334 MUST then retry the IKE_SA_INIT request, and include the COOKIE 1335 notification containing the received data as the first payload, and 1336 all other payloads unchanged. The initial exchange will then be as 1337 follows: 1339 Initiator Responder 1340 ------------------------------------------------------------------- 1341 HDR(A,0), SAi1, KEi, Ni --> 1342 <-- HDR(A,0), N(COOKIE) 1343 HDR(A,0), N(COOKIE), SAi1, 1344 KEi, Ni --> 1345 <-- HDR(A,B), SAr1, KEr, 1346 Nr, [CERTREQ] 1347 HDR(A,B), SK {IDi, [CERT,] 1348 [CERTREQ,] [IDr,] AUTH, 1349 SAi2, TSi, TSr} --> 1350 <-- HDR(A,B), SK {IDr, [CERT,] 1351 AUTH, SAr2, TSi, TSr} 1353 The first two messages do not affect any initiator or responder state 1354 except for communicating the cookie. In particular, the message 1355 sequence numbers in the first four messages will all be zero and the 1356 message sequence numbers in the last two messages will be one. 'A' 1357 is the SPI assigned by the initiator, while 'B' is the SPI assigned 1358 by the responder. 1360 {{ Demoted the SHOULD }} An IKE implementation can implement its 1361 responder cookie generation in such a way as to not require any saved 1362 state to recognize its valid cookie when the second IKE_SA_INIT 1363 message arrives. The exact algorithms and syntax they use to 1364 generate cookies do not affect interoperability and hence are not 1365 specified here. The following is an example of how an endpoint could 1366 use cookies to implement limited DOS protection. 1368 A good way to do this is to set the responder cookie to be: 1370 Cookie = | Hash(Ni | IPi | SPIi | ) 1372 where is a randomly generated secret known only to the 1373 responder and periodically changed and | indicates concatenation. 1374 should be changed whenever is 1375 regenerated. The cookie can be recomputed when the IKE_SA_INIT 1376 arrives the second time and compared to the cookie in the received 1377 message. If it matches, the responder knows that the cookie was 1378 generated since the last change to and that IPi must be the 1379 same as the source address it saw the first time. Incorporating SPIi 1380 into the calculation ensures that if multiple IKE SAs are being set 1381 up in parallel they will all get different cookies (assuming the 1382 initiator chooses unique SPIi's). Incorporating Ni in the hash 1383 ensures that an attacker who sees only message 2 can't successfully 1384 forge a message 3. Also, incorporating Ni in the hash prevents an 1385 attacker from fetching one one cookie from the other end, and then 1386 initiating many IKE_SA_INIT exchanges all with different initiator 1387 SPIs (and perhaps port numbers) so that the responder thinks that 1388 there are lots of machines behind one NAT box who are all trying to 1389 connect. 1391 If a new value for is chosen while there are connections in 1392 the process of being initialized, an IKE_SA_INIT might be returned 1393 with other than the current . The responder in 1394 that case MAY reject the message by sending another response with a 1395 new cookie or it MAY keep the old value of around for a 1396 short time and accept cookies computed from either one. {{ Demoted 1397 the SHOULD NOT }} The responder should not accept cookies 1398 indefinitely after is changed, since that would defeat part 1399 of the denial of service protection. {{ Demoted the SHOULD }} The 1400 responder should change the value of frequently, especially 1401 if under attack. 1403 {{ Clarif-2.1 }} In addition to cookies, there are several cases 1404 where the IKE_SA_INIT exchange does not result in the creation of an 1405 IKE SA (such as INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). In such a 1406 case, sending a zero value for the Responder's SPI is correct. If 1407 the responder sends a non-zero responder SPI, the initiator should 1408 not reject the response for only that reason. 1410 {{ Clarif-2.5 }} When one party receives an IKE_SA_INIT request 1411 containing a cookie whose contents do not match the value expected, 1412 that party MUST ignore the cookie and process the message as if no 1413 cookie had been included; usually this means sending a response 1414 containing a new cookie. The initiator should limit the number of 1415 cookie exchanges it tries before giving up. An attacker can forge 1416 multiple cookie responses to the initiator's IKE_SA_INIT message, and 1417 each of those forged cookie reply will trigger two packets: one 1418 packet from the initiator to the responder (which will reject those 1419 cookies), and one reply from responder to initiator that includes the 1420 correct cookie. 1422 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD 1424 {{ This section added by Clarif-2.4 }} 1426 There are two common reasons why the initiator may have to retry the 1427 IKE_SA_INIT exchange: the responder requests a cookie or wants a 1428 different Diffie-Hellman group than was included in the KEi payload. 1429 If the initiator receives a cookie from the responder, the initiator 1430 needs to decide whether or not to include the cookie in only the next 1431 retry of the IKE_SA_INIT request, or in all subsequent retries as 1432 well. 1434 If the initiator includes the cookie only in the next retry, one 1435 additional roundtrip may be needed in some cases. An additional 1436 roundtrip is needed also if the initiator includes the cookie in all 1437 retries, but the responder does not support this. For instance, if 1438 the responder includes the SAi1 and KEi payloads in cookie 1439 calculation, it will reject the request by sending a new cookie. 1441 If both peers support including the cookie in all retries, a slightly 1442 shorter exchange can happen. 1444 Initiator Responder 1445 ----------------------------------------------------------- 1446 HDR(A,0), SAi1, KEi, Ni --> 1447 <-- HDR(A,0), N(COOKIE) 1448 HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> 1449 <-- HDR(A,0), N(INVALID_KE_PAYLOAD) 1450 HDR(A,0), N(COOKIE), SAi1, KEi', Ni --> 1451 <-- HDR(A,B), SAr1, KEr, Nr 1453 Implementations SHOULD support this shorter exchange, but MUST NOT 1454 fail if other implementations do not support this shorter exchange. 1456 2.7. Cryptographic Algorithm Negotiation 1458 The payload type known as "SA" indicates a proposal for a set of 1459 choices of IPsec protocols (IKE, ESP, or AH) for the SA as well as 1460 cryptographic algorithms associated with each protocol. 1462 An SA payload consists of one or more proposals. {{ Clarif-7.13 }} 1463 Each proposal includes one protocol. Each protocol contains one or 1464 more transforms -- each specifying a cryptographic algorithm. Each 1465 transform contains zero or more attributes (attributes are needed 1466 only if the transform identifier does not completely specify the 1467 cryptographic algorithm). 1469 This hierarchical structure was designed to efficiently encode 1470 proposals for cryptographic suites when the number of supported 1471 suites is large because multiple values are acceptable for multiple 1472 transforms. The responder MUST choose a single suite, which may be 1473 any subset of the SA proposal following the rules below: 1475 {{ Clarif-7.13 }} Each proposal contains one protocol. If a proposal 1476 is accepted, the SA response MUST contain the same protocol. The 1477 responder MUST accept a single proposal or reject them all and return 1478 an error. {{ 3.10.1-14 }} The error is given in a notification of 1479 type NO_PROPOSAL_CHOSEN. 1481 Each IPsec protocol proposal contains one or more transforms. Each 1482 transform contains a transform type. The accepted cryptographic 1483 suite MUST contain exactly one transform of each type included in the 1484 proposal. For example: if an ESP proposal includes transforms 1485 ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, 1486 AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one 1487 of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six 1488 combinations are acceptable. 1490 If an initiator proposes both normal ciphers with integrity 1491 protection as well as combined-mode ciphers, then two proposals are 1492 needed. One of the proposals includes the normal ciphers with the 1493 integrity algoritms for them, and the other proposal includes all the 1494 combined mode ciphers without the integrity algorithms (because 1495 combined mode ciphers are not allowed to have any integrity algorithm 1496 other than "none"). 1498 Since the initiator sends its Diffie-Hellman value in the 1499 IKE_SA_INIT, it must guess the Diffie-Hellman group that the 1500 responder will select from its list of supported groups. If the 1501 initiator guesses wrong, the responder will respond with a Notify 1502 payload of type INVALID_KE_PAYLOAD indicating the selected group. In 1503 this case, the initiator MUST retry the IKE_SA_INIT with the 1504 corrected Diffie-Hellman group. The initiator MUST again propose its 1505 full set of acceptable cryptographic suites because the rejection 1506 message was unauthenticated and otherwise an active attacker could 1507 trick the endpoints into negotiating a weaker suite than a stronger 1508 one that they both prefer. 1510 {{ Clarif-2.1 }} When the IKE_SA_INIT exchange does not result in the 1511 creation of an IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, 1512 or COOKIE (see Section 2.6), the responder's SPI will be zero. 1513 However, if the responder sends a non-zero responder SPI, the 1514 initiator should not reject the response for only that reason. 1516 2.8. Rekeying 1518 {{ Demoted the SHOULD }} IKE, ESP, and AH security associations use 1519 secret keys that should be used only for a limited amount of time and 1520 to protect a limited amount of data. This limits the lifetime of the 1521 entire security association. When the lifetime of a security 1522 association expires, the security association MUST NOT be used. If 1523 there is demand, new security associations MAY be established. 1524 Reestablishment of security associations to take the place of ones 1525 that expire is referred to as "rekeying". 1527 To allow for minimal IPsec implementations, the ability to rekey SAs 1528 without restarting the entire IKE SA is optional. An implementation 1529 MAY refuse all CREATE_CHILD_SA requests within an IKE SA. If an SA 1530 has expired or is about to expire and rekeying attempts using the 1531 mechanisms described here fail, an implementation MUST close the IKE 1532 SA and any associated Child SAs and then MAY start new ones. {{ 1533 Demoted the SHOULD }} Implementations may wish to support in-place 1534 rekeying of SAs, since doing so offers better performance and is 1535 likely to reduce the number of packets lost during the transition. 1537 To rekey a Child SA within an existing IKE SA, create a new, 1538 equivalent SA (see Section 2.17 below), and when the new one is 1539 established, delete the old one. To rekey an IKE SA, establish a new 1540 equivalent IKE SA (see Section 2.18 below) with the peer to whom the 1541 old IKE SA is shared using a CREATE_CHILD_SA within the existing IKE 1542 SA. An IKE SA so created inherits all of the original IKE SA's Child 1543 SAs, and the new IKE SA is used for all control messages needed to 1544 maintain those Child SAs. The old IKE SA is then deleted, and the 1545 Delete payload to delete itself MUST be the last request sent over 1546 the old IKE SA. Note that, when rekeying, the new Child SA MAY have 1547 different traffic selectors and algorithms than the old one. 1549 {{ Demoted the SHOULD }} SAs should be rekeyed proactively, i.e., the 1550 new SA should be established before the old one expires and becomes 1551 unusable. Enough time should elapse between the time the new SA is 1552 established and the old one becomes unusable so that traffic can be 1553 switched over to the new SA. 1555 A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes 1556 were negotiated. In IKEv2, each end of the SA is responsible for 1557 enforcing its own lifetime policy on the SA and rekeying the SA when 1558 necessary. If the two ends have different lifetime policies, the end 1559 with the shorter lifetime will end up always being the one to request 1560 the rekeying. If an SA has been inactive for a long time and if an 1561 endpoint would not initiate the SA in the absence of traffic, the 1562 endpoint MAY choose to close the SA instead of rekeying it when its 1563 lifetime expires. {{ Demoted the SHOULD }} It should do so if there 1564 has been no traffic since the last time the SA was rekeyed. 1566 Note that IKEv2 deliberately allows parallel SAs with the same 1567 traffic selectors between common endpoints. One of the purposes of 1568 this is to support traffic quality of service (QoS) differences among 1569 the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and section 4.1 of 1570 [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints 1571 and the traffic selectors may not uniquely identify an SA between 1572 those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on 1573 the basis of duplicate traffic selectors SHOULD NOT be used. 1575 {{ Demoted the SHOULD }} The node that initiated the surviving 1576 rekeyed SA should delete the replaced SA after the new one is 1577 established. 1579 There are timing windows -- particularly in the presence of lost 1580 packets -- where endpoints may not agree on the state of an SA. The 1581 responder to a CREATE_CHILD_SA MUST be prepared to accept messages on 1582 an SA before sending its response to the creation request, so there 1583 is no ambiguity for the initiator. The initiator MAY begin sending 1584 on an SA as soon as it processes the response. The initiator, 1585 however, cannot receive on a newly created SA until it receives and 1586 processes the response to its CREATE_CHILD_SA request. How, then, is 1587 the responder to know when it is OK to send on the newly created SA? 1589 From a technical correctness and interoperability perspective, the 1590 responder MAY begin sending on an SA as soon as it sends its response 1591 to the CREATE_CHILD_SA request. In some situations, however, this 1592 could result in packets unnecessarily being dropped, so an 1593 implementation MAY defer such sending. 1595 The responder can be assured that the initiator is prepared to 1596 receive messages on an SA if either (1) it has received a 1597 cryptographically valid message on the new SA, or (2) the new SA 1598 rekeys an existing SA and it receives an IKE request to close the 1599 replaced SA. When rekeying an SA, the responder continues to send 1600 traffic on the old SA until one of those events occurs. When 1601 establishing a new SA, the responder MAY defer sending messages on a 1602 new SA until either it receives one or a timeout has occurred. {{ 1603 Demoted the SHOULD }} If an initiator receives a message on an SA for 1604 which it has not received a response to its CREATE_CHILD_SA request, 1605 it interprets that as a likely packet loss and retransmits the 1606 CREATE_CHILD_SA request. An initiator MAY send a dummy message on a 1607 newly created SA if it has no messages queued in order to assure the 1608 responder that the initiator is ready to receive messages. 1610 2.8.1. Simultaneous Child SA rekeying 1612 {{ The first two paragraphs were moved, and the rest was added, based 1613 on Clarif-5.11 }} 1615 If the two ends have the same lifetime policies, it is possible that 1616 both will initiate a rekeying at the same time (which will result in 1617 redundant SAs). To reduce the probability of this happening, the 1618 timing of rekeying requests SHOULD be jittered (delayed by a random 1619 amount of time after the need for rekeying is noticed). 1621 This form of rekeying may temporarily result in multiple similar SAs 1622 between the same pairs of nodes. When there are two SAs eligible to 1623 receive packets, a node MUST accept incoming packets through either 1624 SA. If redundant SAs are created though such a collision, the SA 1625 created with the lowest of the four nonces used in the two exchanges 1626 SHOULD be closed by the endpoint that created it. {{ Clarif-5.10 }} 1627 "Lowest" means an octet-by-octet, lexicographical comparison (instead 1628 of, for instance, comparing the nonces as large integers). In other 1629 words, start by comparing the first octet; if they're equal, move to 1630 the next octet, and so on. If you reach the end of one nonce, that 1631 nonce is the lower one. 1633 The following is an explanation on the impact this has on 1634 implementations. Assume that hosts A and B have an existing IPsec SA 1635 pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same 1636 time: 1638 Host A Host B 1639 ------------------------------------------------------------------- 1640 send req1: N(REKEY_SA,SPIa1), 1641 SA(..,SPIa2,..),Ni1,.. --> 1642 <-- send req2: N(REKEY_SA,SPIb1), 1643 SA(..,SPIb2,..),Ni2 1644 recv req2 <-- 1646 At this point, A knows there is a simultaneous rekeying going on. 1647 However, it cannot yet know which of the exchanges will have the 1648 lowest nonce, so it will just note the situation and respond as 1649 usual. 1651 send resp2: SA(..,SPIa3,..), 1652 Nr1,.. --> 1653 --> recv req1 1655 Now B also knows that simultaneous rekeying is going on. It responds 1656 as usual. 1658 <-- send resp1: SA(..,SPIb3,..), 1659 Nr2,.. 1660 recv resp1 <-- 1661 --> recv resp2 1663 At this point, there are three Child SA pairs between A and B (the 1664 old one and two new ones). A and B can now compare the nonces. 1665 Suppose that the lowest nonce was Nr1 in message resp2; in this case, 1666 B (the sender of req2) deletes the redundant new SA, and A (the node 1667 that initiated the surviving rekeyed SA), deletes the old one. 1669 send req3: D(SPIa1) --> 1670 <-- send req4: D(SPIb2) 1671 --> recv req3 1672 <-- send resp3: D(SPIb1) 1673 recv req4 <-- 1674 send resp4: D(SPIa3) --> 1676 The rekeying is now finished. 1678 However, there is a second possible sequence of events that can 1679 happen if some packets are lost in the network, resulting in 1680 retransmissions. The rekeying begins as usual, but A's first packet 1681 (req1) is lost. 1683 Host A Host B 1684 ------------------------------------------------------------------- 1685 send req1: N(REKEY_SA,SPIa1), 1686 SA(..,SPIa2,..), 1687 Ni1,.. --> (lost) 1688 <-- send req2: N(REKEY_SA,SPIb1), 1689 SA(..,SPIb2,..),Ni2 1690 recv req2 <-- 1691 send resp2: SA(..,SPIa3,..), 1692 Nr1,.. --> 1693 --> recv resp2 1694 <-- send req3: D(SPIb1) 1695 recv req3 <-- 1696 send resp3: D(SPIa1) --> 1697 --> recv resp3 1699 From B's point of view, the rekeying is now completed, and since it 1700 has not yet received A's req1, it does not even know that there was 1701 simultaneous rekeying. However, A will continue retransmitting the 1702 message, and eventually it will reach B. 1704 resend req1 --> 1705 --> recv req1 1707 To B, it looks like A is trying to rekey an SA that no longer exists; 1708 thus, B responds to the request with something non-fatal such as 1709 NO_PROPOSAL_CHOSEN. 1711 <-- send resp1: N(NO_PROPOSAL_CHOSEN) 1712 recv resp1 <-- 1714 When A receives this error, it already knows there was simultaneous 1715 rekeying, so it can ignore the error message. 1717 2.8.2. Simultaneous IKE SA Rekeying 1719 Probably the most complex case occurs when both peers try to rekey 1720 the IKE_SA at the same time. Basically, the text in Section 2.8 1721 applies to this case as well; however, it is important to ensure that 1722 the CHILD_SAs are inherited by the right IKE_SA. 1724 The case where both endpoints notice the simultaneous rekeying works 1725 the same way as with CHILD_SAs. After the CREATE_CHILD_SA exchanges, 1726 three IKE_SAs exist between A and B; the one containing the lowest 1727 nonce inherits the CHILD_SAs. 1729 However, there is a twist to the other case where one rekeying 1730 finishes first: 1732 Host A Host B 1733 ------------------------------------------------------------------- 1734 send req1: 1735 SA(..,SPIa1,..),Ni1,.. --> 1736 <-- send req2: SA(..,SPIb1,..),Ni2,.. 1737 --> recv req1 1738 <-- send resp1: SA(..,SPIb2,..),Nr2,.. 1739 recv resp1 <-- 1740 send req3: D() --> 1741 --> recv req3 1743 At this point, host B sees a request to close the IKE_SA. There's 1744 not much more to do than to reply as usual. However, at this point 1745 host B should stop retransmitting req2, since once host A receives 1746 resp3, it will delete all the state associated with the old IKE_SA 1747 and will not be able to reply to it. 1749 <-- send resp3: () 1751 2.8.3. Rekeying the IKE SA Versus Reauthentication 1753 {{ Added this section from Clarif-5.2 }} 1755 Rekeying the IKE SA and reauthentication are different concepts in 1756 IKEv2. Rekeying the IKE SA establishes new keys for the IKE SA and 1757 resets the Message ID counters, but it does not authenticate the 1758 parties again (no AUTH or EAP payloads are involved). 1760 Although rekeying the IKE SA may be important in some environments, 1761 reauthentication (the verification that the parties still have access 1762 to the long-term credentials) is often more important. 1764 IKEv2 does not have any special support for reauthentication. 1765 Reauthentication is done by creating a new IKE SA from scratch (using 1766 IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify 1767 payloads), creating new Child SAs within the new IKE SA (without 1768 REKEY_SA notify payloads), and finally deleting the old IKE SA (which 1769 deletes the old Child SAs as well). 1771 This means that reauthentication also establishes new keys for the 1772 IKE SA and Child SAs. Therefore, while rekeying can be performed 1773 more often than reauthentication, the situation where "authentication 1774 lifetime" is shorter than "key lifetime" does not make sense. 1776 While creation of a new IKE SA can be initiated by either party 1777 (initiator or responder in the original IKE SA), the use of EAP 1778 authentication and/or configuration payloads means in practice that 1779 reauthentication has to be initiated by the same party as the 1780 original IKE SA. IKEv2 does not currently allow the responder to 1781 request reauthentication in this case; however, there are extensions 1782 that add this functionality such as [REAUTH]. 1784 2.9. Traffic Selector Negotiation 1786 {{ Clarif-7.2 }} When an RFC4301-compliant IPsec subsystem receives 1787 an IP packet that matches a "protect" selector in its Security Policy 1788 Database (SPD), the subsystem protects that packet with IPsec. When 1789 no SA exists yet, it is the task of IKE to create it. Maintenance of 1790 a system's SPD is outside the scope of IKE (see [PFKEY] for an 1791 example protocol, although it only applies to IKEv1), though some 1792 implementations might update their SPD in connection with the running 1793 of IKE (for an example scenario, see Section 1.1.3). 1795 Traffic Selector (TS) payloads allow endpoints to communicate some of 1796 the information from their SPD to their peers. TS payloads specify 1797 the selection criteria for packets that will be forwarded over the 1798 newly set up SA. This can serve as a consistency check in some 1799 scenarios to assure that the SPDs are consistent. In others, it 1800 guides the dynamic update of the SPD. 1802 Two TS payloads appear in each of the messages in the exchange that 1803 creates a Child SA pair. Each TS payload contains one or more 1804 Traffic Selectors. Each Traffic Selector consists of an address 1805 range (IPv4 or IPv6), a port range, and an IP protocol ID. 1807 The first of the two TS payloads is known as TSi (Traffic Selector- 1808 initiator). The second is known as TSr (Traffic Selector-responder). 1809 TSi specifies the source address of traffic forwarded from (or the 1810 destination address of traffic forwarded to) the initiator of the 1811 Child SA pair. TSr specifies the destination address of the traffic 1812 forwarded to (or the source address of the traffic forwarded from) 1813 the responder of the Child SA pair. For example, if the original 1814 initiator requests the creation of a Child SA pair, and wishes to 1815 tunnel all traffic from subnet 192.0.1.* on the initiator's side to 1816 subnet 192.0.2.* on the responder's side, the initiator would include 1817 a single traffic selector in each TS payload. TSi would specify the 1818 address range (192.0.1.0 - 192.0.1.255) and TSr would specify the 1819 address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was 1820 acceptable to the responder, it would send identical TS payloads 1821 back. (Note: The IP address range 192.0.2.* has been reserved for 1822 use in examples in RFCs and similar documents. This document needed 1823 two such ranges, and so also used 192.0.1.*. This should not be 1824 confused with any actual address.) 1826 IKEv2 allows the responder to choose a subset of the traffic proposed 1827 by the initiator. This could happen when the configurations of the 1828 two endpoints are being updated but only one end has received the new 1829 information. Since the two endpoints may be configured by different 1830 people, the incompatibility may persist for an extended period even 1831 in the absence of errors. It also allows for intentionally different 1832 configurations, as when one end is configured to tunnel all addresses 1833 and depends on the other end to have the up-to-date list. 1835 When the responder chooses a subset of the traffic proposed by the 1836 initiator, it narrows the traffic selectors to some subset of the 1837 initiator's proposal (provided the set does not become the null set). 1838 If the type of traffic selector proposed is unknown, the responder 1839 ignores that traffic selector, so that the unknown type is not be 1840 returned in the narrowed set. 1842 To enable the responder to choose the appropriate range in this case, 1843 if the initiator has requested the SA due to a data packet, the 1844 initiator SHOULD include as the first traffic selector in each of TSi 1845 and TSr a very specific traffic selector including the addresses in 1846 the packet triggering the request. In the example, the initiator 1847 would include in TSi two traffic selectors: the first containing the 1848 address range (192.0.1.43 - 192.0.1.43) and the source port and IP 1849 protocol from the packet and the second containing (192.0.1.0 - 1850 192.0.1.255) with all ports and IP protocols. The initiator would 1851 similarly include two traffic selectors in TSr. If the initiator 1852 creates the Child SA pair not in response to an arriving packet, but 1853 rather, say, upon startup, then there may be no specific addresses 1854 the initiator prefers for the initial tunnel over any other. In that 1855 case, the first values in TSi and TSr can be ranges rather than 1856 specific values. 1858 The responder performs the narrowing as follows: {{ Clarif-4.10 }} 1860 o If the responder's policy does not allow it to accept any part of 1861 the proposed traffic selectors, it responds with TS_UNACCEPTABLE. 1863 o If the responder's policy allows the entire set of traffic covered 1864 by TSi and TSr, no narrowing is necessary, and the responder can 1865 return the same TSi and TSr values. 1867 o If the responder's policy allows it to accept the first selector 1868 of TSi and TSr, then the responder MUST narrow the traffic 1869 selectors to a subset that includes the initiator's first choices. 1870 In this example above, the responder might respond with TSi being 1871 (192.0.1.43 - 192.0.1.43) with all ports and IP protocols. 1873 o If the responder's policy does not allow it to accept the first 1874 selector of TSi and TSr, the responder narrows to an acceptable 1875 subset of TSi and TSr. 1877 When narrowing is done, there may be several subsets that are 1878 acceptable but their union is not. In this case, the responder 1879 arbitrarily chooses one of them, and MAY include an 1880 ADDITIONAL_TS_POSSIBLE notification in the response. {{ 3.10.1-16386 1881 }} The ADDITIONAL_TS_POSSIBLE notification asserts that the responder 1882 narrowed the proposed traffic selectors but that other traffic 1883 selectors would also have been acceptable, though only in a separate 1884 SA. There is no data associated with this Notify type. This case 1885 will occur only when the initiator and responder are configured 1886 differently from one another. If the initiator and responder agree 1887 on the granularity of tunnels, the initiator will never request a 1888 tunnel wider than the responder will accept. {{ Demoted the SHOULD }} 1889 Such misconfigurations should be recorded in error logs. 1891 It is possible for the responder's policy to contain multiple smaller 1892 ranges, all encompassed by the initiator's traffic selector, and with 1893 the responder's policy being that each of those ranges should be sent 1894 over a different SA. Continuing the example above, the responder 1895 might have a policy of being willing to tunnel those addresses to and 1896 from the initiator, but might require that each address pair be on a 1897 separately negotiated Child SA. If the initiator generated its 1898 request in response to an incoming packet from 192.0.1.43 to 1899 192.0.2.123, there would be no way for the responder to determine 1900 which pair of addresses should be included in this tunnel, and it 1901 would have to make a guess or reject the request with a status of 1902 SINGLE_PAIR_REQUIRED. 1904 {{ 3.10.1-34 }} The SINGLE_PAIR_REQUIRED error indicates that a 1905 CREATE_CHILD_SA request is unacceptable because its sender is only 1906 willing to accept traffic selectors specifying a single pair of 1907 addresses. The requestor is expected to respond by requesting an SA 1908 for only the specific traffic it is trying to forward. 1910 {{ Clarif-4.11 }} Few implementations will have policies that require 1911 separate SAs for each address pair. Because of this, if only some 1912 parts of the TSi and TSr proposed by the initiator are acceptable to 1913 the responder, responders SHOULD narrow the selectors to an 1914 acceptable subset rather than use SINGLE_PAIR_REQUIRED. 1916 2.9.1. Traffic Selectors Violating Own Policy 1918 {{ Clarif-4.12 }} 1920 When creating a new SA, the initiator needs to avoid proposing 1921 traffic selectors that violate its own policy. If this rule is not 1922 followed, valid traffic may be dropped. If you use decorrelated 1923 policies from [IPSECARCH], this kind of policy violations cannot 1924 happen. 1926 This is best illustrated by an example. Suppose that host A has a 1927 policy whose effect is that traffic to 192.0.1.66 is sent via host B 1928 encrypted using AES, and traffic to all other hosts in 192.0.1.0/24 1929 is also sent via B, but must use 3DES. Suppose also that host B 1930 accepts any combination of AES and 3DES. 1932 If host A now proposes an SA that uses 3DES, and includes TSr 1933 containing (192.0.1.0-192.0.1.255), this will be accepted by host B. 1934 Now, host B can also use this SA to send traffic from 192.0.1.66, but 1935 those packets will be dropped by A since it requires the use of AES 1936 for those traffic. Even if host A creates a new SA only for 1937 192.0.1.66 that uses AES, host B may freely continue to use the first 1938 SA for the traffic. In this situation, when proposing the SA, host A 1939 should have followed its own policy, and included a TSr containing 1940 ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead. 1942 In general, if (1) the initiator makes a proposal "for traffic X 1943 (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator 1944 does not actually accept traffic X' with SA, and (3) the initiator 1945 would be willing to accept traffic X' with some SA' (!=SA), valid 1946 traffic can be unnecessarily dropped since the responder can apply 1947 either SA or SA' to traffic X'. 1949 2.10. Nonces 1951 The IKE_SA_INIT messages each contain a nonce. These nonces are used 1952 as inputs to cryptographic functions. The CREATE_CHILD_SA request 1953 and the CREATE_CHILD_SA response also contain nonces. These nonces 1954 are used to add freshness to the key derivation technique used to 1955 obtain keys for Child SA, and to ensure creation of strong pseudo- 1956 random bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST 1957 be randomly chosen, MUST be at least 128 bits in size, and MUST be at 1958 least half the key size of the negotiated prf. ("prf" refers to 1959 "pseudo-random function", one of the cryptographic algorithms 1960 negotiated in the IKE exchange.) {{ Clarif-7.4 }} However, the 1961 initiator chooses the nonce before the outcome of the negotiation is 1962 known. Because of that, the nonce has to be long enough for all the 1963 PRFs being proposed. If the same random number source is used for 1964 both keys and nonces, care must be taken to ensure that the latter 1965 use does not compromise the former. 1967 2.11. Address and Port Agility 1969 IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and 1970 AH associations for the same IP addresses it runs over. The IP 1971 addresses and ports in the outer header are, however, not themselves 1972 cryptographically protected, and IKE is designed to work even through 1973 Network Address Translation (NAT) boxes. An implementation MUST 1974 accept incoming requests even if the source port is not 500 or 4500, 1975 and MUST respond to the address and port from which the request was 1976 received. It MUST specify the address and port at which the request 1977 was received as the source address and port in the response. IKE 1978 functions identically over IPv4 or IPv6. 1980 2.12. Reuse of Diffie-Hellman Exponentials 1982 IKE generates keying material using an ephemeral Diffie-Hellman 1983 exchange in order to gain the property of "perfect forward secrecy". 1984 This means that once a connection is closed and its corresponding 1985 keys are forgotten, even someone who has recorded all of the data 1986 from the connection and gets access to all of the long-term keys of 1987 the two endpoints cannot reconstruct the keys used to protect the 1988 conversation without doing a brute force search of the session key 1989 space. 1991 Achieving perfect forward secrecy requires that when a connection is 1992 closed, each endpoint MUST forget not only the keys used by the 1993 connection but also any information that could be used to recompute 1994 those keys. 1996 Since the computing of Diffie-Hellman exponentials is computationally 1997 expensive, an endpoint may find it advantageous to reuse those 1998 exponentials for multiple connection setups. There are several 1999 reasonable strategies for doing this. An endpoint could choose a new 2000 exponential only periodically though this could result in less-than- 2001 perfect forward secrecy if some connection lasts for less than the 2002 lifetime of the exponential. Or it could keep track of which 2003 exponential was used for each connection and delete the information 2004 associated with the exponential only when some corresponding 2005 connection was closed. This would allow the exponential to be reused 2006 without losing perfect forward secrecy at the cost of maintaining 2007 more state. 2009 Decisions as to whether and when to reuse Diffie-Hellman exponentials 2010 is a private decision in the sense that it will not affect 2011 interoperability. An implementation that reuses exponentials MAY 2012 choose to remember the exponential used by the other endpoint on past 2013 exchanges and if one is reused to avoid the second half of the 2014 calculation. See [REUSE] for a security analysis of this practice 2015 and for additional security considerations when reusing ephemeral DH 2016 keys. 2018 2.13. Generating Keying Material 2020 In the context of the IKE SA, four cryptographic algorithms are 2021 negotiated: an encryption algorithm, an integrity protection 2022 algorithm, a Diffie-Hellman group, and a pseudo-random function 2023 (prf). The pseudo-random function is used for the construction of 2024 keying material for all of the cryptographic algorithms used in both 2025 the IKE SA and the Child SAs. 2027 We assume that each encryption algorithm and integrity protection 2028 algorithm uses a fixed-size key and that any randomly chosen value of 2029 that fixed size can serve as an appropriate key. For algorithms that 2030 accept a variable length key, a fixed key size MUST be specified as 2031 part of the cryptographic transform negotiated (see Section 3.3.5 for 2032 the defintion of the Key Length transform attribute). For algorithms 2033 for which not all values are valid keys (such as DES or 3DES with key 2034 parity), the algorithm by which keys are derived from arbitrary 2035 values MUST be specified by the cryptographic transform. For 2036 integrity protection functions based on Hashed Message Authentication 2037 Code (HMAC), the fixed key size is the size of the output of the 2038 underlying hash function. 2040 It is assumed that pseudo-random functions (PRFs) accept keys of any 2041 length, but have a preferred key size. The preferred key size is 2042 used as the length of SK_d, SK_pi, and SK_pr (see Section 2.14). For 2043 PRFs based on the HMAC construction, the preferred key size is equal 2044 to the length of the output of the underlying hash function. Other 2045 types of PRFs MUST specify their preferred key size. 2047 Keying material will always be derived as the output of the 2048 negotiated prf algorithm. Since the amount of keying material needed 2049 may be greater than the size of the output of the prf algorithm, we 2050 will use the prf iteratively. We will use the terminology prf+ to 2051 describe the function that outputs a pseudo-random stream based on 2052 the inputs to a prf as follows: (where | indicates concatenation) 2054 prf+ (K,S) = T1 | T2 | T3 | T4 | ... 2056 where: 2057 T1 = prf (K, S | 0x01) 2058 T2 = prf (K, T1 | S | 0x02) 2059 T3 = prf (K, T2 | S | 0x03) 2060 T4 = prf (K, T3 | S | 0x04) 2062 continuing as needed to compute all required keys. The keys are 2063 taken from the output string without regard to boundaries (e.g., if 2064 the required keys are a 256-bit Advanced Encryption Standard (AES) 2065 key and a 160-bit HMAC key, and the prf function generates 160 bits, 2066 the AES key will come from T1 and the beginning of T2, while the HMAC 2067 key will come from the rest of T2 and the beginning of T3). 2069 The constant concatenated to the end of each string feeding the prf 2070 is a single octet. prf+ in this document is not defined beyond 255 2071 times the size of the prf output. 2073 2.14. Generating Keying Material for the IKE SA 2075 The shared keys are computed as follows. A quantity called SKEYSEED 2076 is calculated from the nonces exchanged during the IKE_SA_INIT 2077 exchange and the Diffie-Hellman shared secret established during that 2078 exchange. SKEYSEED is used to calculate seven other secrets: SK_d 2079 used for deriving new keys for the Child SAs established with this 2080 IKE SA; SK_ai and SK_ar used as a key to the integrity protection 2081 algorithm for authenticating the component messages of subsequent 2082 exchanges; SK_ei and SK_er used for encrypting (and of course 2083 decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are 2084 used when generating an AUTH payload. The lengths of SK_d, SK_pi, 2085 and SK_pr are the preferred key length of the agreed-to PRF. 2087 SKEYSEED and its derivatives are computed as follows: 2089 SKEYSEED = prf(Ni | Nr, g^ir) 2091 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } 2092 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) 2094 (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, 2095 SK_pi, and SK_pr are taken in order from the generated bits of the 2096 prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman 2097 exchange. g^ir is represented as a string of octets in big endian 2098 order padded with zeros if necessary to make it the length of the 2099 modulus. Ni and Nr are the nonces, stripped of any headers. For 2100 historical backwards-compatibility reasons, there are two PRFs that 2101 are treated specially in this calculation. If the negotiated PRF is 2102 AES-XCBC-PRF-128 [RFC4434] or AES-CMAC-PRF-128 [RFC4615], only the 2103 first 64 bits of Ni and the first 64 bits of Nr are used in the 2104 calculation. 2106 The two directions of traffic flow use different keys. The keys used 2107 to protect messages from the original initiator are SK_ai and SK_ei. 2108 The keys used to protect messages in the other direction are SK_ar 2109 and SK_er. 2111 2.15. Authentication of the IKE SA 2113 When not using extensible authentication (see Section 2.16), the 2114 peers are authenticated by having each sign (or MAC using a shared 2115 secret as the key) a block of data. For the responder, the octets to 2116 be signed start with the first octet of the first SPI in the header 2117 of the second message (IKE_SA_INIT response) and end with the last 2118 octet of the last payload in the second message. Appended to this 2119 (for purposes of computing the signature) are the initiator's nonce 2120 Ni (just the value, not the payload containing it), and the value 2121 prf(SK_pr,IDr') where IDr' is the responder's ID payload excluding 2122 the fixed header. Note that neither the nonce Ni nor the value 2123 prf(SK_pr,IDr') are transmitted. Similarly, the initiator signs the 2124 first message (IKE_SA_INIT request), starting with the first octet of 2125 the first SPI in the header and ending with the last octet of the 2126 last payload. Appended to this (for purposes of computing the 2127 signature) are the responder's nonce Nr, and the value 2128 prf(SK_pi,IDi'). In the above calculation, IDi' and IDr' are the 2129 entire ID payloads excluding the fixed header. It is critical to the 2130 security of the exchange that each side sign the other side's nonce. 2132 {{ Clarif-3.1 }} 2134 The initiator's signed octets can be described as: 2136 InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI 2137 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 2138 RealIKEHDR = SPIi | SPIr | . . . | Length 2139 RealMessage1 = RealIKEHDR | RestOfMessage1 2140 NonceRPayload = PayloadHeader | NonceRData 2141 InitiatorIDPayload = PayloadHeader | RestOfIDPayload 2142 RestOfInitIDPayload = IDType | RESERVED | InitIDData 2143 MACedIDForI = prf(SK_pi, RestOfInitIDPayload) 2145 The responder's signed octets can be described as: 2147 ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR 2148 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 2149 RealIKEHDR = SPIi | SPIr | . . . | Length 2150 RealMessage2 = RealIKEHDR | RestOfMessage2 2151 NonceIPayload = PayloadHeader | NonceIData 2152 ResponderIDPayload = PayloadHeader | RestOfIDPayload 2153 RestOfRespIDPayload = IDType | RESERVED | RespIDData 2154 MACedIDForR = prf(SK_pr, RestOfRespIDPayload) 2156 Note that all of the payloads are included under the signature, 2157 including any payload types not defined in this document. If the 2158 first message of the exchange is sent multiple times (such as with a 2159 responder cookie and/or a different Diffie-Hellman group), it is the 2160 latest version of the message that is signed. 2162 Optionally, messages 3 and 4 MAY include a certificate, or 2163 certificate chain providing evidence that the key used to compute a 2164 digital signature belongs to the name in the ID payload. The 2165 signature or MAC will be computed using algorithms dictated by the 2166 type of key used by the signer, and specified by the Auth Method 2167 field in the Authentication payload. There is no requirement that 2168 the initiator and responder sign with the same cryptographic 2169 algorithms. The choice of cryptographic algorithms depends on the 2170 type of key each has. In particular, the initiator may be using a 2171 shared key while the responder may have a public signature key and 2172 certificate. It will commonly be the case (but it is not required) 2173 that if a shared secret is used for authentication that the same key 2174 is used in both directions. 2176 Note that it is a common but typically insecure practice to have a 2177 shared key derived solely from a user-chosen password without 2178 incorporating another source of randomness. This is typically 2179 insecure because user-chosen passwords are unlikely to have 2180 sufficient unpredictability to resist dictionary attacks and these 2181 attacks are not prevented in this authentication method. 2182 (Applications using password-based authentication for bootstrapping 2183 and IKE SA should use the authentication method in Section 2.16, 2184 which is designed to prevent off-line dictionary attacks.) {{ Demoted 2185 the SHOULD }} The pre-shared key needs to contain as much 2186 unpredictability as the strongest key being negotiated. In the case 2187 of a pre-shared key, the AUTH value is computed as: 2189 AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), ) 2191 where the string "Key Pad for IKEv2" is 17 ASCII characters without 2192 null termination. The shared secret can be variable length. The pad 2193 string is added so that if the shared secret is derived from a 2194 password, the IKE implementation need not store the password in 2195 cleartext, but rather can store the value prf(Shared Secret,"Key Pad 2196 for IKEv2"), which could not be used as a password equivalent for 2197 protocols other than IKEv2. As noted above, deriving the shared 2198 secret from a password is not secure. This construction is used 2199 because it is anticipated that people will do it anyway. The 2200 management interface by which the Shared Secret is provided MUST 2201 accept ASCII strings of at least 64 octets and MUST NOT add a null 2202 terminator before using them as shared secrets. It MUST also accept 2203 a hex encoding of the Shared Secret. The management interface MAY 2204 accept other encodings if the algorithm for translating the encoding 2205 to a binary string is specified. 2207 2.16. Extensible Authentication Protocol Methods 2209 In addition to authentication using public key signatures and shared 2210 secrets, IKE supports authentication using methods defined in RFC 2211 3748 [EAP]. Typically, these methods are asymmetric (designed for a 2212 user authenticating to a server), and they may not be mutual. For 2213 this reason, these protocols are typically used to authenticate the 2214 initiator to the responder and MUST be used in conjunction with a 2215 public key signature based authentication of the responder to the 2216 initiator. These methods are often associated with mechanisms 2217 referred to as "Legacy Authentication" mechanisms. 2219 While this memo references [EAP] with the intent that new methods can 2220 be added in the future without updating this specification, some 2221 simpler variations are documented here and in Section 3.16. [EAP] 2222 defines an authentication protocol requiring a variable number of 2223 messages. Extensible Authentication is implemented in IKE as 2224 additional IKE_AUTH exchanges that MUST be completed in order to 2225 initialize the IKE SA. 2227 An initiator indicates a desire to use extensible authentication by 2228 leaving out the AUTH payload from message 3. By including an IDi 2229 payload but not an AUTH payload, the initiator has declared an 2230 identity but has not proven it. If the responder is willing to use 2231 an extensible authentication method, it will place an Extensible 2232 Authentication Protocol (EAP) payload in message 4 and defer sending 2233 SAr2, TSi, and TSr until initiator authentication is complete in a 2234 subsequent IKE_AUTH exchange. In the case of a minimal extensible 2235 authentication, the initial SA establishment will appear as follows: 2237 Initiator Responder 2238 ------------------------------------------------------------------- 2239 HDR, SAi1, KEi, Ni --> 2240 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 2241 HDR, SK {IDi, [CERTREQ,] 2242 [IDr,] SAi2, 2243 TSi, TSr} --> 2244 <-- HDR, SK {IDr, [CERT,] AUTH, 2245 EAP } 2246 HDR, SK {EAP} --> 2247 <-- HDR, SK {EAP (success)} 2248 HDR, SK {AUTH} --> 2249 <-- HDR, SK {AUTH, SAr2, TSi, TSr } 2251 {{ Clarif-3.10 }} As described in Section 2.2, when EAP is used, each 2252 pair of IKE SA initial setup messages will have their message numbers 2253 incremented; the first pair of AUTH messages will have an ID of 1, 2254 the second will be 2, and so on. 2256 For EAP methods that create a shared key as a side effect of 2257 authentication, that shared key MUST be used by both the initiator 2258 and responder to generate AUTH payloads in messages 7 and 8 using the 2259 syntax for shared secrets specified in Section 2.15. The shared key 2260 from EAP is the field from the EAP specification named MSK. This 2261 shared key generated during an IKE exchange MUST NOT be used for any 2262 other purpose. 2264 EAP methods that do not establish a shared key SHOULD NOT be used, as 2265 they are subject to a number of man-in-the-middle attacks [EAPMITM] 2266 if these EAP methods are used in other protocols that do not use a 2267 server-authenticated tunnel. Please see the Security Considerations 2268 section for more details. If EAP methods that do not generate a 2269 shared key are used, the AUTH payloads in messages 7 and 8 MUST be 2270 generated using SK_pi and SK_pr, respectively. 2272 {{ Demoted the SHOULD }} The initiator of an IKE SA using EAP needs 2273 to be capable of extending the initial protocol exchange to at least 2274 ten IKE_AUTH exchanges in the event the responder sends notification 2275 messages and/or retries the authentication prompt. Once the protocol 2276 exchange defined by the chosen EAP authentication method has 2277 successfully terminated, the responder MUST send an EAP payload 2278 containing the Success message. Similarly, if the authentication 2279 method has failed, the responder MUST send an EAP payload containing 2280 the Failure message. The responder MAY at any time terminate the IKE 2281 exchange by sending an EAP payload containing the Failure message. 2283 Following such an extended exchange, the EAP AUTH payloads MUST be 2284 included in the two messages following the one containing the EAP 2285 Success message. 2287 {{ Clarif-3.5 }} When the initiator authentication uses EAP, it is 2288 possible that the contents of the IDi payload is used only for AAA 2289 routing purposes and selecting which EAP method to use. This value 2290 may be different from the identity authenticated by the EAP method. 2291 It is important that policy lookups and access control decisions use 2292 the actual authenticated identity. Often the EAP server is 2293 implemented in a separate AAA server that communicates with the IKEv2 2294 responder. In this case, the authenticated identity has to be sent 2295 from the AAA server to the IKEv2 responder. 2297 2.17. Generating Keying Material for Child SAs 2299 A single Child SA is created by the IKE_AUTH exchange, and additional 2300 Child SAs can optionally be created in CREATE_CHILD_SA exchanges. 2301 Keying material for them is generated as follows: 2303 KEYMAT = prf+(SK_d, Ni | Nr) 2305 Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this 2306 request is the first Child SA created or the fresh Ni and Nr from the 2307 CREATE_CHILD_SA exchange if this is a subsequent creation. 2309 For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman 2310 exchange, the keying material is defined as: 2312 KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) 2314 where g^ir (new) is the shared secret from the ephemeral Diffie- 2315 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 2316 octet string in big endian order padded with zeros in the high-order 2317 bits if necessary to make it the length of the modulus). 2319 For ESP and AH, a single Child SA negotiation results in two security 2320 associations (one in each direction). Keying material MUST be taken 2321 from the expanded KEYMAT in the following order: 2323 o The encryption key (if any) for the SA carrying data from the 2324 initiator to the responder. 2326 o The authentication key (if any) for the SA carrying data from the 2327 initiator to the responder. 2329 o The encryption key (if any) for the SA carrying data from the 2330 responder to the initiator. 2332 o The authentication key (if any) for the SA carrying data from the 2333 responder to the initiator. 2335 Each cryptographic algorithm takes a fixed number of bits of keying 2336 material specified as part of the algorithm, or negotiated in SA 2337 payloads (see Section 2.13 for description of key lengths, and 2338 Section 3.3.5 for the definition of the Key Length transform 2339 attribute). 2341 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange 2343 The CREATE_CHILD_SA exchange can be used to rekey an existing IKE SA 2344 (see Section 2.8). {{ Clarif-5.3 }} New initiator and responder SPIs 2345 are supplied in the SPI fields in the Proposal structures inside the 2346 Security Association (SA) payloads (not the SPI fields in the IKE 2347 header). The TS payloads are omitted when rekeying an IKE SA. 2348 SKEYSEED for the new IKE SA is computed using SK_d from the existing 2349 IKE SA as follows: 2351 SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr) 2353 where g^ir (new) is the shared secret from the ephemeral Diffie- 2354 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 2355 octet string in big endian order padded with zeros if necessary to 2356 make it the length of the modulus) and Ni and Nr are the two nonces 2357 stripped of any headers. 2359 {{ Clarif-5.5 }} The old and new IKE SA may have selected a different 2360 PRF. Because the rekeying exchange belongs to the old IKE SA, it is 2361 the old IKE SA's PRF that is used. 2363 {{ Clarif-5.12}} The main reason for rekeying the IKE SA is to ensure 2364 that the compromise of old keying material does not provide 2365 information about the current keys, or vice versa. Therefore, 2366 implementations MUST perform a new Diffie-Hellman exchange when 2367 rekeying the IKE SA. In other words, an initiator MUST NOT propose 2368 the value "NONE" for the D-H transform, and a responder MUST NOT 2369 accept such a proposal. This means that a succesful exchange 2370 rekeying the IKE SA always includes the KEi/KEr payloads. 2372 The new IKE SA MUST reset its message counters to 0. 2374 SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as 2375 specified in Section 2.14. 2377 2.19. Requesting an Internal Address on a Remote Network 2379 Most commonly occurring in the endpoint-to-security-gateway scenario, 2380 an endpoint may need an IP address in the network protected by the 2381 security gateway and may need to have that address dynamically 2382 assigned. A request for such a temporary address can be included in 2383 any request to create a Child SA (including the implicit request in 2384 message 3) by including a CP payload. Note, however, it is usual to 2385 only assign one IP address during the IKE_AUTH exchange. That 2386 address persists at least until the deletion of the IKE SA. 2388 This function provides address allocation to an IPsec Remote Access 2389 Client (IRAC) trying to tunnel into a network protected by an IPsec 2390 Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an 2391 IKE SA and a Child SA, the IRAC MUST request the IRAS-controlled 2392 address (and optionally other information concerning the protected 2393 network) in the IKE_AUTH exchange. The IRAS may procure an address 2394 for the IRAC from any number of sources such as a DHCP/BOOTP server 2395 or its own address pool. 2397 Initiator Responder 2398 ------------------------------------------------------------------- 2399 HDR, SK {IDi, [CERT,] 2400 [CERTREQ,] [IDr,] AUTH, 2401 CP(CFG_REQUEST), SAi2, 2402 TSi, TSr} --> 2403 <-- HDR, SK {IDr, [CERT,] AUTH, 2404 CP(CFG_REPLY), SAr2, 2405 TSi, TSr} 2407 In all cases, the CP payload MUST be inserted before the SA payload. 2408 In variations of the protocol where there are multiple IKE_AUTH 2409 exchanges, the CP payloads MUST be inserted in the messages 2410 containing the SA payloads. 2412 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute 2413 (either IPv4 or IPv6) but MAY contain any number of additional 2414 attributes the initiator wants returned in the response. 2416 For example, message from initiator to responder: 2418 CP(CFG_REQUEST)= 2419 INTERNAL_ADDRESS() 2420 TSi = (0, 0-65535,0.0.0.0-255.255.255.255) 2421 TSr = (0, 0-65535,0.0.0.0-255.255.255.255) 2423 NOTE: Traffic Selectors contain (protocol, port range, address 2424 range). 2426 Message from responder to initiator: 2428 CP(CFG_REPLY)= 2429 INTERNAL_ADDRESS(192.0.2.202) 2430 INTERNAL_NETMASK(255.255.255.0) 2431 INTERNAL_SUBNET(192.0.2.0/255.255.255.0) 2432 TSi = (0, 0-65535,192.0.2.202-192.0.2.202) 2433 TSr = (0, 0-65535,192.0.2.0-192.0.2.255) 2435 All returned values will be implementation dependent. As can be seen 2436 in the above example, the IRAS MAY also send other attributes that 2437 were not included in CP(CFG_REQUEST) and MAY ignore the non- 2438 mandatory attributes that it does not support. 2440 {{ 3.10.1-37 }} The FAILED_CP_REQUIRED notification is sent by 2441 responder in the case where CP(CFG_REQUEST) was expected but not 2442 received, and so is a conflict with locally configured policy. There 2443 is no associated data. 2445 The responder MUST NOT send a CFG_REPLY without having first received 2446 a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS 2447 to perform an unnecessary configuration lookup if the IRAC cannot 2448 process the REPLY. In the case where the IRAS's configuration 2449 requires that CP be used for a given identity IDi, but IRAC has 2450 failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and 2451 terminate the IKE exchange with a FAILED_CP_REQUIRED error. The 2452 FAILED_CP_REQUIRED is not fatal to the IKE SA; it simply causes the 2453 Child SA creation fail. The initiator can fix this by later starting 2454 a new configuration payload request. 2456 2.19.1. Configuration Payloads 2458 Editor's note: some of this sub-section is redundant and will go away 2459 in the next version of the document. 2461 In support of the scenario described in Section 1.1.3, an initiator 2462 may request that the responder assign an IP address and tell the 2463 initiator what it is. {{ Clarif-6.1 }} That request is done using 2464 configuration payloads, not traffic selectors. An address in a TSi 2465 payload in a response does not mean that the responder has assigned 2466 that address to the initiator: it only means that if packets matching 2467 these traffic selectors are sent by the initiator, IPsec processing 2468 can be performed as agreed for this SA. 2470 Configuration payloads are of type CFG_REQUEST/CFG_REPLY or CFG_SET/ 2471 CFG_ACK (see CFG Type in the payload description below). CFG_REQUEST 2472 and CFG_SET payloads may optionally be added to any IKE request. The 2473 IKE response MUST include either a corresponding CFG_REPLY or CFG_ACK 2474 or a Notify payload with an error type indicating why the request 2475 could not be honored. An exception is that a minimal implementation 2476 MAY ignore all CFG_REQUEST and CFG_SET payloads, so a response 2477 message without a corresponding CFG_REPLY or CFG_ACK MUST be accepted 2478 as an indication that the request was not supported. 2480 "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information 2481 from its peer. If an attribute in the CFG_REQUEST Configuration 2482 Payload is not zero-length, it is taken as a suggestion for that 2483 attribute. The CFG_REPLY Configuration Payload MAY return that 2484 value, or a new one. It MAY also add new attributes and not include 2485 some requested ones. Requestors MUST ignore returned attributes that 2486 they do not recognize. 2488 Some attributes MAY be multi-valued, in which case multiple attribute 2489 values of the same type are sent and/or returned. Generally, all 2490 values of an attribute are returned when the attribute is requested. 2491 For some attributes (in this version of the specification only 2492 internal addresses), multiple requests indicates a request that 2493 multiple values be assigned. For these attributes, the number of 2494 values returned SHOULD NOT exceed the number requested. 2496 If the data type requested in a CFG_REQUEST is not recognized or not 2497 supported, the responder MUST NOT return an error type but rather 2498 MUST either send a CFG_REPLY that MAY be empty or a reply not 2499 containing a CFG_REPLY payload at all. Error returns are reserved 2500 for cases where the request is recognized but cannot be performed as 2501 requested or the request is badly formatted. 2503 "CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data 2504 to its peer. In this case, the CFG_SET Configuration Payload 2505 contains attributes the initiator wants its peer to alter. The 2506 responder MUST return a Configuration Payload if it accepted any of 2507 the configuration data and it MUST contain the attributes that the 2508 responder accepted with zero-length data. Those attributes that it 2509 did not accept MUST NOT be in the CFG_ACK Configuration Payload. If 2510 no attributes were accepted, the responder MUST return either an 2511 empty CFG_ACK payload or a response message without a CFG_ACK 2512 payload. There are currently no defined uses for the CFG_SET/CFG_ACK 2513 exchange, though they may be used in connection with extensions based 2514 on Vendor IDs. An minimal implementation of this specification MAY 2515 ignore CFG_SET payloads. 2517 {{ Demoted the SHOULD }} Extensions via the CP payload should not be 2518 used for general purpose management. Its main intent is to provide a 2519 bootstrap mechanism to exchange information within IPsec from IRAS to 2520 IRAC. While it MAY be useful to use such a method to exchange 2521 information between some Security Gateways (SGW) or small networks, 2522 existing management protocols such as DHCP [DHCP], RADIUS [RADIUS], 2523 SNMP, or LDAP [LDAP] should be preferred for enterprise management as 2524 well as subsequent information exchanges. 2526 2.20. Requesting the Peer's Version 2528 An IKE peer wishing to inquire about the other peer's IKE software 2529 version information MAY use the method below. This is an example of 2530 a configuration request within an INFORMATIONAL exchange, after the 2531 IKE SA and first Child SA have been created. 2533 An IKE implementation MAY decline to give out version information 2534 prior to authentication or even after authentication to prevent 2535 trolling in case some implementation is known to have some security 2536 weakness. In that case, it MUST either return an empty string or no 2537 CP payload if CP is not supported. 2539 Initiator Responder 2540 ------------------------------------------------------------------- 2541 HDR, SK{CP(CFG_REQUEST)} --> 2542 <-- HDR, SK{CP(CFG_REPLY)} 2544 CP(CFG_REQUEST)= 2545 APPLICATION_VERSION("") 2547 CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar 2548 Inc.") 2550 2.21. Error Handling 2552 There are many kinds of errors that can occur during IKE processing. 2553 If a request is received that is badly formatted or unacceptable for 2554 reasons of policy (e.g., no matching cryptographic algorithms), the 2555 response MUST contain a Notify payload indicating the error. If an 2556 error occurs outside the context of an IKE request (e.g., the node is 2557 getting ESP messages on a nonexistent SPI), the node SHOULD initiate 2558 an INFORMATIONAL exchange with a Notify payload describing the 2559 problem. 2561 Errors that occur before a cryptographically protected IKE SA is 2562 established must be handled very carefully. There is a trade-off 2563 between wanting to be helpful in diagnosing a problem and responding 2564 to it and wanting to avoid being a dupe in a denial of service attack 2565 based on forged messages. 2567 If a node receives a message on UDP port 500 or 4500 outside the 2568 context of an IKE SA known to it (and not a request to start one), it 2569 may be the result of a recent crash of the node. If the message is 2570 marked as a response, the node MAY audit the suspicious event but 2571 MUST NOT respond. If the message is marked as a request, the node 2572 MAY audit the suspicious event and MAY send a response. If a 2573 response is sent, the response MUST be sent to the IP address and 2574 port from whence it came with the same IKE SPIs and the Message ID 2575 copied. The response MUST NOT be cryptographically protected and 2576 MUST contain a Notify payload indicating INVALID_IKE_SPI. {{ 3.10.1-4 2577 }} The INVALID_IKE_SPI notification indicates an IKE message was 2578 received with an unrecognized destination SPI; this usually indicates 2579 that the recipient has rebooted and forgotten the existence of an IKE 2580 SA. 2582 A node receiving such an unprotected Notify payload MUST NOT respond 2583 and MUST NOT change the state of any existing SAs. The message might 2584 be a forgery or might be a response the genuine correspondent was 2585 tricked into sending. {{ Demoted two SHOULDs }} A node should treat 2586 such a message (and also a network message like ICMP destination 2587 unreachable) as a hint that there might be problems with SAs to that 2588 IP address and should initiate a liveness test for any such IKE SA. 2589 An implementation SHOULD limit the frequency of such tests to avoid 2590 being tricked into participating in a denial of service attack. 2592 A node receiving a suspicious message from an IP address with which 2593 it has an IKE SA MAY send an IKE Notify payload in an IKE 2594 INFORMATIONAL exchange over that SA. {{ Demoted the SHOULD }} The 2595 recipient MUST NOT change the state of any SAs as a result, but may 2596 wish to audit the event to aid in diagnosing malfunctions. A node 2597 MUST limit the rate at which it will send messages in response to 2598 unprotected messages. 2600 2.22. IPComp 2602 Use of IP compression [IP-COMP] can be negotiated as part of the 2603 setup of a Child SA. While IP compression involves an extra header 2604 in each packet and a compression parameter index (CPI), the virtual 2605 "compression association" has no life outside the ESP or AH SA that 2606 contains it. Compression associations disappear when the 2607 corresponding ESP or AH SA goes away. It is not explicitly mentioned 2608 in any DELETE payload. 2610 Negotiation of IP compression is separate from the negotiation of 2611 cryptographic parameters associated with a Child SA. A node 2612 requesting a Child SA MAY advertise its support for one or more 2613 compression algorithms through one or more Notify payloads of type 2614 IPCOMP_SUPPORTED. This notification may be included only in a 2615 message containing an SA payload negotiating a Child SA and indicates 2616 a willingness by its sender to use IPComp on this SA. The response 2617 MAY indicate acceptance of a single compression algorithm with a 2618 Notify payload of type IPCOMP_SUPPORTED. These payloads MUST NOT 2619 occur in messages that do not contain SA payloads. 2621 {{ 3.10.1-16387 }}The data associated with this notification includes 2622 a two-octet IPComp CPI followed by a one-octet transform ID 2623 optionally followed by attributes whose length and format are defined 2624 by that transform ID. A message proposing an SA may contain multiple 2625 IPCOMP_SUPPORTED notifications to indicate multiple supported 2626 algorithms. A message accepting an SA may contain at most one. 2628 The transform IDs currently defined are: 2630 Name Number Defined In 2631 ------------------------------------- 2632 RESERVED 0 2633 IPCOMP_OUI 1 2634 IPCOMP_DEFLATE 2 RFC 2394 2635 IPCOMP_LZS 3 RFC 2395 2636 IPCOMP_LZJH 4 RFC 3051 2637 RESERVED TO IANA 5-240 2638 PRIVATE USE 241-255 2640 Although there has been discussion of allowing multiple compression 2641 algorithms to be accepted and to have different compression 2642 algorithms available for the two directions of a Child SA, 2643 implementations of this specification MUST NOT accept an IPComp 2644 algorithm that was not proposed, MUST NOT accept more than one, and 2645 MUST NOT compress using an algorithm other than one proposed and 2646 accepted in the setup of the Child SA. 2648 A side effect of separating the negotiation of IPComp from 2649 cryptographic parameters is that it is not possible to propose 2650 multiple cryptographic suites and propose IP compression with some of 2651 them but not others. 2653 In some cases, Robust Header Compression (ROHC) may be more 2654 appropriate than IP Compression. [ROHCV2] defines the use of ROHC 2655 with IKEv2 and IPsec. 2657 2.23. NAT Traversal 2659 Network Address Translation (NAT) gateways are a controversial 2660 subject. This section briefly describes what they are and how they 2661 are likely to act on IKE traffic. Many people believe that NATs are 2662 evil and that we should not design our protocols so as to make them 2663 work better. IKEv2 does specify some unintuitive processing rules in 2664 order that NATs are more likely to work. 2666 NATs exist primarily because of the shortage of IPv4 addresses, 2667 though there are other rationales. IP nodes that are "behind" a NAT 2668 have IP addresses that are not globally unique, but rather are 2669 assigned from some space that is unique within the network behind the 2670 NAT but that are likely to be reused by nodes behind other NATs. 2671 Generally, nodes behind NATs can communicate with other nodes behind 2672 the same NAT and with nodes with globally unique addresses, but not 2673 with nodes behind other NATs. There are exceptions to that rule. 2674 When those nodes make connections to nodes on the real Internet, the 2675 NAT gateway "translates" the IP source address to an address that 2676 will be routed back to the gateway. Messages to the gateway from the 2677 Internet have their destination addresses "translated" to the 2678 internal address that will route the packet to the correct endnode. 2680 NATs are designed to be "transparent" to endnodes. Neither software 2681 on the node behind the NAT nor the node on the Internet requires 2682 modification to communicate through the NAT. Achieving this 2683 transparency is more difficult with some protocols than with others. 2684 Protocols that include IP addresses of the endpoints within the 2685 payloads of the packet will fail unless the NAT gateway understands 2686 the protocol and modifies the internal references as well as those in 2687 the headers. Such knowledge is inherently unreliable, is a network 2688 layer violation, and often results in subtle problems. 2690 Opening an IPsec connection through a NAT introduces special 2691 problems. If the connection runs in transport mode, changing the IP 2692 addresses on packets will cause the checksums to fail and the NAT 2693 cannot correct the checksums because they are cryptographically 2694 protected. Even in tunnel mode, there are routing problems because 2695 transparently translating the addresses of AH and ESP packets 2696 requires special logic in the NAT and that logic is heuristic and 2697 unreliable in nature. For that reason, IKEv2 will use UDP 2698 encapsulation of IKE and ESP packets. This encoding is slightly less 2699 efficient but is easier for NATs to process. In addition, firewalls 2700 may be configured to pass IPsec traffic over UDP but not ESP/AH or 2701 vice versa. 2703 It is a common practice of NATs to translate TCP and UDP port numbers 2704 as well as addresses and use the port numbers of inbound packets to 2705 decide which internal node should get a given packet. For this 2706 reason, even though IKE packets MUST be sent from and to UDP port 500 2707 or 4500, they MUST be accepted coming from any port and responses 2708 MUST be sent to the port from whence they came. This is because the 2709 ports may be modified as the packets pass through NATs. Similarly, 2710 IP addresses of the IKE endpoints are generally not included in the 2711 IKE payloads because the payloads are cryptographically protected and 2712 could not be transparently modified by NATs. 2714 Port 4500 is reserved for UDP-encapsulated ESP and IKE. {{ Clarif-7.6 2715 }} An IPsec endpoint that discovers a NAT between it and its 2716 correspondent MUST send all subsequent traffic from port 4500, which 2717 NATs should not treat specially (as they might with port 500). 2719 An initiator can float to port 4500, regardless whether or not there 2720 is NAT, even at the beginning of IKE. When either side is using port 2721 4500, sending with UDP encapsulation is not required, but 2722 understanding received packets with UDP encapsulation is required. 2723 UDP encapsulation MUST NOT be done on port 500. If NAT-T is 2724 supported (that is, if NAT_DETECTION_*_IP payloads were exchanged 2725 during IKE_SA_INIT), all devices MUST be able to receive and process 2726 both UDP encapsulated and non-UDP encapsulated packets at any time. 2727 Either side can decide whether or not to use UDP encapsulation 2728 irrespective of the choice made by the other side. However, if a NAT 2729 is detected, both devices MUST send UDP encapsulated packets. 2731 The specific requirements for supporting NAT traversal [NATREQ] are 2732 listed below. Support for NAT traversal is optional. In this 2733 section only, requirements listed as MUST apply only to 2734 implementations supporting NAT traversal. 2736 o IKE MUST listen on port 4500 as well as port 500. IKE MUST 2737 respond to the IP address and port from which packets arrived. 2739 o Both IKE initiator and responder MUST include in their IKE_SA_INIT 2740 packets Notify payloads of type NAT_DETECTION_SOURCE_IP and 2741 NAT_DETECTION_DESTINATION_IP. Those payloads can be used to 2742 detect if there is NAT between the hosts, and which end is behind 2743 the NAT. The location of the payloads in the IKE_SA_INIT packets 2744 is just after the Ni and Nr payloads (before the optional CERTREQ 2745 payload). 2747 o {{ 3.10.1-16388 }} The data associated with the 2748 NAT_DETECTION_SOURCE_IP notification is a SHA-1 digest of the SPIs 2749 (in the order they appear in the header), IP address, and port on 2750 which this packet was sent. There MAY be multiple 2751 NAT_DETECTION_SOURCE_IP payloads in a message if the sender does 2752 not know which of several network attachments will be used to send 2753 the packet. 2755 o {{ 3.10.1-16389 }} The data associated with the 2756 NAT_DETECTION_DESTINATION_IP notification is a SHA-1 digest of the 2757 SPIs (in the order they appear in the header), IP address, and 2758 port to which this packet was sent. 2760 o {{ 3.10.1-16388 }} {{ 3.10.1-16389 }} The recipient of either the 2761 NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP 2762 notification MAY compare the supplied value to a SHA-1 hash of the 2763 SPIs, source IP address, and port, and if they don't match it 2764 SHOULD enable NAT traversal. In the case of a mismatching 2765 NAT_DETECTION_SOURCE_IP hash, the recipient MAY reject the 2766 connection attempt if NAT traversal is not supported. In the case 2767 of a mismatching NAT_DETECTION_DESTINATION_IP hash, it means that 2768 the system receiving the NAT_DETECTION_DESTINATION_IP payload is 2769 behind a NAT and that system SHOULD start sending keepalive 2770 packets as defined in [UDPENCAPS]; alternately, it MAY reject the 2771 connection attempt if NAT traversal is not supported. 2773 o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches 2774 the expected value of the source IP and port found from the IP 2775 header of the packet containing the payload, it means that the 2776 system sending those payloads is behind NAT (i.e., someone along 2777 the route changed the source address of the original packet to 2778 match the address of the NAT box). In this case, the system 2779 receiving the payloads should allow dynamic update of the other 2780 systems' IP address, as described later. 2782 o If the NAT_DETECTION_DESTINATION_IP payload received does not 2783 match the hash of the destination IP and port found from the IP 2784 header of the packet containing the payload, it means that the 2785 system receiving the NAT_DETECTION_DESTINATION_IP payload is 2786 behind a NAT. In this case, that system SHOULD start sending 2787 keepalive packets as explained in [UDPENCAPS]. 2789 o The IKE initiator MUST check these payloads if present and if they 2790 do not match the addresses in the outer packet MUST tunnel all 2791 future IKE and ESP packets associated with this IKE SA over UDP 2792 port 4500. 2794 o To tunnel IKE packets over UDP port 4500, the IKE header has four 2795 octets of zero prepended and the result immediately follows the 2796 UDP header. To tunnel ESP packets over UDP port 4500, the ESP 2797 header immediately follows the UDP header. Since the first four 2798 octets of the ESP header contain the SPI, and the SPI cannot 2799 validly be zero, it is always possible to distinguish ESP and IKE 2800 messages. 2802 o Implementations MUST process received UDP-encapsulated ESP packets 2803 even when no NAT was detected. 2805 o The original source and destination IP address required for the 2806 transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) 2807 are obtained from the Traffic Selectors associated with the 2808 exchange. In the case of NAT traversal, the Traffic Selectors 2809 MUST contain exactly one IP address, which is then used as the 2810 original IP address. 2812 o There are cases where a NAT box decides to remove mappings that 2813 are still alive (for example, the keepalive interval is too long, 2814 or the NAT box is rebooted). To recover in these cases, hosts 2815 that are not behind a NAT SHOULD send all packets (including 2816 retransmission packets) to the IP address and port from the last 2817 valid authenticated packet from the other end (i.e., dynamically 2818 update the address). A host behind a NAT SHOULD NOT do this 2819 because it opens a DoS attack possibility. Any authenticated IKE 2820 packet or any authenticated UDP-encapsulated ESP packet can be 2821 used to detect that the IP address or the port has changed. 2823 2.24. Explicit Congestion Notification (ECN) 2825 When IPsec tunnels behave as originally specified in [IPSECARCH-OLD], 2826 ECN usage is not appropriate for the outer IP headers because tunnel 2827 decapsulation processing discards ECN congestion indications to the 2828 detriment of the network. ECN support for IPsec tunnels for IKEv1- 2829 based IPsec requires multiple operating modes and negotiation (see 2830 [ECN]). IKEv2 simplifies this situation by requiring that ECN be 2831 usable in the outer IP headers of all tunnel-mode IPsec SAs created 2832 by IKEv2. Specifically, tunnel encapsulators and decapsulators for 2833 all tunnel-mode SAs created by IKEv2 MUST support the ECN full- 2834 functionality option for tunnels specified in [ECN] and MUST 2835 implement the tunnel encapsulation and decapsulation processing 2836 specified in [IPSECARCH] to prevent discarding of ECN congestion 2837 indications. 2839 3. Header and Payload Formats 2841 In the tables in this section, some cryptographic primitives and 2842 configuation attributes are marked as "UNSPECIFIED". These are items 2843 for which there are no known specifications and therefore 2844 interoperability is currently impossible. A future specification may 2845 describe their use, but until such specification is made, 2846 implementations SHOULD NOT attempt to use items marked as 2847 "UNSPECIFIED" in implementations that are meant to be interoperable. 2849 3.1. The IKE Header 2851 IKE messages use UDP ports 500 and/or 4500, with one IKE message per 2852 UDP datagram. Information from the beginning of the packet through 2853 the UDP header is largely ignored except that the IP addresses and 2854 UDP ports from the headers are reversed and used for return packets. 2855 When sent on UDP port 500, IKE messages begin immediately following 2856 the UDP header. When sent on UDP port 4500, IKE messages have 2857 prepended four octets of zero. These four octets of zero are not 2858 part of the IKE message and are not included in any of the length 2859 fields or checksums defined by IKE. Each IKE message begins with the 2860 IKE header, denoted HDR in this memo. Following the header are one 2861 or more IKE payloads each identified by a "Next Payload" field in the 2862 preceding payload. Payloads are processed in the order in which they 2863 appear in an IKE message by invoking the appropriate processing 2864 routine according to the "Next Payload" field in the IKE header and 2865 subsequently according to the "Next Payload" field in the IKE payload 2866 itself until a "Next Payload" field of zero indicates that no 2867 payloads follow. If a payload of type "Encrypted" is found, that 2868 payload is decrypted and its contents parsed as additional payloads. 2869 An Encrypted payload MUST be the last payload in a packet and an 2870 Encrypted payload MUST NOT contain another Encrypted payload. 2872 The Recipient SPI in the header identifies an instance of an IKE 2873 security association. It is therefore possible for a single instance 2874 of IKE to multiplex distinct sessions with multiple peers. 2876 All multi-octet fields representing integers are laid out in big 2877 endian order (also known as "most significant byte first", or 2878 "network byte order"). 2880 The format of the IKE header is shown in Figure 4. 2882 1 2 3 2883 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 2884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2885 | IKE SA Initiator's SPI | 2886 | | 2887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2888 | IKE SA Responder's SPI | 2889 | | 2890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2891 | Next Payload | MjVer | MnVer | Exchange Type | Flags | 2892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2893 | Message ID | 2894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2895 | Length | 2896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2898 Figure 4: IKE Header Format 2900 o Initiator's SPI (8 octets) - A value chosen by the initiator to 2901 identify a unique IKE security association. This value MUST NOT 2902 be zero. 2904 o Responder's SPI (8 octets) - A value chosen by the responder to 2905 identify a unique IKE security association. This value MUST be 2906 zero in the first message of an IKE Initial Exchange (including 2907 repeats of that message including a cookie). {{ The phrase "and 2908 MUST NOT be zero in any other message" was removed; Clarif-2.1 }} 2910 o Next Payload (1 octet) - Indicates the type of payload that 2911 immediately follows the header. The format and value of each 2912 payload are defined below. 2914 o Major Version (4 bits) - Indicates the major version of the IKE 2915 protocol in use. Implementations based on this version of IKE 2916 MUST set the Major Version to 2. Implementations based on 2917 previous versions of IKE and ISAKMP MUST set the Major Version to 2918 1. Implementations based on this version of IKE MUST reject or 2919 ignore messages containing a version number greater than 2 with an 2920 INVALID_MAJOR_VERSION notification message as described in Section 2921 2.5. 2923 o Minor Version (4 bits) - Indicates the minor version of the IKE 2924 protocol in use. Implementations based on this version of IKE 2925 MUST set the Minor Version to 0. They MUST ignore the minor 2926 version number of received messages. 2928 o Exchange Type (1 octet) - Indicates the type of exchange being 2929 used. This constrains the payloads sent in each message in an 2930 exchange. 2932 Exchange Type Value 2933 ---------------------------------- 2934 RESERVED 0-33 2935 IKE_SA_INIT 34 2936 IKE_AUTH 35 2937 CREATE_CHILD_SA 36 2938 INFORMATIONAL 37 2939 RESERVED TO IANA 38-239 2940 PRIVATE USE 240-255 2942 o Flags (1 octet) - Indicates specific options that are set for the 2943 message. Presence of options is indicated by the appropriate bit 2944 in the flags field being set. The bits are defined LSB first, so 2945 bit 0 would be the least significant bit of the Flags octet. In 2946 the description below, a bit being 'set' means its value is '1', 2947 while 'cleared' means its value is '0'. 2949 * X(reserved) (bits 0-2) - These bits MUST be cleared when 2950 sending and MUST be ignored on receipt. 2952 * I(nitiator) (bit 3 of Flags) - This bit MUST be set in messages 2953 sent by the original initiator of the IKE SA and MUST be 2954 cleared in messages sent by the original responder. It is used 2955 by the recipient to determine which eight octets of the SPI 2956 were generated by the recipient. This bit changes to reflect 2957 who initiated the last rekey of the IKE SA. 2959 * V(ersion) (bit 4 of Flags) - This bit indicates that the 2960 transmitter is capable of speaking a higher major version 2961 number of the protocol than the one indicated in the major 2962 version number field. Implementations of IKEv2 must clear this 2963 bit when sending and MUST ignore it in incoming messages. 2965 * R(esponse) (bit 5 of Flags) - This bit indicates that this 2966 message is a response to a message containing the same message 2967 ID. This bit MUST be cleared in all request messages and MUST 2968 be set in all responses. An IKE endpoint MUST NOT generate a 2969 response to a message that is marked as being a response. 2971 * X(reserved) (bits 6-7 of Flags) - These bits MUST be cleared 2972 when sending and MUST be ignored on receipt. 2974 o Message ID (4 octets) - Message identifier used to control 2975 retransmission of lost packets and matching of requests and 2976 responses. It is essential to the security of the protocol 2977 because it is used to prevent message replay attacks. See 2978 Section 2.1 and Section 2.2. 2980 o Length (4 octets) - Length of total message (header + payloads) in 2981 octets. 2983 3.2. Generic Payload Header 2985 Each IKE payload defined in Section 3.3 through Section 3.16 begins 2986 with a generic payload header, shown in Figure 5. Figures for each 2987 payload below will include the generic payload header, but for 2988 brevity the description of each field will be omitted. 2990 1 2 3 2991 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 2992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2993 | Next Payload |C| RESERVED | Payload Length | 2994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2996 Figure 5: Generic Payload Header 2998 The Generic Payload Header fields are defined as follows: 3000 o Next Payload (1 octet) - Identifier for the payload type of the 3001 next payload in the message. If the current payload is the last 3002 in the message, then this field will be 0. This field provides a 3003 "chaining" capability whereby additional payloads can be added to 3004 a message by appending it to the end of the message and setting 3005 the "Next Payload" field of the preceding payload to indicate the 3006 new payload's type. An Encrypted payload, which must always be 3007 the last payload of a message, is an exception. It contains data 3008 structures in the format of additional payloads. In the header of 3009 an Encrypted payload, the Next Payload field is set to the payload 3010 type of the first contained payload (instead of 0). The payload 3011 type values are: 3013 Next Payload Type Notation Value 3014 -------------------------------------------------- 3015 No Next Payload 0 3016 RESERVED 1-32 3017 Security Association SA 33 3018 Key Exchange KE 34 3019 Identification - Initiator IDi 35 3020 Identification - Responder IDr 36 3021 Certificate CERT 37 3022 Certificate Request CERTREQ 38 3023 Authentication AUTH 39 3024 Nonce Ni, Nr 40 3025 Notify N 41 3026 Delete D 42 3027 Vendor ID V 43 3028 Traffic Selector - Initiator TSi 44 3029 Traffic Selector - Responder TSr 45 3030 Encrypted E 46 3031 Configuration CP 47 3032 Extensible Authentication EAP 48 3033 RESERVED TO IANA 49-127 3034 PRIVATE USE 128-255 3036 (Payload type values 1-32 should not be assigned in the 3037 future so that there is no overlap with the code assignments 3038 for IKEv1.) 3040 o Critical (1 bit) - MUST be set to zero if the sender wants the 3041 recipient to skip this payload if it does not understand the 3042 payload type code in the Next Payload field of the previous 3043 payload. MUST be set to one if the sender wants the recipient to 3044 reject this entire message if it does not understand the payload 3045 type. MUST be ignored by the recipient if the recipient 3046 understands the payload type code. MUST be set to zero for 3047 payload types defined in this document. Note that the critical 3048 bit applies to the current payload rather than the "next" payload 3049 whose type code appears in the first octet. The reasoning behind 3050 not setting the critical bit for payloads defined in this document 3051 is that all implementations MUST understand all payload types 3052 defined in this document and therefore must ignore the Critical 3053 bit's value. Skipped payloads are expected to have valid Next 3054 Payload and Payload Length fields. 3056 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on 3057 receipt. 3059 o Payload Length (2 octets) - Length in octets of the current 3060 payload, including the generic payload header. 3062 {{ Clarif-7.10 }} Many payloads contain fields marked as "RESERVED". 3063 Some payloads in IKEv2 (and historically in IKEv1) are not aligned to 3064 4-octet boundaries. 3066 3.3. Security Association Payload 3068 The Security Association Payload, denoted SA in this memo, is used to 3069 negotiate attributes of a security association. Assembly of Security 3070 Association Payloads requires great peace of mind. An SA payload MAY 3071 contain multiple proposals. If there is more than one, they MUST be 3072 ordered from most preferred to least preferred. Each proposal 3073 contains a single IPsec protocol (where a protocol is IKE, ESP, or 3074 AH), each protocol MAY contain multiple transforms, and each 3075 transform MAY contain multiple attributes. When parsing an SA, an 3076 implementation MUST check that the total Payload Length is consistent 3077 with the payload's internal lengths and counts. Proposals, 3078 Transforms, and Attributes each have their own variable length 3079 encodings. They are nested such that the Payload Length of an SA 3080 includes the combined contents of the SA, Proposal, Transform, and 3081 Attribute information. The length of a Proposal includes the lengths 3082 of all Transforms and Attributes it contains. The length of a 3083 Transform includes the lengths of all Attributes it contains. 3085 The syntax of Security Associations, Proposals, Transforms, and 3086 Attributes is based on ISAKMP; however the semantics are somewhat 3087 different. The reason for the complexity and the hierarchy is to 3088 allow for multiple possible combinations of algorithms to be encoded 3089 in a single SA. Sometimes there is a choice of multiple algorithms, 3090 whereas other times there is a combination of algorithms. For 3091 example, an initiator might want to propose using ESP with either 3092 (3DES and HMAC_MD5) or (AES and HMAC_SHA1). 3094 One of the reasons the semantics of the SA payload has changed from 3095 ISAKMP and IKEv1 is to make the encodings more compact in common 3096 cases. 3098 The Proposal structure contains within it a Proposal # and an IPsec 3099 protocol ID. Each structure MUST have a proposal number one (1) 3100 greater than the previous structure. The first Proposal in the 3101 initiator's SA payload MUST have a Proposal # of one (1). One reason 3102 to use multiple proposals is to propose both standard crypto ciphers 3103 and combined-mode ciphers. Combined-mode ciphers include both 3104 integrity and encryption in a single encryption algorithm, and are 3105 not allowed to be offered with a separate integrity algorithm other 3106 than "none". If an initiator wants to propose both combined-mode 3107 ciphers and normal ciphers, it must include two proposals: one will 3108 have all the combined-mode ciphers, and the other will have all the 3109 normal ciphers with the integrity algorithms. For example, one such 3110 proposal would have two proposal structures: ESP with ENCR_AES-CCM_8, 3111 ENCR_AES-CCM_12, and ENCR_AES-CCM_16 as Proposal #1, and ESP with 3112 ENCR_AES_CBC, ENCR_3DES, AUTH_AES_XCBC_96, and AUTH_HMAC_SHA1_96 as 3113 Proposal #2. 3115 Each Proposal/Protocol structure is followed by one or more transform 3116 structures. The number of different transforms is generally 3117 determined by the Protocol. AH generally has two transforms: 3118 Extended Sequence Numbers (ESN) and an integrity check algorithm. 3119 ESP generally has three: ESN, an encryption algorithm and an 3120 integrity check algorithm. IKE generally has four transforms: a 3121 Diffie-Hellman group, an integrity check algorithm, a prf algorithm, 3122 and an encryption algorithm. If an algorithm that combines 3123 encryption and integrity protection is proposed, it MUST be proposed 3124 as an encryption algorithm and an integrity protection algorithm MUST 3125 NOT be proposed. For each Protocol, the set of permissible 3126 transforms is assigned transform ID numbers, which appear in the 3127 header of each transform. 3129 If there are multiple transforms with the same Transform Type, the 3130 proposal is an OR of those transforms. If there are multiple 3131 Transforms with different Transform Types, the proposal is an AND of 3132 the different groups. For example, to propose ESP with (3DES or AES- 3133 CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two 3134 Transform Type 1 candidates (one for 3DES and one for AEC-CBC) and 3135 two Transform Type 3 candidates (one for HMAC_MD5 and one for 3136 HMAC_SHA). This effectively proposes four combinations of 3137 algorithms. If the initiator wanted to propose only a subset of 3138 those, for example (3DES and HMAC_MD5) or (IDEA and HMAC_SHA), there 3139 is no way to encode that as multiple transforms within a single 3140 Proposal. Instead, the initiator would have to construct two 3141 different Proposals, each with two transforms. 3143 A given transform MAY have one or more Attributes. Attributes are 3144 necessary when the transform can be used in more than one way, as 3145 when an encryption algorithm has a variable key size. The transform 3146 would specify the algorithm and the attribute would specify the key 3147 size. Most transforms do not have attributes. A transform MUST NOT 3148 have multiple attributes of the same type. To propose alternate 3149 values for an attribute (for example, multiple key sizes for the AES 3150 encryption algorithm), and implementation MUST include multiple 3151 Transforms with the same Transform Type each with a single Attribute. 3153 Note that the semantics of Transforms and Attributes are quite 3154 different from those in IKEv1. In IKEv1, a single Transform carried 3155 multiple algorithms for a protocol with one carried in the Transform 3156 and the others carried in the Attributes. 3158 1 2 3 3159 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 3160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3161 | Next Payload |C| RESERVED | Payload Length | 3162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3163 | | 3164 ~ ~ 3165 | | 3166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3168 Figure 6: Security Association Payload 3170 o Proposals (variable) - One or more proposal substructures. 3172 The payload type for the Security Association Payload is thirty three 3173 (33). 3175 3.3.1. Proposal Substructure 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 | 0 (last) or 2 | RESERVED | Proposal Length | 3181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3182 | Proposal # | Protocol ID | SPI Size |# of Transforms| 3183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3184 ~ SPI (variable) ~ 3185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3186 | | 3187 ~ ~ 3188 | | 3189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3191 Figure 7: Proposal Substructure 3193 o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the 3194 last Proposal Substructure in the SA. This syntax is inherited 3195 from ISAKMP, but is unnecessary because the last Proposal could be 3196 identified from the length of the SA. The value (2) corresponds 3197 to a Payload Type of Proposal in IKEv1, and the first four octets 3198 of the Proposal structure are designed to look somewhat like the 3199 header of a Payload. 3201 o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on 3202 receipt. 3204 o Proposal Length (2 octets) - Length of this proposal, including 3205 all transforms and attributes that follow. 3207 o Proposal # (1 octet) - When a proposal is made, the first proposal 3208 in an SA payload MUST be #1, and subsequent proposals MUST be one 3209 more than the previous proposal (indicating an OR of the two 3210 proposals). When a proposal is accepted, the proposal number in 3211 the SA payload MUST match the number on the proposal sent that was 3212 accepted. 3214 o Protocol ID (1 octet) - Specifies the IPsec protocol identifier 3215 for the current negotiation. The defined values are: 3217 Protocol Protocol ID 3218 ----------------------------------- 3219 RESERVED 0 3220 IKE 1 3221 AH 2 3222 ESP 3 3223 RESERVED TO IANA 4-200 3224 PRIVATE USE 201-255 3226 o SPI Size (1 octet) - For an initial IKE SA negotiation, this field 3227 MUST be zero; the SPI is obtained from the outer header. During 3228 subsequent negotiations, it is equal to the size, in octets, of 3229 the SPI of the corresponding protocol (8 for IKE, 4 for ESP and 3230 AH). 3232 o # of Transforms (1 octet) - Specifies the number of transforms in 3233 this proposal. 3235 o SPI (variable) - The sending entity's SPI. Even if the SPI Size 3236 is not a multiple of 4 octets, there is no padding applied to the 3237 payload. When the SPI Size field is zero, this field is not 3238 present in the Security Association payload. 3240 o Transforms (variable) - One or more transform substructures. 3242 3.3.2. Transform Substructure 3244 1 2 3 3245 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 3246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3247 | 0 (last) or 3 | RESERVED | Transform Length | 3248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3249 |Transform Type | RESERVED | Transform ID | 3250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3251 | | 3252 ~ Transform Attributes ~ 3253 | | 3254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3256 Figure 8: Transform Substructure 3258 o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the 3259 last Transform Substructure in the Proposal. This syntax is 3260 inherited from ISAKMP, but is unnecessary because the last 3261 transform could be identified from the length of the proposal. 3262 The value (3) corresponds to a Payload Type of Transform in IKEv1, 3263 and the first four octets of the Transform structure are designed 3264 to look somewhat like the header of a Payload. 3266 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 3268 o Transform Length - The length (in octets) of the Transform 3269 Substructure including Header and Attributes. 3271 o Transform Type (1 octet) - The type of transform being specified 3272 in this transform. Different protocols support different 3273 transform types. For some protocols, some of the transforms may 3274 be optional. If a transform is optional and the initiator wishes 3275 to propose that the transform be omitted, no transform of the 3276 given type is included in the proposal. If the initiator wishes 3277 to make use of the transform optional to the responder, it 3278 includes a transform substructure with transform ID = 0 as one of 3279 the options. 3281 o Transform ID (2 octets) - The specific instance of the transform 3282 type being proposed. 3284 The transform type values are: 3286 Description Trans. Used In 3287 Type 3288 ------------------------------------------------------------------ 3289 RESERVED 0 3290 Encryption Algorithm (ENCR) 1 IKE and ESP 3291 Pseudo-random Function (PRF) 2 IKE 3292 Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP 3293 Diffie-Hellman Group (D-H) 4 IKE, optional in AH & ESP 3294 Extended Sequence Numbers (ESN) 5 AH and ESP 3295 RESERVED TO IANA 6-240 3296 PRIVATE USE 241-255 3298 (*) Negotiating an integrity algorithm is mandatory for the 3299 Encrypted payload format specified in this document. For example, 3300 [AEAD] specifies additional formats based on authenticated 3301 encryption, in which a separate integrity algorithm is not 3302 negotiated. 3304 For Transform Type 1 (Encryption Algorithm), defined Transform IDs 3305 are: 3307 Name Number Defined In 3308 --------------------------------------------------- 3309 RESERVED 0 3310 ENCR_DES_IV64 1 (UNSPECIFIED) 3311 ENCR_DES 2 (RFC2405), [DES] 3312 ENCR_3DES 3 (RFC2451) 3313 ENCR_RC5 4 (RFC2451) 3314 ENCR_IDEA 5 (RFC2451), [IDEA] 3315 ENCR_CAST 6 (RFC2451) 3316 ENCR_BLOWFISH 7 (RFC2451) 3317 ENCR_3IDEA 8 (UNSPECIFIED) 3318 ENCR_DES_IV32 9 (UNSPECIFIED) 3319 RESERVED 10 3320 ENCR_NULL 11 (RFC2410) 3321 ENCR_AES_CBC 12 (RFC3602) 3322 ENCR_AES_CTR 13 (RFC3686) 3323 RESERVED TO IANA 14-1023 3324 PRIVATE USE 1024-65535 3326 For Transform Type 2 (Pseudo-random Function), defined Transform IDs 3327 are: 3329 Name Number Defined In 3330 ------------------------------------------------------ 3331 RESERVED 0 3332 PRF_HMAC_MD5 1 (RFC2104), [MD5] 3333 PRF_HMAC_SHA1 2 (RFC2104), [SHA] 3334 PRF_HMAC_TIGER 3 (RFC2104) 3335 PRF_AES128_XCBC 4 (RFC4434) 3336 RESERVED TO IANA 5-1023 3337 PRIVATE USE 1024-65535 3339 For Transform Type 3 (Integrity Algorithm), defined Transform IDs 3340 are: 3342 Name Number Defined In 3343 ---------------------------------------- 3344 NONE 0 3345 AUTH_HMAC_MD5_96 1 (RFC2403) 3346 AUTH_HMAC_SHA1_96 2 (RFC2404) 3347 AUTH_DES_MAC 3 (UNSPECIFIED) 3348 AUTH_KPDK_MD5 4 (UNSPECIFIED) 3349 AUTH_AES_XCBC_96 5 (RFC3566) 3350 RESERVED TO IANA 6-1023 3351 PRIVATE USE 1024-65535 3353 For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs 3354 are: 3356 Name Number Defined in 3357 ---------------------------------------- 3358 NONE 0 3359 768 Bit MODP 1 Appendix B 3360 1024 Bit MODP 2 Appendix B 3361 RESERVED TO IANA 3-4 3362 1536-bit MODP 5 [ADDGROUP] 3363 RESERVED TO IANA 6-13 3364 2048-bit MODP 14 [ADDGROUP] 3365 3072-bit MODP 15 [ADDGROUP] 3366 4096-bit MODP 16 [ADDGROUP] 3367 6144-bit MODP 17 [ADDGROUP] 3368 8192-bit MODP 18 [ADDGROUP] 3369 RESERVED TO IANA 19-1023 3370 PRIVATE USE 1024-65535 3372 For Transform Type 5 (Extended Sequence Numbers), defined Transform 3373 IDs are: 3375 Name Number 3376 -------------------------------------------- 3377 No Extended Sequence Numbers 0 3378 Extended Sequence Numbers 1 3379 RESERVED 2 - 65535 3381 {{ Clarif-4.4 }} Note that an initiator who supports ESNs will 3382 usually include two ESN transforms, with values "0" and "1", in its 3383 proposals. A proposal containing a single ESN transform with value 3384 "1" means that using normal (non-extended) sequence numbers is not 3385 acceptable. 3387 Numerous additional transform types have been defined since the 3388 publication of RFC 4306. Please refer to the IANA IKEv2 registry for 3389 details. 3391 3.3.3. Valid Transform Types by Protocol 3393 The number and type of transforms that accompany an SA payload are 3394 dependent on the protocol in the SA itself. An SA payload proposing 3395 the establishment of an SA has the following mandatory and optional 3396 transform types. A compliant implementation MUST understand all 3397 mandatory and optional types for each protocol it supports (though it 3398 need not accept proposals with unacceptable suites). A proposal MAY 3399 omit the optional types if the only value for them it will accept is 3400 NONE. 3402 Protocol Mandatory Types Optional Types 3403 --------------------------------------------------- 3404 IKE ENCR, PRF, INTEG*, D-H 3405 ESP ENCR, ESN INTEG, D-H 3406 AH INTEG, ESN D-H 3408 (*) Negotiating an integrity algorithm is mandatory for the 3409 Encrypted payload format specified in this document. For example, 3410 [AEAD] specifies additional formats based on authenticated 3411 encryption, in which a separate integrity algorithm is not 3412 negotiated. 3414 3.3.4. Mandatory Transform IDs 3416 The specification of suites that MUST and SHOULD be supported for 3417 interoperability has been removed from this document because they are 3418 likely to change more rapidly than this document evolves. 3420 An important lesson learned from IKEv1 is that no system should only 3421 implement the mandatory algorithms and expect them to be the best 3422 choice for all customers. 3424 It is likely that IANA will add additional transforms in the future, 3425 and some users may want to use private suites, especially for IKE 3426 where implementations should be capable of supporting different 3427 parameters, up to certain size limits. In support of this goal, all 3428 implementations of IKEv2 SHOULD include a management facility that 3429 allows specification (by a user or system administrator) of Diffie- 3430 Hellman (DH) parameters (the generator, modulus, and exponent lengths 3431 and values) for new DH groups. Implementations SHOULD provide a 3432 management interface through which these parameters and the 3433 associated transform IDs may be entered (by a user or system 3434 administrator), to enable negotiating such groups. 3436 All implementations of IKEv2 MUST include a management facility that 3437 enables a user or system administrator to specify the suites that are 3438 acceptable for use with IKE. Upon receipt of a payload with a set of 3439 transform IDs, the implementation MUST compare the transmitted 3440 transform IDs against those locally configured via the management 3441 controls, to verify that the proposed suite is acceptable based on 3442 local policy. The implementation MUST reject SA proposals that are 3443 not authorized by these IKE suite controls. Note that cryptographic 3444 suites that MUST be implemented need not be configured as acceptable 3445 to local policy. 3447 3.3.5. Transform Attributes 3449 Each transform in a Security Association payload may include 3450 attributes that modify or complete the specification of the 3451 transform. The set of valid attributes depends on the transform. 3452 Currently, only a single attribute type is defined: the Key Length 3453 attribute is used by certain encryption transforms with variable- 3454 length keys (see below for details). 3456 The attributes are type/value pairs and are defined below. 3457 Attributes can have a value with a fixed two-octet length or a 3458 variable-length value. For the latter, the attribute is encoded as 3459 type/length/value. 3461 1 2 3 3462 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 3463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3464 |A| Attribute Type | AF=0 Attribute Length | 3465 |F| | AF=1 Attribute Value | 3466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3467 | AF=0 Attribute Value | 3468 | AF=1 Not Transmitted | 3469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3471 Figure 9: Data Attributes 3473 o Attribute Format (AF) (1 bit) - Indicates whether the data 3474 attribute follow the Type/Length/Value (TLV) format or a shortened 3475 Type/Value (TV) format. If the AF bit is zero (0), then the 3476 attribute uses TLV format; if the AF bit is one (1), the TV format 3477 (with two-byte value) is used. 3479 o Attribute Type (15 bits) - Unique identifier for each type of 3480 attribute (see below). 3482 o Attribute Value (variable length) - Value of the Attribute 3483 associated with the Attribute Type. If the AF bit is a zero (0), 3484 this field has a variable length defined by the Attribute Length 3485 field. If the AF bit is a one (1), the Attribute Value has a 3486 length of 2 octets. 3488 Note that the only currently defined attribute type (Key Length) is 3489 fixed length; the variable-length encoding specification is included 3490 only for future extensions. Attributes described as fixed length 3491 MUST NOT be encoded using the variable-length encoding. Variable- 3492 length attributes MUST NOT be encoded as fixed-length even if their 3493 value can fit into two octets. NOTE: This is a change from IKEv1, 3494 where increased flexibility may have simplified the composer of 3495 messages but certainly complicated the parser. 3497 Attribute Type Value Attribute Format 3498 ------------------------------------------------------------ 3499 RESERVED 0-13 3500 Key Length (in bits) 14 TV 3501 RESERVED 15-17 3502 RESERVED TO IANA 18-16383 3503 PRIVATE USE 16384-32767 3505 Values 0-13 and 15-17 were used in a similar context in IKEv1, and 3506 should not be assigned except to matching values. 3508 The Key Length attribute specifies the key length in bits (MUST use 3509 network byte order) for certain transforms as follows: {{ Clarif-7.11 3510 }} 3512 o The Key Length attribute MUST NOT be used with transforms that use 3513 a fixed length key. This includes, e.g., ENCR_DES, ENCR_IDEA, and 3514 all the Type 2 (Pseudo-random function) and Type 3 (Integrity 3515 Algorithm) transforms specified in this document. It is 3516 recommended that future Type 2 or 3 transforms do not use this 3517 attribute. 3519 o Some transforms specify that the Key Length attribute MUST be 3520 always included (omitting the attribute is not allowed, and 3521 proposals not containing it MUST be rejected). This includes, 3522 e.g., ENCR_AES_CBC and ENCR_AES_CTR. 3524 o Some transforms allow variable-length keys, but also specify a 3525 default key length if the attribute is not included. These 3526 transforms include, e.g., ENCR_RC5 and ENCR_BLOWFISH. 3528 Implementation note: To further interoperability and to support 3529 upgrading endpoints independently, implementers of this protocol 3530 SHOULD accept values that they deem to supply greater security. For 3531 instance, if a peer is configured to accept a variable-length cipher 3532 with a key length of X bits and is offered that cipher with a larger 3533 key length, the implementation SHOULD accept the offer if it supports 3534 use of the longer key. 3536 Support of this capability allows a responder to express a concept of 3537 "at least" a certain level of security -- "a key length of _at least_ 3538 X bits for cipher Y". However, as the attribute is always returned 3539 unchanged (see Section 3.3.6), an initiator willing to accept 3540 multiple key lengths has to include multiple transforms with the same 3541 Transform Type, each with different Key Length attribute. 3543 3.3.6. Attribute Negotiation 3545 During security association negotiation initiators present offers to 3546 responders. Responders MUST select a single complete set of 3547 parameters from the offers (or reject all offers if none are 3548 acceptable). If there are multiple proposals, the responder MUST 3549 choose a single proposal. If the selected proposal has multiple 3550 Transforms with the same type, the responder MUST choose a single 3551 one. Any attributes of a selected transform MUST be returned 3552 unmodified. The initiator of an exchange MUST check that the 3553 accepted offer is consistent with one of its proposals, and if not 3554 that response MUST be rejected. 3556 If the responder receives a proposal that contains a Transform Type 3557 it does not understand, or a proposal that is missing a mandatory 3558 Transform Type, it MUST consider this proposal unacceptable; however, 3559 other proposals in the same SA payload are processed as usual. 3560 Similarly, if the responder receives a transform that contains a 3561 Transform Attribute it does not understand, it MUST consider this 3562 transform unacceptable; other transforms with the same Transform Type 3563 are processed as usual. This allows new Transform Types and 3564 Transform Attributes to be defined in the future. 3566 Negotiating Diffie-Hellman groups presents some special challenges. 3567 SA offers include proposed attributes and a Diffie-Hellman public 3568 number (KE) in the same message. If in the initial exchange the 3569 initiator offers to use one of several Diffie-Hellman groups, it 3570 SHOULD pick the one the responder is most likely to accept and 3571 include a KE corresponding to that group. If the guess turns out to 3572 be wrong, the responder will indicate the correct group in the 3573 response and the initiator SHOULD pick an element of that group for 3574 its KE value when retrying the first message. It SHOULD, however, 3575 continue to propose its full supported set of groups in order to 3576 prevent a man-in-the-middle downgrade attack. 3578 3.4. Key Exchange Payload 3580 The Key Exchange Payload, denoted KE in this memo, is used to 3581 exchange Diffie-Hellman public numbers as part of a Diffie-Hellman 3582 key exchange. The Key Exchange Payload consists of the IKE generic 3583 payload header followed by the Diffie-Hellman public value itself. 3585 1 2 3 3586 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 3587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3588 | Next Payload |C| RESERVED | Payload Length | 3589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3590 | DH Group # | RESERVED | 3591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3592 | | 3593 ~ Key Exchange Data ~ 3594 | | 3595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3597 Figure 10: Key Exchange Payload Format 3599 A key exchange payload is constructed by copying one's Diffie-Hellman 3600 public value into the "Key Exchange Data" portion of the payload. 3601 The length of the Diffie-Hellman public value MUST be equal to the 3602 length of the prime modulus over which the exponentiation was 3603 performed, prepending zero bits to the value if necessary. 3605 The DH Group # identifies the Diffie-Hellman group in which the Key 3606 Exchange Data was computed (see Section 3.3.2. This Group # MUST 3607 match a DH Group specified in a proposal in the SA payload that is 3608 sent in the same message, and SHOULD match the DH group in the first 3609 group in the first proposal, if such exists. If none of the 3610 proposals in that SA payload specifies a DH Group, the KE payload 3611 MUST NOT be present. If the selected proposal uses a different 3612 Diffie-Hellman group (other than NONE), the message MUST be rejected 3613 with a Notify payload of type INVALID_KE_PAYLOAD. 3615 The payload type for the Key Exchange payload is thirty four (34). 3617 3.5. Identification Payloads 3619 The Identification Payloads, denoted IDi and IDr in this memo, allow 3620 peers to assert an identity to one another. This identity may be 3621 used for policy lookup, but does not necessarily have to match 3622 anything in the CERT payload; both fields may be used by an 3623 implementation to perform access control decisions. {{ Clarif-7.1 }} 3624 When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr 3625 payloads, IKEv2 does not require this address to match the address in 3626 the IP header of IKEv2 packets, or anything in the TSi/TSr payloads. 3627 The contents of IDi/IDr is used purely to fetch the policy and 3628 authentication data related to the other party. 3630 NOTE: In IKEv1, two ID payloads were used in each direction to hold 3631 Traffic Selector (TS) information for data passing over the SA. In 3632 IKEv2, this information is carried in TS payloads (see Section 3.13). 3634 The Identification Payload consists of the IKE generic payload header 3635 followed by identification fields as follows: 3637 1 2 3 3638 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 3639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3640 | Next Payload |C| RESERVED | Payload Length | 3641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3642 | ID Type | RESERVED | 3643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3644 | | 3645 ~ Identification Data ~ 3646 | | 3647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3649 Figure 11: Identification Payload Format 3651 o ID Type (1 octet) - Specifies the type of Identification being 3652 used. 3654 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 3656 o Identification Data (variable length) - Value, as indicated by the 3657 Identification Type. The length of the Identification Data is 3658 computed from the size in the ID payload header. 3660 The payload types for the Identification Payload are thirty five (35) 3661 for IDi and thirty six (36) for IDr. 3663 The following table lists the assigned values for the Identification 3664 Type field: 3666 ID Type Value 3667 ------------------------------------------------------------------- 3668 RESERVED 0 3670 ID_IPV4_ADDR 1 3671 A single four (4) octet IPv4 address. 3673 ID_FQDN 2 3674 A fully-qualified domain name string. An example of a ID_FQDN 3675 is, "example.com". The string MUST not contain any terminators 3676 (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; 3677 for an "internationalized domain name", the syntax is as defined 3678 in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net". 3680 ID_RFC822_ADDR 3 3681 A fully-qualified RFC822 email address string, An example of a 3682 ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not 3683 contain any terminators. Because of [EAI], implementations would 3684 be wise to treat this field as UTF-8 encoded text, not as 3685 pure ASCII. 3687 RESERVED TO IANA 4 3689 ID_IPV6_ADDR 5 3690 A single sixteen (16) octet IPv6 address. 3692 RESERVED TO IANA 6 - 8 3694 ID_DER_ASN1_DN 9 3695 The binary Distinguished Encoding Rules (DER) encoding of an 3696 ASN.1 X.500 Distinguished Name [X.501]. 3698 ID_DER_ASN1_GN 10 3699 The binary DER encoding of an ASN.1 X.500 GeneralName [X.509]. 3701 ID_KEY_ID 11 3702 An opaque octet stream which may be used to pass vendor- 3703 specific information necessary to do certain proprietary 3704 types of identification. 3706 RESERVED TO IANA 12-200 3708 PRIVATE USE 201-255 3710 Two implementations will interoperate only if each can generate a 3711 type of ID acceptable to the other. To assure maximum 3712 interoperability, implementations MUST be configurable to send at 3713 least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and 3714 MUST be configurable to accept all of these types. Implementations 3715 SHOULD be capable of generating and accepting all of these types. 3716 IPv6-capable implementations MUST additionally be configurable to 3717 accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable 3718 to send only ID_IPV6_ADDR. 3720 {{ Clarif-3.4 }} EAP [EAP] does not mandate the use of any particular 3721 type of identifier, but often EAP is used with Network Access 3722 Identifiers (NAIs) defined in [NAI]. Although NAIs look a bit like 3723 email addresses (e.g., "joe@example.com"), the syntax is not exactly 3724 the same as the syntax of email address in [MAILFORMAT]. For those 3725 NAIs that include the realm component, the ID_RFC822_ADDR 3726 identification type SHOULD be used. Responder implementations should 3727 not attempt to verify that the contents actually conform to the exact 3728 syntax given in [MAILFORMAT], but instead should accept any 3729 reasonable-looking NAI. For NAIs that do not include the realm 3730 component,the ID_KEY_ID identification type SHOULD be used. 3732 3.6. Certificate Payload 3734 The Certificate Payload, denoted CERT in this memo, provides a means 3735 to transport certificates or other authentication-related information 3736 via IKE. Certificate payloads SHOULD be included in an exchange if 3737 certificates are available to the sender unless the peer has 3738 indicated an ability to retrieve this information from elsewhere 3739 using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the 3740 term "Certificate Payload" is somewhat misleading, because not all 3741 authentication mechanisms use certificates and data other than 3742 certificates may be passed in this payload. 3744 The Certificate Payload is defined as follows: 3746 1 2 3 3747 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 3748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3749 | Next Payload |C| RESERVED | Payload Length | 3750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3751 | Cert Encoding | | 3752 +-+-+-+-+-+-+-+-+ | 3753 ~ Certificate Data ~ 3754 | | 3755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3757 Figure 12: Certificate Payload Format 3759 o Certificate Encoding (1 octet) - This field indicates the type of 3760 certificate or certificate-related information contained in the 3761 Certificate Data field. 3763 Certificate Encoding Value 3764 ---------------------------------------------------- 3765 RESERVED 0 3766 PKCS #7 wrapped X.509 certificate 1 UNSPECIFIED 3767 PGP Certificate 2 UNSPECIFIED 3768 DNS Signed Key 3 UNSPECIFIED 3769 X.509 Certificate - Signature 4 3770 Kerberos Token 6 UNSPECIFIED 3771 Certificate Revocation List (CRL) 7 3772 Authority Revocation List (ARL) 8 UNSPECIFIED 3773 SPKI Certificate 9 UNSPECIFIED 3774 X.509 Certificate - Attribute 10 UNSPECIFIED 3775 Raw RSA Key 11 3776 Hash and URL of X.509 certificate 12 3777 Hash and URL of X.509 bundle 13 3778 RESERVED to IANA 14 - 200 3779 PRIVATE USE 201 - 255 3781 o Certificate Data (variable length) - Actual encoding of 3782 certificate data. The type of certificate is indicated by the 3783 Certificate Encoding field. 3785 The payload type for the Certificate Payload is thirty seven (37). 3787 Specific syntax for some of the certificate type codes above is not 3788 defined in this document. The types whose syntax is defined in this 3789 document are: 3791 o X.509 Certificate - Signature (4) contains a DER encoded X.509 3792 certificate whose public key is used to validate the sender's AUTH 3793 payload. 3795 o Certificate Revocation List (7) contains a DER encoded X.509 3796 certificate revocation list. 3798 o {{ Added "DER-encoded RSAPublicKey structure" from Clarif-3.6 }} 3799 Raw RSA Key (11) contains a PKCS #1 encoded RSA key, that is, a 3800 DER-encoded RSAPublicKey structure (see [RSA] and [PKCS1]). 3802 o Hash and URL encodings (12-13) allow IKE messages to remain short 3803 by replacing long data structures with a 20 octet SHA-1 hash (see 3804 [SHA]) of the replaced value followed by a variable-length URL 3805 that resolves to the DER encoded data structure itself. This 3806 improves efficiency when the endpoints have certificate data 3807 cached and makes IKE less subject to denial of service attacks 3808 that become easier to mount when IKE messages are large enough to 3809 require IP fragmentation [DOSUDPPROT]. 3811 Use the following ASN.1 definition for an X.509 bundle: 3813 CertBundle 3814 { iso(1) identified-organization(3) dod(6) internet(1) 3815 security(5) mechanisms(5) pkix(7) id-mod(0) 3816 id-mod-cert-bundle(34) } 3818 DEFINITIONS EXPLICIT TAGS ::= 3819 BEGIN 3821 IMPORTS 3822 Certificate, CertificateList 3823 FROM PKIX1Explicit88 3824 { iso(1) identified-organization(3) dod(6) 3825 internet(1) security(5) mechanisms(5) pkix(7) 3826 id-mod(0) id-pkix1-explicit(18) } ; 3828 CertificateOrCRL ::= CHOICE { 3829 cert [0] Certificate, 3830 crl [1] CertificateList } 3832 CertificateBundle ::= SEQUENCE OF CertificateOrCRL 3834 END 3836 Implementations MUST be capable of being configured to send and 3837 accept up to four X.509 certificates in support of authentication, 3838 and also MUST be capable of being configured to send and accept the 3839 two Hash and URL formats (with HTTP URLs). Implementations SHOULD be 3840 capable of being configured to send and accept Raw RSA keys. If 3841 multiple certificates are sent, the first certificate MUST contain 3842 the public key used to sign the AUTH payload. The other certificates 3843 may be sent in any order. 3845 3.7. Certificate Request Payload 3847 The Certificate Request Payload, denoted CERTREQ in this memo, 3848 provides a means to request preferred certificates via IKE and can 3849 appear in the IKE_INIT_SA response and/or the IKE_AUTH request. 3850 Certificate Request payloads MAY be included in an exchange when the 3851 sender needs to get the certificate of the receiver. If multiple CAs 3852 are trusted and the certificate encoding does not allow a list, then 3853 multiple Certificate Request payloads would need to be transmitted. 3855 The Certificate Request Payload is defined as follows: 3857 1 2 3 3858 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 3859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3860 | Next Payload |C| RESERVED | Payload Length | 3861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3862 | Cert Encoding | | 3863 +-+-+-+-+-+-+-+-+ | 3864 ~ Certification Authority ~ 3865 | | 3866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3868 Figure 13: Certificate Request Payload Format 3870 o Certificate Encoding (1 octet) - Contains an encoding of the type 3871 or format of certificate requested. Values are listed in 3872 Section 3.6. 3874 o Certification Authority (variable length) - Contains an encoding 3875 of an acceptable certification authority for the type of 3876 certificate requested. 3878 The payload type for the Certificate Request Payload is thirty eight 3879 (38). 3881 The Certificate Encoding field has the same values as those defined 3882 in Section 3.6. The Certification Authority field contains an 3883 indicator of trusted authorities for this certificate type. The 3884 Certification Authority value is a concatenated list of SHA-1 hashes 3885 of the public keys of trusted Certification Authorities (CAs). Each 3886 is encoded as the SHA-1 hash of the Subject Public Key Info element 3887 (see section 4.1.2.7 of [PKIX]) from each Trust Anchor certificate. 3888 The twenty-octet hashes are concatenated and included with no other 3889 formatting. 3891 {{ Clarif-3.6 }} The contents of the "Certification Authority" field 3892 are defined only for X.509 certificates, which are types 4, 10, 12, 3893 and 13. Other values SHOULD NOT be used until standards-track 3894 specifications that specify their use are published. 3896 Note that the term "Certificate Request" is somewhat misleading, in 3897 that values other than certificates are defined in a "Certificate" 3898 payload and requests for those values can be present in a Certificate 3899 Request Payload. The syntax of the Certificate Request payload in 3900 such cases is not defined in this document. 3902 The Certificate Request Payload is processed by inspecting the "Cert 3903 Encoding" field to determine whether the processor has any 3904 certificates of this type. If so, the "Certification Authority" 3905 field is inspected to determine if the processor has any certificates 3906 that can be validated up to one of the specified certification 3907 authorities. This can be a chain of certificates. 3909 If an end-entity certificate exists that satisfies the criteria 3910 specified in the CERTREQ, a certificate or certificate chain SHOULD 3911 be sent back to the certificate requestor if the recipient of the 3912 CERTREQ: 3914 o is configured to use certificate authentication, 3916 o is allowed to send a CERT payload, 3918 o has matching CA trust policy governing the current negotiation, 3919 and 3921 o has at least one time-wise and usage appropriate end-entity 3922 certificate chaining to a CA provided in the CERTREQ. 3924 Certificate revocation checking must be considered during the 3925 chaining process used to select a certificate. Note that even if two 3926 peers are configured to use two different CAs, cross-certification 3927 relationships should be supported by appropriate selection logic. 3929 The intent is not to prevent communication through the strict 3930 adherence of selection of a certificate based on CERTREQ, when an 3931 alternate certificate could be selected by the sender that would 3932 still enable the recipient to successfully validate and trust it 3933 through trust conveyed by cross-certification, CRLs, or other out-of- 3934 band configured means. Thus, the processing of a CERTREQ should be 3935 seen as a suggestion for a certificate to select, not a mandated one. 3936 If no certificates exist, then the CERTREQ is ignored. This is not 3937 an error condition of the protocol. There may be cases where there 3938 is a preferred CA sent in the CERTREQ, but an alternate might be 3939 acceptable (perhaps after prompting a human operator). 3941 {{ 3.10.1-16392 }} The HTTP_CERT_LOOKUP_SUPPORTED notification MAY be 3942 included in any message that can include a CERTREQ payload and 3943 indicates that the sender is capable of looking up certificates based 3944 on an HTTP-based URL (and hence presumably would prefer to receive 3945 certificate specifications in that format). 3947 3.8. Authentication Payload 3949 The Authentication Payload, denoted AUTH in this memo, contains data 3950 used for authentication purposes. The syntax of the Authentication 3951 data varies according to the Auth Method as specified below. 3953 The Authentication Payload is defined as follows: 3955 1 2 3 3956 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 3957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3958 | Next Payload |C| RESERVED | Payload Length | 3959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3960 | Auth Method | RESERVED | 3961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3962 | | 3963 ~ Authentication Data ~ 3964 | | 3965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3967 Figure 14: Authentication Payload Format 3969 o Auth Method (1 octet) - Specifies the method of authentication 3970 used. Values defined are: 3972 * RSA Digital Signature (1) - Computed as specified in 3973 Section 2.15 using an RSA private key with RSASSA-PKCS1-v1_5 3974 signature scheme specified in [PKCS1] (implementors should note 3975 that IKEv1 used a different method for RSA signatures) {{ 3976 Clarif-3.3 }}. {{ Clarif-3.2 }} To promote interoperability, 3977 implementations that support this type SHOULD support 3978 signatures that use SHA-1 as the hash function and SHOULD use 3979 SHA-1 as the default hash function when generating signatures. 3981 * Shared Key Message Integrity Code (2) - Computed as specified 3982 in Section 2.15 using the shared key associated with the 3983 identity in the ID payload and the negotiated prf function 3985 * DSS Digital Signature (3) - Computed as specified in 3986 Section 2.15 using a DSS private key (see [DSS]) over a SHA-1 3987 hash. 3989 * The values 0 and 4-200 are reserved to IANA. The values 201- 3990 255 are available for private use. 3992 o Authentication Data (variable length) - see Section 2.15. 3994 The payload type for the Authentication Payload is thirty nine (39). 3996 3.9. Nonce Payload 3998 The Nonce Payload, denoted Ni and Nr in this memo for the initiator's 3999 and responder's nonce respectively, contains random data used to 4000 guarantee liveness during an exchange and protect against replay 4001 attacks. 4003 The Nonce Payload is defined as follows: 4005 1 2 3 4006 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 4007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4008 | Next Payload |C| RESERVED | Payload Length | 4009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4010 | | 4011 ~ Nonce Data ~ 4012 | | 4013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4015 Figure 15: Nonce Payload Format 4017 o Nonce Data (variable length) - Contains the random data generated 4018 by the transmitting entity. 4020 The payload type for the Nonce Payload is forty (40). 4022 The size of a Nonce MUST be between 16 and 256 octets inclusive. 4023 Nonce values MUST NOT be reused. 4025 3.10. Notify Payload 4027 The Notify Payload, denoted N in this document, is used to transmit 4028 informational data, such as error conditions and state transitions, 4029 to an IKE peer. A Notify Payload may appear in a response message 4030 (usually specifying why a request was rejected), in an INFORMATIONAL 4031 Exchange (to report an error not in an IKE request), or in any other 4032 message to indicate sender capabilities or to modify the meaning of 4033 the request. 4035 The Notify Payload is defined as follows: 4037 1 2 3 4038 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 4039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4040 | Next Payload |C| RESERVED | Payload Length | 4041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4042 | Protocol ID | SPI Size | Notify Message Type | 4043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4044 | | 4045 ~ Security Parameter Index (SPI) ~ 4046 | | 4047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4048 | | 4049 ~ Notification Data ~ 4050 | | 4051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4053 Figure 16: Notify Payload Format 4055 o Protocol ID (1 octet) - If this notification concerns an existing 4056 SA whose SPI is given the SPI field, this field indicates the type 4057 of that SA. For notifications concerning IPsec SAs this field 4058 MUST contain either (2) to indicate AH or (3) to indicate ESP. {{ 4059 Clarif-7.8 }} Of the notifications defined in this document, the 4060 SPI is included only with INVALID_SELECTORS and REKEY_SA. If the 4061 SPI field is empty, this field MUST be sent as zero and MUST be 4062 ignored on receipt. All other values for this field are reserved 4063 to IANA for future assignment. 4065 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 4066 IPsec protocol ID or zero if no SPI is applicable. For a 4067 notification concerning the IKE SA, the SPI Size MUST be zero and 4068 the field must be empty. 4070 o Notify Message Type (2 octets) - Specifies the type of 4071 notification message. 4073 o SPI (variable length) - Security Parameter Index. 4075 o Notification Data (variable length) - Informational or error data 4076 transmitted in addition to the Notify Message Type. Values for 4077 this field are type specific (see below). 4079 The payload type for the Notify Payload is forty one (41). 4081 3.10.1. Notify Message Types 4083 Notification information can be error messages specifying why an SA 4084 could not be established. It can also be status data that a process 4085 managing an SA database wishes to communicate with a peer process. 4086 The table below lists the Notification messages and their 4087 corresponding values. The number of different error statuses was 4088 greatly reduced from IKEv1 both for simplification and to avoid 4089 giving configuration information to probers. 4091 Types in the range 0 - 16383 are intended for reporting errors. An 4092 implementation receiving a Notify payload with one of these types 4093 that it does not recognize in a response MUST assume that the 4094 corresponding request has failed entirely. {{ Demoted the SHOULD }} 4095 Unrecognized error types in a request and status types in a request 4096 or response MUST be ignored, and they should be logged. 4098 Notify payloads with status types MAY be added to any message and 4099 MUST be ignored if not recognized. They are intended to indicate 4100 capabilities, and as part of SA negotiation are used to negotiate 4101 non-cryptographic parameters. 4103 NOTIFY messages: error types Value 4104 ------------------------------------------------------------------- 4106 RESERVED 0 4108 UNSUPPORTED_CRITICAL_PAYLOAD 1 4109 See Section 2.5. 4111 INVALID_IKE_SPI 4 4112 See Section 2.21. 4114 INVALID_MAJOR_VERSION 5 4115 See Section 2.5. 4117 INVALID_SYNTAX 7 4118 Indicates the IKE message that was received was invalid because 4119 some type, length, or value was out of range or because the 4120 request was rejected for policy reasons. To avoid a denial of 4121 service attack using forged messages, this status may only be 4122 returned for and in an encrypted packet if the message ID and 4123 cryptographic checksum were valid. To avoid leaking information 4124 to someone probing a node, this status MUST be sent in response 4125 to any error not covered by one of the other status types. 4126 {{ Demoted the SHOULD }} To aid debugging, more detailed error 4127 information should be written to a console or log. 4129 INVALID_MESSAGE_ID 9 4130 See Section 2.3. 4132 INVALID_SPI 11 4133 See Section 1.5. 4135 NO_PROPOSAL_CHOSEN 14 4136 None of the proposed crypto suites was acceptable. This can be 4137 sent in any case where the offered proposal (including but not 4138 limited to SA payload values, USE_TRANSPORT_MODE notify, 4139 IPCOMP_SUPPORTED notify) are not acceptable for the responder. 4140 This can also be used as "generic" Child SA error when Child SA 4141 cannot be created for some other reason. See also Section 2.7. 4143 INVALID_KE_PAYLOAD 17 4144 See Section 1.3. 4146 AUTHENTICATION_FAILED 24 4147 Sent in the response to an IKE_AUTH message when for some reason 4148 the authentication failed. There is no associated data. 4150 SINGLE_PAIR_REQUIRED 34 4151 See Section 2.9. 4153 NO_ADDITIONAL_SAS 35 4154 See Section 1.3. 4156 INTERNAL_ADDRESS_FAILURE 36 4157 See Section 3.15.4. 4159 FAILED_CP_REQUIRED 37 4160 See Section 2.19. 4162 TS_UNACCEPTABLE 38 4163 See Section 2.9. 4165 INVALID_SELECTORS 39 4166 MAY be sent in an IKE INFORMATIONAL exchange when a node receives 4167 an ESP or AH packet whose selectors do not match those of the SA 4168 on which it was delivered (and that caused the packet to be 4169 dropped). The Notification Data contains the start of the 4170 offending packet (as in ICMP messages) and the SPI field of the 4171 notification is set to match the SPI of the IPsec SA. 4173 RESERVED TO IANA 40-8191 4175 PRIVATE USE 8192-16383 4176 NOTIFY messages: status types Value 4177 ------------------------------------------------------------------- 4179 INITIAL_CONTACT 16384 4180 See Section 2.4. 4182 SET_WINDOW_SIZE 16385 4183 See Section 2.3. 4185 ADDITIONAL_TS_POSSIBLE 16386 4186 See Section 2.9. 4188 IPCOMP_SUPPORTED 16387 4189 See Section 2.22. 4191 NAT_DETECTION_SOURCE_IP 16388 4192 See Section 2.23. 4194 NAT_DETECTION_DESTINATION_IP 16389 4195 See Section 2.23. 4197 COOKIE 16390 4198 See Section 2.6. 4200 USE_TRANSPORT_MODE 16391 4201 See Section 1.3.1. 4203 HTTP_CERT_LOOKUP_SUPPORTED 16392 4204 See Section 3.6. 4206 REKEY_SA 16393 4207 See Section 1.3.3. 4209 ESP_TFC_PADDING_NOT_SUPPORTED 16394 4210 See Section 1.3.1. 4212 NON_FIRST_FRAGMENTS_ALSO 16395 4213 See Section 1.3.1. 4215 RESERVED TO IANA 16396-40959 4217 PRIVATE USE 40960-65535 4219 3.11. Delete Payload 4221 The Delete Payload, denoted D in this memo, contains a protocol 4222 specific security association identifier that the sender has removed 4223 from its security association database and is, therefore, no longer 4224 valid. Figure 17 shows the format of the Delete Payload. It is 4225 possible to send multiple SPIs in a Delete payload; however, each SPI 4226 MUST be for the same protocol. Mixing of protocol identifiers MUST 4227 NOT be performed in the Delete payload. It is permitted, however, to 4228 include multiple Delete payloads in a single INFORMATIONAL exchange 4229 where each Delete payload lists SPIs for a different protocol. 4231 Deletion of the IKE SA is indicated by a protocol ID of 1 (IKE) but 4232 no SPIs. Deletion of a Child SA, such as ESP or AH, will contain the 4233 IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI 4234 is the SPI the sending endpoint would expect in inbound ESP or AH 4235 packets. 4237 The Delete Payload is defined as follows: 4239 1 2 3 4240 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 4241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4242 | Next Payload |C| RESERVED | Payload Length | 4243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4244 | Protocol ID | SPI Size | # of SPIs | 4245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4246 | | 4247 ~ Security Parameter Index(es) (SPI) ~ 4248 | | 4249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4251 Figure 17: Delete Payload Format 4253 o Protocol ID (1 octet) - Must be 1 for an IKE SA, 2 for AH, or 3 4254 for ESP. 4256 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 4257 protocol ID. It MUST be zero for IKE (SPI is in message header) 4258 or four for AH and ESP. 4260 o # of SPIs (2 octets) - The number of SPIs contained in the Delete 4261 payload. The size of each SPI is defined by the SPI Size field. 4263 o Security Parameter Index(es) (variable length) - Identifies the 4264 specific security association(s) to delete. The length of this 4265 field is determined by the SPI Size and # of SPIs fields. 4267 The payload type for the Delete Payload is forty two (42). 4269 3.12. Vendor ID Payload 4271 The Vendor ID Payload, denoted V in this memo, contains a vendor 4272 defined constant. The constant is used by vendors to identify and 4273 recognize remote instances of their implementations. This mechanism 4274 allows a vendor to experiment with new features while maintaining 4275 backward compatibility. 4277 A Vendor ID payload MAY announce that the sender is capable of 4278 accepting certain extensions to the protocol, or it MAY simply 4279 identify the implementation as an aid in debugging. A Vendor ID 4280 payload MUST NOT change the interpretation of any information defined 4281 in this specification (i.e., the critical bit MUST be set to 0). 4282 Multiple Vendor ID payloads MAY be sent. An implementation is NOT 4283 REQUIRED to send any Vendor ID payload at all. 4285 A Vendor ID payload may be sent as part of any message. Reception of 4286 a familiar Vendor ID payload allows an implementation to make use of 4287 Private USE numbers described throughout this memo-- private 4288 payloads, private exchanges, private notifications, etc. Unfamiliar 4289 Vendor IDs MUST be ignored. 4291 Writers of Internet-Drafts who wish to extend this protocol MUST 4292 define a Vendor ID payload to announce the ability to implement the 4293 extension in the Internet-Draft. It is expected that Internet-Drafts 4294 that gain acceptance and are standardized will be given "magic 4295 numbers" out of the Future Use range by IANA, and the requirement to 4296 use a Vendor ID will go away. 4298 The Vendor ID Payload fields are defined as follows: 4300 1 2 3 4301 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 4302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4303 | Next Payload |C| RESERVED | Payload Length | 4304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4305 | | 4306 ~ Vendor ID (VID) ~ 4307 | | 4308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4310 Figure 18: Vendor ID Payload Format 4312 o Vendor ID (variable length) - It is the responsibility of the 4313 person choosing the Vendor ID to assure its uniqueness in spite of 4314 the absence of any central registry for IDs. Good practice is to 4315 include a company name, a person name, or some such. If you want 4316 to show off, you might include the latitude and longitude and time 4317 where you were when you chose the ID and some random input. A 4318 message digest of a long unique string is preferable to the long 4319 unique string itself. 4321 The payload type for the Vendor ID Payload is forty three (43). 4323 3.13. Traffic Selector Payload 4325 The Traffic Selector Payload, denoted TS in this memo, allows peers 4326 to identify packet flows for processing by IPsec security services. 4327 The Traffic Selector Payload consists of the IKE generic payload 4328 header followed by individual traffic selectors as follows: 4330 1 2 3 4331 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 4332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4333 | Next Payload |C| RESERVED | Payload Length | 4334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4335 | Number of TSs | RESERVED | 4336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4337 | | 4338 ~ ~ 4339 | | 4340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4342 Figure 19: Traffic Selectors Payload Format 4344 o Number of TSs (1 octet) - Number of traffic selectors being 4345 provided. 4347 o RESERVED - This field MUST be sent as zero and MUST be ignored on 4348 receipt. 4350 o Traffic Selectors (variable length) - One or more individual 4351 traffic selectors. 4353 The length of the Traffic Selector payload includes the TS header and 4354 all the traffic selectors. 4356 The payload type for the Traffic Selector payload is forty four (44) 4357 for addresses at the initiator's end of the SA and forty five (45) 4358 for addresses at the responder's end. 4360 {{ Clarif-4.7 }} There is no requirement that TSi and TSr contain the 4361 same number of individual traffic selectors. Thus, they are 4362 interpreted as follows: a packet matches a given TSi/TSr if it 4363 matches at least one of the individual selectors in TSi, and at least 4364 one of the individual selectors in TSr. 4366 For instance, the following traffic selectors: 4368 TSi = ((17, 100, 192.0.1.66-192.0.1.66), 4369 (17, 200, 192.0.1.66-192.0.1.66)) 4370 TSr = ((17, 300, 0.0.0.0-255.255.255.255), 4371 (17, 400, 0.0.0.0-255.255.255.255)) 4373 would match UDP packets from 192.0.1.66 to anywhere, with any of the 4374 four combinations of source/destination ports (100,300), (100,400), 4375 (200,300), and (200, 400). 4377 Thus, some types of policies may require several Child SA pairs. For 4378 instance, a policy matching only source/destination ports (100,300) 4379 and (200,400), but not the other two combinations, cannot be 4380 negotiated as a single Child SA pair. 4382 3.13.1. Traffic Selector 4384 1 2 3 4385 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 4386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4387 | TS Type |IP Protocol ID*| Selector Length | 4388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4389 | Start Port* | End Port* | 4390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4391 | | 4392 ~ Starting Address* ~ 4393 | | 4394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4395 | | 4396 ~ Ending Address* ~ 4397 | | 4398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4400 Figure 20: Traffic Selector 4402 *Note: All fields other than TS Type and Selector Length depend on 4403 the TS Type. The fields shown are for TS Types 7 and 8, the only two 4404 values currently defined. 4406 o TS Type (one octet) - Specifies the type of traffic selector. 4408 o IP protocol ID (1 octet) - Value specifying an associated IP 4409 protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that the 4410 protocol ID is not relevant to this traffic selector-- the SA can 4411 carry all protocols. 4413 o Selector Length - Specifies the length of this Traffic Selector 4414 Substructure including the header. 4416 o Start Port (2 octets) - Value specifying the smallest port number 4417 allowed by this Traffic Selector. For protocols for which port is 4418 undefined (including protocol 0), or if all ports are allowed, 4419 this field MUST be zero. For the ICMP protocol, the two one-octet 4420 fields Type and Code are treated as a single 16-bit integer (with 4421 Type in the most significant eight bits and Code in the least 4422 significant eight bits) port number for the purposes of filtering 4423 based on this field. 4425 o End Port (2 octets) - Value specifying the largest port number 4426 allowed by this Traffic Selector. For protocols for which port is 4427 undefined (including protocol 0), or if all ports are allowed, 4428 this field MUST be 65535. For the ICMP protocol, the two one- 4429 octet fields Type and Code are treated as a single 16-bit integer 4430 (with Type in the most significant eight bits and Code in the 4431 least significant eight bits) port number for the purposed of 4432 filtering based on this field. 4434 o Starting Address - The smallest address included in this Traffic 4435 Selector (length determined by TS type). 4437 o Ending Address - The largest address included in this Traffic 4438 Selector (length determined by TS type). 4440 Systems that are complying with [IPSECARCH] that wish to indicate 4441 "ANY" ports MUST set the start port to 0 and the end port to 65535; 4442 note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems 4443 working with [IPSECARCH] that wish to indicate "OPAQUE" ports, but 4444 not "ANY" ports, MUST set the start port to 65535 and the end port to 4445 0. 4447 {{ Added from Clarif-4.8 }} The traffic selector types 7 and 8 can 4448 also refer to ICMP type and code fields. Note, however, that ICMP 4449 packets do not have separate source and destination port fields. The 4450 method for specifying the traffic selectors for ICMP is shown by 4451 example in Section 4.4.1.3 of [IPSECARCH]. 4453 {{ Added from Clarif-4.9 }} Traffic selectors can use IP Protocol ID 4454 135 to match the IPv6 mobility header [MIPV6]. This document does 4455 not specify how to represent the "MH Type" field in traffic 4456 selectors, although it is likely that a different document will 4457 specify this in the future. Note that [IPSECARCH] says that the IPv6 4458 mobility header (MH) message type is placed in the most significant 4459 eight bits of the 16-bit local port selector. The direction 4460 semantics of TSi/TSr port fields are the same as for ICMP. 4462 The following table lists the assigned values for the Traffic 4463 Selector Type field and the corresponding Address Selector Data. 4465 TS Type Value 4466 ------------------------------------------------------------------- 4467 RESERVED 0-6 4469 TS_IPV4_ADDR_RANGE 7 4471 A range of IPv4 addresses, represented by two four-octet 4472 values. The first value is the beginning IPv4 address 4473 (inclusive) and the second value is the ending IPv4 address 4474 (inclusive). All addresses falling between the two specified 4475 addresses are considered to be within the list. 4477 TS_IPV6_ADDR_RANGE 8 4479 A range of IPv6 addresses, represented by two sixteen-octet 4480 values. The first value is the beginning IPv6 address 4481 (inclusive) and the second value is the ending IPv6 address 4482 (inclusive). All addresses falling between the two specified 4483 addresses are considered to be within the list. 4485 RESERVED TO IANA 9-240 4486 PRIVATE USE 241-255 4488 3.14. Encrypted Payload 4490 The Encrypted Payload, denoted SK{...} or E in this memo, contains 4491 other payloads in encrypted form. The Encrypted Payload, if present 4492 in a message, MUST be the last payload in the message. Often, it is 4493 the only payload in the message. 4495 The algorithms for encryption and integrity protection are negotiated 4496 during IKE SA setup, and the keys are computed as specified in 4497 Section 2.14 and Section 2.18. 4499 This document specifies the cryptographic processing of Encrypted 4500 payloads using a block cipher in CBC mode and an integrity check 4501 algorithm that computes a fixed-length checksum over a variable size 4502 message. The design is modeled after the ESP algorithms described in 4503 RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document 4504 completely specifies the cryptographic processing of IKE data, but 4505 those documents should be consulted for design rationale. Future 4506 documents may specify the processing of Encrypted payloads for other 4507 types of transforms, such as counter mode encryption and 4508 authenticated encryption algorithms. Peers MUST NOT negotiate 4509 transforms for which no such specification exists. 4511 The payload type for an Encrypted payload is forty six (46). The 4512 Encrypted Payload consists of the IKE generic payload header followed 4513 by individual fields as follows: 4515 1 2 3 4516 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 4517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4518 | Next Payload |C| RESERVED | Payload Length | 4519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4520 | Initialization Vector | 4521 | (length is block size for encryption algorithm) | 4522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4523 ~ Encrypted IKE Payloads ~ 4524 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4525 | | Padding (0-255 octets) | 4526 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 4527 | | Pad Length | 4528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4529 ~ Integrity Checksum Data ~ 4530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4532 Figure 21: Encrypted Payload Format 4534 o Next Payload - The payload type of the first embedded payload. 4535 Note that this is an exception in the standard header format, 4536 since the Encrypted payload is the last payload in the message and 4537 therefore the Next Payload field would normally be zero. But 4538 because the content of this payload is embedded payloads and there 4539 was no natural place to put the type of the first one, that type 4540 is placed here. 4542 o Payload Length - Includes the lengths of the header, IV, Encrypted 4543 IKE Payloads, Padding, Pad Length, and Integrity Checksum Data. 4545 o Initialization Vector - For CBC mode ciphers, the length of the 4546 initialization vector (IV) is equal to the block length of the 4547 underlying encryption algorithm. Senders MUST select a new 4548 unpredictable IV for every message; recipients MUST accept any 4549 value. The reader is encouraged to consult [MODES] for advice on 4550 IV generation. In particular, using the final ciphertext block of 4551 the previous message is not considered unpredictable. For modes 4552 other than CBC, the IV format and processing is specified in the 4553 document specifying the encryption algorithm and mode. 4555 o IKE Payloads are as specified earlier in this section. This field 4556 is encrypted with the negotiated cipher. 4558 o Padding MAY contain any value chosen by the sender, and MUST have 4559 a length that makes the combination of the Payloads, the Padding, 4560 and the Pad Length to be a multiple of the encryption block size. 4561 This field is encrypted with the negotiated cipher. 4563 o Pad Length is the length of the Padding field. The sender SHOULD 4564 set the Pad Length to the minimum value that makes the combination 4565 of the Payloads, the Padding, and the Pad Length a multiple of the 4566 block size, but the recipient MUST accept any length that results 4567 in proper alignment. This field is encrypted with the negotiated 4568 cipher. 4570 o Integrity Checksum Data is the cryptographic checksum of the 4571 entire message starting with the Fixed IKE Header through the Pad 4572 Length. The checksum MUST be computed over the encrypted message. 4573 Its length is determined by the integrity algorithm negotiated. 4575 3.15. Configuration Payload 4577 The Configuration payload, denoted CP in this document, is used to 4578 exchange configuration information between IKE peers. The exchange 4579 is for an IRAC to request an internal IP address from an IRAS and to 4580 exchange other information of the sort that one would acquire with 4581 Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly 4582 connected to a LAN. 4584 The Configuration Payload is defined as follows: 4586 1 2 3 4587 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 4588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4589 | Next Payload |C| RESERVED | Payload Length | 4590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4591 | CFG Type | RESERVED | 4592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4593 | | 4594 ~ Configuration Attributes ~ 4595 | | 4596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4598 Figure 22: Configuration Payload Format 4600 The payload type for the Configuration Payload is forty seven (47). 4602 o CFG Type (1 octet) - The type of exchange represented by the 4603 Configuration Attributes. 4605 CFG Type Value 4606 -------------------------- 4607 RESERVED 0 4608 CFG_REQUEST 1 4609 CFG_REPLY 2 4610 CFG_SET 3 4611 CFG_ACK 4 4612 RESERVED TO IANA 5-127 4613 PRIVATE USE 128-255 4615 o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on 4616 receipt. 4618 o Configuration Attributes (variable length) - These are type length 4619 values specific to the Configuration Payload and are defined 4620 below. There may be zero or more Configuration Attributes in this 4621 payload. 4623 3.15.1. Configuration Attributes 4625 1 2 3 4626 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 4627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4628 |R| Attribute Type | Length | 4629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4630 | | 4631 ~ Value ~ 4632 | | 4633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4635 Figure 23: Configuration Attribute Format 4637 o Reserved (1 bit) - This bit MUST be set to zero and MUST be 4638 ignored on receipt. 4640 o Attribute Type (15 bits) - A unique identifier for each of the 4641 Configuration Attribute Types. 4643 o Length (2 octets) - Length in octets of Value. 4645 o Value (0 or more octets) - The variable-length value of this 4646 Configuration Attribute. The following attribute types have been 4647 defined: 4649 Multi- 4650 Attribute Type Value Valued Length 4651 ------------------------------------------------------- 4652 RESERVED 0 4653 INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets 4654 INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets 4655 INTERNAL_IP4_DNS 3 YES 0 or 4 octets 4656 INTERNAL_IP4_NBNS 4 YES 0 or 4 octets 4657 RESERVED 5 4658 INTERNAL_IP4_DHCP 6 YES 0 or 4 octets 4659 APPLICATION_VERSION 7 NO 0 or more 4660 INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets 4661 RESERVED 9 4662 INTERNAL_IP6_DNS 10 YES 0 or 16 octets 4663 INTERNAL_IP6_NBNS 11 YES 0 or 16 octets 4664 INTERNAL_IP6_DHCP 12 YES 0 or 16 octets 4665 INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets 4666 SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 4667 INTERNAL_IP6_SUBNET 15 YES 17 octets 4668 RESERVED TO IANA 16-16383 4669 PRIVATE USE 16384-32767 4671 * These attributes may be multi-valued on return only if 4672 multiple values were requested. 4674 o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the 4675 internal network, sometimes called a red node address or private 4676 address and MAY be a private address on the Internet. {{ 4677 Clarif-6.2}} In a request message, the address specified is a 4678 requested address (or a zero-length address if no specific address 4679 is requested). If a specific address is requested, it likely 4680 indicates that a previous connection existed with this address and 4681 the requestor would like to reuse that address. With IPv6, a 4682 requestor MAY supply the low-order address octets it wants to use. 4683 Multiple internal addresses MAY be requested by requesting 4684 multiple internal address attributes. The responder MAY only send 4685 up to the number of addresses requested. The INTERNAL_IP6_ADDRESS 4686 is made up of two fields: the first is a 16-octet IPv6 address, 4687 and the second is a one-octet prefix-length as defined in 4688 [ADDRIPV6]. The requested address is valid until there are no IKE 4689 SAs between the peers. This is described in more detail in 4690 Section 3.15.3. 4692 o INTERNAL_IP4_NETMASK - The internal network's netmask. Only one 4693 netmask is allowed in the request and reply messages (e.g., 4694 255.255.255.0), and it MUST be used only with an 4695 INTERNAL_IP4_ADDRESS attribute. {{ Clarif-6.4 }} 4696 INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the same thing 4697 as INTERNAL_IP4_SUBNET containing the same information ("send 4698 traffic to these addresses through me"), but also implies a link 4699 boundary. For instance, the client could use its own address and 4700 the netmask to calculate the broadcast address of the link. An 4701 empty INTERNAL_IP4_NETMASK attribute can be included in a 4702 CFG_REQUEST to request this information (although the gateway can 4703 send the information even when not requested). Non-empty values 4704 for this attribute in a CFG_REQUEST do not make sense and thus 4705 MUST NOT be included. 4707 o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS 4708 server within the network. Multiple DNS servers MAY be requested. 4709 The responder MAY respond with zero or more DNS server attributes. 4711 o INTERNAL_IP4_NBNS - Specifies an address of a NetBios Name Server 4712 (WINS) within the network. Multiple NBNS servers MAY be 4713 requested. The responder MAY respond with zero or more NBNS 4714 server attributes. 4716 o INTERNAL_IP6_NBNS - {{ Clarif-6.6 }} NetBIOS is not defined for 4717 IPv6; therefore, INTERNAL_IP6_NBNS is also unspecified and is only 4718 retained for compatibility with RFC 4306. 4720 o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send 4721 any internal DHCP requests to the address contained within the 4722 attribute. Multiple DHCP servers MAY be requested. The responder 4723 MAY respond with zero or more DHCP server attributes. 4725 o APPLICATION_VERSION - The version or application information of 4726 the IPsec host. This is a string of printable ASCII characters 4727 that is NOT null terminated. 4729 o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge- 4730 device protects. This attribute is made up of two fields: the 4731 first being an IP address and the second being a netmask. 4732 Multiple sub-networks MAY be requested. The responder MAY respond 4733 with zero or more sub-network attributes. This is discussed in 4734 more detail in Section 3.15.2. 4736 o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute 4737 MUST be zero-length and specifies a query to the responder to 4738 reply back with all of the attributes that it supports. The 4739 response contains an attribute that contains a set of attribute 4740 identifiers each in 2 octets. The length divided by 2 (octets) 4741 would state the number of supported attributes contained in the 4742 response. 4744 o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge- 4745 device protects. This attribute is made up of two fields: the 4746 first is a 16-octet IPv6 address, and the second is a one-octet 4747 prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY 4748 be requested. The responder MAY respond with zero or more sub- 4749 network attributes. This is discussed in more detail in Section 4750 3.15.2. 4752 Note that no recommendations are made in this document as to how an 4753 implementation actually figures out what information to send in a 4754 reply. That is, we do not recommend any specific method of an IRAS 4755 determining which DNS server should be returned to a requesting IRAC. 4757 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET 4759 {{ Section added based on Clarif-6.3 }} 4761 INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets, 4762 ones that need one or more separate SAs, that can be reached through 4763 the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET 4764 attributes may also express the gateway's policy about what traffic 4765 should be sent through the gateway; the client can choose whether 4766 other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is 4767 sent through the gateway or directly to the destination. Thus, 4768 traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET 4769 attributes should be sent through the gateway that announces the 4770 attributes. If there are no existing IPsec SAs whose traffic 4771 selectors cover the address in question, new SAs need to be created. 4773 For instance, if there are two subnets, 192.0.1.0/26 and 4774 192.0.2.0/24, and the client's request contains the following: 4776 CP(CFG_REQUEST) = 4777 INTERNAL_IP4_ADDRESS() 4778 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) 4779 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) 4781 then a valid response could be the following (in which TSr and 4782 INTERNAL_IP4_SUBNET contain the same information): 4784 CP(CFG_REPLY) = 4785 INTERNAL_IP4_ADDRESS(192.0.1.234) 4786 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 4787 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 4788 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 4789 TSr = ((0, 0-65535, 192.0.1.0-192.0.1.63), 4790 (0, 0-65535, 192.0.2.0-192.0.2.255)) 4792 In these cases, the INTERNAL_IP4_SUBNET does not really carry any 4793 useful information. 4795 A different possible reply would have been this: 4797 CP(CFG_REPLY) = 4798 INTERNAL_IP4_ADDRESS(192.0.1.234) 4799 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 4800 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 4801 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 4802 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) 4804 That reply would mean that the client can send all its traffic 4805 through the gateway, but the gateway does not mind if the client 4806 sends traffic not included by INTERNAL_IP4_SUBNET directly to the 4807 destination (without going through the gateway). 4809 A different situation arises if the gateway has a policy that 4810 requires the traffic for the two subnets to be carried in separate 4811 SAs. Then a response like this would indicate to the client that if 4812 it wants access to the second subnet, it needs to create a separate 4813 SA: 4815 CP(CFG_REPLY) = 4816 INTERNAL_IP4_ADDRESS(192.0.1.234) 4817 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 4818 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 4819 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 4820 TSr = (0, 0-65535, 192.0.1.0-192.0.1.63) 4822 INTERNAL_IP4_SUBNET can also be useful if the client's TSr included 4823 only part of the address space. For instance, if the client requests 4824 the following: 4826 CP(CFG_REQUEST) = 4827 INTERNAL_IP4_ADDRESS() 4828 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) 4829 TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) 4831 then the gateway's reply might be: 4833 CP(CFG_REPLY) = 4834 INTERNAL_IP4_ADDRESS(192.0.1.234) 4835 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 4836 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 4837 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 4838 TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) 4839 Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET is in 4840 CFG_REQUESTs is unclear, they cannot be used reliably in 4841 CFG_REQUESTs. 4843 3.15.3. Configuration payloads for IPv6 4845 {{ Added this section from Clarif-6.5 }} 4847 The configuration payloads for IPv6 are based on the corresponding 4848 IPv4 payloads, and do not fully follow the "normal IPv6 way of doing 4849 things". In particular, IPv6 stateless autoconfiguration or router 4850 advertisement messages are not used; neither is neighbor discovery. 4852 A client can be assigned an IPv6 address using the 4853 INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange might 4854 look like this: 4856 CP(CFG_REQUEST) = 4857 INTERNAL_IP6_ADDRESS() 4858 INTERNAL_IP6_DNS() 4859 TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 4860 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 4862 CP(CFG_REPLY) = 4863 INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) 4864 INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) 4865 TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) 4866 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 4868 The client MAY send a non-empty INTERNAL_IP6_ADDRESS attribute in the 4869 CFG_REQUEST to request a specific address or interface identifier. 4870 The gateway first checks if the specified address is acceptable, and 4871 if it is, returns that one. If the address was not acceptable, the 4872 gateway attempts to use the interface identifier with some other 4873 prefix; if even that fails, the gateway selects another interface 4874 identifier. 4876 The INTERNAL_IP6_ADDRESS attribute also contains a prefix length 4877 field. When used in a CFG_REPLY, this corresponds to the 4878 INTERNAL_IP4_NETMASK attribute in the IPv4 case. 4880 Although this approach to configuring IPv6 addresses is reasonably 4881 simple, it has some limitations. IPsec tunnels configured using 4882 IKEv2 are not fully-featured "interfaces" in the IPv6 addressing 4883 architecture sense [IPV6ADDR]. In particular, they do not 4884 necessarily have link-local addresses, and this may complicate the 4885 use of protocols that assume them, such as [MLDV2]. 4887 3.15.4. Address Assignment Failures 4889 {{ Added this section from Clarif-6.8 }} 4891 If the responder encounters an error while attempting to assign an IP 4892 address to the initiator during the processing of a Configuration 4893 Payload, it responds with an INTERNAL_ADDRESS_FAILURE notification. 4894 The IKE SA is still created even if the initial Child SA cannot be 4895 created because of this failure. {{ 3.10.1-36 }} If this error is 4896 generated within an IKE_AUTH exchange, no Child SA will be created. 4897 However, there are some more complex error cases. 4899 If the responder does not support configuration payloads at all, it 4900 can simply ignore all configuration payloads. This type of 4901 implementation never sends INTERNAL_ADDRESS_FAILURE notifications. 4902 If the initiator requires the assignment of an IP address, it will 4903 treat a response without CFG_REPLY as an error. 4905 The initiator may request a particular type of address (IPv4 or IPv6) 4906 that the responder does not support, even though the responder 4907 supports configuration payloads. In this case, the responder simply 4908 ignores the type of address it does not support and processes the 4909 rest of the request as usual. 4911 If the initiator requests multiple addresses of a type that the 4912 responder supports, and some (but not all) of the requests fail, the 4913 responder replies with the successful addresses only. The responder 4914 sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned. 4916 3.16. Extensible Authentication Protocol (EAP) Payload 4918 The Extensible Authentication Protocol Payload, denoted EAP in this 4919 memo, allows IKE SAs to be authenticated using the protocol defined 4920 in RFC 3748 [EAP] and subsequent extensions to that protocol. The 4921 full set of acceptable values for the payload is defined elsewhere, 4922 but a short summary of RFC 3748 is included here to make this 4923 document stand alone in the common cases. 4925 1 2 3 4926 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 4927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4928 | Next Payload |C| RESERVED | Payload Length | 4929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4930 | | 4931 ~ EAP Message ~ 4932 | | 4933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4934 Figure 24: EAP Payload Format 4936 The payload type for an EAP Payload is forty eight (48). 4938 1 2 3 4939 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 4940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4941 | Code | Identifier | Length | 4942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4943 | Type | Type_Data... 4944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 4946 Figure 25: EAP Message Format 4948 o Code (1 octet) indicates whether this message is a Request (1), 4949 Response (2), Success (3), or Failure (4). 4951 o Identifier (1 octet) is used in PPP to distinguish replayed 4952 messages from repeated ones. Since in IKE, EAP runs over a 4953 reliable protocol, it serves no function here. In a response 4954 message, this octet MUST be set to match the identifier in the 4955 corresponding request. In other messages, this field MAY be set 4956 to any value. 4958 o Length (2 octets) is the length of the EAP message and MUST be 4959 four less than the Payload Length of the encapsulating payload. 4961 o Type (1 octet) is present only if the Code field is Request (1) or 4962 Response (2). For other codes, the EAP message length MUST be 4963 four octets and the Type and Type_Data fields MUST NOT be present. 4964 In a Request (1) message, Type indicates the data being requested. 4965 In a Response (2) message, Type MUST either be Nak or match the 4966 type of the data requested. The following types are defined in 4967 RFC 3748: 4969 1 Identity 4970 2 Notification 4971 3 Nak (Response Only) 4972 4 MD5-Challenge 4973 5 One-Time Password (OTP) 4974 6 Generic Token Card 4976 o Type_Data (Variable Length) varies with the Type of Request and 4977 the associated Response. For the documentation of the EAP 4978 methods, see [EAP]. 4980 {{ Demoted the SHOULD NOT and SHOULD }} Note that since IKE passes an 4981 indication of initiator identity in message 3 of the protocol, the 4982 responder should not send EAP Identity requests. The initiator may, 4983 however, respond to such requests if it receives them. 4985 4. Conformance Requirements 4987 In order to assure that all implementations of IKEv2 can 4988 interoperate, there are "MUST support" requirements in addition to 4989 those listed elsewhere. Of course, IKEv2 is a security protocol, and 4990 one of its major functions is to allow only authorized parties to 4991 successfully complete establishment of SAs. So a particular 4992 implementation may be configured with any of a number of restrictions 4993 concerning algorithms and trusted authorities that will prevent 4994 universal interoperability. 4996 IKEv2 is designed to permit minimal implementations that can 4997 interoperate with all compliant implementations. There are a series 4998 of optional features that can easily be ignored by a particular 4999 implementation if it does not support that feature. Those features 5000 include: 5002 o Ability to negotiate SAs through a NAT and tunnel the resulting 5003 ESP SA over UDP. 5005 o Ability to request (and respond to a request for) a temporary IP 5006 address on the remote end of a tunnel. 5008 o Ability to support various types of legacy authentication. 5010 o Ability to support window sizes greater than one. 5012 o Ability to establish multiple ESP or AH SAs within a single IKE 5013 SA. 5015 o Ability to rekey SAs. 5017 To assure interoperability, all implementations MUST be capable of 5018 parsing all payload types (if only to skip over them) and to ignore 5019 payload types that it does not support unless the critical bit is set 5020 in the payload header. If the critical bit is set in an unsupported 5021 payload header, all implementations MUST reject the messages 5022 containing those payloads. 5024 Every implementation MUST be capable of doing four-message 5025 IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, 5026 one for ESP or AH). Implementations MAY be initiate-only or respond- 5027 only if appropriate for their platform. Every implementation MUST be 5028 capable of responding to an INFORMATIONAL exchange, but a minimal 5029 implementation MAY respond to any INFORMATIONAL message with an empty 5030 INFORMATIONAL reply (note that within the context of an IKE SA, an 5031 "empty" message consists of an IKE header followed by an Encrypted 5032 payload with no payloads contained in it). A minimal implementation 5033 MAY support the CREATE_CHILD_SA exchange only in so far as to 5034 recognize requests and reject them with a Notify payload of type 5035 NO_ADDITIONAL_SAS. A minimal implementation need not be able to 5036 initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA 5037 expires (based on locally configured values of either lifetime or 5038 octets passed), and implementation MAY either try to renew it with a 5039 CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and 5040 create a new one. If the responder rejects the CREATE_CHILD_SA 5041 request with a NO_ADDITIONAL_SAS notification, the implementation 5042 MUST be capable of instead deleting the old SA and creating a new 5043 one. 5045 Implementations are not required to support requesting temporary IP 5046 addresses or responding to such requests. If an implementation does 5047 support issuing such requests, it MUST include a CP payload in 5048 message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or 5049 INTERNAL_IP6_ADDRESS. All other fields are optional. If an 5050 implementation supports responding to such requests, it MUST parse 5051 the CP payload of type CFG_REQUEST in message 3 and recognize a field 5052 of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports 5053 leasing an address of the appropriate type, it MUST return a CP 5054 payload of type CFG_REPLY containing an address of the requested 5055 type. {{ Demoted the SHOULD }} The responder may include any other 5056 related attributes. 5058 A minimal IPv4 responder implementation will ignore the contents of 5059 the CP payload except to determine that it includes an 5060 INTERNAL_IP4_ADDRESS attribute and will respond with the address and 5061 other related attributes regardless of whether the initiator 5062 requested them. 5064 A minimal IPv4 initiator will generate a CP payload containing only 5065 an INTERNAL_IP4_ADDRESS attribute and will parse the response 5066 ignoring attributes it does not know how to use. 5068 For an implementation to be called conforming to this specification, 5069 it MUST be possible to configure it to accept the following: 5071 o PKIX Certificates containing and signed by RSA keys of size 1024 5072 or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, 5073 ID_RFC822_ADDR, or ID_DER_ASN1_DN. 5075 o Shared key authentication where the ID passed is any of ID_KEY_ID, 5076 ID_FQDN, or ID_RFC822_ADDR. 5078 o Authentication where the responder is authenticated using PKIX 5079 Certificates and the initiator is authenticated using shared key 5080 authentication. 5082 5. Security Considerations 5084 While this protocol is designed to minimize disclosure of 5085 configuration information to unauthenticated peers, some such 5086 disclosure is unavoidable. One peer or the other must identify 5087 itself first and prove its identity first. To avoid probing, the 5088 initiator of an exchange is required to identify itself first, and 5089 usually is required to authenticate itself first. The initiator can, 5090 however, learn that the responder supports IKE and what cryptographic 5091 protocols it supports. The responder (or someone impersonating the 5092 responder) can probe the initiator not only for its identity, but 5093 using CERTREQ payloads may be able to determine what certificates the 5094 initiator is willing to use. 5096 Use of EAP authentication changes the probing possibilities somewhat. 5097 When EAP authentication is used, the responder proves its identity 5098 before the initiator does, so an initiator that knew the name of a 5099 valid initiator could probe the responder for both its name and 5100 certificates. 5102 Repeated rekeying using CREATE_CHILD_SA without additional Diffie- 5103 Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a 5104 single key or overrun of either endpoint. Implementers should take 5105 note of this fact and set a limit on CREATE_CHILD_SA exchanges 5106 between exponentiations. This memo does not prescribe such a limit. 5108 The strength of a key derived from a Diffie-Hellman exchange using 5109 any of the groups defined here depends on the inherent strength of 5110 the group, the size of the exponent used, and the entropy provided by 5111 the random number generator used. Due to these inputs, it is 5112 difficult to determine the strength of a key for any of the defined 5113 groups. Diffie-Hellman group number two, when used with a strong 5114 random number generator and an exponent no less than 200 bits, is 5115 common for use with 3DES. Group five provides greater security than 5116 group two. Group one is for historic purposes only and does not 5117 provide sufficient strength except for use with DES, which is also 5118 for historic use only. Implementations should make note of these 5119 estimates when establishing policy and negotiating security 5120 parameters. 5122 Note that these limitations are on the Diffie-Hellman groups 5123 themselves. There is nothing in IKE that prohibits using stronger 5124 groups nor is there anything that will dilute the strength obtained 5125 from stronger groups (limited by the strength of the other algorithms 5126 negotiated including the prf function). In fact, the extensible 5127 framework of IKE encourages the definition of more groups; use of 5128 elliptical curve groups may greatly increase strength using much 5129 smaller numbers. 5131 It is assumed that all Diffie-Hellman exponents are erased from 5132 memory after use. 5134 The IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator 5135 has been authenticated. As a result, an implementation of this 5136 protocol needs to be completely robust when deployed on any insecure 5137 network. Implementation vulnerabilities, particularly denial-of- 5138 service attacks, can be exploited by unauthenticated peers. This 5139 issue is particularly worrisome because of the unlimited number of 5140 messages in EAP-based authentication. 5142 The strength of all keys is limited by the size of the output of the 5143 negotiated prf function. For this reason, a prf function whose 5144 output is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with 5145 this protocol. 5147 The security of this protocol is critically dependent on the 5148 randomness of the randomly chosen parameters. These should be 5149 generated by a strong random or properly seeded pseudo-random source 5150 (see [RANDOMNESS]). Implementers should take care to ensure that use 5151 of random numbers for both keys and nonces is engineered in a fashion 5152 that does not undermine the security of the keys. 5154 For information on the rationale of many of the cryptographic design 5155 choices in this protocol, see [SIGMA] and [SKEME]. Though the 5156 security of negotiated Child SAs does not depend on the strength of 5157 the encryption and integrity protection negotiated in the IKE SA, 5158 implementations MUST NOT negotiate NONE as the IKE integrity 5159 protection algorithm or ENCR_NULL as the IKE encryption algorithm. 5161 When using pre-shared keys, a critical consideration is how to assure 5162 the randomness of these secrets. The strongest practice is to ensure 5163 that any pre-shared key contain as much randomness as the strongest 5164 key being negotiated. Deriving a shared secret from a password, 5165 name, or other low-entropy source is not secure. These sources are 5166 subject to dictionary and social engineering attacks, among others. 5168 The NAT_DETECTION_*_IP notifications contain a hash of the addresses 5169 and ports in an attempt to hide internal IP addresses behind a NAT. 5170 Since the IPv4 address space is only 32 bits, and it is usually very 5171 sparse, it would be possible for an attacker to find out the internal 5172 address used behind the NAT box by trying all possible IP addresses 5173 and trying to find the matching hash. The port numbers are normally 5174 fixed to 500, and the SPIs can be extracted from the packet. This 5175 reduces the number of hash calculations to 2^32. With an educated 5176 guess of the use of private address space, the number of hash 5177 calculations is much smaller. Designers should therefore not assume 5178 that use of IKE will not leak internal address information. 5180 When using an EAP authentication method that does not generate a 5181 shared key for protecting a subsequent AUTH payload, certain man-in- 5182 the-middle and server impersonation attacks are possible [EAPMITM]. 5183 These vulnerabilities occur when EAP is also used in protocols that 5184 are not protected with a secure tunnel. Since EAP is a general- 5185 purpose authentication protocol, which is often used to provide 5186 single-signon facilities, a deployed IPsec solution that relies on an 5187 EAP authentication method that does not generate a shared key (also 5188 known as a non-key-generating EAP method) can become compromised due 5189 to the deployment of an entirely unrelated application that also 5190 happens to use the same non-key-generating EAP method, but in an 5191 unprotected fashion. Note that this vulnerability is not limited to 5192 just EAP, but can occur in other scenarios where an authentication 5193 infrastructure is reused. For example, if the EAP mechanism used by 5194 IKEv2 utilizes a token authenticator, a man-in-the-middle attacker 5195 could impersonate the web server, intercept the token authentication 5196 exchange, and use it to initiate an IKEv2 connection. For this 5197 reason, use of non-key-generating EAP methods SHOULD be avoided where 5198 possible. Where they are used, it is extremely important that all 5199 usages of these EAP methods SHOULD utilize a protected tunnel, where 5200 the initiator validates the responder's certificate before initiating 5201 the EAP authentication. {{ Demoted the SHOULD }} Implementers should 5202 describe the vulnerabilities of using non-key-generating EAP methods 5203 in the documentation of their implementations so that the 5204 administrators deploying IPsec solutions are aware of these dangers. 5206 An implementation using EAP MUST also use strong authentication of 5207 the server to the client before the EAP authentication begins, even 5208 if the EAP method offers mutual authentication. This avoids having 5209 additional IKEv2 protocol variations and protects the EAP data from 5210 active attackers. 5212 If the messages of IKEv2 are long enough that IP-level fragmentation 5213 is necessary, it is possible that attackers could prevent the 5214 exchange from completing by exhausting the reassembly buffers. The 5215 chances of this can be minimized by using the Hash and URL encodings 5216 instead of sending certificates (see Section 3.6). Additional 5217 mitigations are discussed in [DOSUDPPROT]. 5219 5.1. Traffic selector authorization 5221 {{ Added this section from Clarif-4.13 }} 5223 IKEv2 relies on information in the Peer Authorization Database (PAD) 5224 when determining what kind of IPsec SAs a peer is allowed to create. 5225 This process is described in [IPSECARCH] Section 4.4.3. When a peer 5226 requests the creation of an IPsec SA with some traffic selectors, the 5227 PAD must contain "Child SA Authorization Data" linking the identity 5228 authenticated by IKEv2 and the addresses permitted for traffic 5229 selectors. 5231 For example, the PAD might be configured so that authenticated 5232 identity "sgw23.example.com" is allowed to create IPsec SAs for 5233 192.0.2.0/24, meaning this security gateway is a valid 5234 "representative" for these addresses. Host-to-host IPsec requires 5235 similar entries, linking, for example, "fooserver4.example.com" with 5236 192.0.1.66/32, meaning this identity a valid "owner" or 5237 "representative" of the address in question. 5239 As noted in [IPSECARCH], "It is necessary to impose these constraints 5240 on creation of child SAs to prevent an authenticated peer from 5241 spoofing IDs associated with other, legitimate peers." In the 5242 example given above, a correct configuration of the PAD prevents 5243 sgw23 from creating IPsec SAs with address 192.0.1.66, and prevents 5244 fooserver4 from creating IPsec SAs with addresses from 192.0.2.0/24. 5246 It is important to note that simply sending IKEv2 packets using some 5247 particular address does not imply a permission to create IPsec SAs 5248 with that address in the traffic selectors. For example, even if 5249 sgw23 would be able to spoof its IP address as 192.0.1.66, it could 5250 not create IPsec SAs matching fooserver4's traffic. 5252 The IKEv2 specification does not specify how exactly IP address 5253 assignment using configuration payloads interacts with the PAD. Our 5254 interpretation is that when a security gateway assigns an address 5255 using configuration payloads, it also creates a temporary PAD entry 5256 linking the authenticated peer identity and the newly allocated inner 5257 address. 5259 It has been recognized that configuring the PAD correctly may be 5260 difficult in some environments. For instance, if IPsec is used 5261 between a pair of hosts whose addresses are allocated dynamically 5262 using DHCP, it is extremely difficult to ensure that the PAD 5263 specifies the correct "owner" for each IP address. This would 5264 require a mechanism to securely convey address assignments from the 5265 DHCP server, and link them to identities authenticated using IKEv2. 5267 Due to this limitation, some vendors have been known to configure 5268 their PADs to allow an authenticated peer to create IPsec SAs with 5269 traffic selectors containing the same address that was used for the 5270 IKEv2 packets. In environments where IP spoofing is possible (i.e., 5271 almost everywhere) this essentially allows any peer to create IPsec 5272 SAs with any traffic selectors. This is not an appropriate or secure 5273 configuration in most circumstances. See [H2HIPSEC] for an extensive 5274 discussion about this issue, and the limitations of host-to-host 5275 IPsec in general. 5277 6. IANA Considerations 5279 {{ This section was changed to not re-define any new IANA registries. 5280 }} 5282 [IKEV2] defined many field types and values. IANA has already 5283 registered those types and values, so the are not listed here again. 5284 No new types or values are registered in this document. However, 5285 IANA should update all references to RFC 4306 to point to this 5286 document. 5288 7. Acknowledgements 5290 The individuals on the IPsec mailing list was very helpful in both 5291 pointing out where clarifications and changes were needed, as well as 5292 in reviewing the clarifications suggested by others. 5294 The acknowledgements from the IKEv2 document were: 5296 This document is a collaborative effort of the entire IPsec WG. If 5297 there were no limit to the number of authors that could appear on an 5298 RFC, the following, in alphabetical order, would have been listed: 5299 Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt 5300 Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John 5301 Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero 5302 Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer 5303 Reingold, and Michael Richardson. Many other people contributed to 5304 the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, 5305 each of which has its own list of authors. Hugh Daniel suggested the 5306 feature of having the initiator, in message 3, specify a name for the 5307 responder, and gave the feature the cute name "You Tarzan, Me Jane". 5308 David Faucher and Valery Smyzlov helped refine the design of the 5309 traffic selector negotiation. 5311 This paragraph lists references that appear only in figures. The 5312 section is only here to keep the 'xml2rfc' program happy, and needs 5313 to be removed when the document is published. The RFC Editor will 5314 remove it before publication. [AEAD] [EAI] [DES] [IDEA] [MD5] 5315 [X.501] [X.509] 5317 8. References 5319 8.1. Normative References 5321 [ADDGROUP] 5322 Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 5323 Diffie-Hellman groups for Internet Key Exchange (IKE)", 5324 RFC 3526, May 2003. 5326 [ADDRIPV6] 5327 Hinden, R. and S. Deering, "Internet Protocol Version 6 5328 (IPv6) Addressing Architecture", RFC 4291, February 2006. 5330 [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 5331 Levkowetz, "Extensible Authentication Protocol (EAP)", 5332 RFC 3748, June 2004. 5334 [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 5335 of Explicit Congestion Notification (ECN) to IP", 5336 RFC 3168, September 2001. 5338 [ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 5339 Algorithms", RFC 2451, November 1998. 5341 [IPSECARCH] 5342 Kent, S. and K. Seo, "Security Architecture for the 5343 Internet Protocol", RFC 4301, December 2005. 5345 [MUSTSHOULD] 5346 Bradner, S., "Key Words for use in RFCs to indicate 5347 Requirement Levels", BCP 14, RFC 2119, March 1997. 5349 [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 5350 Standards (PKCS) #1: RSA Cryptography Specifications 5351 Version 2.1", RFC 3447, February 2003. 5353 [PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 5354 X.509 Public Key Infrastructure Certificate and 5355 Certificate Revocation List (CRL) Profile", RFC 3280, 5356 April 2002. 5358 [RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the 5359 Internet Key Exchange Protocol (IKE)", RFC 4434, 5360 February 2006. 5362 [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 5363 Advanced Encryption Standard-Cipher-based Message 5364 Authentication Code-Pseudo-Random Function-128 (AES-CMAC- 5365 PRF-128) Algorithm for the Internet Key Exchange Protocol 5366 (IKE)", RFC 4615, August 2006. 5368 [UDPENCAPS] 5369 Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 5370 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 5371 RFC 3948, January 2005. 5373 8.2. Informative References 5375 [AEAD] McGrew, D., "An Interface and Algorithms for Authenticated 5376 Encryption", RFC 5116, January 2008. 5378 [AH] Kent, S., "IP Authentication Header", RFC 4302, 5379 December 2005. 5381 [ARCHGUIDEPHIL] 5382 Bush, R. and D. Meyer, "Some Internet Architectural 5383 Guidelines and Philosophy", RFC 3439, December 2002. 5385 [ARCHPRINC] 5386 Carpenter, B., "Architectural Principles of the Internet", 5387 RFC 1958, June 1996. 5389 [Clarif] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 5390 Implementation Guidelines", RFC 4718, October 2006. 5392 [DES] American National Standards Institute, "American National 5393 Standard for Information Systems-Data Link Encryption", 5394 ANSI X3.106, 1983. 5396 [DH] Diffie, W. and M. Hellman, "New Directions in 5397 Cryptography", IEEE Transactions on Information Theory, 5398 V.IT-22 n. 6, June 1977. 5400 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", 5401 RFC 2131, March 1997. 5403 [DIFFSERVARCH] 5404 Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 5405 and W. Weiss, "An Architecture for Differentiated 5406 Services", RFC 2475. 5408 [DIFFSERVFIELD] 5409 Nichols, K., Blake, S., Baker, F., and D. Black, 5410 "Definition of the Differentiated Services Field (DS 5411 Field) in the IPv4 and IPv6 Headers", RFC 2474, 5412 December 1998. 5414 [DIFFTUNNEL] 5415 Black, D., "Differentiated Services and Tunnels", 5416 RFC 2983, October 2000. 5418 [DOI] Piper, D., "The Internet IP Security Domain of 5419 Interpretation for ISAKMP", RFC 2407, November 1998. 5421 [DOSUDPPROT] 5422 C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection 5423 for UDP-based protocols", ACM Conference on Computer and 5424 Communications Security , October 2003. 5426 [DSS] National Institute of Standards and Technology, U.S. 5427 Department of Commerce, "Digital Signature Standard", 5428 Draft FIPS 186-3, June 2008. 5430 [EAI] Abel, Y., "Internationalized Email Headers", RFC 5335, 5431 September 2008. 5433 [EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, "Man-in-the-Middle in 5434 Tunneled Authentication Protocols", November 2002, 5435 . 5437 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 5438 RFC 4303, December 2005. 5440 [EXCHANGEANALYSIS] 5441 R. Perlman and C. Kaufman, "Analysis of the IPsec key 5442 exchange Standard", WET-ICE Security Conference, MIT , 5443 2001, 5444 . 5446 [H2HIPSEC] 5447 Aura, T., Roe, M., and A. Mohammed, "Experiences with 5448 Host-to-Host IPsec", 13th International Workshop on 5449 Security Protocols, Cambridge, UK, April 2005. 5451 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 5452 Hashing for Message Authentication", RFC 2104, 5453 February 1997. 5455 [IDEA] X. Lai, "On the Design and Security of Block Ciphers", ETH 5456 Series in Information Processing, v. 1, Konstanz: Hartung- 5457 Gorre Verlag, 1992. 5459 [IDNA] Faltstrom, P., Hoffman, P., and A. Costello, 5460 "Internationalizing Domain Names in Applications (IDNA)", 5461 RFC 3490, March 2003. 5463 [IKEV1] Harkins, D. and D. Carrel, "The Internet Key Exchange 5464 (IKE)", RFC 2409, November 1998. 5466 [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 5467 RFC 4306, December 2005. 5469 [IP-COMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP 5470 Payload Compression Protocol (IPComp)", RFC 3173, 5471 September 2001. 5473 [IPSECARCH-OLD] 5474 Kent, S. and R. Atkinson, "Security Architecture for the 5475 Internet Protocol", RFC 2401, November 1998. 5477 [IPV6ADDR] 5478 Hinden, R. and S. Deering, "Internet Protocol Version 6 5479 (IPv6) Addressing Architecture", RFC 4291, February 2006. 5481 [ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet 5482 Security Association and Key Management Protocol 5483 (ISAKMP)", RFC 2408, November 1998. 5485 [LDAP] Sermersheim, J., "Lightweight Directory Access Protocol 5486 (v3)", RFC 4511, June 2006. 5488 [MAILFORMAT] 5489 Resnick, P., "Internet Message Format", RFC 2822, 5490 April 2001. 5492 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 5493 April 1992. 5495 [MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 5496 in IPv6", RFC 3775, June 2004. 5498 [MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery 5499 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 5501 [MODES] National Institute of Standards and Technology, U.S. 5502 Department of Commerce, "Recommendation for Block Cipher 5503 Modes of Operation", SP 800-38A, 2001. 5505 [NAI] Aboba, B., Beadles, M., Eronen, P., and J. Arkko, "The 5506 Network Access Identifier", RFC 4282, December 2005. 5508 [NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 5509 (NAT) Compatibility Requirements", RFC 3715, March 2004. 5511 [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", 5512 RFC 2412, November 1998. 5514 [PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 5515 Management API, Version 2", RFC 2367, July 1998. 5517 [PHOTURIS] 5518 Karn, P. and W. Simpson, "Photuris: Session-Key Management 5519 Protocol", RFC 2522, March 1999. 5521 [RADIUS] Rigney, C., Rubens, A., Simpson, W., and S. Willens, 5522 "Remote Authentication Dial In User Service (RADIUS)", 5523 RFC 2138, April 1997. 5525 [RANDOMNESS] 5526 Eastlake, D., Schiller, J., and S. Crocker, "Randomness 5527 Requirements for Security", BCP 106, RFC 4086, June 2005. 5529 [REAUTH] Nir, Y., "Repeated Authentication in Internet Key Exchange 5530 (IKEv2) Protocol", RFC 4478, April 2006. 5532 [REUSE] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In 5533 Diffie-Hellman Key Agreement Protocols", December 2008, 5534 . 5537 [ROHCV2] Ertekin, et. al., E., "IKEv2 Extensions to Support Robust 5538 Header Compression over IPsec (ROHCoIPsec)", 5539 draft-ietf-rohc-ikev2-extensions-hcoipsec (work in 5540 progress), October 2008. 5542 [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for 5543 Obtaining Digital Signatures and Public-Key 5544 Cryptosystems", February 1978. 5546 [SHA] National Institute of Standards and Technology, U.S. 5547 Department of Commerce, "Secure Hash Standard", 5548 FIPS 180-3, October 2008. 5550 [SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to 5551 Authenticated Diffie-Hellman and its Use in the IKE 5552 Protocols", Advances in Cryptography - CRYPTO 2003 5553 Proceedings LNCS 2729, 2003, . 5557 [SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange 5558 Mechanism for Internet", IEEE Proceedings of the 1996 5559 Symposium on Network and Distributed Systems Security , 5560 1996. 5562 [TRANSPARENCY] 5563 Carpenter, B., "Internet Transparency", RFC 2775, 5564 February 2000. 5566 [X.501] ITU-T, "Recommendation X.501: Information Technology - 5567 Open Systems Interconnection - The Directory: Models", 5568 1993. 5570 [X.509] ITU-T, "Recommendation X.509 (1997 E): Information 5571 Technology - Open Systems Interconnection - The Directory: 5572 Authentication Framework", 1997. 5574 Appendix A. Summary of changes from IKEv1 5576 The goals of this revision to IKE are: 5578 1. To define the entire IKE protocol in a single document, 5579 replacing RFCs 2407, 2408, and 2409 and incorporating subsequent 5580 changes to support NAT Traversal, Extensible Authentication, and 5581 Remote Address acquisition; 5583 2. To simplify IKE by replacing the eight different initial 5584 exchanges with a single four-message exchange (with changes in 5585 authentication mechanisms affecting only a single AUTH payload 5586 rather than restructuring the entire exchange) see 5587 [EXCHANGEANALYSIS]; 5589 3. To remove the Domain of Interpretation (DOI), Situation (SIT), 5590 and Labeled Domain Identifier fields, and the Commit and 5591 Authentication only bits; 5593 4. To decrease IKE's latency in the common case by making the 5594 initial exchange be 2 round trips (4 messages), and allowing the 5595 ability to piggyback setup of a Child SA on that exchange; 5597 5. To replace the cryptographic syntax for protecting the IKE 5598 messages themselves with one based closely on ESP to simplify 5599 implementation and security analysis; 5601 6. To reduce the number of possible error states by making the 5602 protocol reliable (all messages are acknowledged) and sequenced. 5603 This allows shortening CREATE_CHILD_SA exchanges from 3 messages 5604 to 2; 5606 7. To increase robustness by allowing the responder to not do 5607 significant processing until it receives a message proving that 5608 the initiator can receive messages at its claimed IP address; 5610 8. To fix cryptographic weaknesses such as the problem with 5611 symmetries in hashes used for authentication documented by Tero 5612 Kivinen; 5614 9. To specify Traffic Selectors in their own payloads type rather 5615 than overloading ID payloads, and making more flexible the 5616 Traffic Selectors that may be specified; 5618 10. To specify required behavior under certain error conditions or 5619 when data that is not understood is received in order to make it 5620 easier to make future revisions in a way that does not break 5621 backwards compatibility; 5623 11. To simplify and clarify how shared state is maintained in the 5624 presence of network failures and Denial of Service attacks; and 5626 12. To maintain existing syntax and magic numbers to the extent 5627 possible to make it likely that implementations of IKEv1 can be 5628 enhanced to support IKEv2 with minimum effort. 5630 Appendix B. Diffie-Hellman Groups 5632 There are two Diffie-Hellman groups defined here for use in IKE. 5633 These groups were generated by Richard Schroeppel at the University 5634 of Arizona. Properties of these primes are described in [OAKLEY]. 5636 The strength supplied by group one may not be sufficient for the 5637 mandatory-to-implement encryption algorithm and is here for historic 5638 reasons. 5640 Additional Diffie-Hellman groups have been defined in [ADDGROUP]. 5642 B.1. Group 1 - 768 Bit MODP 5644 This group is assigned id 1 (one). 5646 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 5647 Its hexadecimal value is: 5649 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 5650 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 5651 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 5652 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF 5654 The generator is 2. 5656 B.2. Group 2 - 1024 Bit MODP 5658 This group is assigned id 2 (two). 5660 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 5661 Its hexadecimal value is: 5663 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 5664 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 5665 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 5666 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 5667 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 5668 FFFFFFFF FFFFFFFF 5670 The generator is 2. 5672 Appendix C. Exchanges and Payloads 5674 {{ Clarif-AppA }} 5676 This appendix contains a short summary of the IKEv2 exchanges, and 5677 what payloads can appear in which message. This appendix is purely 5678 informative; if it disagrees with the body of this document, the 5679 other text is considered correct. 5681 Vendor-ID (V) payloads may be included in any place in any message. 5682 This sequence here shows what are the most logical places for them. 5684 C.1. IKE_SA_INIT Exchange 5686 request --> [N(COOKIE)], 5687 SA, KE, Ni, 5688 [N(NAT_DETECTION_SOURCE_IP)+, 5689 N(NAT_DETECTION_DESTINATION_IP)], 5690 [V+] 5692 normal response <-- SA, KE, Nr, 5693 (no cookie) [N(NAT_DETECTION_SOURCE_IP), 5694 N(NAT_DETECTION_DESTINATION_IP)], 5695 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 5696 [V+] 5698 cookie response <-- N(COOKIE), 5699 [V+] 5701 different D-H <-- N(INVALID_KE_PAYLOAD), 5702 group wanted [V+] 5704 C.2. IKE_AUTH Exchange without EAP 5706 request --> IDi, [CERT+], 5707 [N(INITIAL_CONTACT)], 5708 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 5709 [IDr], 5710 AUTH, 5711 [CP(CFG_REQUEST)], 5712 [N(IPCOMP_SUPPORTED)+], 5713 [N(USE_TRANSPORT_MODE)], 5714 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5715 [N(NON_FIRST_FRAGMENTS_ALSO)], 5716 SA, TSi, TSr, 5717 [V+] 5719 response <-- IDr, [CERT+], 5720 AUTH, 5721 [CP(CFG_REPLY)], 5722 [N(IPCOMP_SUPPORTED)], 5723 [N(USE_TRANSPORT_MODE)], 5724 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5725 [N(NON_FIRST_FRAGMENTS_ALSO)], 5726 SA, TSi, TSr, 5727 [N(ADDITIONAL_TS_POSSIBLE)], 5728 [V+] 5730 error in Child SA <-- IDr, [CERT+], 5731 creation AUTH, 5732 N(error), 5733 [V+] 5735 C.3. IKE_AUTH Exchange with EAP 5737 first request --> IDi, 5738 [N(INITIAL_CONTACT)], 5739 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 5740 [IDr], 5741 [CP(CFG_REQUEST)], 5742 [N(IPCOMP_SUPPORTED)+], 5743 [N(USE_TRANSPORT_MODE)], 5744 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5745 [N(NON_FIRST_FRAGMENTS_ALSO)], 5746 SA, TSi, TSr, 5747 [V+] 5749 first response <-- IDr, [CERT+], AUTH, 5750 EAP, 5751 [V+] 5753 / --> EAP 5754 repeat 1..N times | 5755 \ <-- EAP 5757 last request --> AUTH 5759 last response <-- AUTH, 5760 [CP(CFG_REPLY)], 5761 [N(IPCOMP_SUPPORTED)], 5762 [N(USE_TRANSPORT_MODE)], 5763 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5764 [N(NON_FIRST_FRAGMENTS_ALSO)], 5765 SA, TSi, TSr, 5766 [N(ADDITIONAL_TS_POSSIBLE)], 5767 [V+] 5769 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying Child SAs 5771 request --> [N(REKEY_SA)], 5772 [CP(CFG_REQUEST)], 5773 [N(IPCOMP_SUPPORTED)+], 5774 [N(USE_TRANSPORT_MODE)], 5775 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5776 [N(NON_FIRST_FRAGMENTS_ALSO)], 5777 SA, Ni, [KEi], TSi, TSr 5778 [V+] 5780 normal <-- [CP(CFG_REPLY)], 5781 response [N(IPCOMP_SUPPORTED)], 5782 [N(USE_TRANSPORT_MODE)], 5783 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5784 [N(NON_FIRST_FRAGMENTS_ALSO)], 5785 SA, Nr, [KEr], TSi, TSr, 5786 [N(ADDITIONAL_TS_POSSIBLE)] 5787 [V+] 5789 error case <-- N(error) 5791 different D-H <-- N(INVALID_KE_PAYLOAD), 5792 group wanted [V+] 5794 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA 5796 request --> SA, Ni, [KEi] 5797 [V+] 5799 response <-- SA, Nr, [KEr] 5800 [V+] 5802 C.6. INFORMATIONAL Exchange 5804 request --> [N+], 5805 [D+], 5806 [CP(CFG_REQUEST)] 5808 response <-- [N+], 5809 [D+], 5810 [CP(CFG_REPLY)] 5812 Appendix D. Significant Changes from RFC 4306 5814 This is a placeholder that will be filled in. The WG needs to decide 5815 what level of specificity is most useful here. For example, it might 5816 only be changes that involve SHOULD-level or MUST-level requirements, 5817 or it might also include additional "significant" advice that was 5818 added. 5820 Appendix E. Changes Between Internet Draft Versions 5822 This section will be removed before publication as an RFC, but should 5823 be left intact until then so that reviewers can follow what has 5824 changed. 5826 E.1. Changes from IKEv2 to draft -00 5828 There were a zillion additions from RFC 4718. These are noted with 5829 "{{ Clarif-nn }}". 5831 Cleaned up many of the figures. Made the table headings consistent. 5832 Made some tables easier to read by removing blank spaces. Removed 5833 the "reserved to IANA" and "private use" text wording and moved it 5834 into the tables. 5836 Changed many SHOULD requirements to better match RFC 2119. These are 5837 also marked with comments such as "{{ Demoted the SHOULD }}". 5839 In Section 2.16, changed the MUST requirement of authenticating the 5840 responder from "public key signature based" to "strong" because that 5841 is what most current IKEv2 implementations do, and it better matches 5842 the actual security requirement. 5844 E.2. Changes from draft -00 to draft -01 5846 The most significant technical change was to make KE optional but 5847 strongly recommended in Section 1.3.2. 5849 Updated all references to the IKEv2 Clarifications document to RFC 5850 4718. 5852 Moved a lot of the protocol description out of the long tables in 5853 Section 3.10.1 into the body of the document. These are noted with 5854 "{{ 3.10.1-nnnn }}", where "nnnn" is the notification type number. 5856 Made some table changes based on suggestions from Alfred Hoenes. 5858 Changed "byte" to "octet" in many places. 5860 Removed discussion of ESP+AH bundles in many places, and added a 5861 paragraph about it in Section 1.7. 5863 Removed the discussion of INTERNAL_ADDRESS_EXPIRY in many places, and 5864 added a paragraph about it in Section 1.7. 5866 Moved Clarif-7.10 from Section 1.2 to Section 3.2. 5868 In the figure in Section 1.3.2, made KEi optional, and added text 5869 saying "The KEi payload SHOULD be included." 5871 In the figure in Section 1.3.2, maked KEr optional, and removed text 5872 saying "KEi and KEr are required for rekeying an IKE SA." 5874 In Section 1.4, clarified that the half-closed connections being 5875 discussed are AH and ESP. 5877 Rearranged the end of Section 1.7, and added the new notation for 5878 moving text out of 3.10.1. 5880 Clarified the wording in the second paragraph of Section 2.2. This 5881 allowd the removal of the fourth paragraph, which previously had 5882 Clarif-2.2 in it. 5884 In section 2.5, removed "or later" from "version 2.0". 5886 Added the question for implementers about payload order at the end of 5887 Section 2.5. 5889 Corrected Section 2.7 based on Clarif-7-13 to say that you can't do 5890 ESP and AH at one time. 5892 In Section 2.8, clarified the wording about how to replace an IKE SA. 5894 Clarified the text in the last many paragraphs in Section 2.9. Also 5895 moved some text from near the beginning of 2.9 to the beginning of 5896 2.9.1. 5898 Removed some redundant text in Section 2.9 concerning creating a 5899 Child SA pair not in response to an arriving packet. 5901 Added the following to the end of the first paragraph of Section 5902 2.14: "The lengths of SK_d, SK_pi, and SK_pr are the key length of 5903 the agreed-to PRF." 5905 Added the restriction in Section 2.15 that all PRFs used with IKEv2 5906 MUST take variable-sized keys. 5908 In Section 2.17, removed "If multiple IPsec protocols are negotiated, 5909 keying material is taken in the order in which the protocol headers 5910 will appear in the encapsulated packet" because multiple IPsec 5911 protocols cannot be negotiated at one time. 5913 Added the material from Clarif-5.12 to Section 2.18. 5915 Changed "hash of" to "expected value of" in Section 2.23. 5917 In the bulleted list in Section 2.23, replaced "this end" with a 5918 clearer description of which system is being discussed. 5920 Added the paragraph at the beginning of Section 3 about 5921 interoperability and UNSPECIFIED values ("In the tables in this 5922 section..."). 5924 Fixed Section 3.3 to not include proposal that include both AH and 5925 ESP. Ditto for the "Proposal #" bullet in Section 3.3.1. 5927 In the description of ID_FQDN in Section 3.5, added "All characters 5928 in the ID_FQDN are ASCII; this follows that for an "internationalized 5929 domain name" as defined in [IDNA]." 5931 In Section 3.8, shortened and clarified the description of "RSA 5932 Digital Signature". 5934 In Section 3.10, shortened and clarified the description of "Protocol 5935 ID". 5937 In Section 3.15, "The requested address is valid until the expiry 5938 time defined with the INTERNAL_ADDRESS_EXPIRY attribute or there are 5939 no IKE SAs between the peers" is shortened to just "The requested 5940 address is valid until there are no IKE SAs between the peers." 5942 In Section 3.15.1, changed "INTERNAL_IP6_NBNS" to unspecified. 5944 Made [ADDRIPV6] an informative reference instead of a normative 5945 reference and updated it. 5947 Made [PKCS1] a normative reference instead of an informative 5948 reference and changed the pointer to RFC 3447. 5950 E.3. Changes from draft -00 to draft -01 5952 In Section 1.5, added "request" to first sentence to make it "If an 5953 encrypted IKE request packet arrives on port 500 or 4500 with an 5954 unrecognized SPI...". 5956 In Section 3.3, fifth paragraph, upped the number of transforms for 5957 AH and ESP by one each to account for ESN, which is now mandatory. 5959 In Section 2.1, added "or equal to" in "The responder MUST remember 5960 each response until it receives a request whose sequence number is 5961 larger than or equal to the sequence number in the response plus its 5962 window size." 5964 In Section 2.18, removed " Note that this may not work if the new IKE 5965 SA's PRF has a fixed key size because the output of the PRF may not 5966 be of the correct size." because it is no longer relevant. 5968 E.4. Changes from draft -01 to draft -02 5970 Many grammatical fixes. 5972 In Section 1.2, reworded Clarif-4.3 to be clearer. 5974 In Section 1.3.3, reworded 3.10.1-16393 and Clarif-5.4 to remove 5975 redundant text. 5977 In Section 2.13, replaced text about variable length keys with 5978 clearer explanation and requirement on non-HMAC PRFs. Also added 5979 "preferred" to Section 2.14 for the key length, and removed redundant 5980 text. 5982 In Section 2.14, removed the "half and half" description and replaced 5983 it with exceptions for RFC4434 and RFC4615. 5985 Removed the now-redundant "All PRFs used with IKEv2 MUST take 5986 variable-sized keys" from Section 2.15. 5988 In Section 2.15, added "(IKE_SA_INIT response)" after "of the second 5989 message" and "(IKE_SA_INIT request)" after "the first message". 5991 In Section 2.17, simplified because there are no more bundles. "A 5992 single Child SA negotiation may result in multiple security 5993 associations. ESP and AH SAs exist in pairs (one in each 5994 direction)." becomes "For ESP and AH, a single Child SA negotiation 5995 results in two security associations (one in each direction)." 5997 In section 3.3, made the example of combinations of algorithms and 5998 the contents of the first proposal clearer. 6000 Added Clarif-4.4 to the end of Section 3.3.2. 6002 Reordered Section 3.3.5 and added Clarif-7.11. 6004 Clarified Section 3.3.6 about choosing a single proposal. Also added 6005 second paragraph about transforms not understood, and clarified third 6006 paragraph about picking D-H groups. 6008 Moved 3.10.1-16392 from Section 3.6 to 3.7. 6010 In Section 3.10, clarified 3.10.1-16394. 6012 Updated Section 6 to indicate that there is nothing new for IANA in 6013 this spec. Also removed the definition of "Expert Review" from 6014 Section 1.6 for the same reason. 6016 In Appendix A, removed "and not commit any state to an exchange until 6017 the initiator can be cryptographically authenticated" because that 6018 was only true in an earlier version of IKEv2. 6020 E.5. Changes from draft -02 to draft -03 6022 In Section 1.3, changed "If the responder rejects the Diffie-Hellman 6023 group of the KEi payload, the responder MUST reject the request and 6024 indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD 6025 Notification payload." to "If the responder selects a proposal using 6026 a different Diffie-Hellman group (other than NONE), the responder 6027 MUST reject the request and indicate its preferred Diffie-Hellman 6028 group in the INVALID_KE_PAYLOAD Notification payload. 6030 In Section 2.3, added the last two paragraphs covering why you 6031 initiator's SPI and/or IP to differentiate if this is a "half-open" 6032 IKE SA or a new request. Also removed similar text from Section 2.2. 6034 In Section 2.5, added "Payloads sent in IKE response messages MUST 6035 NOT have the critical flag set. Note that the critical flag applies 6036 only to the payload type, not the contents. If the payload type is 6037 recognized, but the payload contains something which is not (such as 6038 an unknown transform inside an SA payload, or an unknown Notify 6039 Message Type inside a Notify payload), the critical flag is ignored." 6041 In Section 2.6, moved the text about {{ 3.10.1-16390 }} later in the 6042 section. Also reworded the text to make it clearer what the COOKIE 6043 is for. 6045 Moved text from {{ Clarif-2.1 }} from Section 2.6 to Section 2.7. 6047 In Section 2.13, added "(see Section 3.3.5 for the defintion of the 6048 Key Length transform attribute)". 6050 In Section 2.17, change the description of the keying material from 6051 the list with two bullets to a clearer list. 6053 In Section 2.23, added "Implementations MUST process received UDP- 6054 encapsulated ESP packets even when no NAT was detected." 6055 In Section 3.3, changed "Each proposal may contain a" to "Each 6056 proposal contains a". 6058 Added the asterisks to the transform type table in Section 3.3.2 and 6059 the types table in 3.3.3 to foreshadow future developments. 6061 In Section 3.3.2, changed the following algorithms to (UNSPECIFIED) 6062 because the RFCs listed didn't really specify how to implement them 6063 in an interoperable fashion: 6065 Encryption Algorithms 6066 ENCR_DES_IV64 1 (RFC1827) 6067 ENCR_3IDEA 8 (RFC2451) 6068 ENCR_DES_IV32 9 6069 Pseudo-random Functions 6070 PRF_HMAC_TIGER 3 (RFC2104) 6071 Integrity Algorithms 6072 AUTH_DES_MAC 3 6073 AUTH_KPDK_MD5 4 (RFC1826) 6075 In Section 3.4, added "(other than NONE)" to the second-to-last 6076 paragraph. 6078 Rewrote the third paragraph of Section 3.14 to talk about other 6079 modes, and to clarify which encryption and integrity protection we 6080 are talking about. 6082 Changed the "Initialization Vector" bullet in Section 3.14 to specify 6083 better what is needed for the IV. Upgraded the SHOULDs to MUSTs. 6084 Also added the reference for [MODES]. 6086 In Section 5, in the second-to-last paragraph, changed "a public-key- 6087 based" to "strong" to match the wording in Section 2.16. 6089 E.6. Changes from draft -03 to draft-ietf-ipsecme-ikev2bis-00 6091 Changed the document's filename to draft-ietf-ipsecme-ikev2bis-00. 6092 Added Yoav Nir as a co-author. 6094 In many places in the document, changed "and/or" to "or" when talking 6095 about combinations of ESP and AH SAs. For example, in the intro, it 6096 said "can be used to efficiently establish SAs for Encapsulating 6097 Security Payload (ESP) and/or Authentication Header (AH)". This is 6098 changed to "or" to indicate that you can only establish one type of 6099 SA at a time. 6101 In Section 1, clarified that RFC 4306 already replaced IKEv1, and 6102 that this document replaces RFC 4306. Also fixed Section 2.5 for 6103 similar issue. Also updated the Abstract to cover this. 6105 In Section 2.15, in the responder's signed octets, changed: 6107 RestOfRespIDPayload = IDType | RESERVED | InitIDData 6108 to 6109 RestOfRespIDPayload = IDType | RESERVED | RespIDData 6111 In 2.16, changed "strong" back to "public key signature based" to 6112 make it the same as 4306. 6114 In section 3.10, added "and the field must be empty" to make it clear 6115 that a zero-length SPI is really empty. 6117 E.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to 6118 draft-ietf-ipsecme-ikev2bis-01 6120 Throughout, changed "IKE_SA" to "IKE SA", and changed "CHILD_SA" to 6121 "Child SA" (except left "CREATE_CHILD_SA" alone). 6123 Added the middle sentence in the Abstract to say what IKE actually 6124 does. 6126 Added in section 1 "(unless there is failure setting up the AH or ESP 6127 Child SA, in which case the IKE SA is still established without IPsec 6128 SA)". 6130 Clarified the titles of 1.1.1, 1.1.2, and 1.1.3. 6132 In 1.1.2, changed "If there is an inner IP header, the inner 6133 addresses will be the same as the outer addresses." because we are 6134 talking about transport mode here. 6136 Added reference to section 2.14 to setion 1.2 and 1.3. 6138 In 1.2, clarified what is and isn't encrypted in a message. 6140 Added the following to 1.2: "If the IDr proposed by the initiator is 6141 not acceptable to the responder, the responder might use some other 6142 IDr to finish the exchange. If the initiator then does not accept 6143 that fact that responder used different IDr than the one that was 6144 requested, the initiator can close the SA after noticing the fact." 6146 Moved the paragraph beginning "All messages following..." from 1.3 up 6147 to 1.2, and reworded it to apply to all the cases it covers. 6149 At the end of section 1.3.1, clarified that the responder is the one 6150 who controls whether non-first-fragments will be sent, and reworded 6151 the paragraph. 6153 In section 1.3.3, added "The Protocol ID field of the REKEY_SA 6154 notification is set to match the protocol of the SA we are rekeying, 6155 for example, 3 for ESP and 2 for AH." [Issue #10] 6157 In 1.3.2, added "of the SA payload" to "New initiator and responder 6158 SPIs are supplied in the SPI fields." 6160 In 1.3.3, fixed the art. 6162 <-- HDR, SK {SA, Nr, [KEr], 6163 Si, TSr} 6164 becomes 6165 <-- HDR, SK {SA, Nr, [KEr], 6166 TSi, TSr} 6168 In 1.4 and 2.18, changed "replaced for the purpose of rekeying" to 6169 "rekeyed". 6171 Split out the SA deletion material from section 1.4 into its own 6172 subsection, 1.4.1. 6174 Clarified which bits are set at the end of Section 1.5. 6176 In 1.7, added "That is, the version number is *not* changed from RFC 6177 4306.". 6179 In 2.1, added wording about retransmissions needing to be identical. 6181 In 2.2, added "or rekeyed" to "In the unlikely event that Message IDs 6182 grow too large to fit in 32 bits, the IKE SA MUST be closed" 6184 In 2.2, moved the sentence "Rekeying an IKE SA resets the sequence 6185 numbers." up higher so it would be more likely to be seen. [Issue 6186 #15] 6188 Moved the definition of "original initiator" from 2.8 into 2.2 6189 because that is where it is first used. 6191 In 2.4, added "fresh (i.e., not retransmitted)" to "If a 6192 cryptographically protected message has been received from the other 6193 side recently". Also added the sentence saying that liveness checks 6194 are sometimes call dead peer detection. 6196 Removed the question to implementers about payload order in 2.5. 6198 Changed the title of 2.6 to "IKE SA SPIs and Cookies". Also, in the 6199 paragraph that describes how to implement the responder, changed the 6200 lower-case "should" to "can" to emphasize that this is a choice. 6202 Added the second paragraph in 2.6 to make it clear that the SPI is 6203 used for mapping. 6205 In section 2.6, upgraded "needs to choose them so as to be unique 6206 identifiers of an IKE_SA" to a MUST. 6208 Added sentences at the end of 2.6 eplaining wny the initiator should 6209 limit the number of responses it sends out. 6211 In 2.6.1, added the example of the shorter exchange; this is copied 6212 from RFC 4718 but was dropped in early drafts of this document. 6214 Added the paragraph to 2.7 that describes needing two proposals if 6215 you are having both normal ciphers and combined-mode ciphers. [Issue 6216 #20]. 6218 In section 2.8, added "Note that, when rekeying, the new Child SA MAY 6219 have different traffic selectors and algorithms than the old one." 6221 Added a note in 2.9 that PFKEY applies only to IKEv1. Also added 6222 that unknown traffic selector types are not returned in narrowed 6223 responses. 6225 Added note in the first paragraph of Setion 2.9.1 about decorrelated 6226 policies preventing the problem mentioned. 6228 In 2.12, removed "In particular, it MUST forget the secrets used in 6229 the Diffie-Hellman calculation and any state that may persist in the 6230 state of a pseudo-random number generator that could be used to 6231 recompute the Diffie-Hellman secrets." 6233 In 2.15, noted that the retry could happen multiple times for 6234 different reasons. 6236 In section 2.16, changed "This shared key generated during an IKE 6237 exchange" to "This key". 6239 At the end of 2.19, added statement that FAILED_CP_REQUIRED is not 6240 fatal to the IKE SA. 6242 Added the reference to ROHCV2 to the end of 2.22. 6244 In 2.23, changed "can negotiate" to "will use". for UDP 6245 encapsulation. Added "or 4500" to "...MUST be sent from and to UDP 6246 port 500". Also removed the text about why not to do NAT-traversal 6247 over port 500 because we later say you can't do that anyway. [Issue 6248 #27] Also removed the last paragraph, which obliquely pointed to 6249 MOBIKE. More will be added later on MOBIKE. 6251 In 3.1, removed "and orderings of messages" from "Exchange type". 6252 [Issue #29] 6254 In 3.1, added "This bit changes to reflect who initiated the last 6255 rekey of the IKE SA." to the description of the Initiator bit. 6257 In 3.3, added a long example of why you might use a Proposal 6258 structure because of combined-mode algorithms. [Issue #42] 6260 In 3.3.2, changed "is unnecessary because the last Proposal could be 6261 identified from the length of the SA" to "is unnecessary because the 6262 last transform could be identified from the length of the proposal." 6264 Added reference to AEAD to 3.3.2 and 3.3.3. 6266 Added the reference to RFC 2104 back for PRF_HMAC_TIGER in 3.3.2. 6267 [Issue #33] 6269 Added note at the bottom of 3.3.2 to see the IANA registry. 6271 In 3.3.4, removed all the "this could happen in the future" stuff 6272 because it already happened. 6274 Added a reference to email address internationalization to 3.5, 6275 making the address binary (not ASCII). 6277 In the table in 3.6, made "Authority Revocation List (ARL) 8" and 6278 "X.509 Certificate - Attribute 10" unspecified. 6280 In 3.7, changed the last sentence of the first paragraph to eliminate 6281 the non-protocol SHOULD. 6283 In 3.13.1, added "(including protocol 0)" for the start port and end 6284 port. 6286 In 3.14, updated the discussion of initialization modes to reflect 6287 that it is only about CBC, and that other specs have to specify their 6288 own IVs. 6290 In 3.15.1, added a pointer to 3.15.3. In the entries for 6291 INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET, added a pointer to 6292 3.15.2. 6294 In 3.15.4, added "The IKE SA is still created even if the initial 6295 Child SA cannot be created because of this failure." 6297 Changed "EAP exchange" to "EAP authentication" in 5. 6299 Removed "In particular, these exponents MUST NOT be derived from 6300 long-lived secrets like the seed to a pseudo-random generator that is 6301 not erased after use." from section 5 because it is not possible in 6302 most implementations to do so. 6304 Updated a bunch of reference to their newer versions. 6306 Added "[V+]" to the end of the exchanges in C.4 and C.5. 6308 Added two more response templates to Appendix C.1. Added another 6309 response template in Appendix C.2. Added two more responses in 6310 Appendix C.4. 6312 E.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to 6313 draft-ietf-ipsecme-ikev2bis-02 6315 In section 1.3.1, added "Failure of an attempt to create a CHILD SA 6316 SHOULD NOT tear down the IKE SA: there is no reason to lose the work 6317 done to set up the IKE SA. When an IKE SA is not created, the error 6318 message return SHOULD NOT be encrypted because the other party will 6319 not be able to authenticate that message." This may be changed again 6320 in the future. [Issue #9] 6322 In section 1.3.2, changed "The KEi payload SHOULD be included" to be 6323 "The KEi payload MUST be included". This also lead to changes in 6324 section 2.18. The square brackets around "g^ir (new)" in the 6325 SKEYSEED calculation are eliminated, and the requirement language in 6326 the paragraph starting "The main rekeying" is changed from SHOULD to 6327 MUST. [Issue #50] 6329 In section 1.3.2, changed "The window size starts at 1 for any new 6330 IKE SA." to "The first IKE requests from both sides on the new IKE SA 6331 will have message ID 0. The old IKE SA retains its numbering, so any 6332 further requests (for example, to delete the IKE SA) will have 6333 consecutive numbering. The new IKE SA also has its window size reset 6334 to 1, and the initiator in this rekey exchange is the new "original 6335 initiator" of the new IKE SA." [Issue #65] 6337 Added to section 1.5: For a one-way INVALID_IKE_SPI notification for 6338 an unrecognized SPI, the responder SHOULD copy the Exchange Type from 6339 the request. [Issue #46] 6341 In 2.1, at the end of the paragraph about retransmission timers, 6342 added "In order to allow saving memory, responders are allowed to 6343 forget response after a timeout of several minutes. If the responder 6344 receives a retransmitted request for which it has already forgotten 6345 the response, it MUST ignore the request (and not, for example, 6346 attempt constructing a new response)." [Issue #14] 6348 In 2.6, added: "Also, incorporating Ni in the hash prevents an 6349 attacker from fetching one one cookie from the other end, and then 6350 initiating many IKE_SA_INIT exchanges all with different initiator 6351 SPIs (and perhaps port numbers) so that the responder thinks that 6352 there are lots of machines behind one NAT box who are all trying to 6353 connect." [Issue #19] 6355 Added text for the new 2.8.2, and bumped the section number of the 6356 old 2.8.2 to 2.8.3. [Issue #22] 6358 Added a reference to the end of 2.12 on key reuse. 6360 Added to the end of the first paragraph in 2.19: Note, however, it is 6361 usual to only assign one IP address during the IKE_AUTH exchange. 6362 That address persists at least until the deletion of the IKE SA. 6363 [Issue #79] 6365 Added the following to 2.23: An initiator can float to port 4500, 6366 regardless whether or not there is NAT, even at the beginning of IKE. 6367 When either side is using port 4500, sending with UDP encapsulation 6368 is not required, but understanding received packets with UDP 6369 encapsulation is required. UDP encapsulation MUST NOT be done on 6370 port 500. If NAT-T is supported (that is, if NAT_DETECTION_*_IP 6371 payloads were exchanged during IKE_SA_INIT), all devices MUST be able 6372 to receive and process both UDP encapsulated and non-UDP encapsulated 6373 packets at any time. Either side can decide whether or not to use 6374 UDP encapsulation irrespective of the choice made by the other side. 6375 However, if a NAT is detected, both devices MUST send UDP 6376 encapsulated packets. [Issue #40] 6378 The second-to-last paragraph in section 3.4 is changed to: The DH 6379 Group # identifies the Diffie-Hellman group in which the Key Exchange 6380 Data was computed (see Section 3.3.2. This Group # MUST match a DH 6381 Group specified in a proposal in the SA payload that is sent in the 6382 same message, and SHOULD match the DH group in the first group in the 6383 first proposal, if such exists. If none of the proposals in that SA 6384 payload specifies a DH Group, the KE payload MUST NOT be present. If 6385 the selected proposal uses a different Diffie-Hellman group (other 6386 than NONE), the message MUST be rejected with a Notify payload of 6387 type INVALID_KE_PAYLOAD. [Issue #30] 6389 In 3.10.1, changed the definition of NO_PROPOSAL_CHOSEN, 14, to: None 6390 of the proposed crypto suites was acceptable. This can be sent in 6391 any case where the offered proposal (including but not limited to SA 6392 payload values, USE_TRANSPORT_MODE notify, IPCOMP_SUPPORTED notify) 6393 are not acceptable for the responder. This can also be used as 6394 "generic" Child SA error when Child SA cannot be created for some 6395 other reason. See also Section 2.7. [Issue #81] 6397 In the description of IVs in 3.14, reorganized the text a bit to 6398 emphasize when we are and are not talking about CBC. [Issue #68] 6400 Added the following to section 5 (Security Considerations): "The 6401 IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator has 6402 been authenticated. As a result, an implementation of this protocol 6403 needs to be completely robust when deployed on any insecure network. 6404 Implementation vulnerabilities, particularly denial-of-service 6405 attacks, can be exploited by unauthenticated peers. This issue is 6406 particularly worrisome because of the unlimited number of messages in 6407 EAP-based authentication." [Issue #62] 6409 Added new Appendix D, "Significant Changes from RFC 4306", as a 6410 placeholder for now. [Issue #3] 6412 Authors' Addresses 6414 Charlie Kaufman 6415 Microsoft 6416 1 Microsoft Way 6417 Redmond, WA 98052 6418 US 6420 Phone: 1-425-707-3335 6421 Email: charliek@microsoft.com 6423 Paul Hoffman 6424 VPN Consortium 6425 127 Segre Place 6426 Santa Cruz, CA 95060 6427 US 6429 Phone: 1-831-426-9827 6430 Email: paul.hoffman@vpnc.org 6431 Yoav Nir 6432 Check Point Software Technologies Ltd. 6433 5 Hasolelim St. 6434 Tel Aviv 67897 6435 Israel 6437 Email: ynir@checkpoint.com 6439 Pasi Eronen 6440 Nokia Research Center 6441 P.O. Box 407 6442 FIN-00045 Nokia Group 6443 Finland 6445 Email: pasi.eronen@nokia.com