idnits 2.17.1 draft-ietf-ipsecme-ikev2bis-05.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 == Line 2999 has weird spacing: '... TSr entri...' == 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 (October 5, 2009) is 5316 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 2232, but not defined == Missing Reference: 'KEi' is mentioned on line 6051, but not defined == Missing Reference: 'KEr' is mentioned on line 6420, but not defined == Missing Reference: 'CP' is mentioned on line 765, but not defined -- Looks like a reference, but probably isn't: '0' on line 4059 -- Looks like a reference, but probably isn't: '1' on line 4060 == Missing Reference: 'IDr' is mentioned on line 5995, 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) Summary: 3 errors (**), 0 flaws (~~), 12 warnings (==), 20 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: April 8, 2010 Check Point 8 P. Eronen 9 Nokia 10 October 5, 2009 12 Internet Key Exchange Protocol: IKEv2 13 draft-ietf-ipsecme-ikev2bis-05 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 April 8, 2010. 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 . . 8 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 . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . 19 84 1.6. Requirements Terminology . . . . . . . . . . . . . . . . 20 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 . . . . 31 94 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 32 95 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 33 96 2.8.1. Simultaneous Child SA rekeying . . . . . . . . . . . 35 97 2.8.2. Simultaneous IKE SA Rekeying . . . . . . . . . . . . 37 98 2.8.3. Rekeying the IKE SA Versus Reauthentication . . . . . 38 99 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 39 100 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 41 101 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 42 102 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 42 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 . . . . . . . . 49 109 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . . 50 110 2.19. Requesting an Internal Address on a Remote Network . . . 51 111 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 53 112 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 53 113 2.21.1. Error Handling in IKE_SA_INIT . . . . . . . . . . . . 54 114 2.21.2. Error Handling in IKE_AUTH . . . . . . . . . . . . . 54 115 2.21.3. Error Handling after IKE SA is Authenticated . . . . 55 116 2.21.4. Error Handling Outside IKE SA . . . . . . . . . . . . 56 117 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 56 118 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 58 119 2.23.1. Transport Mode NAT Traversal . . . . . . . . . . . . 61 120 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 65 121 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 65 122 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 66 123 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 69 124 3.3. Security Association Payload . . . . . . . . . . . . . . 71 125 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 73 126 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 75 127 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 78 128 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 78 129 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 79 130 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 81 131 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 82 132 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 83 133 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 86 134 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 88 135 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 90 136 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 91 137 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 92 138 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 93 139 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 96 140 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 98 141 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 99 142 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 100 143 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 102 144 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 104 145 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 105 146 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 108 147 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 110 148 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 111 149 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 112 150 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 113 151 5. Security Considerations . . . . . . . . . . . . . . . . . . . 115 152 5.1. Traffic selector authorization . . . . . . . . . . . . . 118 153 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 119 154 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 119 155 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 120 156 8.1. Normative References . . . . . . . . . . . . . . . . . . 120 157 8.2. Informative References . . . . . . . . . . . . . . . . . 121 158 Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 126 159 Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 127 160 B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 127 161 B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 127 163 Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 128 164 C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 128 165 C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 129 166 C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 130 167 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying 168 Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 131 169 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 131 170 C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 131 171 Appendix D. Significant Changes from RFC 4306 . . . . . . . . . 131 172 Appendix E. Changes Between Internet Draft Versions . . . . . . 132 173 E.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 132 174 E.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 132 175 E.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 134 176 E.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 135 177 E.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 136 178 E.6. Changes from draft -03 to 179 draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 137 180 E.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to 181 draft-ietf-ipsecme-ikev2bis-01 . . . . . . . . . . . . . 138 182 E.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to 183 draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 142 184 E.9. Changes from draft-ietf-ipsecme-ikev2bis-01 to 185 draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 144 186 E.10. Changes from draft-ietf-ipsecme-ikev2bis-02 to 187 draft-ietf-ipsecme-ikev2bis-03 . . . . . . . . . . . . . 145 188 E.11. Changes from draft-ietf-ipsecme-ikev2bis-03 to 189 draft-ietf-ipsecme-ikev2bis-04 . . . . . . . . . . . . . 145 190 E.12. Changes from draft-ietf-ipsecme-ikev2bis-04 to 191 draft-ietf-ipsecme-ikev2bis-05 . . . . . . . . . . . . . 146 192 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 148 194 1. Introduction 196 {{ An introduction to the differences between RFC 4306 [IKEV2] and 197 this document is given at the end of Section 1. It is put there 198 (instead of here) to preserve the section numbering of RFC 4306. }} 200 IP Security (IPsec) provides confidentiality, data integrity, access 201 control, and data source authentication to IP datagrams. These 202 services are provided by maintaining shared state between the source 203 and the sink of an IP datagram. This state defines, among other 204 things, the specific services provided to the datagram, which 205 cryptographic algorithms will be used to provide the services, and 206 the keys used as input to the cryptographic algorithms. 208 Establishing this shared state in a manual fashion does not scale 209 well. Therefore, a protocol to establish this state dynamically is 210 needed. This memo describes such a protocol -- the Internet Key 211 Exchange (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI], 212 2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 replaced all of those RFCs. 213 IKEv2 was defined in [IKEV2] (RFC 4306) and was clarified in [Clarif] 214 (RFC 4718). This document replaces and updates RFC 4306 and RFC 215 4718. IKEv2 was a change to the IKE protocol that was not backward 216 compatible. In contrast, the current document not only provides a 217 clarification of IKEv2, but makes minimum changes to the IKE 218 protocol. 220 IKE performs mutual authentication between two parties and 221 establishes an IKE security association (SA) that includes shared 222 secret information that can be used to efficiently establish SAs for 223 Encapsulating Security Payload (ESP) [ESP] or Authentication Header 224 (AH) [AH] and a set of cryptographic algorithms to be used by the SAs 225 to protect the traffic that they carry. In this document, the term 226 "suite" or "cryptographic suite" refers to a complete set of 227 algorithms used to protect an SA. An initiator proposes one or more 228 suites by listing supported algorithms that can be combined into 229 suites in a mix-and-match fashion. IKE can also negotiate use of IP 230 Compression (IPComp) [IP-COMP] in connection with an ESP or AH SA. 231 The SAs for ESP or AH that get set up through that IKE SA we call 232 "Child SAs". 234 All IKE communications consist of pairs of messages: a request and a 235 response. The pair is called an "exchange". We call the first 236 messages establishing an IKE SA IKE_SA_INIT and IKE_AUTH exchanges 237 and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL 238 exchanges. In the common case, there is a single IKE_SA_INIT 239 exchange and a single IKE_AUTH exchange (a total of four messages) to 240 establish the IKE SA and the first Child SA. In exceptional cases, 241 there may be more than one of each of these exchanges. In all cases, 242 all IKE_SA_INIT exchanges MUST complete before any other exchange 243 type, then all IKE_AUTH exchanges MUST complete, and following that 244 any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur 245 in any order. In some scenarios, only a single Child SA is needed 246 between the IPsec endpoints, and therefore there would be no 247 additional exchanges. Subsequent exchanges MAY be used to establish 248 additional Child SAs between the same authenticated pair of endpoints 249 and to perform housekeeping functions. 251 IKE message flow always consists of a request followed by a response. 252 It is the responsibility of the requester to ensure reliability. If 253 the response is not received within a timeout interval, the requester 254 needs to retransmit the request (or abandon the connection). 256 The first request/response of an IKE session (IKE_SA_INIT) negotiates 257 security parameters for the IKE SA, sends nonces, and sends Diffie- 258 Hellman values. 260 The second request/response (IKE_AUTH) transmits identities, proves 261 knowledge of the secrets corresponding to the two identities, and 262 sets up an SA for the first (and often only) AH or ESP Child SA 263 (unless there is failure setting up the AH or ESP Child SA, in which 264 case the IKE SA is still established without IPsec SA). 266 The types of subsequent exchanges are CREATE_CHILD_SA (which creates 267 a Child SA) and INFORMATIONAL (which deletes an SA, reports error 268 conditions, or does other housekeeping). Every request requires a 269 response. An INFORMATIONAL request with no payloads (other than the 270 empty Encrypted payload required by the syntax) is commonly used as a 271 check for liveness. These subsequent exchanges cannot be used until 272 the initial exchanges have completed. 274 In the description that follows, we assume that no errors occur. 275 Modifications to the flow should errors occur are described in 276 Section 2.21. 278 1.1. Usage Scenarios 280 IKE is expected to be used to negotiate ESP or AH SAs in a number of 281 different scenarios, each with its own special requirements. 283 1.1.1. Security Gateway to Security Gateway Tunnel Mode 285 +-+-+-+-+-+ +-+-+-+-+-+ 286 | | IPsec | | 287 Protected |Tunnel | tunnel |Tunnel | Protected 288 Subnet <-->|Endpoint |<---------->|Endpoint |<--> Subnet 289 | | | | 290 +-+-+-+-+-+ +-+-+-+-+-+ 292 Figure 1: Security Gateway to Security Gateway Tunnel 294 In this scenario, neither endpoint of the IP connection implements 295 IPsec, but network nodes between them protect traffic for part of the 296 way. Protection is transparent to the endpoints, and depends on 297 ordinary routing to send packets through the tunnel endpoints for 298 processing. Each endpoint would announce the set of addresses 299 "behind" it, and packets would be sent in tunnel mode where the inner 300 IP header would contain the IP addresses of the actual endpoints. 302 1.1.2. Endpoint-to-Endpoint Transport Mode 304 +-+-+-+-+-+ +-+-+-+-+-+ 305 | | IPsec transport | | 306 |Protected| or tunnel mode SA |Protected| 307 |Endpoint |<---------------------------------------->|Endpoint | 308 | | | | 309 +-+-+-+-+-+ +-+-+-+-+-+ 311 Figure 2: Endpoint to Endpoint 313 In this scenario, both endpoints of the IP connection implement 314 IPsec, as required of hosts in [IPSECARCH]. Transport mode will 315 commonly be used with no inner IP header. A single pair of addresses 316 will be negotiated for packets to be protected by this SA. These 317 endpoints MAY implement application layer access controls based on 318 the IPsec authenticated identities of the participants. This 319 scenario enables the end-to-end security that has been a guiding 320 principle for the Internet since [ARCHPRINC], [TRANSPARENCY], and a 321 method of limiting the inherent problems with complexity in networks 322 noted by [ARCHGUIDEPHIL]. Although this scenario may not be fully 323 applicable to the IPv4 Internet, it has been deployed successfully in 324 specific scenarios within intranets using IKEv1. It should be more 325 broadly enabled during the transition to IPv6 and with the adoption 326 of IKEv2. 328 It is possible in this scenario that one or both of the protected 329 endpoints will be behind a network address translation (NAT) node, in 330 which case the tunneled packets will have to be UDP encapsulated so 331 that port numbers in the UDP headers can be used to identify 332 individual endpoints "behind" the NAT (see Section 2.23). 334 1.1.3. Endpoint to Security Gateway Tunnel Mode 336 +-+-+-+-+-+ +-+-+-+-+-+ 337 | | IPsec | | Protected 338 |Protected| tunnel |Tunnel | Subnet 339 |Endpoint |<------------------------>|Endpoint |<--- and/or 340 | | | | Internet 341 +-+-+-+-+-+ +-+-+-+-+-+ 343 Figure 3: Endpoint to Security Gateway Tunnel 345 In this scenario, a protected endpoint (typically a portable roaming 346 computer) connects back to its corporate network through an IPsec- 347 protected tunnel. It might use this tunnel only to access 348 information on the corporate network, or it might tunnel all of its 349 traffic back through the corporate network in order to take advantage 350 of protection provided by a corporate firewall against Internet-based 351 attacks. In either case, the protected endpoint will want an IP 352 address associated with the security gateway so that packets returned 353 to it will go to the security gateway and be tunneled back. This IP 354 address may be static or may be dynamically allocated by the security 355 gateway. In support of the latter case, IKEv2 includes a mechanism 356 (namely, configuration payloads) for the initiator to request an IP 357 address owned by the security gateway for use for the duration of its 358 SA. 360 In this scenario, packets will use tunnel mode. On each packet from 361 the protected endpoint, the outer IP header will contain the source 362 IP address associated with its current location (i.e., the address 363 that will get traffic routed to the endpoint directly), while the 364 inner IP header will contain the source IP address assigned by the 365 security gateway (i.e., the address that will get traffic routed to 366 the security gateway for forwarding to the endpoint). The outer 367 destination address will always be that of the security gateway, 368 while the inner destination address will be the ultimate destination 369 for the packet. 371 In this scenario, it is possible that the protected endpoint will be 372 behind a NAT. In that case, the IP address as seen by the security 373 gateway will not be the same as the IP address sent by the protected 374 endpoint, and packets will have to be UDP encapsulated in order to be 375 routed properly. 377 1.1.4. Other Scenarios 379 Other scenarios are possible, as are nested combinations of the 380 above. One notable example combines aspects of 1.1.1 and 1.1.3. A 381 subnet may make all external accesses through a remote security 382 gateway using an IPsec tunnel, where the addresses on the subnet are 383 routed to the security gateway by the rest of the Internet. An 384 example would be someone's home network being virtually on the 385 Internet with static IP addresses even though connectivity is 386 provided by an ISP that assigns a single dynamically assigned IP 387 address to the user's security gateway (where the static IP addresses 388 and an IPsec relay are provided by a third party located elsewhere). 390 1.2. The Initial Exchanges 392 Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH 393 exchanges (known in IKEv1 as Phase 1). These initial exchanges 394 normally consist of four messages, though in some scenarios that 395 number can grow. All communications using IKE consist of request/ 396 response pairs. We'll describe the base exchange first, followed by 397 variations. The first pair of messages (IKE_SA_INIT) negotiate 398 cryptographic algorithms, exchange nonces, and do a Diffie-Hellman 399 exchange [DH]. 401 The second pair of messages (IKE_AUTH) authenticate the previous 402 messages, exchange identities and certificates, and establish the 403 first Child SA. Parts of these messages are encrypted and integrity 404 protected with keys established through the IKE_SA_INIT exchange, so 405 the identities are hidden from eavesdroppers and all fields in all 406 the messages are authenticated. (See Section 2.14 for information on 407 how the encryption keys are generated.) 409 All messages following the initial exchange are cryptographically 410 protected using the cryptographic algorithms and keys negotiated in 411 the the IKE_SA_INIT exchange. These subsequent messages use the 412 syntax of the Encrypted Payload described in Section 3.14, encrypted 413 with keys that are derived as described in Section 2.14. All 414 subsequent messages include an Encrypted Payload, even if they are 415 referred to in the text as "empty". For the CREATE_CHILD_SA, 416 IKE_AUTH, or IKE_INFORMATIONAL exchanges, the message following the 417 header is encrypted and the message including the header is integrity 418 protected using the cryptographic algorithms negotiated for the IKE 419 SA. 421 In the following descriptions, the payloads contained in the message 422 are indicated by names as listed below. 424 Notation Payload 425 ----------------------------------------- 426 AUTH Authentication 427 CERT Certificate 428 CERTREQ Certificate Request 429 CP Configuration 430 D Delete 431 E Encrypted 432 EAP Extensible Authentication 433 HDR IKE Header 434 IDi Identification - Initiator 435 IDr Identification - Responder 436 KE Key Exchange 437 Ni, Nr Nonce 438 N Notify 439 SA Security Association 440 TSi Traffic Selector - Initiator 441 TSr Traffic Selector - Responder 442 V Vendor ID 444 The details of the contents of each payload are described in section 445 3. Payloads that may optionally appear will be shown in brackets, 446 such as [CERTREQ], indicate that optionally a certificate request 447 payload can be included. 449 The initial exchanges are as follows: 451 Initiator Responder 452 ------------------------------------------------------------------- 453 HDR, SAi1, KEi, Ni --> 455 HDR contains the Security Parameter Indexes (SPIs), version numbers, 456 and flags of various sorts. The SAi1 payload states the 457 cryptographic algorithms the initiator supports for the IKE SA. The 458 KE payload sends the initiator's Diffie-Hellman value. Ni is the 459 initiator's nonce. 461 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 463 The responder chooses a cryptographic suite from the initiator's 464 offered choices and expresses that choice in the SAr1 payload, 465 completes the Diffie-Hellman exchange with the KEr payload, and sends 466 its nonce in the Nr payload. 468 At this point in the negotiation, each party can generate SKEYSEED, 469 from which all keys are derived for that IKE SA. The messages that 470 follow are encrypted and integrity protected in their entirety, with 471 the exception of the message headers. The keys used for the 472 encryption and integrity protection are derived from SKEYSEED and are 473 known as SK_e (encryption) and SK_a (authentication, a.k.a. integrity 474 protection). A separate SK_e and SK_a is computed for each 475 direction. In addition to the keys SK_e and SK_a derived from the DH 476 value for protection of the IKE SA, another quantity SK_d is derived 477 and used for derivation of further keying material for Child SAs. 478 The notation SK { ... } indicates that these payloads are encrypted 479 and integrity protected using that direction's SK_e and SK_a. 481 HDR, SK {IDi, [CERT,] [CERTREQ,] 482 [IDr,] AUTH, SAi2, 483 TSi, TSr} --> 485 The initiator asserts its identity with the IDi payload, proves 486 knowledge of the secret corresponding to IDi and integrity protects 487 the contents of the first message using the AUTH payload (see 488 Section 2.15). It might also send its certificate(s) in CERT 489 payload(s) and a list of its trust anchors in CERTREQ payload(s). If 490 any CERT payloads are included, the first certificate provided MUST 491 contain the public key used to verify the AUTH field. 493 The optional payload IDr enables the initiator to specify which of 494 the responder's identities it wants to talk to. This is useful when 495 the machine on which the responder is running is hosting multiple 496 identities at the same IP address. If the IDr proposed by the 497 initiator is not acceptable to the responder, the responder might use 498 some other IDr to finish the exchange. If the initiator then does 499 not accept that fact that responder used different IDr than the one 500 that was requested, the initiator can close the SA after noticing the 501 fact. 503 The initiator begins negotiation of a Child SA using the SAi2 504 payload. The final fields (starting with SAi2) are described in the 505 description of the CREATE_CHILD_SA exchange. 507 <-- HDR, SK {IDr, [CERT,] AUTH, 508 SAr2, TSi, TSr} 510 The responder asserts its identity with the IDr payload, optionally 511 sends one or more certificates (again with the certificate containing 512 the public key used to verify AUTH listed first), authenticates its 513 identity and protects the integrity of the second message with the 514 AUTH payload, and completes negotiation of a Child SA with the 515 additional fields described below in the CREATE_CHILD_SA exchange. 517 The recipients of messages 3 and 4 MUST verify that all signatures 518 and MACs are computed correctly and that the names in the ID payloads 519 correspond to the keys used to generate the AUTH payload. 521 If creating the Child SA during the IKE_AUTH exchange fails for some 522 reason, the IKE SA is still created as usual. The list of responses 523 in the IKE_AUTH exchange that do not prevent an IKE SA from being set 524 up include at least the following: NO_PROPOSAL_CHOSEN, 525 TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and 526 FAILED_CP_REQUIRED. 528 If the failure is related to creating the IKE SA (for example, 529 AUTHENTICATION_FAILED), the IKE SA is not created. Note that 530 although the IKE_AUTH messages are encrypted and integrity protected, 531 if the peer receiving this notification has not yet authenticated the 532 other end (or if the peer fails to authenticate the other end for 533 some reason), the information needs to be treated with caution. More 534 precisely, assuming that the MAC verifies correctly, the sender of 535 the error indication is known to be the responder of the IKE_SA_INIT 536 exchange, but the sender's identity cannot be assured. 538 Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads. 539 Thus, the SA payloads in the IKE_AUTH exchange cannot contain 540 Transform Type 4 (Diffie-Hellman Group) with any value other than 541 NONE. Implementations SHOULD omit the whole transform substructure 542 instead of sending value NONE. 544 1.3. The CREATE_CHILD_SA Exchange 546 The CREATE_CHILD_SA exchange is used to create new Child SAs and to 547 rekey both IKE SAs and Child SAs. This exchange consists of a single 548 request/response pair, and some of its function was referred to as a 549 phase 2 exchange in IKEv1. It MAY be initiated by either end of the 550 IKE SA after the initial exchanges are completed. 552 All messages following the initial exchange are cryptographically 553 protected using the cryptographic algorithms and keys negotiated in 554 the first two messages of the IKE exchange. These subsequent 555 messages use the syntax of the Encrypted Payload described in 556 Section 3.14, encrypted with keys that are derived as described in 557 Section 2.14. All subsequent messages include an Encrypted Payload, 558 even if they are referred to in the text as "empty". For both 559 messages in the CREATE_CHILD_SA, the message following the header is 560 encrypted and the message including the header is integrity protected 561 using the cryptographic algorithms negotiated for the IKE SA. 563 The CREATE_CHILD_SA is also used for rekeying IKE SAs and Child SAs. 564 An SA is rekeyed by creating a new SA and then deleting the old one. 565 This section describes the first part of rekeying, the creation of 566 new SAs; Section 2.8 covers the mechanics of rekeying, including 567 moving traffic from old to new SAs and the deletion of the old SAs. 568 The two sections must be read together to understand the entire 569 process of rekeying. 571 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this 572 section the term initiator refers to the endpoint initiating this 573 exchange. An implementation MAY refuse all CREATE_CHILD_SA requests 574 within an IKE SA. 576 The CREATE_CHILD_SA request MAY optionally contain a KE payload for 577 an additional Diffie-Hellman exchange to enable stronger guarantees 578 of forward secrecy for the Child SA. The keying material for the 579 Child SA is a function of SK_d established during the establishment 580 of the IKE SA, the nonces exchanged during the CREATE_CHILD_SA 581 exchange, and the Diffie-Hellman value (if KE payloads are included 582 in the CREATE_CHILD_SA exchange). 584 If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of 585 the SA offers MUST include the Diffie-Hellman group of the KEi. The 586 Diffie-Hellman group of the KEi MUST be an element of the group the 587 initiator expects the responder to accept (additional Diffie-Hellman 588 groups can be proposed). If the responder selects a proposal using a 589 different Diffie-Hellman group (other than NONE), the responder MUST 590 reject the request and indicate its preferred Diffie-Hellman group in 591 the INVALID_KE_PAYLOAD Notification payload. There are two octets of 592 data associated with this notification: the accepted D-H Group number 593 in big endian order. In the case of such a rejection, the 594 CREATE_CHILD_SA exchange fails, and the initiator will probably retry 595 the exchange with a Diffie-Hellman proposal and KEi in the group that 596 the responder gave in the INVALID_KE_PAYLOAD. 598 The responder sends a NO_ADDITIONAL_SAS notification to indicate that 599 a CREATE_CHILD_SA request is unacceptable because the responder is 600 unwilling to accept any more Child SAs on this IKE SA. Some minimal 601 implementations may only accept a single Child SA setup in the 602 context of an initial IKE exchange and reject any subsequent attempts 603 to add more. 605 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA Exchange 607 A Child SA may be created by sending a CREATE_CHILD_SA request. The 608 CREATE_CHILD_SA request for creating a new Child SA is: 610 Initiator Responder 611 ------------------------------------------------------------------- 612 HDR, SK {SA, Ni, [KEi], 613 TSi, TSr} --> 615 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 616 payload, optionally a Diffie-Hellman value in the KEi payload, and 617 the proposed traffic selectors for the proposed Child SA in the TSi 618 and TSr payloads. 620 The CREATE_CHILD_SA response for creating a new Child SA is: 622 <-- HDR, SK {SA, Nr, [KEr], 623 TSi, TSr} 625 The responder replies (using the same Message ID to respond) with the 626 accepted offer in an SA payload, and a Diffie-Hellman value in the 627 KEr payload if KEi was included in the request and the selected 628 cryptographic suite includes that group. 630 The traffic selectors for traffic to be sent on that SA are specified 631 in the TS payloads in the response, which may be a subset of what the 632 initiator of the Child SA proposed. 634 The USE_TRANSPORT_MODE notification MAY be included in a request 635 message that also includes an SA payload requesting a Child SA. It 636 requests that the Child SA use transport mode rather than tunnel mode 637 for the SA created. If the request is accepted, the response MUST 638 also include a notification of type USE_TRANSPORT_MODE. If the 639 responder declines the request, the Child SA will be established in 640 tunnel mode. If this is unacceptable to the initiator, the initiator 641 MUST delete the SA. Note: Except when using this option to negotiate 642 transport mode, all Child SAs will use tunnel mode. 644 The ESP_TFC_PADDING_NOT_SUPPORTED notification asserts that the 645 sending endpoint will NOT accept packets that contain Traffic Flow 646 Confidentiality (TFC) padding over the Child SA being negotiated. If 647 neither endpoint accepts TFC padding, this notification is included 648 in both the request and the response. If this notification is 649 included in only one of the messages, TFC padding can still be sent 650 in the other direction. 652 The NON_FIRST_FRAGMENTS_ALSO notification is used for fragmentation 653 control. See [IPSECARCH] for a fuller explanation. Both parties 654 need to agree to sending non-first fragments before either party does 655 so. It is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is 656 included in both the request proposing an SA and the response 657 accepting it. If the responder does not want to send or receive non- 658 first fragments, it only omits NON_FIRST_FRAGMENTS_ALSO notification 659 from its response, but does not reject the whole Child SA creation. 661 Failure of an attempt to create a CHILD SA SHOULD NOT tear down the 662 IKE SA: there is no reason to lose the work done to set up the IKE 663 SA. When an IKE SA is not created, the error message return SHOULD 664 NOT be encrypted because the other party will not be able to 665 authenticate that message. [[ Note: this text may be changed in the 666 future. ]] 668 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange 670 The CREATE_CHILD_SA request for rekeying an IKE SA is: 672 Initiator Responder 673 ------------------------------------------------------------------- 674 HDR, SK {SA, Ni, KEi} --> 676 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 677 payload, and a Diffie-Hellman value in the KEi payload. The KEi 678 payload MUST be included. New initiator and responder SPIs are 679 supplied in the SPI fields of the SA payload. 681 The CREATE_CHILD_SA response for rekeying an IKE SA is: 683 <-- HDR, SK {SA, Nr,[KEr]} 685 The responder replies (using the same Message ID to respond) with the 686 accepted offer in an SA payload, and a Diffie-Hellman value in the 687 KEr payload if the selected cryptographic suite includes that group. 689 The new IKE SA has its message counters set to 0, regardless of what 690 they were in the earlier IKE SA. The first IKE requests from both 691 sides on the new IKE SA will have message ID 0. The old IKE SA 692 retains its numbering, so any further requests (for example, to 693 delete the IKE SA) will have consecutive numbering. The new IKE SA 694 also has its window size reset to 1, and the initiator in this rekey 695 exchange is the new "original initiator" of the new IKE SA. 697 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange 699 The CREATE_CHILD_SA request for rekeying a Child SA is: 701 Initiator Responder 702 ------------------------------------------------------------------- 703 HDR, SK {N, SA, Ni, [KEi], 704 TSi, TSr} --> 706 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 707 payload, optionally a Diffie-Hellman value in the KEi payload, and 708 the proposed traffic selectors for the proposed Child SA in the TSi 709 and TSr payloads. 711 The REKEY_SA notification MUST be included in a CREATE_CHILD_SA 712 exchange if the purpose of the exchange is to replace an existing ESP 713 or AH SA. The SA being rekeyed is identified by the SPI field in the 714 Notify payload; this is the SPI the exchange initiator would expect 715 in inbound ESP or AH packets. There is no data associated with this 716 Notify type. The Protocol ID field of the REKEY_SA notification is 717 set to match the protocol of the SA we are rekeying, for example, 3 718 for ESP and 2 for AH. 720 The CREATE_CHILD_SA response for rekeying a Child SA is: 722 <-- HDR, SK {SA, Nr, [KEr], 723 TSi, TSr} 725 The responder replies (using the same Message ID to respond) with the 726 accepted offer in an SA payload, and a Diffie-Hellman value in the 727 KEr payload if KEi was included in the request and the selected 728 cryptographic suite includes that group. 730 The traffic selectors for traffic to be sent on that SA are specified 731 in the TS payloads in the response, which may be a subset of what the 732 initiator of the Child SA proposed. 734 1.4. The INFORMATIONAL Exchange 736 At various points during the operation of an IKE SA, peers may desire 737 to convey control messages to each other regarding errors or 738 notifications of certain events. To accomplish this, IKE defines an 739 INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur 740 after the initial exchanges and are cryptographically protected with 741 the negotiated keys. Section 2.21 also covers error messages in 742 great detail. 744 Control messages that pertain to an IKE SA MUST be sent under that 745 IKE SA. Control messages that pertain to Child SAs MUST be sent 746 under the protection of the IKE SA which generated them (or its 747 successor if the IKE SA was rekeyed). 749 Messages in an INFORMATIONAL exchange contain zero or more 750 Notification, Delete, and Configuration payloads. The Recipient of 751 an INFORMATIONAL exchange request MUST send some response (else the 752 Sender will assume the message was lost in the network and will 753 retransmit it). That response MAY be a message with no payloads. 754 The request message in an INFORMATIONAL exchange MAY also contain no 755 payloads. This is the expected way an endpoint can ask the other 756 endpoint to verify that it is alive. 758 The INFORMATIONAL exchange is defined as: 760 Initiator Responder 761 ------------------------------------------------------------------- 762 HDR, SK {[N,] [D,] 763 [CP,] ...} --> 764 <-- HDR, SK {[N,] [D,] 765 [CP], ...} 767 The processing of an INFORMATIONAL exchange is determined by its 768 component payloads. 770 1.4.1. Deleting an SA with INFORMATIONAL Exchanges 772 ESP and AH SAs always exist in pairs, with one SA in each direction. 773 When an SA is closed, both members of the pair MUST be closed (that 774 is, deleted). Each endpoint MUST close its incoming SAs and allow 775 the other endpoint to close the other SA in each pair. To delete an 776 SA, an INFORMATIONAL exchange with one or more delete payloads is 777 sent listing the SPIs (as they would be expected in the headers of 778 inbound packets) of the SAs to be deleted. The recipient MUST close 779 the designated SAs. Note that one never sends delete payloads for 780 the two sides of an SA in a single message. If there are many SAs to 781 delete at the same time, one includes delete payloads for the inbound 782 half of each SA pair in your Informational exchange. 784 Normally, the reply in the INFORMATIONAL exchange will contain delete 785 payloads for the paired SAs going in the other direction. There is 786 one exception. If by chance both ends of a set of SAs independently 787 decide to close them, each may send a delete payload and the two 788 requests may cross in the network. If a node receives a delete 789 request for SAs for which it has already issued a delete request, it 790 MUST delete the outgoing SAs while processing the request and the 791 incoming SAs while processing the response. In that case, the 792 responses MUST NOT include delete payloads for the deleted SAs, since 793 that would result in duplicate deletion and could in theory delete 794 the wrong SA. 796 Half-closed ESP or AH connections are anomalous, and a node with 797 auditing capability should probably audit their existence if they 798 persist. Note that this specification nowhere specifies time 799 periods, so it is up to individual endpoints to decide how long to 800 wait. A node MAY refuse to accept incoming data on half-closed 801 connections but MUST NOT unilaterally close them and reuse the SPIs. 802 If connection state becomes sufficiently messed up, a node MAY close 803 the IKE SA; doing so will implicitly close all SAs negotiated under 804 it. It can then rebuild the SAs it needs on a clean base under a new 805 IKE SA. The response to a request that deletes the IKE SA is an 806 empty Informational response. 808 1.5. Informational Messages outside of an IKE SA 810 If an encrypted IKE request packet arrives on port 500 or 4500 with 811 an unrecognized SPI, it could be because the receiving node has 812 recently crashed and lost state or because of some other system 813 malfunction or attack. If the receiving node has an active IKE SA to 814 the IP address from whence the packet came, it MAY send a 815 notification of the wayward packet over that IKE SA in an 816 INFORMATIONAL exchange. If it does not have such an IKE SA, it MAY 817 send an Informational message without cryptographic protection to the 818 source IP address. Such a message is not part of an informational 819 exchange, and the receiving node MUST NOT respond to it. Doing so 820 could cause a message loop. 822 The INVALID_SPI notification MAY be sent in an IKE INFORMATIONAL 823 exchange when a node receives an ESP or AH packet with an invalid 824 SPI. The Notification Data contains the SPI of the invalid packet. 825 This usually indicates a node has rebooted and forgotten an SA. If 826 this Informational Message is sent outside the context of an IKE SA, 827 it should only be used by the recipient as a "hint" that something 828 might be wrong (because it could easily be forged). The recipient of 829 this notification cannot tell whether the SPI is for AH or ESP, but 830 this is not important because the SPIs are supposed to be different 831 for the two. 833 There are two cases when a one-way message is sent: INVALID_IKE_SPI 834 and INVALID_SPI. These messages are sent outside of an IKE SA. Note 835 that such messages are explicitly not Informational exchanges; these 836 are one-way messages that must not be responded to. 837 (INVALID_MAJOR_VERSION is also a one-way message which is sent 838 outside of an IKE SA, although it is sent as a response to the 839 incoming IKE SA creation.) 841 In case of INVALID_IKE_SPI, the message sent is a response message, 842 and thus it is sent to the IP address and port from whence it came 843 with the same IKE SPIs and the Message ID is copied. The Response 844 bit is set to 1, and the version flags are set in the normal fashion. 845 For a one-way INVALID_IKE_SPI notification for an unrecognized SPI, 846 the responder SHOULD copy the Exchange Type from the request. 848 In case of INVALID_SPI, however, there are no IKE SPI values that 849 would be meaningful to the recipient of such a notification. Using 850 zero values or random values are both acceptable. The Initiator flag 851 is set, the Response bit is set to 0, and the version flags are set 852 in the normal fashion. 854 1.6. Requirements Terminology 856 Definitions of the primitive terms in this document (such as Security 857 Association or SA) can be found in [IPSECARCH]. It should be noted 858 that parts of IKEv2 rely on some of the processing rules in 859 [IPSECARCH], as described in various sections of this document. 861 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 862 "MAY" that appear in this document are to be interpreted as described 863 in [MUSTSHOULD]. 865 1.7. Differences Between RFC 4306 and This Document 867 {{ Added this entire section, including this recursive remark. }} 869 This document contains clarifications and amplifications to IKEv2 870 [IKEV2]. The clarifications are mostly based on [Clarif]. The 871 changes listed in that document were discussed in the IPsec Working 872 Group and, after the Working Group was disbanded, on the IPsec 873 mailing list. That document contains detailed explanations of areas 874 that were unclear in IKEv2, and is thus useful to implementers of 875 IKEv2. 877 The protocol described in this document retains the same major 878 version number (2) and minor version number (0) as was used in RFC 879 4306. That is, the version number is *not* changed from RFC 4306. 881 This document makes the figures and references a bit more regular 882 than in [IKEV2]. 884 IKEv2 developers have noted that the SHOULD-level requirements are 885 often unclear in that they don't say when it is OK to not obey the 886 requirements. They also have noted that there are MUST-level 887 requirements that are not related to interoperability. This document 888 has more explanation of some of these requirements. All non- 889 capitalized uses of the words SHOULD and MUST now mean their normal 890 English sense, not the interoperability sense of [MUSTSHOULD]. 892 IKEv2 (and IKEv1) developers have noted that there is a great deal of 893 material in the tables of codes in Section 3.10.1. This leads to 894 implementers not having all the needed information in the main body 895 of the document. Much of the material from those tables has been 896 moved into the associated parts of the main body of the document. 898 This document removes discussion of nesting AH and ESP. This was a 899 mistake in RFC 4306 caused by the lag between finishing RFC 4306 and 900 RFC 4301. Basically, IKEv2 is based on RFC 4301, which does not 901 include "SA bundles" that were part of RFC 2401. While a single 902 packet can go through IPsec processing multiple times, each of these 903 passes uses a separate SA, and the passes are coordinated by the 904 forwarding tables. In IKEv2, each of these SAs has to be created 905 using a separate CREATE_CHILD_SA exchange. 907 This document removes discussion of the INTERNAL_ADDRESS_EXPIRY 908 configuration attribute because its implementation was very 909 problematic. Implementations that conform to this document MUST 910 ignore proposals that have configuration attribute type 5, the old 911 value for INTERNAL_ADDRESS_EXPIRY. 913 This document adds the restriction in Section 2.13 that all PRFs used 914 with IKEv2 MUST take variable-sized keys. This should not affect any 915 implementations because there were no standardized PRFs that have 916 fixed-size keys. 918 Section 2.21 has been greatly expanded to cover the different cases 919 where error responses are needed and the appropriate responses to 920 them. 922 2. IKE Protocol Details and Variations 924 IKE normally listens and sends on UDP port 500, though IKE messages 925 may also be received on UDP port 4500 with a slightly different 926 format (see Section 2.23). Since UDP is a datagram (unreliable) 927 protocol, IKE includes in its definition recovery from transmission 928 errors, including packet loss, packet replay, and packet forgery. 929 IKE is designed to function so long as (1) at least one of a series 930 of retransmitted packets reaches its destination before timing out; 931 and (2) the channel is not so full of forged and replayed packets so 932 as to exhaust the network or CPU capacities of either endpoint. Even 933 in the absence of those minimum performance requirements, IKE is 934 designed to fail cleanly (as though the network were broken). 936 Although IKEv2 messages are intended to be short, they contain 937 structures with no hard upper bound on size (in particular, X.509 938 certificates), and IKEv2 itself does not have a mechanism for 939 fragmenting large messages. IP defines a mechanism for fragmentation 940 of oversize UDP messages, but implementations vary in the maximum 941 message size supported. Furthermore, use of IP fragmentation opens 942 an implementation to denial of service attacks [DOSUDPPROT]. 943 Finally, some NAT and/or firewall implementations may block IP 944 fragments. 946 All IKEv2 implementations MUST be able to send, receive, and process 947 IKE messages that are up to 1280 octets long, and they SHOULD be able 948 to send, receive, and process messages that are up to 3000 octets 949 long. IKEv2 implementations need to be aware of the maximum UDP 950 message size supported and MAY shorten messages by leaving out some 951 certificates or cryptographic suite proposals if that will keep 952 messages below the maximum. Use of the "Hash and URL" formats rather 953 than including certificates in exchanges where possible can avoid 954 most problems. Implementations and configuration need to keep in 955 mind, however, that if the URL lookups are possible only after the 956 IPsec SA is established, recursion issues could prevent this 957 technique from working. 959 The UDP payload of all packets containing IKE messages sent on port 960 4500 MUST begin with the prefix of four zeros; otherwise, the 961 receiver won't know how to handle them. 963 2.1. Use of Retransmission Timers 965 All messages in IKE exist in pairs: a request and a response. The 966 setup of an IKE SA normally consists of two request/response pairs. 967 Once the IKE SA is set up, either end of the security association may 968 initiate requests at any time, and there can be many requests and 969 responses "in flight" at any given moment. But each message is 970 labeled as either a request or a response, and for each request/ 971 response pair one end of the security association is the initiator 972 and the other is the responder. 974 For every pair of IKE messages, the initiator is responsible for 975 retransmission in the event of a timeout. The responder MUST never 976 retransmit a response unless it receives a retransmission of the 977 request. In that event, the responder MUST ignore the retransmitted 978 request except insofar as it triggers a retransmission of the 979 response. The initiator MUST remember each request until it receives 980 the corresponding response. The responder MUST remember each 981 response until it receives a request whose sequence number is larger 982 than or equal to the sequence number in the response plus its window 983 size (see Section 2.3). In order to allow saving memory, responders 984 are allowed to forget response after a timeout of several minutes. 985 If the responder receives a retransmitted request for which it has 986 already forgotten the response, it MUST ignore the request (and not, 987 for example, attempt constructing a new response). 989 IKE is a reliable protocol, in the sense that the initiator MUST 990 retransmit a request until either it receives a corresponding reply 991 OR it deems the IKE security association to have failed and it 992 discards all state associated with the IKE SA and any Child SAs 993 negotiated using that IKE SA. A retransmission from the initiator 994 MUST be bitwise identical to the original request. That is, 995 everything starting from the IKE Header (the IKE SA Initiator's SPI 996 onwards) must be bitwise identical; items before it (such as the IP 997 and UDP headers, and the zero non-ESP marker) do not have to be 998 identical. 1000 Retransmissions of the IKE_SA_INIT request require some special 1001 handling. When a responder receives an IKE_SA_INIT request, it has 1002 to determine whether the packet is a retransmission belonging to an 1003 existing "half-open" IKE SA (in which case the responder retransmits 1004 the same response), or a new request (in which case the responder 1005 creates a new IKE SA and sends a fresh response), or it belongs to an 1006 existing IKE SA where the IKE_AUTH request has been already received 1007 (in which case the responder ignores it). 1009 It is not sufficient to use the initiator's SPI and/or IP address to 1010 differentiate between these three cases because two different peers 1011 behind a single NAT could choose the same initiator SPI. Instead, a 1012 robust responder will do the IKE SA lookup using the whole packet, 1013 its hash, or the Ni payload. 1015 2.2. Use of Sequence Numbers for Message ID 1017 Every IKE message contains a Message ID as part of its fixed header. 1018 This Message ID is used to match up requests and responses, and to 1019 identify retransmissions of messages. 1021 The Message ID is a 32-bit quantity, which is zero for the 1022 IKE_SA_INIT messages (including retries of the message due to 1023 responses such as COOKIE and INVALID_KE_PAYLOAD), and incremented for 1024 each subsequent exchange. The Message ID is reset to zero in the new 1025 IKE SA after the IKE SA is rekeyed. Rekeying an IKE SA resets the 1026 sequence numbers. Thus, the first pair of IKE_AUTH messages will 1027 have ID of 1, the second (when EAP is used) will be 2, and so on. 1029 Each endpoint in the IKE Security Association maintains two "current" 1030 Message IDs: the next one to be used for a request it initiates and 1031 the next one it expects to see in a request from the other end. 1032 These counters increment as requests are generated and received. 1033 Responses always contain the same message ID as the corresponding 1034 request. That means that after the initial exchange, each integer n 1035 may appear as the message ID in four distinct messages: the nth 1036 request from the original IKE initiator, the corresponding response, 1037 the nth request from the original IKE responder, and the 1038 corresponding response. If the two ends make very different numbers 1039 of requests, the Message IDs in the two directions can be very 1040 different. There is no ambiguity in the messages, however, because 1041 the (I)nitiator and (R)esponse bits in the message header specify 1042 which of the four messages a particular one is. 1044 Throughout this document, "initiator" refers to the party who 1045 initiated the exchange being described, and "original initiator" 1046 refers to the party who initiated the whole IKE SA. The "original 1047 initiator" always refers to the party who initiated the exchange 1048 which resulted in the current IKE SA. In other words, if the 1049 "original responder" starts rekeying the IKE SA, that party becomes 1050 the "original initiator" of the new IKE SA. 1052 Note that Message IDs are cryptographically protected and provide 1053 protection against message replays. In the unlikely event that 1054 Message IDs grow too large to fit in 32 bits, the IKE SA MUST be 1055 closed or rekeyed. 1057 2.3. Window Size for Overlapping Requests 1059 The SET_WINDOW_SIZE notification asserts that the sending endpoint is 1060 capable of keeping state for multiple outstanding exchanges, 1061 permitting the recipient to send multiple requests before getting a 1062 response to the first. The data associated with a SET_WINDOW_SIZE 1063 notification MUST be 4 octets long and contain the big endian 1064 representation of the number of messages the sender promises to keep. 1065 The window size is always one until the initial exchanges complete. 1067 An IKE endpoint MUST wait for a response to each of its messages 1068 before sending a subsequent message unless it has received a 1069 SET_WINDOW_SIZE Notify message from its peer informing it that the 1070 peer is prepared to maintain state for multiple outstanding messages 1071 in order to allow greater throughput. 1073 After an IKE SA is set up, in order to maximize IKE throughput, an 1074 IKE endpoint MAY issue multiple requests before getting a response to 1075 any of them, up to the limit set by its peer's SET_WINDOW_SIZE. 1076 These requests may pass one another over the network. An IKE 1077 endpoint MUST be prepared to accept and process a request while it 1078 has a request outstanding in order to avoid a deadlock in this 1079 situation. An IKE endpoint may also accept and process multiple 1080 requests while it has a request outstanding. 1082 An IKE endpoint MUST NOT exceed the peer's stated window size for 1083 transmitted IKE requests. In other words, if the responder stated 1084 its window size is N, then when the initiator needs to make a request 1085 X, it MUST wait until it has received responses to all requests up 1086 through request X-N. An IKE endpoint MUST keep a copy of (or be able 1087 to regenerate exactly) each request it has sent until it receives the 1088 corresponding response. An IKE endpoint MUST keep a copy of (or be 1089 able to regenerate exactly) the number of previous responses equal to 1090 its declared window size in case its response was lost and the 1091 initiator requests its retransmission by retransmitting the request. 1093 An IKE endpoint supporting a window size greater than one ought to be 1094 capable of processing incoming requests out of order to maximize 1095 performance in the event of network failures or packet reordering. 1097 The window size is normally a (possibly configurable) property of a 1098 particular implementation, and is not related to congestion control 1099 (unlike the window size in TCP, for example). In particular, it is 1100 not defined what the responder should do when it receives a 1101 SET_WINDOW_SIZE notification containing a smaller value than is 1102 currently in effect. Thus, there is currently no way to reduce the 1103 window size of an existing IKE SA; you can only increase it. When 1104 rekeying an IKE SA, the new IKE SA starts with window size 1 until it 1105 is explicitly increased by sending a new SET_WINDOW_SIZE 1106 notification. 1108 The INVALID_MESSAGE_ID notification is sent when an IKE message ID 1109 outside the supported window is received. This Notify MUST NOT be 1110 sent in a response; the invalid request MUST NOT be acknowledged. 1111 Instead, inform the other side by initiating an INFORMATIONAL 1112 exchange with Notification data containing the four octet invalid 1113 message ID. Sending this notification is optional, and notifications 1114 of this type MUST be rate limited. 1116 2.4. State Synchronization and Connection Timeouts 1118 An IKE endpoint is allowed to forget all of its state associated with 1119 an IKE SA and the collection of corresponding Child SAs at any time. 1120 This is the anticipated behavior in the event of an endpoint crash 1121 and restart. It is important when an endpoint either fails or 1122 reinitializes its state that the other endpoint detect those 1123 conditions and not continue to waste network bandwidth by sending 1124 packets over discarded SAs and having them fall into a black hole. 1126 The INITIAL_CONTACT notification asserts that this IKE SA is the only 1127 IKE SA currently active between the authenticated identities. It MAY 1128 be sent when an IKE SA is established after a crash, and the 1129 recipient MAY use this information to delete any other IKE SAs it has 1130 to the same authenticated identity without waiting for a timeout. 1131 This notification MUST NOT be sent by an entity that may be 1132 replicated (e.g., a roaming user's credentials where the user is 1133 allowed to connect to the corporate firewall from two remote systems 1134 at the same time). The INITIAL_CONTACT notification, if sent, MUST 1135 be in the first IKE_AUTH request or response, not as a separate 1136 exchange afterwards; however, receiving parties MAY ignore it in 1137 other messages. 1139 Since IKE is designed to operate in spite of Denial of Service (DoS) 1140 attacks from the network, an endpoint MUST NOT conclude that the 1141 other endpoint has failed based on any routing information (e.g., 1142 ICMP messages) or IKE messages that arrive without cryptographic 1143 protection (e.g., Notify messages complaining about unknown SPIs). 1144 An endpoint MUST conclude that the other endpoint has failed only 1145 when repeated attempts to contact it have gone unanswered for a 1146 timeout period or when a cryptographically protected INITIAL_CONTACT 1147 notification is received on a different IKE SA to the same 1148 authenticated identity. An endpoint should suspect that the other 1149 endpoint has failed based on routing information and initiate a 1150 request to see whether the other endpoint is alive. To check whether 1151 the other side is alive, IKE specifies an empty INFORMATIONAL message 1152 that (like all IKE requests) requires an acknowledgement (note that 1153 within the context of an IKE SA, an "empty" message consists of an 1154 IKE header followed by an Encrypted payload that contains no 1155 payloads). If a cryptographically protected (fresh, i.e. not 1156 retransmitted) message has been received from the other side 1157 recently, unprotected notifications MAY be ignored. Implementations 1158 MUST limit the rate at which they take actions based on unprotected 1159 messages. 1161 Numbers of retries and lengths of timeouts are not covered in this 1162 specification because they do not affect interoperability. It is 1163 suggested that messages be retransmitted at least a dozen times over 1164 a period of at least several minutes before giving up on an SA, but 1165 different environments may require different rules. To be a good 1166 network citizen, retranmission times MUST increase exponentially to 1167 avoid flooding the network and making an existing congestion 1168 situation worse. If there has only been outgoing traffic on all of 1169 the SAs associated with an IKE SA, it is essential to confirm 1170 liveness of the other endpoint to avoid black holes. If no 1171 cryptographically protected messages have been received on an IKE SA 1172 or any of its Child SAs recently, the system needs to perform a 1173 liveness check in order to prevent sending messages to a dead peer. 1174 (This is sometimes called "dead peer detection" or "DPD", although it 1175 is really detecting live peers, not dead ones.) Receipt of a fresh 1176 cryptographically protected message on an IKE SA or any of its Child 1177 SAs ensures liveness of the IKE SA and all of its Child SAs. Note 1178 that this places requirements on the failure modes of an IKE 1179 endpoint. An implementation MUST NOT continue sending on any SA if 1180 some failure prevents it from receiving on all of the associated SAs. 1181 If Child SAs can fail independently from one another without the 1182 associated IKE SA being able to send a delete message, then they MUST 1183 be negotiated by separate IKE SAs. 1185 There is a Denial of Service attack on the initiator of an IKE SA 1186 that can be avoided if the initiator takes the proper care. Since 1187 the first two messages of an SA setup are not cryptographically 1188 protected, an attacker could respond to the initiator's message 1189 before the genuine responder and poison the connection setup attempt. 1190 To prevent this, the initiator MAY be willing to accept multiple 1191 responses to its first message, treat each as potentially legitimate, 1192 respond to it, and then discard all the invalid half-open connections 1193 when it receives a valid cryptographically protected response to any 1194 one of its requests. Once a cryptographically valid response is 1195 received, all subsequent responses should be ignored whether or not 1196 they are cryptographically valid. 1198 Note that with these rules, there is no reason to negotiate and agree 1199 upon an SA lifetime. If IKE presumes the partner is dead, based on 1200 repeated lack of acknowledgement to an IKE message, then the IKE SA 1201 and all Child SAs set up through that IKE SA are deleted. 1203 An IKE endpoint may at any time delete inactive Child SAs to recover 1204 resources used to hold their state. If an IKE endpoint chooses to 1205 delete Child SAs, it MUST send Delete payloads to the other end 1206 notifying it of the deletion. It MAY similarly time out the IKE SA. 1207 Closing the IKE SA implicitly closes all associated Child SAs. In 1208 this case, an IKE endpoint SHOULD send a Delete payload indicating 1209 that it has closed the IKE SA unless the other endpoint is no longer 1210 responding. 1212 2.5. Version Numbers and Forward Compatibility 1214 This document describes version 2.0 of IKE, meaning the major version 1215 number is 2 and the minor version number is 0. This document is a 1216 replacement for [IKEV2]. It is likely that some implementations will 1217 want to support version 1.0 and version 2.0, and in the future, other 1218 versions. 1220 The major version number should be incremented only if the packet 1221 formats or required actions have changed so dramatically that an 1222 older version node would not be able to interoperate with a newer 1223 version node if it simply ignored the fields it did not understand 1224 and took the actions specified in the older specification. The minor 1225 version number indicates new capabilities, and MUST be ignored by a 1226 node with a smaller minor version number, but used for informational 1227 purposes by the node with the larger minor version number. For 1228 example, it might indicate the ability to process a newly defined 1229 notification message. The node with the larger minor version number 1230 would simply note that its correspondent would not be able to 1231 understand that message and therefore would not send it. 1233 If an endpoint receives a message with a higher major version number, 1234 it MUST drop the message and SHOULD send an unauthenticated 1235 notification message of type INVALID_MAJOR_VERSION containing the 1236 highest (closest) version number it supports. If an endpoint 1237 supports major version n, and major version m, it MUST support all 1238 versions between n and m. If it receives a message with a major 1239 version that it supports, it MUST respond with that version number. 1240 In order to prevent two nodes from being tricked into corresponding 1241 with a lower major version number than the maximum that they both 1242 support, IKE has a flag that indicates that the node is capable of 1243 speaking a higher major version number. 1245 Thus, the major version number in the IKE header indicates the 1246 version number of the message, not the highest version number that 1247 the transmitter supports. If the initiator is capable of speaking 1248 versions n, n+1, and n+2, and the responder is capable of speaking 1249 versions n and n+1, then they will negotiate speaking n+1, where the 1250 initiator will set a flag indicating its ability to speak a higher 1251 version. If they mistakenly (perhaps through an active attacker 1252 sending error messages) negotiate to version n, then both will notice 1253 that the other side can support a higher version number, and they 1254 MUST break the connection and reconnect using version n+1. 1256 Note that IKEv1 does not follow these rules, because there is no way 1257 in v1 of noting that you are capable of speaking a higher version 1258 number. So an active attacker can trick two v2-capable nodes into 1259 speaking v1. When a v2-capable node negotiates down to v1, it should 1260 note that fact in its logs. 1262 Also for forward compatibility, all fields marked RESERVED MUST be 1263 set to zero by an implementation running version 2.0, and their 1264 content MUST be ignored by an implementation running version 2.0 ("Be 1265 conservative in what you send and liberal in what you receive"). In 1266 this way, future versions of the protocol can use those fields in a 1267 way that is guaranteed to be ignored by implementations that do not 1268 understand them. Similarly, payload types that are not defined are 1269 reserved for future use; implementations of a version where they are 1270 undefined MUST skip over those payloads and ignore their contents. 1272 IKEv2 adds a "critical" flag to each payload header for further 1273 flexibility for forward compatibility. If the critical flag is set 1274 and the payload type is unrecognized, the message MUST be rejected 1275 and the response to the IKE request containing that payload MUST 1276 include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an 1277 unsupported critical payload was included. In that Notify payload, 1278 the notification data contains the one-octet payload type. If the 1279 critical flag is not set and the payload type is unsupported, that 1280 payload MUST be ignored. Payloads sent in IKE response messages MUST 1281 NOT have the critical flag set. Note that the critical flag applies 1282 only to the payload type, not the contents. If the payload type is 1283 recognized, but the payload contains something which is not (such as 1284 an unknown transform inside an SA payload, or an unknown Notify 1285 Message Type inside a Notify payload), the critical flag is ignored. 1287 Although new payload types may be added in the future and may appear 1288 interleaved with the fields defined in this specification, 1289 implementations SHOULD send the payloads defined in this 1290 specification in the order shown in the figures in Section 2; 1291 implementations MUST NOT reject as invalid a message with those 1292 payloads in any other order. 1294 2.6. IKE SA SPIs and Cookies 1296 The term "cookies" originates with Karn and Simpson [PHOTURIS] in 1297 Photuris, an early proposal for key management with IPsec, and it has 1298 persisted. The Internet Security Association and Key Management 1299 Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight- 1300 octet fields titled "cookies", and that syntax is used by both IKEv1 1301 and IKEv2, although in IKEv2 they are referred to as the "IKE SPI" 1302 and there is a new separate field in a Notify payload holding the 1303 cookie. The initial two eight-octet fields in the header are used as 1304 a connection identifier at the beginning of IKE packets. Each 1305 endpoint chooses one of the two SPIs and MUST choose them so as to be 1306 unique identifiers of an IKE SA. An SPI value of zero is special and 1307 indicates that the remote SPI value is not yet known by the sender. 1309 Incoming IKE packets are mapped to an IKE SA only using the packet's 1310 SPI, not using (for example) the source IP address of the packet. 1312 Unlike ESP and AH where only the recipient's SPI appears in the 1313 header of a message, in IKE the sender's SPI is also sent in every 1314 message. Since the SPI chosen by the original initiator of the IKE 1315 SA is always sent first, an endpoint with multiple IKE SAs open that 1316 wants to find the appropriate IKE SA using the SPI it assigned must 1317 look at the I(nitiator) Flag bit in the header to determine whether 1318 it assigned the first or the second eight octets. 1320 In the first message of an initial IKE exchange, the initiator will 1321 not know the responder's SPI value and will therefore set that field 1322 to zero. 1324 An expected attack against IKE is state and CPU exhaustion, where the 1325 target is flooded with session initiation requests from forged IP 1326 addresses. This attack can be made less effective if an 1327 implementation of a responder uses minimal CPU and commits no state 1328 to an SA until it knows the initiator can receive packets at the 1329 address from which it claims to be sending them. 1331 When a responder detects a large number of half-open IKE SAs, it 1332 SHOULD reply to IKE_SA_INIT requests with a response containing the 1333 COOKIE notification. The data associated with this notification MUST 1334 be between 1 and 64 octets in length (inclusive), and its generation 1335 is described later in this section. If the IKE_SA_INIT response 1336 includes the COOKIE notification, the initiator MUST then retry the 1337 IKE_SA_INIT request, and include the COOKIE notification containing 1338 the received data as the first payload, and all other payloads 1339 unchanged. The initial exchange will then be as follows: 1341 Initiator Responder 1342 ------------------------------------------------------------------- 1343 HDR(A,0), SAi1, KEi, Ni --> 1344 <-- HDR(A,0), N(COOKIE) 1345 HDR(A,0), N(COOKIE), SAi1, 1346 KEi, Ni --> 1347 <-- HDR(A,B), SAr1, KEr, 1348 Nr, [CERTREQ] 1349 HDR(A,B), SK {IDi, [CERT,] 1350 [CERTREQ,] [IDr,] AUTH, 1351 SAi2, TSi, TSr} --> 1352 <-- HDR(A,B), SK {IDr, [CERT,] 1353 AUTH, SAr2, TSi, TSr} 1355 The first two messages do not affect any initiator or responder state 1356 except for communicating the cookie. In particular, the message 1357 sequence numbers in the first four messages will all be zero and the 1358 message sequence numbers in the last two messages will be one. 'A' 1359 is the SPI assigned by the initiator, while 'B' is the SPI assigned 1360 by the responder. 1362 An IKE implementation can implement its responder cookie generation 1363 in such a way as to not require any saved state to recognize its 1364 valid cookie when the second IKE_SA_INIT message arrives. The exact 1365 algorithms and syntax they use to generate cookies do not affect 1366 interoperability and hence are not specified here. The following is 1367 an example of how an endpoint could use cookies to implement limited 1368 DOS protection. 1370 A good way to do this is to set the responder cookie to be: 1372 Cookie = | Hash(Ni | IPi | SPIi | ) 1374 where is a randomly generated secret known only to the 1375 responder and periodically changed and | indicates concatenation. 1376 should be changed whenever is 1377 regenerated. The cookie can be recomputed when the IKE_SA_INIT 1378 arrives the second time and compared to the cookie in the received 1379 message. If it matches, the responder knows that the cookie was 1380 generated since the last change to and that IPi must be the 1381 same as the source address it saw the first time. Incorporating SPIi 1382 into the calculation ensures that if multiple IKE SAs are being set 1383 up in parallel they will all get different cookies (assuming the 1384 initiator chooses unique SPIi's). Incorporating Ni in the hash 1385 ensures that an attacker who sees only message 2 can't successfully 1386 forge a message 3. Also, incorporating Ni in the hash prevents an 1387 attacker from fetching one one cookie from the other end, and then 1388 initiating many IKE_SA_INIT exchanges all with different initiator 1389 SPIs (and perhaps port numbers) so that the responder thinks that 1390 there are lots of machines behind one NAT box who are all trying to 1391 connect. 1393 If a new value for is chosen while there are connections in 1394 the process of being initialized, an IKE_SA_INIT might be returned 1395 with other than the current . The responder in 1396 that case MAY reject the message by sending another response with a 1397 new cookie or it MAY keep the old value of around for a 1398 short time and accept cookies computed from either one. The 1399 responder should not accept cookies indefinitely after is 1400 changed, since that would defeat part of the denial of service 1401 protection. The responder should change the value of 1402 frequently, especially if under attack. 1404 In addition to cookies, there are several cases where the IKE_SA_INIT 1405 exchange does not result in the creation of an IKE SA (such as 1406 INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). In such a case, sending a 1407 zero value for the Responder's SPI is correct. If the responder 1408 sends a non-zero responder SPI, the initiator should not reject the 1409 response for only that reason. 1411 When one party receives an IKE_SA_INIT request containing a cookie 1412 whose contents do not match the value expected, that party MUST 1413 ignore the cookie and process the message as if no cookie had been 1414 included; usually this means sending a response containing a new 1415 cookie. The initiator should limit the number of cookie exchanges it 1416 tries before giving up. An attacker can forge multiple cookie 1417 responses to the initiator's IKE_SA_INIT message, and each of those 1418 forged cookie reply will trigger two packets: one packet from the 1419 initiator to the responder (which will reject those cookies), and one 1420 reply from responder to initiator that includes the correct cookie. 1422 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD 1424 There are two common reasons why the initiator may have to retry the 1425 IKE_SA_INIT exchange: the responder requests a cookie or wants a 1426 different Diffie-Hellman group than was included in the KEi payload. 1427 If the initiator receives a cookie from the responder, the initiator 1428 needs to decide whether or not to include the cookie in only the next 1429 retry of the IKE_SA_INIT request, or in all subsequent retries as 1430 well. 1432 If the initiator includes the cookie only in the next retry, one 1433 additional roundtrip may be needed in some cases. An additional 1434 roundtrip is needed also if the initiator includes the cookie in all 1435 retries, but the responder does not support this. For instance, if 1436 the responder includes the SAi1 and KEi payloads in cookie 1437 calculation, it will reject the request by sending a new cookie. 1439 If both peers support including the cookie in all retries, a slightly 1440 shorter exchange can happen. 1442 Initiator Responder 1443 ----------------------------------------------------------- 1444 HDR(A,0), SAi1, KEi, Ni --> 1445 <-- HDR(A,0), N(COOKIE) 1446 HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> 1447 <-- HDR(A,0), N(INVALID_KE_PAYLOAD) 1448 HDR(A,0), N(COOKIE), SAi1, KEi', Ni --> 1449 <-- HDR(A,B), SAr1, KEr, Nr 1451 Implementations SHOULD support this shorter exchange, but MUST NOT 1452 fail if other implementations do not support this shorter exchange. 1454 2.7. Cryptographic Algorithm Negotiation 1456 The payload type known as "SA" indicates a proposal for a set of 1457 choices of IPsec protocols (IKE, ESP, or AH) for the SA as well as 1458 cryptographic algorithms associated with each protocol. 1460 An SA payload consists of one or more proposals. Each proposal 1461 includes one protocol. Each protocol contains one or more transforms 1462 -- each specifying a cryptographic algorithm. Each transform 1463 contains zero or more attributes (attributes are needed only if the 1464 transform identifier does not completely specify the cryptographic 1465 algorithm). 1467 This hierarchical structure was designed to efficiently encode 1468 proposals for cryptographic suites when the number of supported 1469 suites is large because multiple values are acceptable for multiple 1470 transforms. The responder MUST choose a single suite, which may be 1471 any subset of the SA proposal following the rules below: 1473 Each proposal contains one protocol. If a proposal is accepted, the 1474 SA response MUST contain the same protocol. The responder MUST 1475 accept a single proposal or reject them all and return an error. The 1476 error is given in a notification of type NO_PROPOSAL_CHOSEN. 1478 Each IPsec protocol proposal contains one or more transforms. Each 1479 transform contains a transform type. The accepted cryptographic 1480 suite MUST contain exactly one transform of each type included in the 1481 proposal. For example: if an ESP proposal includes transforms 1482 ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, 1483 AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one 1484 of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six 1485 combinations are acceptable. 1487 If an initiator proposes both normal ciphers with integrity 1488 protection as well as combined-mode ciphers, then two proposals are 1489 needed. One of the proposals includes the normal ciphers with the 1490 integrity algoritms for them, and the other proposal includes all the 1491 combined mode ciphers without the integrity algorithms (because 1492 combined mode ciphers are not allowed to have any integrity algorithm 1493 other than "none"). 1495 Since the initiator sends its Diffie-Hellman value in the 1496 IKE_SA_INIT, it must guess the Diffie-Hellman group that the 1497 responder will select from its list of supported groups. If the 1498 initiator guesses wrong, the responder will respond with a Notify 1499 payload of type INVALID_KE_PAYLOAD indicating the selected group. In 1500 this case, the initiator MUST retry the IKE_SA_INIT with the 1501 corrected Diffie-Hellman group. The initiator MUST again propose its 1502 full set of acceptable cryptographic suites because the rejection 1503 message was unauthenticated and otherwise an active attacker could 1504 trick the endpoints into negotiating a weaker suite than a stronger 1505 one that they both prefer. 1507 When the IKE_SA_INIT exchange does not result in the creation of an 1508 IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, or COOKIE (see 1509 Section 2.6), the responder's SPI will be zero. However, if the 1510 responder sends a non-zero responder SPI, the initiator should not 1511 reject the response for only that reason. 1513 2.8. Rekeying 1515 IKE, ESP, and AH security associations use secret keys that should be 1516 used only for a limited amount of time and to protect a limited 1517 amount of data. This limits the lifetime of the entire security 1518 association. When the lifetime of a security association expires, 1519 the security association MUST NOT be used. If there is demand, new 1520 security associations MAY be established. Reestablishment of 1521 security associations to take the place of ones that expire is 1522 referred to as "rekeying". 1524 To allow for minimal IPsec implementations, the ability to rekey SAs 1525 without restarting the entire IKE SA is optional. An implementation 1526 MAY refuse all CREATE_CHILD_SA requests within an IKE SA. If an SA 1527 has expired or is about to expire and rekeying attempts using the 1528 mechanisms described here fail, an implementation MUST close the IKE 1529 SA and any associated Child SAs and then MAY start new ones. 1530 Implementations may wish to support in-place rekeying of SAs, since 1531 doing so offers better performance and is likely to reduce the number 1532 of packets lost during the transition. 1534 To rekey a Child SA within an existing IKE SA, create a new, 1535 equivalent SA (see Section 2.17 below), and when the new one is 1536 established, delete the old one. To rekey an IKE SA, establish a new 1537 equivalent IKE SA (see Section 2.18 below) with the peer to whom the 1538 old IKE SA is shared using a CREATE_CHILD_SA within the existing IKE 1539 SA. An IKE SA so created inherits all of the original IKE SA's Child 1540 SAs, and the new IKE SA is used for all control messages needed to 1541 maintain those Child SAs. The old IKE SA is then deleted, and the 1542 Delete payload to delete itself MUST be the last request sent over 1543 the old IKE SA. Note that, when rekeying, the new Child SA SHOULD 1544 NOT have different traffic selectors and algorithms than the old one. 1546 SAs should be rekeyed proactively, i.e., the new SA should be 1547 established before the old one expires and becomes unusable. Enough 1548 time should elapse between the time the new SA is established and the 1549 old one becomes unusable so that traffic can be switched over to the 1550 new SA. 1552 A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes 1553 were negotiated. In IKEv2, each end of the SA is responsible for 1554 enforcing its own lifetime policy on the SA and rekeying the SA when 1555 necessary. If the two ends have different lifetime policies, the end 1556 with the shorter lifetime will end up always being the one to request 1557 the rekeying. If an SA has been inactive for a long time and if an 1558 endpoint would not initiate the SA in the absence of traffic, the 1559 endpoint MAY choose to close the SA instead of rekeying it when its 1560 lifetime expires. It should do so if there has been no traffic since 1561 the last time the SA was rekeyed. 1563 Note that IKEv2 deliberately allows parallel SAs with the same 1564 traffic selectors between common endpoints. One of the purposes of 1565 this is to support traffic quality of service (QoS) differences among 1566 the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and section 4.1 of 1567 [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints 1568 and the traffic selectors may not uniquely identify an SA between 1569 those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on 1570 the basis of duplicate traffic selectors SHOULD NOT be used. 1572 The node that initiated the surviving rekeyed SA should delete the 1573 replaced SA after the new one is established. 1575 There are timing windows -- particularly in the presence of lost 1576 packets -- where endpoints may not agree on the state of an SA. The 1577 responder to a CREATE_CHILD_SA MUST be prepared to accept messages on 1578 an SA before sending its response to the creation request, so there 1579 is no ambiguity for the initiator. The initiator MAY begin sending 1580 on an SA as soon as it processes the response. The initiator, 1581 however, cannot receive on a newly created SA until it receives and 1582 processes the response to its CREATE_CHILD_SA request. How, then, is 1583 the responder to know when it is OK to send on the newly created SA? 1585 From a technical correctness and interoperability perspective, the 1586 responder MAY begin sending on an SA as soon as it sends its response 1587 to the CREATE_CHILD_SA request. In some situations, however, this 1588 could result in packets unnecessarily being dropped, so an 1589 implementation MAY defer such sending. 1591 The responder can be assured that the initiator is prepared to 1592 receive messages on an SA if either (1) it has received a 1593 cryptographically valid message on the new SA, or (2) the new SA 1594 rekeys an existing SA and it receives an IKE request to close the 1595 replaced SA. When rekeying an SA, the responder continues to send 1596 traffic on the old SA until one of those events occurs. When 1597 establishing a new SA, the responder MAY defer sending messages on a 1598 new SA until either it receives one or a timeout has occurred. If an 1599 initiator receives a message on an SA for which it has not received a 1600 response to its CREATE_CHILD_SA request, it interprets that as a 1601 likely packet loss and retransmits the CREATE_CHILD_SA request. An 1602 initiator MAY send a dummy message on a newly created SA if it has no 1603 messages queued in order to assure the responder that the initiator 1604 is ready to receive messages. 1606 2.8.1. Simultaneous Child SA rekeying 1608 If the two ends have the same lifetime policies, it is possible that 1609 both will initiate a rekeying at the same time (which will result in 1610 redundant SAs). To reduce the probability of this happening, the 1611 timing of rekeying requests SHOULD be jittered (delayed by a random 1612 amount of time after the need for rekeying is noticed). 1614 This form of rekeying may temporarily result in multiple similar SAs 1615 between the same pairs of nodes. When there are two SAs eligible to 1616 receive packets, a node MUST accept incoming packets through either 1617 SA. If redundant SAs are created though such a collision, the SA 1618 created with the lowest of the four nonces used in the two exchanges 1619 SHOULD be closed by the endpoint that created it. "Lowest" means an 1620 octet-by-octet, lexicographical comparison (instead of, for instance, 1621 comparing the nonces as large integers). In other words, start by 1622 comparing the first octet; if they're equal, move to the next octet, 1623 and so on. If you reach the end of one nonce, that nonce is the 1624 lower one. 1626 The following is an explanation on the impact this has on 1627 implementations. Assume that hosts A and B have an existing IPsec SA 1628 pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same 1629 time: 1631 Host A Host B 1632 ------------------------------------------------------------------- 1633 send req1: N(REKEY_SA,SPIa1), 1634 SA(..,SPIa2,..),Ni1,.. --> 1635 <-- send req2: N(REKEY_SA,SPIb1), 1636 SA(..,SPIb2,..),Ni2 1637 recv req2 <-- 1639 At this point, A knows there is a simultaneous rekeying going on. 1640 However, it cannot yet know which of the exchanges will have the 1641 lowest nonce, so it will just note the situation and respond as 1642 usual. 1644 send resp2: SA(..,SPIa3,..), 1645 Nr1,.. --> 1646 --> recv req1 1648 Now B also knows that simultaneous rekeying is going on. It responds 1649 as usual. 1651 <-- send resp1: SA(..,SPIb3,..), 1652 Nr2,.. 1653 recv resp1 <-- 1654 --> recv resp2 1656 At this point, there are three Child SA pairs between A and B (the 1657 old one and two new ones). A and B can now compare the nonces. 1658 Suppose that the lowest nonce was Nr1 in message resp2; in this case, 1659 B (the sender of req2) deletes the redundant new SA, and A (the node 1660 that initiated the surviving rekeyed SA), deletes the old one. 1662 send req3: D(SPIa1) --> 1663 <-- send req4: D(SPIb2) 1664 --> recv req3 1665 <-- send resp3: D(SPIb1) 1666 recv req4 <-- 1667 send resp4: D(SPIa3) --> 1669 The rekeying is now finished. 1671 However, there is a second possible sequence of events that can 1672 happen if some packets are lost in the network, resulting in 1673 retransmissions. The rekeying begins as usual, but A's first packet 1674 (req1) is lost. 1676 Host A Host B 1677 ------------------------------------------------------------------- 1678 send req1: N(REKEY_SA,SPIa1), 1679 SA(..,SPIa2,..), 1680 Ni1,.. --> (lost) 1681 <-- send req2: N(REKEY_SA,SPIb1), 1682 SA(..,SPIb2,..),Ni2 1683 recv req2 <-- 1684 send resp2: SA(..,SPIa3,..), 1685 Nr1,.. --> 1686 --> recv resp2 1687 <-- send req3: D(SPIb1) 1688 recv req3 <-- 1689 send resp3: D(SPIa1) --> 1690 --> recv resp3 1692 From B's point of view, the rekeying is now completed, and since it 1693 has not yet received A's req1, it does not even know that there was 1694 simultaneous rekeying. However, A will continue retransmitting the 1695 message, and eventually it will reach B. 1697 resend req1 --> 1698 --> recv req1 1700 To B, it looks like A is trying to rekey an SA that no longer exists; 1701 thus, B responds to the request with something non-fatal such as 1702 NO_PROPOSAL_CHOSEN. 1704 <-- send resp1: N(NO_PROPOSAL_CHOSEN) 1705 recv resp1 <-- 1707 When A receives this error, it already knows there was simultaneous 1708 rekeying, so it can ignore the error message. 1710 2.8.2. Simultaneous IKE SA Rekeying 1712 Probably the most complex case occurs when both peers try to rekey 1713 the IKE_SA at the same time. Basically, the text in Section 2.8 1714 applies to this case as well; however, it is important to ensure that 1715 the CHILD_SAs are inherited by the right IKE_SA. 1717 The case where both endpoints notice the simultaneous rekeying works 1718 the same way as with CHILD_SAs. After the CREATE_CHILD_SA exchanges, 1719 three IKE_SAs exist between A and B; the one containing the lowest 1720 nonce inherits the CHILD_SAs. 1722 However, there is a twist to the other case where one rekeying 1723 finishes first: 1725 Host A Host B 1726 ------------------------------------------------------------------- 1727 send req1: 1728 SA(..,SPIa1,..),Ni1,.. --> 1729 <-- send req2: SA(..,SPIb1,..),Ni2,.. 1730 --> recv req1 1731 <-- send resp1: SA(..,SPIb2,..),Nr2,.. 1732 recv resp1 <-- 1733 send req3: D() --> 1734 --> recv req3 1736 At this point, host B sees a request to close the IKE_SA. There's 1737 not much more to do than to reply as usual. However, at this point 1738 host B should stop retransmitting req2, since once host A receives 1739 resp3, it will delete all the state associated with the old IKE_SA 1740 and will not be able to reply to it. 1742 <-- send resp3: () 1744 2.8.3. Rekeying the IKE SA Versus Reauthentication 1746 Rekeying the IKE SA and reauthentication are different concepts in 1747 IKEv2. Rekeying the IKE SA establishes new keys for the IKE SA and 1748 resets the Message ID counters, but it does not authenticate the 1749 parties again (no AUTH or EAP payloads are involved). 1751 Although rekeying the IKE SA may be important in some environments, 1752 reauthentication (the verification that the parties still have access 1753 to the long-term credentials) is often more important. 1755 IKEv2 does not have any special support for reauthentication. 1756 Reauthentication is done by creating a new IKE SA from scratch (using 1757 IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify 1758 payloads), creating new Child SAs within the new IKE SA (without 1759 REKEY_SA notify payloads), and finally deleting the old IKE SA (which 1760 deletes the old Child SAs as well). 1762 This means that reauthentication also establishes new keys for the 1763 IKE SA and Child SAs. Therefore, while rekeying can be performed 1764 more often than reauthentication, the situation where "authentication 1765 lifetime" is shorter than "key lifetime" does not make sense. 1767 While creation of a new IKE SA can be initiated by either party 1768 (initiator or responder in the original IKE SA), the use of EAP 1769 authentication and/or configuration payloads means in practice that 1770 reauthentication has to be initiated by the same party as the 1771 original IKE SA. IKEv2 does not currently allow the responder to 1772 request reauthentication in this case; however, there are extensions 1773 that add this functionality such as [REAUTH]. 1775 2.9. Traffic Selector Negotiation 1777 When an RFC4301-compliant IPsec subsystem receives an IP packet that 1778 matches a "protect" selector in its Security Policy Database (SPD), 1779 the subsystem protects that packet with IPsec. When no SA exists 1780 yet, it is the task of IKE to create it. Maintenance of a system's 1781 SPD is outside the scope of IKE (see [PFKEY] for an example 1782 programming interface, although it only applies to IKEv1), though 1783 some implementations might update their SPD in connection with the 1784 running of IKE (for an example scenario, see Section 1.1.3). 1786 Traffic Selector (TS) payloads allow endpoints to communicate some of 1787 the information from their SPD to their peers. TS payloads specify 1788 the selection criteria for packets that will be forwarded over the 1789 newly set up SA. This can serve as a consistency check in some 1790 scenarios to assure that the SPDs are consistent. In others, it 1791 guides the dynamic update of the SPD. 1793 Two TS payloads appear in each of the messages in the exchange that 1794 creates a Child SA pair. Each TS payload contains one or more 1795 Traffic Selectors. Each Traffic Selector consists of an address 1796 range (IPv4 or IPv6), a port range, and an IP protocol ID. 1798 The first of the two TS payloads is known as TSi (Traffic Selector- 1799 initiator). The second is known as TSr (Traffic Selector-responder). 1800 TSi specifies the source address of traffic forwarded from (or the 1801 destination address of traffic forwarded to) the initiator of the 1802 Child SA pair. TSr specifies the destination address of the traffic 1803 forwarded to (or the source address of the traffic forwarded from) 1804 the responder of the Child SA pair. For example, if the original 1805 initiator requests the creation of a Child SA pair, and wishes to 1806 tunnel all traffic from subnet 192.0.1.* on the initiator's side to 1807 subnet 192.0.2.* on the responder's side, the initiator would include 1808 a single traffic selector in each TS payload. TSi would specify the 1809 address range (192.0.1.0 - 192.0.1.255) and TSr would specify the 1810 address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was 1811 acceptable to the responder, it would send identical TS payloads 1812 back. (Note: The IP address range 192.0.2.* has been reserved for 1813 use in examples in RFCs and similar documents. This document needed 1814 two such ranges, and so also used 192.0.1.*. This should not be 1815 confused with any actual address.) 1817 IKEv2 allows the responder to choose a subset of the traffic proposed 1818 by the initiator. This could happen when the configurations of the 1819 two endpoints are being updated but only one end has received the new 1820 information. Since the two endpoints may be configured by different 1821 people, the incompatibility may persist for an extended period even 1822 in the absence of errors. It also allows for intentionally different 1823 configurations, as when one end is configured to tunnel all addresses 1824 and depends on the other end to have the up-to-date list. 1826 When the responder chooses a subset of the traffic proposed by the 1827 initiator, it narrows the traffic selectors to some subset of the 1828 initiator's proposal (provided the set does not become the null set). 1829 If the type of traffic selector proposed is unknown, the responder 1830 ignores that traffic selector, so that the unknown type is not be 1831 returned in the narrowed set. 1833 To enable the responder to choose the appropriate range in this case, 1834 if the initiator has requested the SA due to a data packet, the 1835 initiator SHOULD include as the first traffic selector in each of TSi 1836 and TSr a very specific traffic selector including the addresses in 1837 the packet triggering the request. In the example, the initiator 1838 would include in TSi two traffic selectors: the first containing the 1839 address range (192.0.1.43 - 192.0.1.43) and the source port and IP 1840 protocol from the packet and the second containing (192.0.1.0 - 1841 192.0.1.255) with all ports and IP protocols. The initiator would 1842 similarly include two traffic selectors in TSr. If the initiator 1843 creates the Child SA pair not in response to an arriving packet, but 1844 rather, say, upon startup, then there may be no specific addresses 1845 the initiator prefers for the initial tunnel over any other. In that 1846 case, the first values in TSi and TSr can be ranges rather than 1847 specific values. 1849 The responder performs the narrowing as follows: 1851 o If the responder's policy does not allow it to accept any part of 1852 the proposed traffic selectors, it responds with TS_UNACCEPTABLE. 1854 o If the responder's policy allows the entire set of traffic covered 1855 by TSi and TSr, no narrowing is necessary, and the responder can 1856 return the same TSi and TSr values. 1858 o If the responder's policy allows it to accept the first selector 1859 of TSi and TSr, then the responder MUST narrow the traffic 1860 selectors to a subset that includes the initiator's first choices. 1861 In this example above, the responder might respond with TSi being 1862 (192.0.1.43 - 192.0.1.43) with all ports and IP protocols. 1864 o If the responder's policy does not allow it to accept the first 1865 selector of TSi and TSr, the responder narrows to an acceptable 1866 subset of TSi and TSr. 1868 When narrowing is done, there may be several subsets that are 1869 acceptable but their union is not. In this case, the responder 1870 arbitrarily chooses one of them, and MAY include an 1871 ADDITIONAL_TS_POSSIBLE notification in the response. The 1872 ADDITIONAL_TS_POSSIBLE notification asserts that the responder 1873 narrowed the proposed traffic selectors but that other traffic 1874 selectors would also have been acceptable, though only in a separate 1875 SA. There is no data associated with this Notify type. This case 1876 will occur only when the initiator and responder are configured 1877 differently from one another. If the initiator and responder agree 1878 on the granularity of tunnels, the initiator will never request a 1879 tunnel wider than the responder will accept. Such misconfigurations 1880 should be recorded in error logs. 1882 It is possible for the responder's policy to contain multiple smaller 1883 ranges, all encompassed by the initiator's traffic selector, and with 1884 the responder's policy being that each of those ranges should be sent 1885 over a different SA. Continuing the example above, the responder 1886 might have a policy of being willing to tunnel those addresses to and 1887 from the initiator, but might require that each address pair be on a 1888 separately negotiated Child SA. If the initiator generated its 1889 request in response to an incoming packet from 192.0.1.43 to 1890 192.0.2.123, there would be no way for the responder to determine 1891 which pair of addresses should be included in this tunnel, and it 1892 would have to make a guess or reject the request with a status of 1893 SINGLE_PAIR_REQUIRED. 1895 The SINGLE_PAIR_REQUIRED error indicates that a CREATE_CHILD_SA 1896 request is unacceptable because its sender is only willing to accept 1897 traffic selectors specifying a single pair of addresses. The 1898 requestor is expected to respond by requesting an SA for only the 1899 specific traffic it is trying to forward. 1901 Few implementations will have policies that require separate SAs for 1902 each address pair. Because of this, if only some parts of the TSi 1903 and TSr proposed by the initiator are acceptable to the responder, 1904 responders SHOULD narrow the selectors to an acceptable subset rather 1905 than use SINGLE_PAIR_REQUIRED. 1907 2.9.1. Traffic Selectors Violating Own Policy 1909 When creating a new SA, the initiator needs to avoid proposing 1910 traffic selectors that violate its own policy. If this rule is not 1911 followed, valid traffic may be dropped. If you use decorrelated 1912 policies from [IPSECARCH], this kind of policy violations cannot 1913 happen. 1915 This is best illustrated by an example. Suppose that host A has a 1916 policy whose effect is that traffic to 192.0.1.66 is sent via host B 1917 encrypted using AES, and traffic to all other hosts in 192.0.1.0/24 1918 is also sent via B, but must use 3DES. Suppose also that host B 1919 accepts any combination of AES and 3DES. 1921 If host A now proposes an SA that uses 3DES, and includes TSr 1922 containing (192.0.1.0-192.0.1.255), this will be accepted by host B. 1923 Now, host B can also use this SA to send traffic from 192.0.1.66, but 1924 those packets will be dropped by A since it requires the use of AES 1925 for those traffic. Even if host A creates a new SA only for 1926 192.0.1.66 that uses AES, host B may freely continue to use the first 1927 SA for the traffic. In this situation, when proposing the SA, host A 1928 should have followed its own policy, and included a TSr containing 1929 ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead. 1931 In general, if (1) the initiator makes a proposal "for traffic X 1932 (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator 1933 does not actually accept traffic X' with SA, and (3) the initiator 1934 would be willing to accept traffic X' with some SA' (!=SA), valid 1935 traffic can be unnecessarily dropped since the responder can apply 1936 either SA or SA' to traffic X'. 1938 2.10. Nonces 1940 The IKE_SA_INIT messages each contain a nonce. These nonces are used 1941 as inputs to cryptographic functions. The CREATE_CHILD_SA request 1942 and the CREATE_CHILD_SA response also contain nonces. These nonces 1943 are used to add freshness to the key derivation technique used to 1944 obtain keys for Child SA, and to ensure creation of strong pseudo- 1945 random bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST 1946 be randomly chosen, MUST be at least 128 bits in size, and MUST be at 1947 least half the key size of the negotiated prf. ("prf" refers to 1948 "pseudo-random function", one of the cryptographic algorithms 1949 negotiated in the IKE exchange.) However, the initiator chooses the 1950 nonce before the outcome of the negotiation is known. Because of 1951 that, the nonce has to be long enough for all the PRFs being 1952 proposed. If the same random number source is used for both keys and 1953 nonces, care must be taken to ensure that the latter use does not 1954 compromise the former. 1956 2.11. Address and Port Agility 1958 IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and 1959 AH associations for the same IP addresses it runs over. The IP 1960 addresses and ports in the outer header are, however, not themselves 1961 cryptographically protected, and IKE is designed to work even through 1962 Network Address Translation (NAT) boxes. An implementation MUST 1963 accept incoming requests even if the source port is not 500 or 4500, 1964 and MUST respond to the address and port from which the request was 1965 received. It MUST specify the address and port at which the request 1966 was received as the source address and port in the response. IKE 1967 functions identically over IPv4 or IPv6. 1969 2.12. Reuse of Diffie-Hellman Exponentials 1971 IKE generates keying material using an ephemeral Diffie-Hellman 1972 exchange in order to gain the property of "perfect forward secrecy". 1973 This means that once a connection is closed and its corresponding 1974 keys are forgotten, even someone who has recorded all of the data 1975 from the connection and gets access to all of the long-term keys of 1976 the two endpoints cannot reconstruct the keys used to protect the 1977 conversation without doing a brute force search of the session key 1978 space. 1980 Achieving perfect forward secrecy requires that when a connection is 1981 closed, each endpoint MUST forget not only the keys used by the 1982 connection but also any information that could be used to recompute 1983 those keys. 1985 Since the computing of Diffie-Hellman exponentials is computationally 1986 expensive, an endpoint may find it advantageous to reuse those 1987 exponentials for multiple connection setups. There are several 1988 reasonable strategies for doing this. An endpoint could choose a new 1989 exponential only periodically though this could result in less-than- 1990 perfect forward secrecy if some connection lasts for less than the 1991 lifetime of the exponential. Or it could keep track of which 1992 exponential was used for each connection and delete the information 1993 associated with the exponential only when some corresponding 1994 connection was closed. This would allow the exponential to be reused 1995 without losing perfect forward secrecy at the cost of maintaining 1996 more state. 1998 Decisions as to whether and when to reuse Diffie-Hellman exponentials 1999 is a private decision in the sense that it will not affect 2000 interoperability. An implementation that reuses exponentials MAY 2001 choose to remember the exponential used by the other endpoint on past 2002 exchanges and if one is reused to avoid the second half of the 2003 calculation. See [REUSE] for a security analysis of this practice 2004 and for additional security considerations when reusing ephemeral DH 2005 keys. 2007 2.13. Generating Keying Material 2009 In the context of the IKE SA, four cryptographic algorithms are 2010 negotiated: an encryption algorithm, an integrity protection 2011 algorithm, a Diffie-Hellman group, and a pseudo-random function 2012 (prf). The pseudo-random function is used for the construction of 2013 keying material for all of the cryptographic algorithms used in both 2014 the IKE SA and the Child SAs. 2016 We assume that each encryption algorithm and integrity protection 2017 algorithm uses a fixed-size key and that any randomly chosen value of 2018 that fixed size can serve as an appropriate key. For algorithms that 2019 accept a variable length key, a fixed key size MUST be specified as 2020 part of the cryptographic transform negotiated (see Section 3.3.5 for 2021 the defintion of the Key Length transform attribute). For algorithms 2022 for which not all values are valid keys (such as DES or 3DES with key 2023 parity), the algorithm by which keys are derived from arbitrary 2024 values MUST be specified by the cryptographic transform. For 2025 integrity protection functions based on Hashed Message Authentication 2026 Code (HMAC), the fixed key size is the size of the output of the 2027 underlying hash function. 2029 It is assumed that pseudo-random functions (PRFs) accept keys of any 2030 length, but have a preferred key size. The preferred key size is 2031 used as the length of SK_d, SK_pi, and SK_pr (see Section 2.14). For 2032 PRFs based on the HMAC construction, the preferred key size is equal 2033 to the length of the output of the underlying hash function. Other 2034 types of PRFs MUST specify their preferred key size. 2036 Keying material will always be derived as the output of the 2037 negotiated prf algorithm. Since the amount of keying material needed 2038 may be greater than the size of the output of the prf algorithm, we 2039 will use the prf iteratively. We will use the terminology prf+ to 2040 describe the function that outputs a pseudo-random stream based on 2041 the inputs to a prf as follows: (where | indicates concatenation) 2043 prf+ (K,S) = T1 | T2 | T3 | T4 | ... 2045 where: 2046 T1 = prf (K, S | 0x01) 2047 T2 = prf (K, T1 | S | 0x02) 2048 T3 = prf (K, T2 | S | 0x03) 2049 T4 = prf (K, T3 | S | 0x04) 2051 continuing as needed to compute all required keys. The keys are 2052 taken from the output string without regard to boundaries (e.g., if 2053 the required keys are a 256-bit Advanced Encryption Standard (AES) 2054 key and a 160-bit HMAC key, and the prf function generates 160 bits, 2055 the AES key will come from T1 and the beginning of T2, while the HMAC 2056 key will come from the rest of T2 and the beginning of T3). 2058 The constant concatenated to the end of each string feeding the prf 2059 is a single octet. prf+ in this document is not defined beyond 255 2060 times the size of the prf output. 2062 2.14. Generating Keying Material for the IKE SA 2064 The shared keys are computed as follows. A quantity called SKEYSEED 2065 is calculated from the nonces exchanged during the IKE_SA_INIT 2066 exchange and the Diffie-Hellman shared secret established during that 2067 exchange. SKEYSEED is used to calculate seven other secrets: SK_d 2068 used for deriving new keys for the Child SAs established with this 2069 IKE SA; SK_ai and SK_ar used as a key to the integrity protection 2070 algorithm for authenticating the component messages of subsequent 2071 exchanges; SK_ei and SK_er used for encrypting (and of course 2072 decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are 2073 used when generating an AUTH payload. The lengths of SK_d, SK_pi, 2074 and SK_pr are the preferred key length of the agreed-to PRF. 2076 SKEYSEED and its derivatives are computed as follows: 2078 SKEYSEED = prf(Ni | Nr, g^ir) 2080 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } 2081 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) 2083 (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, 2084 SK_pi, and SK_pr are taken in order from the generated bits of the 2085 prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman 2086 exchange. g^ir is represented as a string of octets in big endian 2087 order padded with zeros if necessary to make it the length of the 2088 modulus. Ni and Nr are the nonces, stripped of any headers. For 2089 historical backwards-compatibility reasons, there are two PRFs that 2090 are treated specially in this calculation. If the negotiated PRF is 2091 AES-XCBC-PRF-128 [RFC4434] or AES-CMAC-PRF-128 [RFC4615], only the 2092 first 64 bits of Ni and the first 64 bits of Nr are used in the 2093 calculation. 2095 The two directions of traffic flow use different keys. The keys used 2096 to protect messages from the original initiator are SK_ai and SK_ei. 2097 The keys used to protect messages in the other direction are SK_ar 2098 and SK_er. 2100 2.15. Authentication of the IKE SA 2102 When not using extensible authentication (see Section 2.16), the 2103 peers are authenticated by having each sign (or MAC using a shared 2104 secret as the key) a block of data. For the responder, the octets to 2105 be signed start with the first octet of the first SPI in the header 2106 of the second message (IKE_SA_INIT response) and end with the last 2107 octet of the last payload in the second message. Appended to this 2108 (for purposes of computing the signature) are the initiator's nonce 2109 Ni (just the value, not the payload containing it), and the value 2110 prf(SK_pr,IDr') where IDr' is the responder's ID payload excluding 2111 the fixed header. Note that neither the nonce Ni nor the value 2112 prf(SK_pr,IDr') are transmitted. Similarly, the initiator signs the 2113 first message (IKE_SA_INIT request), starting with the first octet of 2114 the first SPI in the header and ending with the last octet of the 2115 last payload. Appended to this (for purposes of computing the 2116 signature) are the responder's nonce Nr, and the value 2117 prf(SK_pi,IDi'). In the above calculation, IDi' and IDr' are the 2118 entire ID payloads excluding the fixed header. It is critical to the 2119 security of the exchange that each side sign the other side's nonce. 2121 The initiator's signed octets can be described as: 2123 InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI 2124 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 2125 RealIKEHDR = SPIi | SPIr | . . . | Length 2126 RealMessage1 = RealIKEHDR | RestOfMessage1 2127 NonceRPayload = PayloadHeader | NonceRData 2128 InitiatorIDPayload = PayloadHeader | RestOfIDPayload 2129 RestOfInitIDPayload = IDType | RESERVED | InitIDData 2130 MACedIDForI = prf(SK_pi, RestOfInitIDPayload) 2132 The responder's signed octets can be described as: 2134 ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR 2135 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 2136 RealIKEHDR = SPIi | SPIr | . . . | Length 2137 RealMessage2 = RealIKEHDR | RestOfMessage2 2138 NonceIPayload = PayloadHeader | NonceIData 2139 ResponderIDPayload = PayloadHeader | RestOfIDPayload 2140 RestOfRespIDPayload = IDType | RESERVED | RespIDData 2141 MACedIDForR = prf(SK_pr, RestOfRespIDPayload) 2143 Note that all of the payloads are included under the signature, 2144 including any payload types not defined in this document. If the 2145 first message of the exchange is sent multiple times (such as with a 2146 responder cookie and/or a different Diffie-Hellman group), it is the 2147 latest version of the message that is signed. 2149 Optionally, messages 3 and 4 MAY include a certificate, or 2150 certificate chain providing evidence that the key used to compute a 2151 digital signature belongs to the name in the ID payload. The 2152 signature or MAC will be computed using algorithms dictated by the 2153 type of key used by the signer, and specified by the Auth Method 2154 field in the Authentication payload. There is no requirement that 2155 the initiator and responder sign with the same cryptographic 2156 algorithms. The choice of cryptographic algorithms depends on the 2157 type of key each has. In particular, the initiator may be using a 2158 shared key while the responder may have a public signature key and 2159 certificate. It will commonly be the case (but it is not required) 2160 that if a shared secret is used for authentication that the same key 2161 is used in both directions. 2163 Note that it is a common but typically insecure practice to have a 2164 shared key derived solely from a user-chosen password without 2165 incorporating another source of randomness. This is typically 2166 insecure because user-chosen passwords are unlikely to have 2167 sufficient unpredictability to resist dictionary attacks and these 2168 attacks are not prevented in this authentication method. 2169 (Applications using password-based authentication for bootstrapping 2170 and IKE SA should use the authentication method in Section 2.16, 2171 which is designed to prevent off-line dictionary attacks.) The pre- 2172 shared key needs to contain as much unpredictability as the strongest 2173 key being negotiated. In the case of a pre-shared key, the AUTH 2174 value is computed as: 2176 For the initiator: 2177 AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"), 2178 ) 2179 For the responder: 2180 AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"), 2181 ) 2183 where the string "Key Pad for IKEv2" is 17 ASCII characters without 2184 null termination. The shared secret can be variable length. The pad 2185 string is added so that if the shared secret is derived from a 2186 password, the IKE implementation need not store the password in 2187 cleartext, but rather can store the value prf(Shared Secret,"Key Pad 2188 for IKEv2"), which could not be used as a password equivalent for 2189 protocols other than IKEv2. As noted above, deriving the shared 2190 secret from a password is not secure. This construction is used 2191 because it is anticipated that people will do it anyway. The 2192 management interface by which the Shared Secret is provided MUST 2193 accept ASCII strings of at least 64 octets and MUST NOT add a null 2194 terminator before using them as shared secrets. It MUST also accept 2195 a hex encoding of the Shared Secret. The management interface MAY 2196 accept other encodings if the algorithm for translating the encoding 2197 to a binary string is specified. 2199 2.16. Extensible Authentication Protocol Methods 2201 In addition to authentication using public key signatures and shared 2202 secrets, IKE supports authentication using methods defined in RFC 2203 3748 [EAP]. Typically, these methods are asymmetric (designed for a 2204 user authenticating to a server), and they may not be mutual. For 2205 this reason, these protocols are typically used to authenticate the 2206 initiator to the responder and MUST be used in conjunction with a 2207 public key signature based authentication of the responder to the 2208 initiator. These methods are often associated with mechanisms 2209 referred to as "Legacy Authentication" mechanisms. 2211 While this memo references [EAP] with the intent that new methods can 2212 be added in the future without updating this specification, some 2213 simpler variations are documented here and in Section 3.16. [EAP] 2214 defines an authentication protocol requiring a variable number of 2215 messages. Extensible Authentication is implemented in IKE as 2216 additional IKE_AUTH exchanges that MUST be completed in order to 2217 initialize the IKE SA. 2219 An initiator indicates a desire to use extensible authentication by 2220 leaving out the AUTH payload from message 3. By including an IDi 2221 payload but not an AUTH payload, the initiator has declared an 2222 identity but has not proven it. If the responder is willing to use 2223 an extensible authentication method, it will place an Extensible 2224 Authentication Protocol (EAP) payload in message 4 and defer sending 2225 SAr2, TSi, and TSr until initiator authentication is complete in a 2226 subsequent IKE_AUTH exchange. In the case of a minimal extensible 2227 authentication, the initial SA establishment will appear as follows: 2229 Initiator Responder 2230 ------------------------------------------------------------------- 2231 HDR, SAi1, KEi, Ni --> 2232 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 2233 HDR, SK {IDi, [CERTREQ,] 2234 [IDr,] SAi2, 2235 TSi, TSr} --> 2236 <-- HDR, SK {IDr, [CERT,] AUTH, 2237 EAP } 2238 HDR, SK {EAP} --> 2239 <-- HDR, SK {EAP (success)} 2240 HDR, SK {AUTH} --> 2241 <-- HDR, SK {AUTH, SAr2, TSi, TSr } 2243 As described in Section 2.2, when EAP is used, each pair of IKE SA 2244 initial setup messages will have their message numbers incremented; 2245 the first pair of AUTH messages will have an ID of 1, the second will 2246 be 2, and so on. 2248 For EAP methods that create a shared key as a side effect of 2249 authentication, that shared key MUST be used by both the initiator 2250 and responder to generate AUTH payloads in messages 7 and 8 using the 2251 syntax for shared secrets specified in Section 2.15. The shared key 2252 from EAP is the field from the EAP specification named MSK. This 2253 shared key generated during an IKE exchange MUST NOT be used for any 2254 other purpose. 2256 EAP methods that do not establish a shared key SHOULD NOT be used, as 2257 they are subject to a number of man-in-the-middle attacks [EAPMITM] 2258 if these EAP methods are used in other protocols that do not use a 2259 server-authenticated tunnel. Please see the Security Considerations 2260 section for more details. If EAP methods that do not generate a 2261 shared key are used, the AUTH payloads in messages 7 and 8 MUST be 2262 generated using SK_pi and SK_pr, respectively. 2264 The initiator of an IKE SA using EAP needs to be capable of extending 2265 the initial protocol exchange to at least ten IKE_AUTH exchanges in 2266 the event the responder sends notification messages and/or retries 2267 the authentication prompt. Once the protocol exchange defined by the 2268 chosen EAP authentication method has successfully terminated, the 2269 responder MUST send an EAP payload containing the Success message. 2270 Similarly, if the authentication method has failed, the responder 2271 MUST send an EAP payload containing the Failure message. The 2272 responder MAY at any time terminate the IKE exchange by sending an 2273 EAP payload containing the Failure message. 2275 Following such an extended exchange, the EAP AUTH payloads MUST be 2276 included in the two messages following the one containing the EAP 2277 Success message. 2279 When the initiator authentication uses EAP, it is possible that the 2280 contents of the IDi payload is used only for AAA routing purposes and 2281 selecting which EAP method to use. This value may be different from 2282 the identity authenticated by the EAP method. It is important that 2283 policy lookups and access control decisions use the actual 2284 authenticated identity. Often the EAP server is implemented in a 2285 separate AAA server that communicates with the IKEv2 responder. In 2286 this case, the authenticated identity has to be sent from the AAA 2287 server to the IKEv2 responder. 2289 2.17. Generating Keying Material for Child SAs 2291 A single Child SA is created by the IKE_AUTH exchange, and additional 2292 Child SAs can optionally be created in CREATE_CHILD_SA exchanges. 2294 Keying material for them is generated as follows: 2296 KEYMAT = prf+(SK_d, Ni | Nr) 2298 Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this 2299 request is the first Child SA created or the fresh Ni and Nr from the 2300 CREATE_CHILD_SA exchange if this is a subsequent creation. 2302 For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman 2303 exchange, the keying material is defined as: 2305 KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) 2307 where g^ir (new) is the shared secret from the ephemeral Diffie- 2308 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 2309 octet string in big endian order padded with zeros in the high-order 2310 bits if necessary to make it the length of the modulus). 2312 For ESP and AH, a single Child SA negotiation results in two security 2313 associations (one in each direction). Keying material MUST be taken 2314 from the expanded KEYMAT in the following order: 2316 o The encryption key (if any) for the SA carrying data from the 2317 initiator to the responder. 2319 o The authentication key (if any) for the SA carrying data from the 2320 initiator to the responder. 2322 o The encryption key (if any) for the SA carrying data from the 2323 responder to the initiator. 2325 o The authentication key (if any) for the SA carrying data from the 2326 responder to the initiator. 2328 Each cryptographic algorithm takes a fixed number of bits of keying 2329 material specified as part of the algorithm, or negotiated in SA 2330 payloads (see Section 2.13 for description of key lengths, and 2331 Section 3.3.5 for the definition of the Key Length transform 2332 attribute). 2334 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange 2336 The CREATE_CHILD_SA exchange can be used to rekey an existing IKE SA 2337 (see Section 2.8). New initiator and responder SPIs are supplied in 2338 the SPI fields in the Proposal structures inside the Security 2339 Association (SA) payloads (not the SPI fields in the IKE header). 2340 The TS payloads are omitted when rekeying an IKE SA. SKEYSEED for 2341 the new IKE SA is computed using SK_d from the existing IKE SA as 2342 follows: 2344 SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr) 2346 where g^ir (new) is the shared secret from the ephemeral Diffie- 2347 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 2348 octet string in big endian order padded with zeros if necessary to 2349 make it the length of the modulus) and Ni and Nr are the two nonces 2350 stripped of any headers. 2352 The old and new IKE SA may have selected a different PRF. Because 2353 the rekeying exchange belongs to the old IKE SA, it is the old IKE 2354 SA's PRF that is used. 2356 The main reason for rekeying the IKE SA is to ensure that the 2357 compromise of old keying material does not provide information about 2358 the current keys, or vice versa. Therefore, implementations MUST 2359 perform a new Diffie-Hellman exchange when rekeying the IKE SA. In 2360 other words, an initiator MUST NOT propose the value "NONE" for the 2361 D-H transform, and a responder MUST NOT accept such a proposal. This 2362 means that a succesful exchange rekeying the IKE SA always includes 2363 the KEi/KEr payloads. 2365 The new IKE SA MUST reset its message counters to 0. 2367 SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as 2368 specified in Section 2.14, using SPIi, SPIr, Ni, and Nr from the new 2369 exchange. 2371 2.19. Requesting an Internal Address on a Remote Network 2373 Most commonly occurring in the endpoint-to-security-gateway scenario, 2374 an endpoint may need an IP address in the network protected by the 2375 security gateway and may need to have that address dynamically 2376 assigned. A request for such a temporary address can be included in 2377 any request to create a Child SA (including the implicit request in 2378 message 3) by including a CP payload. Note, however, it is usual to 2379 only assign one IP address during the IKE_AUTH exchange. That 2380 address persists at least until the deletion of the IKE SA. 2382 This function provides address allocation to an IPsec Remote Access 2383 Client (IRAC) trying to tunnel into a network protected by an IPsec 2384 Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an 2385 IKE SA and a Child SA, the IRAC MUST request the IRAS-controlled 2386 address (and optionally other information concerning the protected 2387 network) in the IKE_AUTH exchange. The IRAS may procure an address 2388 for the IRAC from any number of sources such as a DHCP/BOOTP server 2389 or its own address pool. 2391 Initiator Responder 2392 ------------------------------------------------------------------- 2393 HDR, SK {IDi, [CERT,] 2394 [CERTREQ,] [IDr,] AUTH, 2395 CP(CFG_REQUEST), SAi2, 2396 TSi, TSr} --> 2397 <-- HDR, SK {IDr, [CERT,] AUTH, 2398 CP(CFG_REPLY), SAr2, 2399 TSi, TSr} 2401 In all cases, the CP payload MUST be inserted before the SA payload. 2402 In variations of the protocol where there are multiple IKE_AUTH 2403 exchanges, the CP payloads MUST be inserted in the messages 2404 containing the SA payloads. 2406 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute 2407 (either IPv4 or IPv6) but MAY contain any number of additional 2408 attributes the initiator wants returned in the response. 2410 For example, message from initiator to responder: 2412 CP(CFG_REQUEST)= 2413 INTERNAL_ADDRESS() 2414 TSi = (0, 0-65535,0.0.0.0-255.255.255.255) 2415 TSr = (0, 0-65535,0.0.0.0-255.255.255.255) 2417 NOTE: Traffic Selectors contain (protocol, port range, address 2418 range). 2420 Message from responder to initiator: 2422 CP(CFG_REPLY)= 2423 INTERNAL_ADDRESS(192.0.2.202) 2424 INTERNAL_NETMASK(255.255.255.0) 2425 INTERNAL_SUBNET(192.0.2.0/255.255.255.0) 2426 TSi = (0, 0-65535,192.0.2.202-192.0.2.202) 2427 TSr = (0, 0-65535,192.0.2.0-192.0.2.255) 2429 All returned values will be implementation dependent. As can be seen 2430 in the above example, the IRAS MAY also send other attributes that 2431 were not included in CP(CFG_REQUEST) and MAY ignore the non- 2432 mandatory attributes that it does not support. 2434 The FAILED_CP_REQUIRED notification is sent by responder in the case 2435 where CP(CFG_REQUEST) was expected but not received, and so is a 2436 conflict with locally configured policy. There is no associated 2437 data. 2439 The responder MUST NOT send a CFG_REPLY without having first received 2440 a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS 2441 to perform an unnecessary configuration lookup if the IRAC cannot 2442 process the REPLY. In the case where the IRAS's configuration 2443 requires that CP be used for a given identity IDi, but IRAC has 2444 failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and 2445 terminate the IKE exchange with a FAILED_CP_REQUIRED error. The 2446 FAILED_CP_REQUIRED is not fatal to the IKE SA; it simply causes the 2447 Child SA creation fail. The initiator can fix this by later starting 2448 a new configuration payload request. 2450 2.20. Requesting the Peer's Version 2452 An IKE peer wishing to inquire about the other peer's IKE software 2453 version information MAY use the method below. This is an example of 2454 a configuration request within an INFORMATIONAL exchange, after the 2455 IKE SA and first Child SA have been created. 2457 An IKE implementation MAY decline to give out version information 2458 prior to authentication or even after authentication to prevent 2459 trolling in case some implementation is known to have some security 2460 weakness. In that case, it MUST either return an empty string or no 2461 CP payload if CP is not supported. 2463 Initiator Responder 2464 ------------------------------------------------------------------- 2465 HDR, SK{CP(CFG_REQUEST)} --> 2466 <-- HDR, SK{CP(CFG_REPLY)} 2468 CP(CFG_REQUEST)= 2469 APPLICATION_VERSION("") 2471 CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar 2472 Inc.") 2474 2.21. Error Handling 2476 There are many kinds of errors that can occur during IKE processing. 2477 The general rule is that if a request is received that is badly 2478 formatted, or unacceptable for reasons of policy (such as no matching 2479 cryptographic algorithms), the response contains a Notify payload 2480 indicating the error. The decision whether or not to send such a 2481 response depends whether or not there is an authenticated IKE SA. 2483 If there is an error parsing or processing a response packet, the 2484 general rule is to not send back any error message because responses 2485 should not generate new requests (and a new request would be the only 2486 way to send back an error message). Such errors in parsing or 2487 processing response packets should still cause the recipient to clean 2488 up the IKE state (for example, by sending a DELETE for a bad SA). 2490 Only authentication failures (AUTHENTICATION_FAILED) and malformed 2491 messages (INVALID_SYNTAX) lead to a deletion of the IKE SA without 2492 requiring an explicit INFORMATIONAL exchange carrying a DELETE 2493 payload. Other error conditions MAY require such an exchange if 2494 policy dictates that this is needed. 2496 2.21.1. Error Handling in IKE_SA_INIT 2498 Errors that occur before a cryptographically protected IKE SA is 2499 established need to be handled very carefully. There is a trade-off 2500 between wanting to help the peer to diagnose a problem and thus 2501 responding to the error, and wanting to avoid being part of a denial 2502 of service attack based on forged messages. 2504 In an IKE_SA_INIT exchange, any error notification causes the 2505 exchange to fail. Note that some error notifications such as COOKIE, 2506 INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent 2507 successful exchange. Because all error notifications are completely 2508 unauthenticated, the recipient should continue trying for some time 2509 before giving up. The recipient should not immediately act based on 2510 the error notification unless corrective actions are defined in this 2511 specification, such as for COOKIE, INVALID_KE_PAYLOAD, and 2512 INVALID_MAJOR_VERSION. 2514 2.21.2. Error Handling in IKE_AUTH 2516 All errors that occur in an IKE_AUTH exchange, causing the 2517 authentication to fail for whatever reason (invalid shared secret, 2518 invalid ID, untrusted certificate issuer, revoked or expired 2519 certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED 2520 notification. If the error occurred on the responder, the 2521 notification is returned in the protected response, and is usually 2522 the only payload in that response. Although the IKE_AUTH messages 2523 are encrypted and integrity protected, if the peer receiving this 2524 notification has not authenticated the other end yet, that peer needs 2525 to treat the information with caution. 2527 If the error occurs on the initiator, the notification MAY be 2528 returned in a separate INFORMATIONAL exchange, usually with no other 2529 payloads. This is exception for the general rule of not starting new 2530 exchanges based on errors in responses. 2532 Note, however, that request messages that contain an unsupported 2533 critical payload, or where the whole message is malformed (rather 2534 than just bad payload contents), MUST be rejected in their entirety, 2535 and MUST only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or 2536 INVALID_SYNTAX Notification sent as response. The receiver should 2537 not verify the payloads related to authentication in this case. 2539 If authentication has succeeded in the IKE_AUTH exchange, the IKE SA 2540 is established; however, establishing the Child SA or requesting 2541 configuration information may still fail. This failure does not 2542 automatically cause the IKE SA to be deleted. Specifically, a 2543 responder may include all the payloads associated with authentication 2544 (IDr, Cert and AUTH) while sending error notifications for the 2545 piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS, 2546 NO_PROPOSAL_CHOSEN, and so on), and the initiator MUST NOT fail the 2547 authentication because of this. The initiator MAY, of course, for 2548 reasons of policy later delete such an IKE SA. 2550 In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately 2551 following it (in case an error happened in when processing response 2552 to IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and 2553 AUTHENTICATION_FAILED notifications are the only ones to cause the 2554 IKE SA to be deleted or not created, without a DELETE payload. 2555 Extension documents may define new error notifications with these 2556 semantics, but MUST NOT use them unless the peer has been shown to 2557 understand them. 2559 NOTE FOR WG DISCUSSION: Having other payloads in the message is 2560 allowed but there are none suggested. One WG member mentioned the 2561 possibility of adding a DELETE payload when the error is sent in a 2562 separate INFORMATIONAL exchange. Do we want to allow such additional 2563 payloads that have operational semantics? 2565 2.21.3. Error Handling after IKE SA is Authenticated 2567 After the IKE SA is authenticated all requests having errors MUST 2568 result in response notifying about the error. 2570 In normal situations, there should not be cases where valid response 2571 from one peer results in an error situation in the other peer, so 2572 there should not be any reason for a peer to send error messages to 2573 the other end except as a response. Because sending such error 2574 messages as INFORMATIONAL exchange might lead to further errors that 2575 could cause loops, such errors SHOULD NOT be sent. If errors are 2576 seen that indicate that the peers do not have same state, it might be 2577 good to delete the IKE SA to clean up state and start over. 2579 If a peer parsing a request notices that it is badly formatted (after 2580 it has passed the message authentication code checks and window 2581 checks) and it returns an INVALID_SYNTAX notification, then this 2582 error notification is considered fatal in both peers, meaning that 2583 the IKE SA is deleted without needing an explicit DELETE payload. 2585 2.21.4. Error Handling Outside IKE SA 2587 A node needs to limit the rate at which it will send messages in 2588 response to unprotected messages. 2590 If a node receives a message on UDP port 500 or 4500 outside the 2591 context of an IKE SA known to it (and the message is not a request to 2592 start an IKE SA), this may be the result of a recent crash of the 2593 node. If the message is marked as a response, the node can audit the 2594 suspicious event but MUST NOT respond. If the message is marked as a 2595 request, the node can audit the suspicious event and MAY send a 2596 response. If a response is sent, the response MUST be sent to the IP 2597 address and port from where it came with the same IKE SPIs and the 2598 Message ID copied. The response MUST NOT be cryptographically 2599 protected and MUST contain an INVALID_IKE_SPI Notify payload. The 2600 INVALID_IKE_SPI notification indicates an IKE message was received 2601 with an unrecognized destination SPI; this usually indicates that the 2602 recipient has rebooted and forgotten the existence of an IKE SA. 2604 A peer receiving such an unprotected Notify payload MUST NOT respond 2605 and MUST NOT change the state of any existing SAs. The message might 2606 be a forgery or might be a response that a genuine correspondent was 2607 tricked into sending. A node should treat such a message (and also a 2608 network message like ICMP destination unreachable) as a hint that 2609 there might be problems with SAs to that IP address and should 2610 initiate a liveness check for any such IKE SA. An implementation 2611 SHOULD limit the frequency of such tests to avoid being tricked into 2612 participating in a denial of service attack. 2614 If an error occurs outside the context of an IKE request (e.g., the 2615 node is getting ESP messages on a nonexistent SPI), the node SHOULD 2616 initiate an INFORMATIONAL exchange with a Notify payload describing 2617 the problem. 2619 A node receiving a suspicious message from an IP address (and port, 2620 if NAT traversal is used) with which it has an IKE SA SHOULD send an 2621 IKE Notify payload in an IKE INFORMATIONAL exchange over that SA. 2622 The recipient MUST NOT change the state of any SAs as a result, but 2623 may wish to audit the event to aid in diagnosing malfunctions. 2625 2.22. IPComp 2627 Use of IP compression [IP-COMP] can be negotiated as part of the 2628 setup of a Child SA. While IP compression involves an extra header 2629 in each packet and a compression parameter index (CPI), the virtual 2630 "compression association" has no life outside the ESP or AH SA that 2631 contains it. Compression associations disappear when the 2632 corresponding ESP or AH SA goes away. It is not explicitly mentioned 2633 in any DELETE payload. 2635 Negotiation of IP compression is separate from the negotiation of 2636 cryptographic parameters associated with a Child SA. A node 2637 requesting a Child SA MAY advertise its support for one or more 2638 compression algorithms through one or more Notify payloads of type 2639 IPCOMP_SUPPORTED. This notification may be included only in a 2640 message containing an SA payload negotiating a Child SA and indicates 2641 a willingness by its sender to use IPComp on this SA. The response 2642 MAY indicate acceptance of a single compression algorithm with a 2643 Notify payload of type IPCOMP_SUPPORTED. These payloads MUST NOT 2644 occur in messages that do not contain SA payloads. 2646 The data associated with this notification includes a two-octet 2647 IPComp CPI followed by a one-octet transform ID optionally followed 2648 by attributes whose length and format are defined by that transform 2649 ID. A message proposing an SA may contain multiple IPCOMP_SUPPORTED 2650 notifications to indicate multiple supported algorithms. A message 2651 accepting an SA may contain at most one. 2653 The transform IDs currently defined are: 2655 Name Number Defined In 2656 ------------------------------------- 2657 RESERVED 0 2658 IPCOMP_OUI 1 2659 IPCOMP_DEFLATE 2 RFC 2394 2660 IPCOMP_LZS 3 RFC 2395 2661 IPCOMP_LZJH 4 RFC 3051 2662 RESERVED TO IANA 5-240 2663 PRIVATE USE 241-255 2665 Although there has been discussion of allowing multiple compression 2666 algorithms to be accepted and to have different compression 2667 algorithms available for the two directions of a Child SA, 2668 implementations of this specification MUST NOT accept an IPComp 2669 algorithm that was not proposed, MUST NOT accept more than one, and 2670 MUST NOT compress using an algorithm other than one proposed and 2671 accepted in the setup of the Child SA. 2673 A side effect of separating the negotiation of IPComp from 2674 cryptographic parameters is that it is not possible to propose 2675 multiple cryptographic suites and propose IP compression with some of 2676 them but not others. 2678 In some cases, Robust Header Compression (ROHC) may be more 2679 appropriate than IP Compression. [ROHCV2] defines the use of ROHC 2680 with IKEv2 and IPsec. 2682 2.23. NAT Traversal 2684 Network Address Translation (NAT) gateways are a controversial 2685 subject. This section briefly describes what they are and how they 2686 are likely to act on IKE traffic. Many people believe that NATs are 2687 evil and that we should not design our protocols so as to make them 2688 work better. IKEv2 does specify some unintuitive processing rules in 2689 order that NATs are more likely to work. 2691 NATs exist primarily because of the shortage of IPv4 addresses, 2692 though there are other rationales. IP nodes that are "behind" a NAT 2693 have IP addresses that are not globally unique, but rather are 2694 assigned from some space that is unique within the network behind the 2695 NAT but that are likely to be reused by nodes behind other NATs. 2696 Generally, nodes behind NATs can communicate with other nodes behind 2697 the same NAT and with nodes with globally unique addresses, but not 2698 with nodes behind other NATs. There are exceptions to that rule. 2699 When those nodes make connections to nodes on the real Internet, the 2700 NAT gateway "translates" the IP source address to an address that 2701 will be routed back to the gateway. Messages to the gateway from the 2702 Internet have their destination addresses "translated" to the 2703 internal address that will route the packet to the correct endnode. 2705 NATs are designed to be "transparent" to endnodes. Neither software 2706 on the node behind the NAT nor the node on the Internet requires 2707 modification to communicate through the NAT. Achieving this 2708 transparency is more difficult with some protocols than with others. 2709 Protocols that include IP addresses of the endpoints within the 2710 payloads of the packet will fail unless the NAT gateway understands 2711 the protocol and modifies the internal references as well as those in 2712 the headers. Such knowledge is inherently unreliable, is a network 2713 layer violation, and often results in subtle problems. 2715 Opening an IPsec connection through a NAT introduces special 2716 problems. If the connection runs in transport mode, changing the IP 2717 addresses on packets will cause the checksums to fail and the NAT 2718 cannot correct the checksums because they are cryptographically 2719 protected. Even in tunnel mode, there are routing problems because 2720 transparently translating the addresses of AH and ESP packets 2721 requires special logic in the NAT and that logic is heuristic and 2722 unreliable in nature. For that reason, IKEv2 will use UDP 2723 encapsulation of IKE and ESP packets. This encoding is slightly less 2724 efficient but is easier for NATs to process. In addition, firewalls 2725 may be configured to pass IPsec traffic over UDP but not ESP/AH or 2726 vice versa. 2728 It is a common practice of NATs to translate TCP and UDP port numbers 2729 as well as addresses and use the port numbers of inbound packets to 2730 decide which internal node should get a given packet. For this 2731 reason, even though IKE packets MUST be sent from and to UDP port 500 2732 or 4500, they MUST be accepted coming from any port and responses 2733 MUST be sent to the port from whence they came. This is because the 2734 ports may be modified as the packets pass through NATs. Similarly, 2735 IP addresses of the IKE endpoints are generally not included in the 2736 IKE payloads because the payloads are cryptographically protected and 2737 could not be transparently modified by NATs. 2739 Port 4500 is reserved for UDP-encapsulated ESP and IKE. An IPsec 2740 endpoint that discovers a NAT between it and its correspondent MUST 2741 send all subsequent traffic from port 4500, which NATs should not 2742 treat specially (as they might with port 500). 2744 An initiator can float to port 4500, regardless whether or not there 2745 is NAT, even at the beginning of IKE. When either side is using port 2746 4500, sending with UDP encapsulation is not required, but 2747 understanding received packets with UDP encapsulation is required. 2748 UDP encapsulation MUST NOT be done on port 500. If NAT-T is 2749 supported (that is, if NAT_DETECTION_*_IP payloads were exchanged 2750 during IKE_SA_INIT), all devices MUST be able to receive and process 2751 both UDP encapsulated and non-UDP encapsulated packets at any time. 2752 Either side can decide whether or not to use UDP encapsulation 2753 irrespective of the choice made by the other side. However, if a NAT 2754 is detected, both devices MUST send UDP encapsulated packets. 2756 The specific requirements for supporting NAT traversal [NATREQ] are 2757 listed below. Support for NAT traversal is optional. In this 2758 section only, requirements listed as MUST apply only to 2759 implementations supporting NAT traversal. 2761 o IKE MUST listen on port 4500 as well as port 500. IKE MUST 2762 respond to the IP address and port from which packets arrived. 2764 o Both IKE initiator and responder MUST include in their IKE_SA_INIT 2765 packets Notify payloads of type NAT_DETECTION_SOURCE_IP and 2766 NAT_DETECTION_DESTINATION_IP. Those payloads can be used to 2767 detect if there is NAT between the hosts, and which end is behind 2768 the NAT. The location of the payloads in the IKE_SA_INIT packets 2769 is just after the Ni and Nr payloads (before the optional CERTREQ 2770 payload). 2772 o The data associated with the NAT_DETECTION_SOURCE_IP notification 2773 is a SHA-1 digest of the SPIs (in the order they appear in the 2774 header), IP address, and port on which this packet was sent. 2775 There MAY be multiple NAT_DETECTION_SOURCE_IP payloads in a 2776 message if the sender does not know which of several network 2777 attachments will be used to send the packet. 2779 o The data associated with the NAT_DETECTION_DESTINATION_IP 2780 notification is a SHA-1 digest of the SPIs (in the order they 2781 appear in the header), IP address, and port to which this packet 2782 was sent. 2784 o The recipient of either the NAT_DETECTION_SOURCE_IP or 2785 NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied 2786 value to a SHA-1 hash of the SPIs, source IP address, and port, 2787 and if they don't match it SHOULD enable NAT traversal. In the 2788 case of a mismatching NAT_DETECTION_SOURCE_IP hash, the recipient 2789 MAY reject the connection attempt if NAT traversal is not 2790 supported. In the case of a mismatching 2791 NAT_DETECTION_DESTINATION_IP hash, it means that the system 2792 receiving the NAT_DETECTION_DESTINATION_IP payload is behind a NAT 2793 and that system SHOULD start sending keepalive packets as defined 2794 in [UDPENCAPS]; alternately, it MAY reject the connection attempt 2795 if NAT traversal is not supported. 2797 o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches 2798 the expected value of the source IP and port found from the IP 2799 header of the packet containing the payload, it means that the 2800 system sending those payloads is behind NAT (i.e., someone along 2801 the route changed the source address of the original packet to 2802 match the address of the NAT box). In this case, the system 2803 receiving the payloads should allow dynamic update of the other 2804 systems' IP address, as described later. 2806 o If the NAT_DETECTION_DESTINATION_IP payload received does not 2807 match the hash of the destination IP and port found from the IP 2808 header of the packet containing the payload, it means that the 2809 system receiving the NAT_DETECTION_DESTINATION_IP payload is 2810 behind a NAT. In this case, that system SHOULD start sending 2811 keepalive packets as explained in [UDPENCAPS]. 2813 o The IKE initiator MUST check these payloads if present and if they 2814 do not match the addresses in the outer packet MUST tunnel all 2815 future IKE and ESP packets associated with this IKE SA over UDP 2816 port 4500. 2818 o To tunnel IKE packets over UDP port 4500, the IKE header has four 2819 octets of zero prepended and the result immediately follows the 2820 UDP header. To tunnel ESP packets over UDP port 4500, the ESP 2821 header immediately follows the UDP header. Since the first four 2822 octets of the ESP header contain the SPI, and the SPI cannot 2823 validly be zero, it is always possible to distinguish ESP and IKE 2824 messages. 2826 o Implementations MUST process received UDP-encapsulated ESP packets 2827 even when no NAT was detected. 2829 o The original source and destination IP address required for the 2830 transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) 2831 are obtained from the Traffic Selectors associated with the 2832 exchange. In the case of NAT traversal, the Traffic Selectors 2833 MUST contain exactly one IP address, which is then used as the 2834 original IP address. 2836 o There are cases where a NAT box decides to remove mappings that 2837 are still alive (for example, the keepalive interval is too long, 2838 or the NAT box is rebooted). To recover in these cases, hosts 2839 that are not behind a NAT SHOULD send all packets (including 2840 retransmission packets) to the IP address and port from the last 2841 valid authenticated packet from the other end (i.e., dynamically 2842 update the address). A host behind a NAT SHOULD NOT do this 2843 because it opens a DoS attack possibility. Any authenticated IKE 2844 packet or any authenticated UDP-encapsulated ESP packet can be 2845 used to detect that the IP address or the port has changed. 2847 o There are cases where a NAT box decides to remove mappings that 2848 are still alive (for example, the keepalive interval is too long, 2849 or the NAT box is rebooted). To recover in these cases, hosts 2850 that do not support other methods of recovery such as MOBIKE 2851 [MOBIKE], and that are not behind a NAT, SHOULD send all packets 2852 (including retransmission packets) to the IP address and port from 2853 the last valid authenticated packet from the other end (that is, 2854 they should dynamically update the address). A host behind a NAT 2855 SHOULD NOT do this because it opens a possible denial-of-service 2856 attack. Any authenticated IKE packet or any authenticated UDP- 2857 encapsulated ESP packet can be used to detect that the IP address 2858 or the port has changed. When IKEv2 is used with MOBIKE, 2859 dynamically updating the addresses described above interferes with 2860 MOBIKE's way of recovering from the same situation, so this method 2861 MUST NOT be used when MOBIKE is used. See Section 3.8 of [MOBIKE] 2862 for more information. 2864 2.23.1. Transport Mode NAT Traversal 2866 Transport mode used with NAT Traversal requires special handling of 2867 the traffic selectors used in the IKEv2. The complete scenario looks 2868 like: 2870 +------+ +------+ +------+ +------+ 2871 |Client| IP1 | NAT | IPN1 IPN2 | NAT | IP2 |Server| 2872 |node |<------>| A |<---------->| B |<------->| | 2873 +------+ +------+ +------+ +------+ 2875 (Other scenarios are simplications of this complex case, so this 2876 discussion uses the complete scenario.) 2878 In this scenario, there are two address translating NATs: NAT A and 2879 NAT B. NAT A is dynamic NAT that maps the clients source address IP1 2880 to IPN1. NAT B is static NAT configured so that connections coming 2881 to IPN2 address are mapped to the gateways adddress IP2, that is, 2882 IPN2 destination address is mapped to IP2. This allows the client to 2883 connect to a server by connecting to the IPN2. NAT B does not 2884 necessarily need to be a static NAT, but the client needs to know how 2885 to connect to the server, and it can only do that if it somehow knows 2886 the outer address of the NAT B, that is, the IPN2 address. If NAT B 2887 is a static NAT, then its address can be configured to the client's 2888 configuration. Other options would be find it using some other 2889 protocol (like DNS), but those are outside of scope of IKEv2. 2891 In this scenario, both client and server are configured to use 2892 transport mode for the traffic originating from the client node and 2893 destined to the server. 2895 When the client starts creating the IKEv2 SA and Child SA for sending 2896 traffic to the server, it has a triggering packet with source IP 2897 address of IP1, and a destination IP address of IPN2. Its PAD and 2898 SPD needs to have configuration matching those addresses (or wildcard 2899 entries covering them). Because this is transport mode, it uses 2900 exactly same addresses as the traffic selectors and outer IP address 2901 of the IKE packets. For transport mode, it MUST use exactly one IP 2902 address in the TSi and TSr payloads. It can have multiple traffic 2903 selectors if it has, for example, multiple port ranges that it wants 2904 to negotiate, but all TSi entries must use IP1-IP1 range as the IP 2905 addresses, and all TSr entries must have the IPN2-IPN2 range as IP 2906 the addresses. The first traffic selector of TSi and TSr SHOULD have 2907 very specific traffic selectors including protocol and port numbers 2908 from the packet triggering the request. 2910 NAT A will then replace the source address of the IKE packet from IP1 2911 to IPN1, and NAT B will replace the destination address of the IKE 2912 packet from IPN2 to IP2, so when the packet arrives to the server it 2913 will still have the exactly same traffic selectors which were sent by 2914 the client, but the IP address of the IKE packet has been replaced to 2915 IPN1 and IP2. 2917 When the server receives this packet, it normally looks the PAD based 2918 on the ID and then searches the SPD based on the traffic selectors. 2919 Because IP1 does not really mean anything to the server (it is the 2920 address client has behind the NAT), it is useless to do lookup based 2921 on that if transport mode is used. On the other hand, the server 2922 cannot know whether transport mode is allowed by its policy before it 2923 finds the matching SPD entry. 2925 In this case, the server should first check that as initiator 2926 requested transport mode and do address substitution on the traffic 2927 selectors. It needs to first store the old traffic selector IP 2928 addresses to be used later for the incremental checksum fixup (the IP 2929 address in the TSi can be stored as the real source address and the 2930 IP address in the TSr can be stored as the real destination address). 2931 After that, if the other end was detected as being behind a NAT, the 2932 server replaces the IP address in TSi payloads with the IP address 2933 obtained from the source address of the IKE packet received (that is, 2934 it replaces IP1 in TSi with IPN1). If the server's end was detected 2935 to be behind NAT, it replaces the IP address in the TSr payloads with 2936 the IP address obtained from the destination address of the IKE 2937 packet received (thta is, it replaces IPN2 in TSr with IP2). 2939 After this address substitution, both the traffic selectors and the 2940 IKE UDP source/destination addresses look the same, and the server 2941 does SPD lookup based on those new traffic selectors. If an entry is 2942 found and it allows transport mode, then that entry is used. If an 2943 entry is found but it does not allow transport mode, then the server 2944 MAY undo the address substitution and redo the SPD lookup using the 2945 original traffic selectors. If the second lookup succeeds, the 2946 server will create an SA in tunnel mode using real traffic selectors 2947 sent by the other end. 2949 This address substitution in transport mode is needed because the SPD 2950 is looked up using the addresses that will be seen by the local host. 2951 This also will make sure the SAD entries for the tunnel exit checks 2952 and return packets is added using the addresses as seen by the local 2953 operating system stack. 2955 The most common case is that the server's SPD will contain wildcard 2956 entries matching any addresses, but this allows also making different 2957 SPD entries, for example, for different known NATs outer addresses. 2959 After the SPD lookup, the server will do traffic selector narrowing 2960 based on the SPD entry it found. It will again use the already- 2961 substituted traffic selectors, and it will thus send back traffic 2962 selectors having IPN1 and IP2 as their IP addresses; it can still 2963 narrow down the protocol number or port ranges used by the traffic 2964 selectors. The SAD entry created for the Child SA will have the 2965 addresses as seen by the server, namely IPN1 and IP2. 2967 When the client receives the server's reply to the Child SA, it will 2968 do similar processing. If the transport mode SA was created, the 2969 client can store the original returned traffic selectors as real 2970 source and destination addresses. It will replace the IP addresses 2971 in the traffic selectors with the ones from the IP header of the IKE 2972 packet: it will replace IPN1 with IP1 and IP2 with IPN2. Then it 2973 will use those traffic selectors when verifying the SA against sent 2974 traffic selectors, and when installing the SAD entry. 2976 A summary of the rules for NAT-traversal in transport mode is: 2978 For the client proposing transport mode: 2980 - The TSi entries MUST have exactly one IP address, and that MUST 2981 match the source address of the IKE SA. 2983 - The TSr entries MUST have exactly one IP address, and that MUST 2984 match the destination address of the IKE SA. 2986 - The first TSi and TSr traffic selectors SHOULD have very specific 2987 traffic selectors including protocol and port numbers from the 2988 packet triggering the request. 2990 - There MAY be multiple TSi and TSr entries. 2992 - If transport mode for the SA was selected (that is, if the server 2993 included USE_TRANSPORT_MODE notification in its reply): 2995 - Store the original traffic selectors as the real source and 2996 destination address. 2998 - If the server is behind a NAT, substitute the IP address in the 2999 TSr entries with the remote address of the IKE SA. 3001 - If the client is behind a NAT, substitute the IP address in the 3002 TSi entries with the local address of the IKE SA. 3004 - Do address substitution before using those traffic selectors 3005 for anything else other than storing original content of them. 3006 This includes verification that traffic selectors were narrowed 3007 correctly by other end, creation of the SAD entry, and so on. 3009 For the responder, when transport mode is proposed by client: 3011 - Store the original traffic selector IP addresses as real source 3012 and destination address in case we need to undo address 3013 substitution. 3015 - If the client is behind a NAT, substitute the IP address in the 3016 TSi entries with the remote address of the IKE SA. 3018 - If the server is behind a NAT substitute the IP address in the 3019 TSr entries with the local address of the IKE SA. 3021 - Do PAD and SPD lookup using the ID and substituted traffic 3022 selectors. 3024 - If no SPD entry was found, or if found SPD entry does not 3025 allow transport mode, undo the traffic selector substitutions. 3026 Do PAD and SPD lookup again using the ID and original traffic 3027 selectors, but also searching for tunnel mode SPD entry (that 3028 is, fall back to tunnel mode). 3030 - However, if a transport mode SPD entry was found, do normal 3031 traffic selection narrowing based on the substituted traffic 3032 selectors and SPD entry. Use the resulting traffic selectors when 3033 creating SAD entries, and when sending traffic selectors back to 3034 the client. 3036 2.24. Explicit Congestion Notification (ECN) 3038 When IPsec tunnels behave as originally specified in [IPSECARCH-OLD], 3039 ECN usage is not appropriate for the outer IP headers because tunnel 3040 decapsulation processing discards ECN congestion indications to the 3041 detriment of the network. ECN support for IPsec tunnels for IKEv1- 3042 based IPsec requires multiple operating modes and negotiation (see 3043 [ECN]). IKEv2 simplifies this situation by requiring that ECN be 3044 usable in the outer IP headers of all tunnel-mode IPsec SAs created 3045 by IKEv2. Specifically, tunnel encapsulators and decapsulators for 3046 all tunnel-mode SAs created by IKEv2 MUST support the ECN full- 3047 functionality option for tunnels specified in [ECN] and MUST 3048 implement the tunnel encapsulation and decapsulation processing 3049 specified in [IPSECARCH] to prevent discarding of ECN congestion 3050 indications. 3052 3. Header and Payload Formats 3054 In the tables in this section, some cryptographic primitives and 3055 configuation attributes are marked as "UNSPECIFIED". These are items 3056 for which there are no known specifications and therefore 3057 interoperability is currently impossible. A future specification may 3058 describe their use, but until such specification is made, 3059 implementations SHOULD NOT attempt to use items marked as 3060 "UNSPECIFIED" in implementations that are meant to be interoperable. 3062 3.1. The IKE Header 3064 IKE messages use UDP ports 500 and/or 4500, with one IKE message per 3065 UDP datagram. Information from the beginning of the packet through 3066 the UDP header is largely ignored except that the IP addresses and 3067 UDP ports from the headers are reversed and used for return packets. 3068 When sent on UDP port 500, IKE messages begin immediately following 3069 the UDP header. When sent on UDP port 4500, IKE messages have 3070 prepended four octets of zero. These four octets of zero are not 3071 part of the IKE message and are not included in any of the length 3072 fields or checksums defined by IKE. Each IKE message begins with the 3073 IKE header, denoted HDR in this memo. Following the header are one 3074 or more IKE payloads each identified by a "Next Payload" field in the 3075 preceding payload. Payloads are processed in the order in which they 3076 appear in an IKE message by invoking the appropriate processing 3077 routine according to the "Next Payload" field in the IKE header and 3078 subsequently according to the "Next Payload" field in the IKE payload 3079 itself until a "Next Payload" field of zero indicates that no 3080 payloads follow. If a payload of type "Encrypted" is found, that 3081 payload is decrypted and its contents parsed as additional payloads. 3082 An Encrypted payload MUST be the last payload in a packet and an 3083 Encrypted payload MUST NOT contain another Encrypted payload. 3085 The Recipient SPI in the header identifies an instance of an IKE 3086 security association. It is therefore possible for a single instance 3087 of IKE to multiplex distinct sessions with multiple peers. 3089 All multi-octet fields representing integers are laid out in big 3090 endian order (also known as "most significant byte first", or 3091 "network byte order"). 3093 The format of the IKE header is shown in Figure 4. 3095 1 2 3 3096 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 3097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3098 | IKE SA Initiator's SPI | 3099 | | 3100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3101 | IKE SA Responder's SPI | 3102 | | 3103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3104 | Next Payload | MjVer | MnVer | Exchange Type | Flags | 3105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3106 | Message ID | 3107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3108 | Length | 3109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3111 Figure 4: IKE Header Format 3113 o Initiator's SPI (8 octets) - A value chosen by the initiator to 3114 identify a unique IKE security association. This value MUST NOT 3115 be zero. 3117 o Responder's SPI (8 octets) - A value chosen by the responder to 3118 identify a unique IKE security association. This value MUST be 3119 zero in the first message of an IKE Initial Exchange (including 3120 repeats of that message including a cookie). 3122 o Next Payload (1 octet) - Indicates the type of payload that 3123 immediately follows the header. The format and value of each 3124 payload are defined below. 3126 o Major Version (4 bits) - Indicates the major version of the IKE 3127 protocol in use. Implementations based on this version of IKE 3128 MUST set the Major Version to 2. Implementations based on 3129 previous versions of IKE and ISAKMP MUST set the Major Version to 3130 1. Implementations based on this version of IKE MUST reject or 3131 ignore messages containing a version number greater than 2 with an 3132 INVALID_MAJOR_VERSION notification message as described in Section 3133 2.5. 3135 o Minor Version (4 bits) - Indicates the minor version of the IKE 3136 protocol in use. Implementations based on this version of IKE 3137 MUST set the Minor Version to 0. They MUST ignore the minor 3138 version number of received messages. 3140 o Exchange Type (1 octet) - Indicates the type of exchange being 3141 used. This constrains the payloads sent in each message in an 3142 exchange. 3144 Exchange Type Value 3145 ---------------------------------- 3146 RESERVED 0-33 3147 IKE_SA_INIT 34 3148 IKE_AUTH 35 3149 CREATE_CHILD_SA 36 3150 INFORMATIONAL 37 3151 RESERVED TO IANA 38-239 3152 PRIVATE USE 240-255 3154 o Flags (1 octet) - Indicates specific options that are set for the 3155 message. Presence of options is indicated by the appropriate bit 3156 in the flags field being set. The bits are defined LSB first, so 3157 bit 0 would be the least significant bit of the Flags octet. In 3158 the description below, a bit being 'set' means its value is '1', 3159 while 'cleared' means its value is '0'. 3161 * X(reserved) (bits 0-2) - These bits MUST be cleared when 3162 sending and MUST be ignored on receipt. 3164 * I(nitiator) (bit 3 of Flags) - This bit MUST be set in messages 3165 sent by the original initiator of the IKE SA and MUST be 3166 cleared in messages sent by the original responder. It is used 3167 by the recipient to determine which eight octets of the SPI 3168 were generated by the recipient. This bit changes to reflect 3169 who initiated the last rekey of the IKE SA. 3171 * V(ersion) (bit 4 of Flags) - This bit indicates that the 3172 transmitter is capable of speaking a higher major version 3173 number of the protocol than the one indicated in the major 3174 version number field. Implementations of IKEv2 MUST clear this 3175 bit when sending and MUST ignore it in incoming messages. 3177 * R(esponse) (bit 5 of Flags) - This bit indicates that this 3178 message is a response to a message containing the same message 3179 ID. This bit MUST be cleared in all request messages and MUST 3180 be set in all responses. An IKE endpoint MUST NOT generate a 3181 response to a message that is marked as being a response. 3183 * X(reserved) (bits 6-7 of Flags) - These bits MUST be cleared 3184 when sending and MUST be ignored on receipt. 3186 o Message ID (4 octets) - Message identifier used to control 3187 retransmission of lost packets and matching of requests and 3188 responses. It is essential to the security of the protocol 3189 because it is used to prevent message replay attacks. See 3190 Section 2.1 and Section 2.2. 3192 o Length (4 octets) - Length of total message (header + payloads) in 3193 octets. 3195 3.2. Generic Payload Header 3197 Each IKE payload defined in Section 3.3 through Section 3.16 begins 3198 with a generic payload header, shown in Figure 5. Figures for each 3199 payload below will include the generic payload header, but for 3200 brevity the description of each field will be omitted. 3202 1 2 3 3203 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 3204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3205 | Next Payload |C| RESERVED | Payload Length | 3206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3208 Figure 5: Generic Payload Header 3210 The Generic Payload Header fields are defined as follows: 3212 o Next Payload (1 octet) - Identifier for the payload type of the 3213 next payload in the message. If the current payload is the last 3214 in the message, then this field will be 0. This field provides a 3215 "chaining" capability whereby additional payloads can be added to 3216 a message by appending it to the end of the message and setting 3217 the "Next Payload" field of the preceding payload to indicate the 3218 new payload's type. An Encrypted payload, which must always be 3219 the last payload of a message, is an exception. It contains data 3220 structures in the format of additional payloads. In the header of 3221 an Encrypted payload, the Next Payload field is set to the payload 3222 type of the first contained payload (instead of 0). The payload 3223 type values are: 3225 Next Payload Type Notation Value 3226 -------------------------------------------------- 3227 No Next Payload 0 3228 RESERVED 1-32 3229 Security Association SA 33 3230 Key Exchange KE 34 3231 Identification - Initiator IDi 35 3232 Identification - Responder IDr 36 3233 Certificate CERT 37 3234 Certificate Request CERTREQ 38 3235 Authentication AUTH 39 3236 Nonce Ni, Nr 40 3237 Notify N 41 3238 Delete D 42 3239 Vendor ID V 43 3240 Traffic Selector - Initiator TSi 44 3241 Traffic Selector - Responder TSr 45 3242 Encrypted E 46 3243 Configuration CP 47 3244 Extensible Authentication EAP 48 3245 RESERVED TO IANA 49-127 3246 PRIVATE USE 128-255 3248 (Payload type values 1-32 should not be assigned in the 3249 future so that there is no overlap with the code assignments 3250 for IKEv1.) 3252 o Critical (1 bit) - MUST be set to zero if the sender wants the 3253 recipient to skip this payload if it does not understand the 3254 payload type code in the Next Payload field of the previous 3255 payload. MUST be set to one if the sender wants the recipient to 3256 reject this entire message if it does not understand the payload 3257 type. MUST be ignored by the recipient if the recipient 3258 understands the payload type code. MUST be set to zero for 3259 payload types defined in this document. Note that the critical 3260 bit applies to the current payload rather than the "next" payload 3261 whose type code appears in the first octet. The reasoning behind 3262 not setting the critical bit for payloads defined in this document 3263 is that all implementations MUST understand all payload types 3264 defined in this document and therefore must ignore the Critical 3265 bit's value. Skipped payloads are expected to have valid Next 3266 Payload and Payload Length fields. 3268 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on 3269 receipt. 3271 o Payload Length (2 octets) - Length in octets of the current 3272 payload, including the generic payload header. 3274 Many payloads contain fields marked as "RESERVED". Some payloads in 3275 IKEv2 (and historically in IKEv1) are not aligned to 4-octet 3276 boundaries. 3278 3.3. Security Association Payload 3280 The Security Association Payload, denoted SA in this memo, is used to 3281 negotiate attributes of a security association. Assembly of Security 3282 Association Payloads requires great peace of mind. An SA payload MAY 3283 contain multiple proposals. If there is more than one, they MUST be 3284 ordered from most preferred to least preferred. Each proposal 3285 contains a single IPsec protocol (where a protocol is IKE, ESP, or 3286 AH), each protocol MAY contain multiple transforms, and each 3287 transform MAY contain multiple attributes. When parsing an SA, an 3288 implementation MUST check that the total Payload Length is consistent 3289 with the payload's internal lengths and counts. Proposals, 3290 Transforms, and Attributes each have their own variable length 3291 encodings. They are nested such that the Payload Length of an SA 3292 includes the combined contents of the SA, Proposal, Transform, and 3293 Attribute information. The length of a Proposal includes the lengths 3294 of all Transforms and Attributes it contains. The length of a 3295 Transform includes the lengths of all Attributes it contains. 3297 The syntax of Security Associations, Proposals, Transforms, and 3298 Attributes is based on ISAKMP; however the semantics are somewhat 3299 different. The reason for the complexity and the hierarchy is to 3300 allow for multiple possible combinations of algorithms to be encoded 3301 in a single SA. Sometimes there is a choice of multiple algorithms, 3302 whereas other times there is a combination of algorithms. For 3303 example, an initiator might want to propose using ESP with either 3304 (3DES and HMAC_MD5) or (AES and HMAC_SHA1). 3306 One of the reasons the semantics of the SA payload has changed from 3307 ISAKMP and IKEv1 is to make the encodings more compact in common 3308 cases. 3310 The Proposal structure contains within it a Proposal # and an IPsec 3311 protocol ID. Each structure MUST have a proposal number one (1) 3312 greater than the previous structure. The first Proposal in the 3313 initiator's SA payload MUST have a Proposal # of one (1). One reason 3314 to use multiple proposals is to propose both standard crypto ciphers 3315 and combined-mode ciphers. Combined-mode ciphers include both 3316 integrity and encryption in a single encryption algorithm, and are 3317 not allowed to be offered with a separate integrity algorithm other 3318 than "none". If an initiator wants to propose both combined-mode 3319 ciphers and normal ciphers, it must include two proposals: one will 3320 have all the combined-mode ciphers, and the other will have all the 3321 normal ciphers with the integrity algorithms. For example, one such 3322 proposal would have two proposal structures: ESP with ENCR_AES-CCM_8, 3323 ENCR_AES-CCM_12, and ENCR_AES-CCM_16 as Proposal #1, and ESP with 3324 ENCR_AES_CBC, ENCR_3DES, AUTH_AES_XCBC_96, and AUTH_HMAC_SHA1_96 as 3325 Proposal #2. 3327 Each Proposal/Protocol structure is followed by one or more transform 3328 structures. The number of different transforms is generally 3329 determined by the Protocol. AH generally has two transforms: 3330 Extended Sequence Numbers (ESN) and an integrity check algorithm. 3331 ESP generally has three: ESN, an encryption algorithm and an 3332 integrity check algorithm. IKE generally has four transforms: a 3333 Diffie-Hellman group, an integrity check algorithm, a prf algorithm, 3334 and an encryption algorithm. If an algorithm that combines 3335 encryption and integrity protection is proposed, it MUST be proposed 3336 as an encryption algorithm and an integrity protection algorithm MUST 3337 NOT be proposed. For each Protocol, the set of permissible 3338 transforms is assigned transform ID numbers, which appear in the 3339 header of each transform. 3341 If there are multiple transforms with the same Transform Type, the 3342 proposal is an OR of those transforms. If there are multiple 3343 Transforms with different Transform Types, the proposal is an AND of 3344 the different groups. For example, to propose ESP with (3DES or AES- 3345 CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two 3346 Transform Type 1 candidates (one for 3DES and one for AEC-CBC) and 3347 two Transform Type 3 candidates (one for HMAC_MD5 and one for 3348 HMAC_SHA). This effectively proposes four combinations of 3349 algorithms. If the initiator wanted to propose only a subset of 3350 those, for example (3DES and HMAC_MD5) or (IDEA and HMAC_SHA), there 3351 is no way to encode that as multiple transforms within a single 3352 Proposal. Instead, the initiator would have to construct two 3353 different Proposals, each with two transforms. 3355 A given transform MAY have one or more Attributes. Attributes are 3356 necessary when the transform can be used in more than one way, as 3357 when an encryption algorithm has a variable key size. The transform 3358 would specify the algorithm and the attribute would specify the key 3359 size. Most transforms do not have attributes. A transform MUST NOT 3360 have multiple attributes of the same type. To propose alternate 3361 values for an attribute (for example, multiple key sizes for the AES 3362 encryption algorithm), and implementation MUST include multiple 3363 Transforms with the same Transform Type each with a single Attribute. 3365 Note that the semantics of Transforms and Attributes are quite 3366 different from those in IKEv1. In IKEv1, a single Transform carried 3367 multiple algorithms for a protocol with one carried in the Transform 3368 and the others carried in the Attributes. 3370 1 2 3 3371 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 3372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3373 | Next Payload |C| RESERVED | Payload Length | 3374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3375 | | 3376 ~ ~ 3377 | | 3378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3380 Figure 6: Security Association Payload 3382 o Proposals (variable) - One or more proposal substructures. 3384 The payload type for the Security Association Payload is thirty three 3385 (33). 3387 3.3.1. Proposal Substructure 3389 1 2 3 3390 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 3391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3392 | 0 (last) or 2 | RESERVED | Proposal Length | 3393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3394 | Proposal # | Protocol ID | SPI Size |# of Transforms| 3395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3396 ~ SPI (variable) ~ 3397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3398 | | 3399 ~ ~ 3400 | | 3401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3403 Figure 7: Proposal Substructure 3405 o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the 3406 last Proposal Substructure in the SA. This syntax is inherited 3407 from ISAKMP, but is unnecessary because the last Proposal could be 3408 identified from the length of the SA. The value (2) corresponds 3409 to a Payload Type of Proposal in IKEv1, and the first four octets 3410 of the Proposal structure are designed to look somewhat like the 3411 header of a Payload. 3413 o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on 3414 receipt. 3416 o Proposal Length (2 octets) - Length of this proposal, including 3417 all transforms and attributes that follow. 3419 o Proposal # (1 octet) - When a proposal is made, the first proposal 3420 in an SA payload MUST be #1, and subsequent proposals MUST be one 3421 more than the previous proposal (indicating an OR of the two 3422 proposals). When a proposal is accepted, the proposal number in 3423 the SA payload MUST match the number on the proposal sent that was 3424 accepted. 3426 o Protocol ID (1 octet) - Specifies the IPsec protocol identifier 3427 for the current negotiation. The defined values are: 3429 Protocol Protocol ID 3430 ----------------------------------- 3431 RESERVED 0 3432 IKE 1 3433 AH 2 3434 ESP 3 3435 RESERVED TO IANA 4-200 3436 PRIVATE USE 201-255 3438 o SPI Size (1 octet) - For an initial IKE SA negotiation, this field 3439 MUST be zero; the SPI is obtained from the outer header. During 3440 subsequent negotiations, it is equal to the size, in octets, of 3441 the SPI of the corresponding protocol (8 for IKE, 4 for ESP and 3442 AH). 3444 o # of Transforms (1 octet) - Specifies the number of transforms in 3445 this proposal. 3447 o SPI (variable) - The sending entity's SPI. Even if the SPI Size 3448 is not a multiple of 4 octets, there is no padding applied to the 3449 payload. When the SPI Size field is zero, this field is not 3450 present in the Security Association payload. 3452 o Transforms (variable) - One or more transform substructures. 3454 3.3.2. Transform Substructure 3456 1 2 3 3457 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 3458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3459 | 0 (last) or 3 | RESERVED | Transform Length | 3460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3461 |Transform Type | RESERVED | Transform ID | 3462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3463 | | 3464 ~ Transform Attributes ~ 3465 | | 3466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3468 Figure 8: Transform Substructure 3470 o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the 3471 last Transform Substructure in the Proposal. This syntax is 3472 inherited from ISAKMP, but is unnecessary because the last 3473 transform could be identified from the length of the proposal. 3474 The value (3) corresponds to a Payload Type of Transform in IKEv1, 3475 and the first four octets of the Transform structure are designed 3476 to look somewhat like the header of a Payload. 3478 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 3480 o Transform Length - The length (in octets) of the Transform 3481 Substructure including Header and Attributes. 3483 o Transform Type (1 octet) - The type of transform being specified 3484 in this transform. Different protocols support different 3485 transform types. For some protocols, some of the transforms may 3486 be optional. If a transform is optional and the initiator wishes 3487 to propose that the transform be omitted, no transform of the 3488 given type is included in the proposal. If the initiator wishes 3489 to make use of the transform optional to the responder, it 3490 includes a transform substructure with transform ID = 0 as one of 3491 the options. 3493 o Transform ID (2 octets) - The specific instance of the transform 3494 type being proposed. 3496 The transform type values are: 3498 Description Trans. Used In 3499 Type 3500 ------------------------------------------------------------------ 3501 RESERVED 0 3502 Encryption Algorithm (ENCR) 1 IKE and ESP 3503 Pseudo-random Function (PRF) 2 IKE 3504 Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP 3505 Diffie-Hellman Group (D-H) 4 IKE, optional in AH & ESP 3506 Extended Sequence Numbers (ESN) 5 AH and ESP 3507 RESERVED TO IANA 6-240 3508 PRIVATE USE 241-255 3510 (*) Negotiating an integrity algorithm is mandatory for the 3511 Encrypted payload format specified in this document. For example, 3512 [AEAD] specifies additional formats based on authenticated 3513 encryption, in which a separate integrity algorithm is not 3514 negotiated. 3516 For Transform Type 1 (Encryption Algorithm), defined Transform IDs 3517 are: 3519 Name Number Defined In 3520 --------------------------------------------------- 3521 RESERVED 0 3522 ENCR_DES_IV64 1 (UNSPECIFIED) 3523 ENCR_DES 2 (RFC2405), [DES] 3524 ENCR_3DES 3 (RFC2451) 3525 ENCR_RC5 4 (RFC2451) 3526 ENCR_IDEA 5 (RFC2451), [IDEA] 3527 ENCR_CAST 6 (RFC2451) 3528 ENCR_BLOWFISH 7 (RFC2451) 3529 ENCR_3IDEA 8 (UNSPECIFIED) 3530 ENCR_DES_IV32 9 (UNSPECIFIED) 3531 RESERVED 10 3532 ENCR_NULL 11 (RFC2410) 3533 ENCR_AES_CBC 12 (RFC3602) 3534 ENCR_AES_CTR 13 (RFC3686) 3535 RESERVED TO IANA 14-1023 3536 PRIVATE USE 1024-65535 3538 For Transform Type 2 (Pseudo-random Function), defined Transform IDs 3539 are: 3541 Name Number Defined In 3542 ------------------------------------------------------ 3543 RESERVED 0 3544 PRF_HMAC_MD5 1 (RFC2104), [MD5] 3545 PRF_HMAC_SHA1 2 (RFC2104), [SHA] 3546 PRF_HMAC_TIGER 3 (RFC2104) 3547 PRF_AES128_XCBC 4 (RFC4434) 3548 RESERVED TO IANA 5-1023 3549 PRIVATE USE 1024-65535 3551 For Transform Type 3 (Integrity Algorithm), defined Transform IDs 3552 are: 3554 Name Number Defined In 3555 ---------------------------------------- 3556 NONE 0 3557 AUTH_HMAC_MD5_96 1 (RFC2403) 3558 AUTH_HMAC_SHA1_96 2 (RFC2404) 3559 AUTH_DES_MAC 3 (UNSPECIFIED) 3560 AUTH_KPDK_MD5 4 (UNSPECIFIED) 3561 AUTH_AES_XCBC_96 5 (RFC3566) 3562 RESERVED TO IANA 6-1023 3563 PRIVATE USE 1024-65535 3565 For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs 3566 are: 3568 Name Number Defined in 3569 ---------------------------------------- 3570 NONE 0 3571 768 Bit MODP 1 Appendix B 3572 1024 Bit MODP 2 Appendix B 3573 RESERVED TO IANA 3-4 3574 1536-bit MODP 5 [ADDGROUP] 3575 RESERVED TO IANA 6-13 3576 2048-bit MODP 14 [ADDGROUP] 3577 3072-bit MODP 15 [ADDGROUP] 3578 4096-bit MODP 16 [ADDGROUP] 3579 6144-bit MODP 17 [ADDGROUP] 3580 8192-bit MODP 18 [ADDGROUP] 3581 RESERVED TO IANA 19-1023 3582 PRIVATE USE 1024-65535 3584 Although ESP and AH do not directly include a Diffie-Hellman 3585 exchange, a Diffie-Hellman group MAY be negotiated for the Child SA. 3586 This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA 3587 exchange, providing perfect forward secrecy for the generated Child 3588 SA keys. 3590 For Transform Type 5 (Extended Sequence Numbers), defined Transform 3591 IDs are: 3593 Name Number 3594 -------------------------------------------- 3595 No Extended Sequence Numbers 0 3596 Extended Sequence Numbers 1 3597 RESERVED 2 - 65535 3599 Note that an initiator who supports ESNs will usually include two ESN 3600 transforms, with values "0" and "1", in its proposals. A proposal 3601 containing a single ESN transform with value "1" means that using 3602 normal (non-extended) sequence numbers is not acceptable. 3604 Numerous additional transform types have been defined since the 3605 publication of RFC 4306. Please refer to the IANA IKEv2 registry for 3606 details. 3608 3.3.3. Valid Transform Types by Protocol 3610 The number and type of transforms that accompany an SA payload are 3611 dependent on the protocol in the SA itself. An SA payload proposing 3612 the establishment of an SA has the following mandatory and optional 3613 transform types. A compliant implementation MUST understand all 3614 mandatory and optional types for each protocol it supports (though it 3615 need not accept proposals with unacceptable suites). A proposal MAY 3616 omit the optional types if the only value for them it will accept is 3617 NONE. 3619 Protocol Mandatory Types Optional Types 3620 --------------------------------------------------- 3621 IKE ENCR, PRF, INTEG*, D-H 3622 ESP ENCR, ESN INTEG, D-H 3623 AH INTEG, ESN D-H 3625 (*) Negotiating an integrity algorithm is mandatory for the 3626 Encrypted payload format specified in this document. For example, 3627 [AEAD] specifies additional formats based on authenticated 3628 encryption, in which a separate integrity algorithm is not 3629 negotiated. 3631 3.3.4. Mandatory Transform IDs 3633 The specification of suites that MUST and SHOULD be supported for 3634 interoperability has been removed from this document because they are 3635 likely to change more rapidly than this document evolves. 3637 An important lesson learned from IKEv1 is that no system should only 3638 implement the mandatory algorithms and expect them to be the best 3639 choice for all customers. 3641 It is likely that IANA will add additional transforms in the future, 3642 and some users may want to use private suites, especially for IKE 3643 where implementations should be capable of supporting different 3644 parameters, up to certain size limits. In support of this goal, all 3645 implementations of IKEv2 SHOULD include a management facility that 3646 allows specification (by a user or system administrator) of Diffie- 3647 Hellman (DH) parameters (the generator, modulus, and exponent lengths 3648 and values) for new DH groups. Implementations SHOULD provide a 3649 management interface through which these parameters and the 3650 associated transform IDs may be entered (by a user or system 3651 administrator), to enable negotiating such groups. 3653 All implementations of IKEv2 MUST include a management facility that 3654 enables a user or system administrator to specify the suites that are 3655 acceptable for use with IKE. Upon receipt of a payload with a set of 3656 transform IDs, the implementation MUST compare the transmitted 3657 transform IDs against those locally configured via the management 3658 controls, to verify that the proposed suite is acceptable based on 3659 local policy. The implementation MUST reject SA proposals that are 3660 not authorized by these IKE suite controls. Note that cryptographic 3661 suites that MUST be implemented need not be configured as acceptable 3662 to local policy. 3664 3.3.5. Transform Attributes 3666 Each transform in a Security Association payload may include 3667 attributes that modify or complete the specification of the 3668 transform. The set of valid attributes depends on the transform. 3669 Currently, only a single attribute type is defined: the Key Length 3670 attribute is used by certain encryption transforms with variable- 3671 length keys (see below for details). 3673 The attributes are type/value pairs and are defined below. 3674 Attributes can have a value with a fixed two-octet length or a 3675 variable-length value. For the latter, the attribute is encoded as 3676 type/length/value. 3678 1 2 3 3679 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 3680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3681 |A| Attribute Type | AF=0 Attribute Length | 3682 |F| | AF=1 Attribute Value | 3683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3684 | AF=0 Attribute Value | 3685 | AF=1 Not Transmitted | 3686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3688 Figure 9: Data Attributes 3690 o Attribute Format (AF) (1 bit) - Indicates whether the data 3691 attribute follow the Type/Length/Value (TLV) format or a shortened 3692 Type/Value (TV) format. If the AF bit is zero (0), then the 3693 attribute uses TLV format; if the AF bit is one (1), the TV format 3694 (with two-byte value) is used. 3696 o Attribute Type (15 bits) - Unique identifier for each type of 3697 attribute (see below). 3699 o Attribute Value (variable length) - Value of the Attribute 3700 associated with the Attribute Type. If the AF bit is a zero (0), 3701 this field has a variable length defined by the Attribute Length 3702 field. If the AF bit is a one (1), the Attribute Value has a 3703 length of 2 octets. 3705 Note that the only currently defined attribute type (Key Length) is 3706 fixed length; the variable-length encoding specification is included 3707 only for future extensions. Attributes described as fixed length 3708 MUST NOT be encoded using the variable-length encoding. Variable- 3709 length attributes MUST NOT be encoded as fixed-length even if their 3710 value can fit into two octets. NOTE: This is a change from IKEv1, 3711 where increased flexibility may have simplified the composer of 3712 messages but certainly complicated the parser. 3714 Attribute Type Value Attribute Format 3715 ------------------------------------------------------------ 3716 RESERVED 0-13 3717 Key Length (in bits) 14 TV 3718 RESERVED 15-17 3719 RESERVED TO IANA 18-16383 3720 PRIVATE USE 16384-32767 3722 Values 0-13 and 15-17 were used in a similar context in IKEv1, and 3723 should not be assigned except to matching values. 3725 The Key Length attribute specifies the key length in bits (MUST use 3726 network byte order) for certain transforms as follows: 3728 o The Key Length attribute MUST NOT be used with transforms that use 3729 a fixed length key. This includes, e.g., ENCR_DES, ENCR_IDEA, and 3730 all the Type 2 (Pseudo-random function) and Type 3 (Integrity 3731 Algorithm) transforms specified in this document. It is 3732 recommended that future Type 2 or 3 transforms do not use this 3733 attribute. 3735 o Some transforms specify that the Key Length attribute MUST be 3736 always included (omitting the attribute is not allowed, and 3737 proposals not containing it MUST be rejected). This includes, 3738 e.g., ENCR_AES_CBC and ENCR_AES_CTR. 3740 o Some transforms allow variable-length keys, but also specify a 3741 default key length if the attribute is not included. These 3742 transforms include, e.g., ENCR_RC5 and ENCR_BLOWFISH. 3744 Implementation note: To further interoperability and to support 3745 upgrading endpoints independently, implementers of this protocol 3746 SHOULD accept values that they deem to supply greater security. For 3747 instance, if a peer is configured to accept a variable-length cipher 3748 with a key length of X bits and is offered that cipher with a larger 3749 key length, the implementation SHOULD accept the offer if it supports 3750 use of the longer key. 3752 Support of this capability allows a responder to express a concept of 3753 "at least" a certain level of security -- "a key length of _at least_ 3754 X bits for cipher Y". However, as the attribute is always returned 3755 unchanged (see the next section), an initiator willing to accept 3756 multiple key lengths has to include multiple transforms with the same 3757 Transform Type, each with different Key Length attribute. 3759 3.3.6. Attribute Negotiation 3761 During security association negotiation initiators present offers to 3762 responders. Responders MUST select a single complete set of 3763 parameters from the offers (or reject all offers if none are 3764 acceptable). If there are multiple proposals, the responder MUST 3765 choose a single proposal. If the selected proposal has multiple 3766 Transforms with the same type, the responder MUST choose a single 3767 one. Any attributes of a selected transform MUST be returned 3768 unmodified. The initiator of an exchange MUST check that the 3769 accepted offer is consistent with one of its proposals, and if not 3770 that response MUST be rejected. 3772 If the responder receives a proposal that contains a Transform Type 3773 it does not understand, or a proposal that is missing a mandatory 3774 Transform Type, it MUST consider this proposal unacceptable; however, 3775 other proposals in the same SA payload are processed as usual. 3776 Similarly, if the responder receives a transform that contains a 3777 Transform Attribute it does not understand, it MUST consider this 3778 transform unacceptable; other transforms with the same Transform Type 3779 are processed as usual. This allows new Transform Types and 3780 Transform Attributes to be defined in the future. An exception is 3781 the case where one of the proposals offered is for the Diffie-Hellman 3782 group of NONE. In this case, the responder MUST ignore the 3783 initiator's KE payload and omit the KE payload from the response. 3785 Negotiating Diffie-Hellman groups presents some special challenges. 3786 SA offers include proposed attributes and a Diffie-Hellman public 3787 number (KE) in the same message. If in the initial exchange the 3788 initiator offers to use one of several Diffie-Hellman groups, it 3789 SHOULD pick the one the responder is most likely to accept and 3790 include a KE corresponding to that group. If the responder selects a 3791 proposal using a different Diffie-Hellman group (other than NONE), 3792 the responder will indicate the correct group in the response and the 3793 initiator SHOULD pick an element of that group for its KE value when 3794 retrying the first message. It SHOULD, however, continue to propose 3795 its full supported set of groups in order to prevent a man-in-the- 3796 middle downgrade attack. 3798 3.4. Key Exchange Payload 3800 The Key Exchange Payload, denoted KE in this memo, is used to 3801 exchange Diffie-Hellman public numbers as part of a Diffie-Hellman 3802 key exchange. The Key Exchange Payload consists of the IKE generic 3803 payload header followed by the Diffie-Hellman public value itself. 3805 1 2 3 3806 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 3807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3808 | Next Payload |C| RESERVED | Payload Length | 3809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3810 | DH Group # | RESERVED | 3811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3812 | | 3813 ~ Key Exchange Data ~ 3814 | | 3815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3817 Figure 10: Key Exchange Payload Format 3819 A key exchange payload is constructed by copying one's Diffie-Hellman 3820 public value into the "Key Exchange Data" portion of the payload. 3821 The length of the Diffie-Hellman public value MUST be equal to the 3822 length of the prime modulus over which the exponentiation was 3823 performed, prepending zero bits to the value if necessary. 3825 The DH Group # identifies the Diffie-Hellman group in which the Key 3826 Exchange Data was computed (see Section 3.3.2). This Group # MUST 3827 match a DH Group specified in a proposal in the SA payload that is 3828 sent in the same message, and SHOULD match the DH group in the first 3829 group in the first proposal, if such exists. If none of the 3830 proposals in that SA payload specifies a DH Group, the KE payload 3831 MUST NOT be present. If the selected proposal uses a different 3832 Diffie-Hellman group (other than NONE), the message MUST be rejected 3833 with a Notify payload of type INVALID_KE_PAYLOAD. 3835 The payload type for the Key Exchange payload is thirty four (34). 3837 3.5. Identification Payloads 3839 The Identification Payloads, denoted IDi and IDr in this memo, allow 3840 peers to assert an identity to one another. This identity may be 3841 used for policy lookup, but does not necessarily have to match 3842 anything in the CERT payload; both fields may be used by an 3843 implementation to perform access control decisions. When using the 3844 ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 3845 does not require this address to match the address in the IP header 3846 of IKEv2 packets, or anything in the TSi/TSr payloads. The contents 3847 of IDi/IDr is used purely to fetch the policy and authentication data 3848 related to the other party. 3850 NOTE: In IKEv1, two ID payloads were used in each direction to hold 3851 Traffic Selector (TS) information for data passing over the SA. In 3852 IKEv2, this information is carried in TS payloads (see Section 3.13). 3854 The Peer Authorization Database (PAD) as described in RFC 4301 3855 [IPSECARCH] describes the use of the ID payload in IKEv2 and provides 3856 a formal model for the binding of identity to policy in addition to 3857 providing services that deal more specifically with the details of 3858 policy enforcement. The PAD is intended to provide a link between 3859 the SPD and the IKE security association management. See Section 3860 4.4.3 of RFC 4301 for more details. 3862 The Identification Payload consists of the IKE generic payload header 3863 followed by identification fields as follows: 3865 1 2 3 3866 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 3867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3868 | Next Payload |C| RESERVED | Payload Length | 3869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3870 | ID Type | RESERVED | 3871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3872 | | 3873 ~ Identification Data ~ 3874 | | 3875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3877 Figure 11: Identification Payload Format 3879 o ID Type (1 octet) - Specifies the type of Identification being 3880 used. 3882 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 3884 o Identification Data (variable length) - Value, as indicated by the 3885 Identification Type. The length of the Identification Data is 3886 computed from the size in the ID payload header. 3888 The payload types for the Identification Payload are thirty five (35) 3889 for IDi and thirty six (36) for IDr. 3891 The following table lists the assigned values for the Identification 3892 Type field: 3894 ID Type Value 3895 ------------------------------------------------------------------- 3896 RESERVED 0 3898 ID_IPV4_ADDR 1 3899 A single four (4) octet IPv4 address. 3901 ID_FQDN 2 3902 A fully-qualified domain name string. An example of a ID_FQDN 3903 is, "example.com". The string MUST not contain any terminators 3904 (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; 3905 for an "internationalized domain name", the syntax is as defined 3906 in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net". 3908 ID_RFC822_ADDR 3 3909 A fully-qualified RFC822 email address string, An example of a 3910 ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not 3911 contain any terminators. Because of [EAI], implementations would 3912 be wise to treat this field as UTF-8 encoded text, not as 3913 pure ASCII. 3915 RESERVED TO IANA 4 3917 ID_IPV6_ADDR 5 3918 A single sixteen (16) octet IPv6 address. 3920 RESERVED TO IANA 6 - 8 3922 ID_DER_ASN1_DN 9 3923 The binary Distinguished Encoding Rules (DER) encoding of an 3924 ASN.1 X.500 Distinguished Name [X.501]. 3926 ID_DER_ASN1_GN 10 3927 The binary DER encoding of an ASN.1 X.500 GeneralName [X.509]. 3929 ID_KEY_ID 11 3930 An opaque octet stream which may be used to pass vendor- 3931 specific information necessary to do certain proprietary 3932 types of identification. 3934 RESERVED TO IANA 12-200 3936 PRIVATE USE 201-255 3938 Two implementations will interoperate only if each can generate a 3939 type of ID acceptable to the other. To assure maximum 3940 interoperability, implementations MUST be configurable to send at 3941 least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and 3942 MUST be configurable to accept all of these types. Implementations 3943 SHOULD be capable of generating and accepting all of these types. 3944 IPv6-capable implementations MUST additionally be configurable to 3945 accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable 3946 to send only ID_IPV6_ADDR. 3948 EAP [EAP] does not mandate the use of any particular type of 3949 identifier, but often EAP is used with Network Access Identifiers 3950 (NAIs) defined in [NAI]. Although NAIs look a bit like email 3951 addresses (e.g., "joe@example.com"), the syntax is not exactly the 3952 same as the syntax of email address in [MAILFORMAT]. For those NAIs 3953 that include the realm component, the ID_RFC822_ADDR identification 3954 type SHOULD be used. Responder implementations should not attempt to 3955 verify that the contents actually conform to the exact syntax given 3956 in [MAILFORMAT], but instead should accept any reasonable-looking 3957 NAI. For NAIs that do not include the realm component,the ID_KEY_ID 3958 identification type SHOULD be used. 3960 3.6. Certificate Payload 3962 The Certificate Payload, denoted CERT in this memo, provides a means 3963 to transport certificates or other authentication-related information 3964 via IKE. Certificate payloads SHOULD be included in an exchange if 3965 certificates are available to the sender unless the peer has 3966 indicated an ability to retrieve this information from elsewhere 3967 using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the 3968 term "Certificate Payload" is somewhat misleading, because not all 3969 authentication mechanisms use certificates and data other than 3970 certificates may be passed in this payload. 3972 The Certificate Payload is defined as follows: 3974 1 2 3 3975 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 3976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3977 | Next Payload |C| RESERVED | Payload Length | 3978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3979 | Cert Encoding | | 3980 +-+-+-+-+-+-+-+-+ | 3981 ~ Certificate Data ~ 3982 | | 3983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3985 Figure 12: Certificate Payload Format 3987 o Certificate Encoding (1 octet) - This field indicates the type of 3988 certificate or certificate-related information contained in the 3989 Certificate Data field. 3991 Certificate Encoding Value 3992 ---------------------------------------------------- 3993 RESERVED 0 3994 PKCS #7 wrapped X.509 certificate 1 UNSPECIFIED 3995 PGP Certificate 2 UNSPECIFIED 3996 DNS Signed Key 3 UNSPECIFIED 3997 X.509 Certificate - Signature 4 3998 Kerberos Token 6 UNSPECIFIED 3999 Certificate Revocation List (CRL) 7 4000 Authority Revocation List (ARL) 8 UNSPECIFIED 4001 SPKI Certificate 9 UNSPECIFIED 4002 X.509 Certificate - Attribute 10 UNSPECIFIED 4003 Raw RSA Key 11 4004 Hash and URL of X.509 certificate 12 4005 Hash and URL of X.509 bundle 13 4006 RESERVED to IANA 14 - 200 4007 PRIVATE USE 201 - 255 4009 o Certificate Data (variable length) - Actual encoding of 4010 certificate data. The type of certificate is indicated by the 4011 Certificate Encoding field. 4013 The payload type for the Certificate Payload is thirty seven (37). 4015 Specific syntax for some of the certificate type codes above is not 4016 defined in this document. The types whose syntax is defined in this 4017 document are: 4019 o X.509 Certificate - Signature (4) contains a DER encoded X.509 4020 certificate whose public key is used to validate the sender's AUTH 4021 payload. Note that with this encoding, if a chain of certificates 4022 needs to be sent, multiple CERT payloads are used, only the first 4023 of which holds the public key used to validate the sender's AUTH 4024 payload. 4026 o Certificate Revocation List (7) contains a DER encoded X.509 4027 certificate revocation list. 4029 o Raw RSA Key (11) contains a PKCS #1 encoded RSA key, that is, a 4030 DER-encoded RSAPublicKey structure (see [RSA] and [PKCS1]). 4032 o Hash and URL encodings (12-13) allow IKE messages to remain short 4033 by replacing long data structures with a 20 octet SHA-1 hash (see 4034 [SHA]) of the replaced value followed by a variable-length URL 4035 that resolves to the DER encoded data structure itself. This 4036 improves efficiency when the endpoints have certificate data 4037 cached and makes IKE less subject to denial of service attacks 4038 that become easier to mount when IKE messages are large enough to 4039 require IP fragmentation [DOSUDPPROT]. 4041 Use the following ASN.1 definition for an X.509 bundle: 4043 CertBundle 4044 { iso(1) identified-organization(3) dod(6) internet(1) 4045 security(5) mechanisms(5) pkix(7) id-mod(0) 4046 id-mod-cert-bundle(34) } 4048 DEFINITIONS EXPLICIT TAGS ::= 4049 BEGIN 4051 IMPORTS 4052 Certificate, CertificateList 4053 FROM PKIX1Explicit88 4054 { iso(1) identified-organization(3) dod(6) 4055 internet(1) security(5) mechanisms(5) pkix(7) 4056 id-mod(0) id-pkix1-explicit(18) } ; 4058 CertificateOrCRL ::= CHOICE { 4059 cert [0] Certificate, 4060 crl [1] CertificateList } 4062 CertificateBundle ::= SEQUENCE OF CertificateOrCRL 4064 END 4066 Implementations MUST be capable of being configured to send and 4067 accept up to four X.509 certificates in support of authentication, 4068 and also MUST be capable of being configured to send and accept the 4069 two Hash and URL formats (with HTTP URLs). Implementations SHOULD be 4070 capable of being configured to send and accept Raw RSA keys. If 4071 multiple certificates are sent, the first certificate MUST contain 4072 the public key used to sign the AUTH payload. The other certificates 4073 may be sent in any order. 4075 3.7. Certificate Request Payload 4077 The Certificate Request Payload, denoted CERTREQ in this memo, 4078 provides a means to request preferred certificates via IKE and can 4079 appear in the IKE_INIT_SA response and/or the IKE_AUTH request. 4080 Certificate Request payloads MAY be included in an exchange when the 4081 sender needs to get the certificate of the receiver. If multiple CAs 4082 are trusted and the certificate encoding does not allow a list, then 4083 multiple Certificate Request payloads would need to be transmitted. 4085 The Certificate Request Payload is defined as follows: 4087 1 2 3 4088 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 4089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4090 | Next Payload |C| RESERVED | Payload Length | 4091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4092 | Cert Encoding | | 4093 +-+-+-+-+-+-+-+-+ | 4094 ~ Certification Authority ~ 4095 | | 4096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4098 Figure 13: Certificate Request Payload Format 4100 o Certificate Encoding (1 octet) - Contains an encoding of the type 4101 or format of certificate requested. Values are listed in 4102 Section 3.6. 4104 o Certification Authority (variable length) - Contains an encoding 4105 of an acceptable certification authority for the type of 4106 certificate requested. 4108 The payload type for the Certificate Request Payload is thirty eight 4109 (38). 4111 The Certificate Encoding field has the same values as those defined 4112 in Section 3.6. The Certification Authority field contains an 4113 indicator of trusted authorities for this certificate type. The 4114 Certification Authority value is a concatenated list of SHA-1 hashes 4115 of the public keys of trusted Certification Authorities (CAs). Each 4116 is encoded as the SHA-1 hash of the Subject Public Key Info element 4117 (see section 4.1.2.7 of [PKIX]) from each Trust Anchor certificate. 4118 The twenty-octet hashes are concatenated and included with no other 4119 formatting. 4121 The contents of the "Certification Authority" field are defined only 4122 for X.509 certificates, which are types 4, 10, 12, and 13. Other 4123 values SHOULD NOT be used until standards-track specifications that 4124 specify their use are published. 4126 Note that the term "Certificate Request" is somewhat misleading, in 4127 that values other than certificates are defined in a "Certificate" 4128 payload and requests for those values can be present in a Certificate 4129 Request Payload. The syntax of the Certificate Request payload in 4130 such cases is not defined in this document. 4132 The Certificate Request Payload is processed by inspecting the "Cert 4133 Encoding" field to determine whether the processor has any 4134 certificates of this type. If so, the "Certification Authority" 4135 field is inspected to determine if the processor has any certificates 4136 that can be validated up to one of the specified certification 4137 authorities. This can be a chain of certificates. 4139 If an end-entity certificate exists that satisfies the criteria 4140 specified in the CERTREQ, a certificate or certificate chain SHOULD 4141 be sent back to the certificate requestor if the recipient of the 4142 CERTREQ: 4144 o is configured to use certificate authentication, 4146 o is allowed to send a CERT payload, 4148 o has matching CA trust policy governing the current negotiation, 4149 and 4151 o has at least one time-wise and usage appropriate end-entity 4152 certificate chaining to a CA provided in the CERTREQ. 4154 Certificate revocation checking must be considered during the 4155 chaining process used to select a certificate. Note that even if two 4156 peers are configured to use two different CAs, cross-certification 4157 relationships should be supported by appropriate selection logic. 4159 The intent is not to prevent communication through the strict 4160 adherence of selection of a certificate based on CERTREQ, when an 4161 alternate certificate could be selected by the sender that would 4162 still enable the recipient to successfully validate and trust it 4163 through trust conveyed by cross-certification, CRLs, or other out-of- 4164 band configured means. Thus, the processing of a CERTREQ should be 4165 seen as a suggestion for a certificate to select, not a mandated one. 4166 If no certificates exist, then the CERTREQ is ignored. This is not 4167 an error condition of the protocol. There may be cases where there 4168 is a preferred CA sent in the CERTREQ, but an alternate might be 4169 acceptable (perhaps after prompting a human operator). 4171 The HTTP_CERT_LOOKUP_SUPPORTED notification MAY be included in any 4172 message that can include a CERTREQ payload and indicates that the 4173 sender is capable of looking up certificates based on an HTTP-based 4174 URL (and hence presumably would prefer to receive certificate 4175 specifications in that format). 4177 3.8. Authentication Payload 4179 The Authentication Payload, denoted AUTH in this memo, contains data 4180 used for authentication purposes. The syntax of the Authentication 4181 data varies according to the Auth Method as specified below. 4183 The Authentication Payload is defined as follows: 4185 1 2 3 4186 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 4187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4188 | Next Payload |C| RESERVED | Payload Length | 4189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4190 | Auth Method | RESERVED | 4191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4192 | | 4193 ~ Authentication Data ~ 4194 | | 4195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4197 Figure 14: Authentication Payload Format 4199 o Auth Method (1 octet) - Specifies the method of authentication 4200 used. Values defined are: 4202 * RSA Digital Signature (1) - Computed as specified in 4203 Section 2.15 using an RSA private key with RSASSA-PKCS1-v1_5 4204 signature scheme specified in [PKCS1] (implementors should note 4205 that IKEv1 used a different method for RSA signatures). To 4206 promote interoperability, implementations that support this 4207 type SHOULD support signatures that use SHA-1 as the hash 4208 function and SHOULD use SHA-1 as the default hash function when 4209 generating signatures. 4211 * Shared Key Message Integrity Code (2) - Computed as specified 4212 in Section 2.15 using the shared key associated with the 4213 identity in the ID payload and the negotiated prf function 4215 * DSS Digital Signature (3) - Computed as specified in 4216 Section 2.15 using a DSS private key (see [DSS]) over a SHA-1 4217 hash. 4219 * The values 0 and 4-200 are reserved to IANA. The values 201- 4220 255 are available for private use. 4222 o Authentication Data (variable length) - see Section 2.15. 4224 The payload type for the Authentication Payload is thirty nine (39). 4226 3.9. Nonce Payload 4228 The Nonce Payload, denoted Ni and Nr in this memo for the initiator's 4229 and responder's nonce respectively, contains random data used to 4230 guarantee liveness during an exchange and protect against replay 4231 attacks. 4233 The Nonce Payload is defined as follows: 4235 1 2 3 4236 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 4237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4238 | Next Payload |C| RESERVED | Payload Length | 4239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4240 | | 4241 ~ Nonce Data ~ 4242 | | 4243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4245 Figure 15: Nonce Payload Format 4247 o Nonce Data (variable length) - Contains the random data generated 4248 by the transmitting entity. 4250 The payload type for the Nonce Payload is forty (40). 4252 The size of a Nonce MUST be between 16 and 256 octets inclusive. 4253 Nonce values MUST NOT be reused. 4255 3.10. Notify Payload 4257 The Notify Payload, denoted N in this document, is used to transmit 4258 informational data, such as error conditions and state transitions, 4259 to an IKE peer. A Notify Payload may appear in a response message 4260 (usually specifying why a request was rejected), in an INFORMATIONAL 4261 Exchange (to report an error not in an IKE request), or in any other 4262 message to indicate sender capabilities or to modify the meaning of 4263 the request. 4265 The Notify Payload is defined as follows: 4267 1 2 3 4268 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 4269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4270 | Next Payload |C| RESERVED | Payload Length | 4271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4272 | Protocol ID | SPI Size | Notify Message Type | 4273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4274 | | 4275 ~ Security Parameter Index (SPI) ~ 4276 | | 4277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4278 | | 4279 ~ Notification Data ~ 4280 | | 4281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4283 Figure 16: Notify Payload Format 4285 o Protocol ID (1 octet) - If this notification concerns an existing 4286 SA whose SPI is given the SPI field, this field indicates the type 4287 of that SA. For notifications concerning IPsec SAs this field 4288 MUST contain either (2) to indicate AH or (3) to indicate ESP. Of 4289 the notifications defined in this document, the SPI is included 4290 only with INVALID_SELECTORS and REKEY_SA. If the SPI field is 4291 empty, this field MUST be sent as zero and MUST be ignored on 4292 receipt. All other values for this field are reserved to IANA for 4293 future assignment. 4295 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 4296 IPsec protocol ID or zero if no SPI is applicable. For a 4297 notification concerning the IKE SA, the SPI Size MUST be zero and 4298 the field must be empty. 4300 o Notify Message Type (2 octets) - Specifies the type of 4301 notification message. 4303 o SPI (variable length) - Security Parameter Index. 4305 o Notification Data (variable length) - Informational or error data 4306 transmitted in addition to the Notify Message Type. Values for 4307 this field are type specific (see below). 4309 The payload type for the Notify Payload is forty one (41). 4311 3.10.1. Notify Message Types 4313 Notification information can be error messages specifying why an SA 4314 could not be established. It can also be status data that a process 4315 managing an SA database wishes to communicate with a peer process. 4316 The table below lists the Notification messages and their 4317 corresponding values. The number of different error statuses was 4318 greatly reduced from IKEv1 both for simplification and to avoid 4319 giving configuration information to probers. 4321 Types in the range 0 - 16383 are intended for reporting errors. An 4322 implementation receiving a Notify payload with one of these types 4323 that it does not recognize in a response MUST assume that the 4324 corresponding request has failed entirely. Unrecognized error types 4325 in a request and status types in a request or response MUST be 4326 ignored, and they should be logged. 4328 Notify payloads with status types MAY be added to any message and 4329 MUST be ignored if not recognized. They are intended to indicate 4330 capabilities, and as part of SA negotiation are used to negotiate 4331 non-cryptographic parameters. 4333 NOTIFY messages: error types Value 4334 ------------------------------------------------------------------- 4336 RESERVED 0 4338 UNSUPPORTED_CRITICAL_PAYLOAD 1 4339 See Section 2.5. 4341 INVALID_IKE_SPI 4 4342 See Section 2.21. 4344 INVALID_MAJOR_VERSION 5 4345 See Section 2.5. 4347 INVALID_SYNTAX 7 4348 Indicates the IKE message that was received was invalid because 4349 some type, length, or value was out of range or because the 4350 request was rejected for policy reasons. To avoid a denial of 4351 service attack using forged messages, this status may only be 4352 returned for and in an encrypted packet if the message ID and 4353 cryptographic checksum were valid. To avoid leaking information 4354 to someone probing a node, this status MUST be sent in response 4355 to any error not covered by one of the other status types. 4356 {{ Demoted the SHOULD }} To aid debugging, more detailed error 4357 information should be written to a console or log. 4359 INVALID_MESSAGE_ID 9 4360 See Section 2.3. 4362 INVALID_SPI 11 4363 See Section 1.5. 4365 NO_PROPOSAL_CHOSEN 14 4366 None of the proposed crypto suites was acceptable. This can be 4367 sent in any case where the offered proposal (including but not 4368 limited to SA payload values, USE_TRANSPORT_MODE notify, 4369 IPCOMP_SUPPORTED notify) are not acceptable for the responder. 4370 This can also be used as "generic" Child SA error when Child SA 4371 cannot be created for some other reason. See also Section 2.7. 4373 INVALID_KE_PAYLOAD 17 4374 See Section 1.3. 4376 AUTHENTICATION_FAILED 24 4377 Sent in the response to an IKE_AUTH message when for some reason 4378 the authentication failed. There is no associated data. 4380 SINGLE_PAIR_REQUIRED 34 4381 See Section 2.9. 4383 NO_ADDITIONAL_SAS 35 4384 See Section 1.3. 4386 INTERNAL_ADDRESS_FAILURE 36 4387 See Section 3.15.4. 4389 FAILED_CP_REQUIRED 37 4390 See Section 2.19. 4392 TS_UNACCEPTABLE 38 4393 See Section 2.9. 4395 INVALID_SELECTORS 39 4396 MAY be sent in an IKE INFORMATIONAL exchange when a node receives 4397 an ESP or AH packet whose selectors do not match those of the SA 4398 on which it was delivered (and that caused the packet to be 4399 dropped). The Notification Data contains the start of the 4400 offending packet (as in ICMP messages) and the SPI field of the 4401 notification is set to match the SPI of the IPsec SA. 4403 RESERVED TO IANA 40-8191 4405 PRIVATE USE 8192-16383 4406 NOTIFY messages: status types Value 4407 ------------------------------------------------------------------- 4409 INITIAL_CONTACT 16384 4410 See Section 2.4. 4412 SET_WINDOW_SIZE 16385 4413 See Section 2.3. 4415 ADDITIONAL_TS_POSSIBLE 16386 4416 See Section 2.9. 4418 IPCOMP_SUPPORTED 16387 4419 See Section 2.22. 4421 NAT_DETECTION_SOURCE_IP 16388 4422 See Section 2.23. 4424 NAT_DETECTION_DESTINATION_IP 16389 4425 See Section 2.23. 4427 COOKIE 16390 4428 See Section 2.6. 4430 USE_TRANSPORT_MODE 16391 4431 See Section 1.3.1. 4433 HTTP_CERT_LOOKUP_SUPPORTED 16392 4434 See Section 3.6. 4436 REKEY_SA 16393 4437 See Section 1.3.3. 4439 ESP_TFC_PADDING_NOT_SUPPORTED 16394 4440 See Section 1.3.1. 4442 NON_FIRST_FRAGMENTS_ALSO 16395 4443 See Section 1.3.1. 4445 RESERVED TO IANA 16396-40959 4447 PRIVATE USE 40960-65535 4449 3.11. Delete Payload 4451 The Delete Payload, denoted D in this memo, contains a protocol 4452 specific security association identifier that the sender has removed 4453 from its security association database and is, therefore, no longer 4454 valid. Figure 17 shows the format of the Delete Payload. It is 4455 possible to send multiple SPIs in a Delete payload; however, each SPI 4456 MUST be for the same protocol. Mixing of protocol identifiers MUST 4457 NOT be performed in the Delete payload. It is permitted, however, to 4458 include multiple Delete payloads in a single INFORMATIONAL exchange 4459 where each Delete payload lists SPIs for a different protocol. 4461 Deletion of the IKE SA is indicated by a protocol ID of 1 (IKE) but 4462 no SPIs. Deletion of a Child SA, such as ESP or AH, will contain the 4463 IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI 4464 is the SPI the sending endpoint would expect in inbound ESP or AH 4465 packets. 4467 The Delete Payload is defined as follows: 4469 1 2 3 4470 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 4471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4472 | Next Payload |C| RESERVED | Payload Length | 4473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4474 | Protocol ID | SPI Size | # of SPIs | 4475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4476 | | 4477 ~ Security Parameter Index(es) (SPI) ~ 4478 | | 4479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4481 Figure 17: Delete Payload Format 4483 o Protocol ID (1 octet) - Must be 1 for an IKE SA, 2 for AH, or 3 4484 for ESP. 4486 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 4487 protocol ID. It MUST be zero for IKE (SPI is in message header) 4488 or four for AH and ESP. 4490 o # of SPIs (2 octets) - The number of SPIs contained in the Delete 4491 payload. The size of each SPI is defined by the SPI Size field. 4493 o Security Parameter Index(es) (variable length) - Identifies the 4494 specific security association(s) to delete. The length of this 4495 field is determined by the SPI Size and # of SPIs fields. 4497 The payload type for the Delete Payload is forty two (42). 4499 3.12. Vendor ID Payload 4501 The Vendor ID Payload, denoted V in this memo, contains a vendor 4502 defined constant. The constant is used by vendors to identify and 4503 recognize remote instances of their implementations. This mechanism 4504 allows a vendor to experiment with new features while maintaining 4505 backward compatibility. 4507 A Vendor ID payload MAY announce that the sender is capable of 4508 accepting certain extensions to the protocol, or it MAY simply 4509 identify the implementation as an aid in debugging. A Vendor ID 4510 payload MUST NOT change the interpretation of any information defined 4511 in this specification (i.e., the critical bit MUST be set to 0). 4512 Multiple Vendor ID payloads MAY be sent. An implementation is NOT 4513 REQUIRED to send any Vendor ID payload at all. 4515 A Vendor ID payload may be sent as part of any message. Reception of 4516 a familiar Vendor ID payload allows an implementation to make use of 4517 Private USE numbers described throughout this memo-- private 4518 payloads, private exchanges, private notifications, etc. Unfamiliar 4519 Vendor IDs MUST be ignored. 4521 Writers of Internet-Drafts who wish to extend this protocol MUST 4522 define a Vendor ID payload to announce the ability to implement the 4523 extension in the Internet-Draft. It is expected that Internet-Drafts 4524 that gain acceptance and are standardized will be given "magic 4525 numbers" out of the Future Use range by IANA, and the requirement to 4526 use a Vendor ID will go away. 4528 The Vendor ID Payload fields are defined as follows: 4530 1 2 3 4531 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 4532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4533 | Next Payload |C| RESERVED | Payload Length | 4534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4535 | | 4536 ~ Vendor ID (VID) ~ 4537 | | 4538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4540 Figure 18: Vendor ID Payload Format 4542 o Vendor ID (variable length) - It is the responsibility of the 4543 person choosing the Vendor ID to assure its uniqueness in spite of 4544 the absence of any central registry for IDs. Good practice is to 4545 include a company name, a person name, or some such. If you want 4546 to show off, you might include the latitude and longitude and time 4547 where you were when you chose the ID and some random input. A 4548 message digest of a long unique string is preferable to the long 4549 unique string itself. 4551 The payload type for the Vendor ID Payload is forty three (43). 4553 3.13. Traffic Selector Payload 4555 The Traffic Selector Payload, denoted TS in this memo, allows peers 4556 to identify packet flows for processing by IPsec security services. 4557 The Traffic Selector Payload consists of the IKE generic payload 4558 header followed by individual traffic selectors as follows: 4560 1 2 3 4561 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 4562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4563 | Next Payload |C| RESERVED | Payload Length | 4564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4565 | Number of TSs | RESERVED | 4566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4567 | | 4568 ~ ~ 4569 | | 4570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4572 Figure 19: Traffic Selectors Payload Format 4574 o Number of TSs (1 octet) - Number of traffic selectors being 4575 provided. 4577 o RESERVED - This field MUST be sent as zero and MUST be ignored on 4578 receipt. 4580 o Traffic Selectors (variable length) - One or more individual 4581 traffic selectors. 4583 The length of the Traffic Selector payload includes the TS header and 4584 all the traffic selectors. 4586 The payload type for the Traffic Selector payload is forty four (44) 4587 for addresses at the initiator's end of the SA and forty five (45) 4588 for addresses at the responder's end. 4590 There is no requirement that TSi and TSr contain the same number of 4591 individual traffic selectors. Thus, they are interpreted as follows: 4592 a packet matches a given TSi/TSr if it matches at least one of the 4593 individual selectors in TSi, and at least one of the individual 4594 selectors in TSr. 4596 For instance, the following traffic selectors: 4598 TSi = ((17, 100, 192.0.1.66-192.0.1.66), 4599 (17, 200, 192.0.1.66-192.0.1.66)) 4600 TSr = ((17, 300, 0.0.0.0-255.255.255.255), 4601 (17, 400, 0.0.0.0-255.255.255.255)) 4603 would match UDP packets from 192.0.1.66 to anywhere, with any of the 4604 four combinations of source/destination ports (100,300), (100,400), 4605 (200,300), and (200, 400). 4607 Thus, some types of policies may require several Child SA pairs. For 4608 instance, a policy matching only source/destination ports (100,300) 4609 and (200,400), but not the other two combinations, cannot be 4610 negotiated as a single Child SA pair. 4612 3.13.1. Traffic Selector 4614 1 2 3 4615 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 4616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4617 | TS Type |IP Protocol ID*| Selector Length | 4618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4619 | Start Port* | End Port* | 4620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4621 | | 4622 ~ Starting Address* ~ 4623 | | 4624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4625 | | 4626 ~ Ending Address* ~ 4627 | | 4628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4630 Figure 20: Traffic Selector 4632 *Note: All fields other than TS Type and Selector Length depend on 4633 the TS Type. The fields shown are for TS Types 7 and 8, the only two 4634 values currently defined. 4636 o TS Type (one octet) - Specifies the type of traffic selector. 4638 o IP protocol ID (1 octet) - Value specifying an associated IP 4639 protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that the 4640 protocol ID is not relevant to this traffic selector-- the SA can 4641 carry all protocols. 4643 o Selector Length - Specifies the length of this Traffic Selector 4644 Substructure including the header. 4646 o Start Port (2 octets) - Value specifying the smallest port number 4647 allowed by this Traffic Selector. For protocols for which port is 4648 undefined (including protocol 0), or if all ports are allowed, 4649 this field MUST be zero. For the ICMP protocol, the two one-octet 4650 fields Type and Code are treated as a single 16-bit integer (with 4651 Type in the most significant eight bits and Code in the least 4652 significant eight bits) port number for the purposes of filtering 4653 based on this field. 4655 o End Port (2 octets) - Value specifying the largest port number 4656 allowed by this Traffic Selector. For protocols for which port is 4657 undefined (including protocol 0), or if all ports are allowed, 4658 this field MUST be 65535. For the ICMP protocol, the two one- 4659 octet fields Type and Code are treated as a single 16-bit integer 4660 (with Type in the most significant eight bits and Code in the 4661 least significant eight bits) port number for the purposed of 4662 filtering based on this field. 4664 o Starting Address - The smallest address included in this Traffic 4665 Selector (length determined by TS type). 4667 o Ending Address - The largest address included in this Traffic 4668 Selector (length determined by TS type). 4670 Systems that are complying with [IPSECARCH] that wish to indicate 4671 "ANY" ports MUST set the start port to 0 and the end port to 65535; 4672 note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems 4673 working with [IPSECARCH] that wish to indicate "OPAQUE" ports, but 4674 not "ANY" ports, MUST set the start port to 65535 and the end port to 4675 0. 4677 The traffic selector types 7 and 8 can also refer to ICMP type and 4678 code fields. Note, however, that ICMP packets do not have separate 4679 source and destination port fields. The method for specifying the 4680 traffic selectors for ICMP is shown by example in Section 4.4.1.3 of 4681 [IPSECARCH]. 4683 Traffic selectors can use IP Protocol ID 135 to match the IPv6 4684 mobility header [MIPV6]. This document does not specify how to 4685 represent the "MH Type" field in traffic selectors, although it is 4686 likely that a different document will specify this in the future. 4687 Note that [IPSECARCH] says that the IPv6 mobility header (MH) message 4688 type is placed in the most significant eight bits of the 16-bit local 4689 port selector. The direction semantics of TSi/TSr port fields are 4690 the same as for ICMP. 4692 The following table lists the assigned values for the Traffic 4693 Selector Type field and the corresponding Address Selector Data. 4695 TS Type Value 4696 ------------------------------------------------------------------- 4697 RESERVED 0-6 4699 TS_IPV4_ADDR_RANGE 7 4701 A range of IPv4 addresses, represented by two four-octet 4702 values. The first value is the beginning IPv4 address 4703 (inclusive) and the second value is the ending IPv4 address 4704 (inclusive). All addresses falling between the two specified 4705 addresses are considered to be within the list. 4707 TS_IPV6_ADDR_RANGE 8 4709 A range of IPv6 addresses, represented by two sixteen-octet 4710 values. The first value is the beginning IPv6 address 4711 (inclusive) and the second value is the ending IPv6 address 4712 (inclusive). All addresses falling between the two specified 4713 addresses are considered to be within the list. 4715 RESERVED TO IANA 9-240 4716 PRIVATE USE 241-255 4718 3.14. Encrypted Payload 4720 The Encrypted Payload, denoted SK{...} or E in this memo, contains 4721 other payloads in encrypted form. The Encrypted Payload, if present 4722 in a message, MUST be the last payload in the message. Often, it is 4723 the only payload in the message. 4725 The algorithms for encryption and integrity protection are negotiated 4726 during IKE SA setup, and the keys are computed as specified in 4727 Section 2.14 and Section 2.18. 4729 This document specifies the cryptographic processing of Encrypted 4730 payloads using a block cipher in CBC mode and an integrity check 4731 algorithm that computes a fixed-length checksum over a variable size 4732 message. The design is modeled after the ESP algorithms described in 4733 RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document 4734 completely specifies the cryptographic processing of IKE data, but 4735 those documents should be consulted for design rationale. Future 4736 documents may specify the processing of Encrypted payloads for other 4737 types of transforms, such as counter mode encryption and 4738 authenticated encryption algorithms. Peers MUST NOT negotiate 4739 transforms for which no such specification exists. 4741 When an authenticated encryption algorithm is used to protect the IKE 4742 SA, the construction of the encrypted payload is different that what 4743 is described here. See [RFC5282] for more information on 4744 authenticated encryption algorithms and their use in ESP. 4746 The payload type for an Encrypted payload is forty six (46). The 4747 Encrypted Payload consists of the IKE generic payload header followed 4748 by individual fields as follows: 4750 1 2 3 4751 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 4752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4753 | Next Payload |C| RESERVED | Payload Length | 4754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4755 | Initialization Vector | 4756 | (length is block size for encryption algorithm) | 4757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4758 ~ Encrypted IKE Payloads ~ 4759 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4760 | | Padding (0-255 octets) | 4761 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 4762 | | Pad Length | 4763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4764 ~ Integrity Checksum Data ~ 4765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4767 Figure 21: Encrypted Payload Format 4769 o Next Payload - The payload type of the first embedded payload. 4770 Note that this is an exception in the standard header format, 4771 since the Encrypted payload is the last payload in the message and 4772 therefore the Next Payload field would normally be zero. But 4773 because the content of this payload is embedded payloads and there 4774 was no natural place to put the type of the first one, that type 4775 is placed here. 4777 o Payload Length - Includes the lengths of the header, IV, Encrypted 4778 IKE Payloads, Padding, Pad Length, and Integrity Checksum Data. 4780 o Initialization Vector - For CBC mode ciphers, the length of the 4781 initialization vector (IV) is equal to the block length of the 4782 underlying encryption algorithm. Senders MUST select a new 4783 unpredictable IV for every message; recipients MUST accept any 4784 value. The reader is encouraged to consult [MODES] for advice on 4785 IV generation. In particular, using the final ciphertext block of 4786 the previous message is not considered unpredictable. For modes 4787 other than CBC, the IV format and processing is specified in the 4788 document specifying the encryption algorithm and mode. 4790 o IKE Payloads are as specified earlier in this section. This field 4791 is encrypted with the negotiated cipher. 4793 o Padding MAY contain any value chosen by the sender, and MUST have 4794 a length that makes the combination of the Payloads, the Padding, 4795 and the Pad Length to be a multiple of the encryption block size. 4796 This field is encrypted with the negotiated cipher. 4798 o Pad Length is the length of the Padding field. The sender SHOULD 4799 set the Pad Length to the minimum value that makes the combination 4800 of the Payloads, the Padding, and the Pad Length a multiple of the 4801 block size, but the recipient MUST accept any length that results 4802 in proper alignment. This field is encrypted with the negotiated 4803 cipher. 4805 o Integrity Checksum Data is the cryptographic checksum of the 4806 entire message starting with the Fixed IKE Header through the Pad 4807 Length. The checksum MUST be computed over the encrypted message. 4808 Its length is determined by the integrity algorithm negotiated. 4810 3.15. Configuration Payload 4812 The Configuration payload, denoted CP in this document, is used to 4813 exchange configuration information between IKE peers. The exchange 4814 is for an IRAC to request an internal IP address from an IRAS and to 4815 exchange other information of the sort that one would acquire with 4816 Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly 4817 connected to a LAN. 4819 The Configuration Payload is defined as follows: 4821 1 2 3 4822 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 4823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4824 | Next Payload |C| RESERVED | Payload Length | 4825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4826 | CFG Type | RESERVED | 4827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4828 | | 4829 ~ Configuration Attributes ~ 4830 | | 4831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4833 Figure 22: Configuration Payload Format 4835 The payload type for the Configuration Payload is forty seven (47). 4837 o CFG Type (1 octet) - The type of exchange represented by the 4838 Configuration Attributes. 4840 CFG Type Value 4841 -------------------------- 4842 RESERVED 0 4843 CFG_REQUEST 1 4844 CFG_REPLY 2 4845 CFG_SET 3 4846 CFG_ACK 4 4847 RESERVED TO IANA 5-127 4848 PRIVATE USE 128-255 4850 o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on 4851 receipt. 4853 o Configuration Attributes (variable length) - These are type length 4854 values specific to the Configuration Payload and are defined 4855 below. There may be zero or more Configuration Attributes in this 4856 payload. 4858 3.15.1. Configuration Attributes 4860 1 2 3 4861 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 4862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4863 |R| Attribute Type | Length | 4864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4865 | | 4866 ~ Value ~ 4867 | | 4868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4870 Figure 23: Configuration Attribute Format 4872 o Reserved (1 bit) - This bit MUST be set to zero and MUST be 4873 ignored on receipt. 4875 o Attribute Type (15 bits) - A unique identifier for each of the 4876 Configuration Attribute Types. 4878 o Length (2 octets) - Length in octets of Value. 4880 o Value (0 or more octets) - The variable-length value of this 4881 Configuration Attribute. The following attribute types have been 4882 defined: 4884 Multi- 4885 Attribute Type Value Valued Length 4886 ------------------------------------------------------- 4887 RESERVED 0 4888 INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets 4889 INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets 4890 INTERNAL_IP4_DNS 3 YES 0 or 4 octets 4891 INTERNAL_IP4_NBNS 4 YES 0 or 4 octets 4892 RESERVED 5 4893 INTERNAL_IP4_DHCP 6 YES 0 or 4 octets 4894 APPLICATION_VERSION 7 NO 0 or more 4895 INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets 4896 RESERVED 9 4897 INTERNAL_IP6_DNS 10 YES 0 or 16 octets 4898 RESERVED 4899 INTERNAL_IP6_DHCP 12 YES 0 or 16 octets 4900 INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets 4901 SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 4902 INTERNAL_IP6_SUBNET 15 YES 17 octets 4903 RESERVED TO IANA 16-16383 4904 PRIVATE USE 16384-32767 4906 * These attributes may be multi-valued on return only if 4907 multiple values were requested. 4909 o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the 4910 internal network, sometimes called a red node address or private 4911 address and MAY be a private address on the Internet. In a 4912 request message, the address specified is a requested address (or 4913 a zero-length address if no specific address is requested). If a 4914 specific address is requested, it likely indicates that a previous 4915 connection existed with this address and the requestor would like 4916 to reuse that address. With IPv6, a requestor MAY supply the low- 4917 order address octets it wants to use. Multiple internal addresses 4918 MAY be requested by requesting multiple internal address 4919 attributes. The responder MAY only send up to the number of 4920 addresses requested. The INTERNAL_IP6_ADDRESS is made up of two 4921 fields: the first is a 16-octet IPv6 address, and the second is a 4922 one-octet prefix-length as defined in [ADDRIPV6]. The requested 4923 address is valid as long as this IKE SA (or its rekeyed 4924 successors) requesting the address is valid. This is described in 4925 more detail in Section 3.15.3. 4927 o INTERNAL_IP4_NETMASK - The internal network's netmask. Only one 4928 netmask is allowed in the request and reply messages (e.g., 4929 255.255.255.0), and it MUST be used only with an 4930 INTERNAL_IP4_ADDRESS attribute. INTERNAL_IP4_NETMASK in a 4931 CFG_REPLY means roughly the same thing as INTERNAL_IP4_SUBNET 4932 containing the same information ("send traffic to these addresses 4933 through me"), but also implies a link boundary. For instance, the 4934 client could use its own address and the netmask to calculate the 4935 broadcast address of the link. An empty INTERNAL_IP4_NETMASK 4936 attribute can be included in a CFG_REQUEST to request this 4937 information (although the gateway can send the information even 4938 when not requested). Non-empty values for this attribute in a 4939 CFG_REQUEST do not make sense and thus MUST NOT be included. 4941 o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS 4942 server within the network. Multiple DNS servers MAY be requested. 4943 The responder MAY respond with zero or more DNS server attributes. 4945 o INTERNAL_IP4_NBNS - Specifies an address of a NetBios Name Server 4946 (WINS) within the network. Multiple NBNS servers MAY be 4947 requested. The responder MAY respond with zero or more NBNS 4948 server attributes. 4950 o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send 4951 any internal DHCP requests to the address contained within the 4952 attribute. Multiple DHCP servers MAY be requested. The responder 4953 MAY respond with zero or more DHCP server attributes. 4955 o APPLICATION_VERSION - The version or application information of 4956 the IPsec host. This is a string of printable ASCII characters 4957 that is NOT null terminated. 4959 o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge- 4960 device protects. This attribute is made up of two fields: the 4961 first being an IP address and the second being a netmask. 4962 Multiple sub-networks MAY be requested. The responder MAY respond 4963 with zero or more sub-network attributes. This is discussed in 4964 more detail in Section 3.15.2. 4966 o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute 4967 MUST be zero-length and specifies a query to the responder to 4968 reply back with all of the attributes that it supports. The 4969 response contains an attribute that contains a set of attribute 4970 identifiers each in 2 octets. The length divided by 2 (octets) 4971 would state the number of supported attributes contained in the 4972 response. 4974 o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge- 4975 device protects. This attribute is made up of two fields: the 4976 first is a 16-octet IPv6 address, and the second is a one-octet 4977 prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY 4978 be requested. The responder MAY respond with zero or more sub- 4979 network attributes. This is discussed in more detail in Section 4980 3.15.2. 4982 Note that no recommendations are made in this document as to how an 4983 implementation actually figures out what information to send in a 4984 reply. That is, we do not recommend any specific method of an IRAS 4985 determining which DNS server should be returned to a requesting IRAC. 4987 The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request 4988 information from its peer. If an attribute in the CFG_REQUEST 4989 Configuration Payload is not zero-length, it is taken as a suggestion 4990 for that attribute. The CFG_REPLY Configuration Payload MAY return 4991 that value, or a new one. It MAY also add new attributes and not 4992 include some requested ones. Requestors MUST ignore returned 4993 attributes that they do not recognize. 4995 The CFG_SET and CFG_ACK pair allows an IKE endpoint to push 4996 configuration data to its peer. In this case, the CFG_SET 4997 Configuration Payload contains attributes the initiator wants its 4998 peer to alter. The responder MUST return a Configuration Payload if 4999 it accepted any of the configuration data and it MUST contain the 5000 attributes that the responder accepted with zero-length data. Those 5001 attributes that it did not accept MUST NOT be in the CFG_ACK 5002 Configuration Payload. If no attributes were accepted, the responder 5003 MUST return either an empty CFG_ACK payload or a response message 5004 without a CFG_ACK payload. There are currently no defined uses for 5005 the CFG_SET/CFG_ACK exchange, though they may be used in connection 5006 with extensions based on Vendor IDs. An implementation of this 5007 specification MAY ignore CFG_SET payloads. 5009 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET 5011 INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets, 5012 ones that need one or more separate SAs, that can be reached through 5013 the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET 5014 attributes may also express the gateway's policy about what traffic 5015 should be sent through the gateway; the client can choose whether 5016 other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is 5017 sent through the gateway or directly to the destination. Thus, 5018 traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET 5019 attributes should be sent through the gateway that announces the 5020 attributes. If there are no existing IPsec SAs whose traffic 5021 selectors cover the address in question, new SAs need to be created. 5023 For instance, if there are two subnets, 192.0.1.0/26 and 5024 192.0.2.0/24, and the client's request contains the following: 5026 CP(CFG_REQUEST) = 5027 INTERNAL_IP4_ADDRESS() 5028 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) 5029 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) 5031 then a valid response could be the following (in which TSr and 5032 INTERNAL_IP4_SUBNET contain the same information): 5034 CP(CFG_REPLY) = 5035 INTERNAL_IP4_ADDRESS(192.0.1.234) 5036 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 5037 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 5038 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 5039 TSr = ((0, 0-65535, 192.0.1.0-192.0.1.63), 5040 (0, 0-65535, 192.0.2.0-192.0.2.255)) 5042 In these cases, the INTERNAL_IP4_SUBNET does not really carry any 5043 useful information. 5045 A different possible reply would have been this: 5047 CP(CFG_REPLY) = 5048 INTERNAL_IP4_ADDRESS(192.0.1.234) 5049 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 5050 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 5051 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 5052 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) 5054 That reply would mean that the client can send all its traffic 5055 through the gateway, but the gateway does not mind if the client 5056 sends traffic not included by INTERNAL_IP4_SUBNET directly to the 5057 destination (without going through the gateway). 5059 A different situation arises if the gateway has a policy that 5060 requires the traffic for the two subnets to be carried in separate 5061 SAs. Then a response like this would indicate to the client that if 5062 it wants access to the second subnet, it needs to create a separate 5063 SA: 5065 CP(CFG_REPLY) = 5066 INTERNAL_IP4_ADDRESS(192.0.1.234) 5067 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 5068 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 5069 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 5070 TSr = (0, 0-65535, 192.0.1.0-192.0.1.63) 5072 INTERNAL_IP4_SUBNET can also be useful if the client's TSr included 5073 only part of the address space. For instance, if the client requests 5074 the following: 5076 CP(CFG_REQUEST) = 5077 INTERNAL_IP4_ADDRESS() 5078 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) 5079 TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) 5081 then the gateway's reply might be: 5083 CP(CFG_REPLY) = 5084 INTERNAL_IP4_ADDRESS(192.0.1.234) 5085 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 5086 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 5087 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 5088 TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) 5090 Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET is in 5091 CFG_REQUESTs is unclear, they cannot be used reliably in 5092 CFG_REQUESTs. 5094 3.15.3. Configuration payloads for IPv6 5096 The configuration payloads for IPv6 are based on the corresponding 5097 IPv4 payloads, and do not fully follow the "normal IPv6 way of doing 5098 things". In particular, IPv6 stateless autoconfiguration or router 5099 advertisement messages are not used; neither is neighbor discovery. 5100 Note that there is an additional document that discusses IPv6 5101 configuration in IKEv2, [IPV6CONFIG]. At the present time, it is an 5102 experimental document, but there is a hope that with more 5103 implementation experience, it will gain the same standards treatment 5104 as this document. 5106 A client can be assigned an IPv6 address using the 5107 INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange might 5108 look like this: 5110 CP(CFG_REQUEST) = 5111 INTERNAL_IP6_ADDRESS() 5112 INTERNAL_IP6_DNS() 5113 TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 5114 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 5116 CP(CFG_REPLY) = 5117 INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) 5118 INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) 5119 TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) 5120 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 5121 The client MAY send a non-empty INTERNAL_IP6_ADDRESS attribute in the 5122 CFG_REQUEST to request a specific address or interface identifier. 5123 The gateway first checks if the specified address is acceptable, and 5124 if it is, returns that one. If the address was not acceptable, the 5125 gateway attempts to use the interface identifier with some other 5126 prefix; if even that fails, the gateway selects another interface 5127 identifier. 5129 The INTERNAL_IP6_ADDRESS attribute also contains a prefix length 5130 field. When used in a CFG_REPLY, this corresponds to the 5131 INTERNAL_IP4_NETMASK attribute in the IPv4 case. 5133 Although this approach to configuring IPv6 addresses is reasonably 5134 simple, it has some limitations. IPsec tunnels configured using 5135 IKEv2 are not fully-featured "interfaces" in the IPv6 addressing 5136 architecture sense [IPV6ADDR]. In particular, they do not 5137 necessarily have link-local addresses, and this may complicate the 5138 use of protocols that assume them, such as [MLDV2]. 5140 3.15.4. Address Assignment Failures 5142 If the responder encounters an error while attempting to assign an IP 5143 address to the initiator during the processing of a Configuration 5144 Payload, it responds with an INTERNAL_ADDRESS_FAILURE notification. 5145 The IKE SA is still created even if the initial Child SA cannot be 5146 created because of this failure. If this error is generated within 5147 an IKE_AUTH exchange, no Child SA will be created. However, there 5148 are some more complex error cases. 5150 If the responder does not support configuration payloads at all, it 5151 can simply ignore all configuration payloads. This type of 5152 implementation never sends INTERNAL_ADDRESS_FAILURE notifications. 5153 If the initiator requires the assignment of an IP address, it will 5154 treat a response without CFG_REPLY as an error. 5156 The initiator may request a particular type of address (IPv4 or IPv6) 5157 that the responder does not support, even though the responder 5158 supports configuration payloads. In this case, the responder simply 5159 ignores the type of address it does not support and processes the 5160 rest of the request as usual. 5162 If the initiator requests multiple addresses of a type that the 5163 responder supports, and some (but not all) of the requests fail, the 5164 responder replies with the successful addresses only. The responder 5165 sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned. 5167 3.16. Extensible Authentication Protocol (EAP) Payload 5169 The Extensible Authentication Protocol Payload, denoted EAP in this 5170 memo, allows IKE SAs to be authenticated using the protocol defined 5171 in RFC 3748 [EAP] and subsequent extensions to that protocol. The 5172 full set of acceptable values for the payload is defined elsewhere, 5173 but a short summary of RFC 3748 is included here to make this 5174 document stand alone in the common cases. 5176 1 2 3 5177 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 5178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5179 | Next Payload |C| RESERVED | Payload Length | 5180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5181 | | 5182 ~ EAP Message ~ 5183 | | 5184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5186 Figure 24: EAP Payload Format 5188 The payload type for an EAP Payload is forty eight (48). 5190 1 2 3 5191 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 5192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5193 | Code | Identifier | Length | 5194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5195 | Type | Type_Data... 5196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 5198 Figure 25: EAP Message Format 5200 o Code (1 octet) indicates whether this message is a Request (1), 5201 Response (2), Success (3), or Failure (4). 5203 o Identifier (1 octet) is used in PPP to distinguish replayed 5204 messages from repeated ones. Since in IKE, EAP runs over a 5205 reliable protocol, it serves no function here. In a response 5206 message, this octet MUST be set to match the identifier in the 5207 corresponding request. In other messages, this field MAY be set 5208 to any value. 5210 o Length (2 octets) is the length of the EAP message and MUST be 5211 four less than the Payload Length of the encapsulating payload. 5213 o Type (1 octet) is present only if the Code field is Request (1) or 5214 Response (2). For other codes, the EAP message length MUST be 5215 four octets and the Type and Type_Data fields MUST NOT be present. 5216 In a Request (1) message, Type indicates the data being requested. 5217 In a Response (2) message, Type MUST either be Nak or match the 5218 type of the data requested. The following types are defined in 5219 RFC 3748: 5221 1 Identity 5222 2 Notification 5223 3 Nak (Response Only) 5224 4 MD5-Challenge 5225 5 One-Time Password (OTP) 5226 6 Generic Token Card 5228 o Type_Data (Variable Length) varies with the Type of Request and 5229 the associated Response. For the documentation of the EAP 5230 methods, see [EAP]. 5232 Note that since IKE passes an indication of initiator identity in 5233 message 3 of the protocol, the responder should not send EAP Identity 5234 requests. The initiator may, however, respond to such requests if it 5235 receives them. 5237 4. Conformance Requirements 5239 In order to assure that all implementations of IKEv2 can 5240 interoperate, there are "MUST support" requirements in addition to 5241 those listed elsewhere. Of course, IKEv2 is a security protocol, and 5242 one of its major functions is to allow only authorized parties to 5243 successfully complete establishment of SAs. So a particular 5244 implementation may be configured with any of a number of restrictions 5245 concerning algorithms and trusted authorities that will prevent 5246 universal interoperability. 5248 IKEv2 is designed to permit minimal implementations that can 5249 interoperate with all compliant implementations. There are a series 5250 of optional features that can easily be ignored by a particular 5251 implementation if it does not support that feature. Those features 5252 include: 5254 o Ability to negotiate SAs through a NAT and tunnel the resulting 5255 ESP SA over UDP. 5257 o Ability to request (and respond to a request for) a temporary IP 5258 address on the remote end of a tunnel. 5260 o Ability to support various types of legacy authentication. 5262 o Ability to support window sizes greater than one. 5264 o Ability to establish multiple ESP or AH SAs within a single IKE 5265 SA. 5267 o Ability to rekey SAs. 5269 To assure interoperability, all implementations MUST be capable of 5270 parsing all payload types (if only to skip over them) and to ignore 5271 payload types that it does not support unless the critical bit is set 5272 in the payload header. If the critical bit is set in an unsupported 5273 payload header, all implementations MUST reject the messages 5274 containing those payloads. 5276 Every implementation MUST be capable of doing four-message 5277 IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, 5278 one for ESP or AH). Implementations MAY be initiate-only or respond- 5279 only if appropriate for their platform. Every implementation MUST be 5280 capable of responding to an INFORMATIONAL exchange, but a minimal 5281 implementation MAY respond to any INFORMATIONAL message with an empty 5282 INFORMATIONAL reply (note that within the context of an IKE SA, an 5283 "empty" message consists of an IKE header followed by an Encrypted 5284 payload with no payloads contained in it). A minimal implementation 5285 MAY support the CREATE_CHILD_SA exchange only in so far as to 5286 recognize requests and reject them with a Notify payload of type 5287 NO_ADDITIONAL_SAS. A minimal implementation need not be able to 5288 initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA 5289 expires (based on locally configured values of either lifetime or 5290 octets passed), and implementation MAY either try to renew it with a 5291 CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and 5292 create a new one. If the responder rejects the CREATE_CHILD_SA 5293 request with a NO_ADDITIONAL_SAS notification, the implementation 5294 MUST be capable of instead deleting the old SA and creating a new 5295 one. 5297 Implementations are not required to support requesting temporary IP 5298 addresses or responding to such requests. If an implementation does 5299 support issuing such requests, it MUST include a CP payload in 5300 message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or 5301 INTERNAL_IP6_ADDRESS. All other fields are optional. If an 5302 implementation supports responding to such requests, it MUST parse 5303 the CP payload of type CFG_REQUEST in message 3 and recognize a field 5304 of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports 5305 leasing an address of the appropriate type, it MUST return a CP 5306 payload of type CFG_REPLY containing an address of the requested 5307 type. The responder may include any other related attributes. 5309 A minimal IPv4 responder implementation will ignore the contents of 5310 the CP payload except to determine that it includes an 5311 INTERNAL_IP4_ADDRESS attribute and will respond with the address and 5312 other related attributes regardless of whether the initiator 5313 requested them. 5315 A minimal IPv4 initiator will generate a CP payload containing only 5316 an INTERNAL_IP4_ADDRESS attribute and will parse the response 5317 ignoring attributes it does not know how to use. 5319 For an implementation to be called conforming to this specification, 5320 it MUST be possible to configure it to accept the following: 5322 o PKIX Certificates containing and signed by RSA keys of size 1024 5323 or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, 5324 ID_RFC822_ADDR, or ID_DER_ASN1_DN. 5326 o Shared key authentication where the ID passed is any of ID_KEY_ID, 5327 ID_FQDN, or ID_RFC822_ADDR. 5329 o Authentication where the responder is authenticated using PKIX 5330 Certificates and the initiator is authenticated using shared key 5331 authentication. 5333 5. Security Considerations 5335 While this protocol is designed to minimize disclosure of 5336 configuration information to unauthenticated peers, some such 5337 disclosure is unavoidable. One peer or the other must identify 5338 itself first and prove its identity first. To avoid probing, the 5339 initiator of an exchange is required to identify itself first, and 5340 usually is required to authenticate itself first. The initiator can, 5341 however, learn that the responder supports IKE and what cryptographic 5342 protocols it supports. The responder (or someone impersonating the 5343 responder) can probe the initiator not only for its identity, but 5344 using CERTREQ payloads may be able to determine what certificates the 5345 initiator is willing to use. 5347 Use of EAP authentication changes the probing possibilities somewhat. 5348 When EAP authentication is used, the responder proves its identity 5349 before the initiator does, so an initiator that knew the name of a 5350 valid initiator could probe the responder for both its name and 5351 certificates. 5353 Repeated rekeying using CREATE_CHILD_SA without additional Diffie- 5354 Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a 5355 single key or overrun of either endpoint. Implementers should take 5356 note of this fact and set a limit on CREATE_CHILD_SA exchanges 5357 between exponentiations. This memo does not prescribe such a limit. 5359 The strength of a key derived from a Diffie-Hellman exchange using 5360 any of the groups defined here depends on the inherent strength of 5361 the group, the size of the exponent used, and the entropy provided by 5362 the random number generator used. Due to these inputs, it is 5363 difficult to determine the strength of a key for any of the defined 5364 groups. Diffie-Hellman group number two, when used with a strong 5365 random number generator and an exponent no less than 200 bits, is 5366 common for use with 3DES. Group five provides greater security than 5367 group two. Group one is for historic purposes only and does not 5368 provide sufficient strength except for use with DES, which is also 5369 for historic use only. Implementations should make note of these 5370 estimates when establishing policy and negotiating security 5371 parameters. 5373 Note that these limitations are on the Diffie-Hellman groups 5374 themselves. There is nothing in IKE that prohibits using stronger 5375 groups nor is there anything that will dilute the strength obtained 5376 from stronger groups (limited by the strength of the other algorithms 5377 negotiated including the prf function). In fact, the extensible 5378 framework of IKE encourages the definition of more groups; use of 5379 elliptical curve groups may greatly increase strength using much 5380 smaller numbers. 5382 It is assumed that all Diffie-Hellman exponents are erased from 5383 memory after use. 5385 The IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator 5386 has been authenticated. As a result, an implementation of this 5387 protocol needs to be completely robust when deployed on any insecure 5388 network. Implementation vulnerabilities, particularly denial-of- 5389 service attacks, can be exploited by unauthenticated peers. This 5390 issue is particularly worrisome because of the unlimited number of 5391 messages in EAP-based authentication. 5393 The strength of all keys is limited by the size of the output of the 5394 negotiated prf function. For this reason, a prf function whose 5395 output is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with 5396 this protocol. 5398 The security of this protocol is critically dependent on the 5399 randomness of the randomly chosen parameters. These should be 5400 generated by a strong random or properly seeded pseudo-random source 5401 (see [RANDOMNESS]). Implementers should take care to ensure that use 5402 of random numbers for both keys and nonces is engineered in a fashion 5403 that does not undermine the security of the keys. 5405 For information on the rationale of many of the cryptographic design 5406 choices in this protocol, see [SIGMA] and [SKEME]. Though the 5407 security of negotiated Child SAs does not depend on the strength of 5408 the encryption and integrity protection negotiated in the IKE SA, 5409 implementations MUST NOT negotiate NONE as the IKE integrity 5410 protection algorithm or ENCR_NULL as the IKE encryption algorithm. 5412 When using pre-shared keys, a critical consideration is how to assure 5413 the randomness of these secrets. The strongest practice is to ensure 5414 that any pre-shared key contain as much randomness as the strongest 5415 key being negotiated. Deriving a shared secret from a password, 5416 name, or other low-entropy source is not secure. These sources are 5417 subject to dictionary and social engineering attacks, among others. 5419 The NAT_DETECTION_*_IP notifications contain a hash of the addresses 5420 and ports in an attempt to hide internal IP addresses behind a NAT. 5421 Since the IPv4 address space is only 32 bits, and it is usually very 5422 sparse, it would be possible for an attacker to find out the internal 5423 address used behind the NAT box by trying all possible IP addresses 5424 and trying to find the matching hash. The port numbers are normally 5425 fixed to 500, and the SPIs can be extracted from the packet. This 5426 reduces the number of hash calculations to 2^32. With an educated 5427 guess of the use of private address space, the number of hash 5428 calculations is much smaller. Designers should therefore not assume 5429 that use of IKE will not leak internal address information. 5431 When using an EAP authentication method that does not generate a 5432 shared key for protecting a subsequent AUTH payload, certain man-in- 5433 the-middle and server impersonation attacks are possible [EAPMITM]. 5434 These vulnerabilities occur when EAP is also used in protocols that 5435 are not protected with a secure tunnel. Since EAP is a general- 5436 purpose authentication protocol, which is often used to provide 5437 single-signon facilities, a deployed IPsec solution that relies on an 5438 EAP authentication method that does not generate a shared key (also 5439 known as a non-key-generating EAP method) can become compromised due 5440 to the deployment of an entirely unrelated application that also 5441 happens to use the same non-key-generating EAP method, but in an 5442 unprotected fashion. Note that this vulnerability is not limited to 5443 just EAP, but can occur in other scenarios where an authentication 5444 infrastructure is reused. For example, if the EAP mechanism used by 5445 IKEv2 utilizes a token authenticator, a man-in-the-middle attacker 5446 could impersonate the web server, intercept the token authentication 5447 exchange, and use it to initiate an IKEv2 connection. For this 5448 reason, use of non-key-generating EAP methods SHOULD be avoided where 5449 possible. Where they are used, it is extremely important that all 5450 usages of these EAP methods SHOULD utilize a protected tunnel, where 5451 the initiator validates the responder's certificate before initiating 5452 the EAP authentication. Implementers should describe the 5453 vulnerabilities of using non-key-generating EAP methods in the 5454 documentation of their implementations so that the administrators 5455 deploying IPsec solutions are aware of these dangers. 5457 An implementation using EAP MUST also use strong authentication of 5458 the server to the client before the EAP authentication begins, even 5459 if the EAP method offers mutual authentication. This avoids having 5460 additional IKEv2 protocol variations and protects the EAP data from 5461 active attackers. 5463 If the messages of IKEv2 are long enough that IP-level fragmentation 5464 is necessary, it is possible that attackers could prevent the 5465 exchange from completing by exhausting the reassembly buffers. The 5466 chances of this can be minimized by using the Hash and URL encodings 5467 instead of sending certificates (see Section 3.6). Additional 5468 mitigations are discussed in [DOSUDPPROT]. 5470 Admission control is critical to the security of the protocol. For 5471 example, trust anchors used for identifying IKE peers should probably 5472 be different than those used for other forms of trust, such as those 5473 used to identify public web servers. Moreover, although IKE provides 5474 a great deal of leeway in defining the security policy for a trusted 5475 peer's identity, credentials, and the correlation between them, 5476 having such security policy defined explicitly is essential to a 5477 secure implementation. 5479 5.1. Traffic selector authorization 5481 IKEv2 relies on information in the Peer Authorization Database (PAD) 5482 when determining what kind of IPsec SAs a peer is allowed to create. 5483 This process is described in [IPSECARCH] Section 4.4.3. When a peer 5484 requests the creation of an IPsec SA with some traffic selectors, the 5485 PAD must contain "Child SA Authorization Data" linking the identity 5486 authenticated by IKEv2 and the addresses permitted for traffic 5487 selectors. 5489 For example, the PAD might be configured so that authenticated 5490 identity "sgw23.example.com" is allowed to create IPsec SAs for 5491 192.0.2.0/24, meaning this security gateway is a valid 5492 "representative" for these addresses. Host-to-host IPsec requires 5493 similar entries, linking, for example, "fooserver4.example.com" with 5494 192.0.1.66/32, meaning this identity a valid "owner" or 5495 "representative" of the address in question. 5497 As noted in [IPSECARCH], "It is necessary to impose these constraints 5498 on creation of child SAs to prevent an authenticated peer from 5499 spoofing IDs associated with other, legitimate peers." In the 5500 example given above, a correct configuration of the PAD prevents 5501 sgw23 from creating IPsec SAs with address 192.0.1.66, and prevents 5502 fooserver4 from creating IPsec SAs with addresses from 192.0.2.0/24. 5504 It is important to note that simply sending IKEv2 packets using some 5505 particular address does not imply a permission to create IPsec SAs 5506 with that address in the traffic selectors. For example, even if 5507 sgw23 would be able to spoof its IP address as 192.0.1.66, it could 5508 not create IPsec SAs matching fooserver4's traffic. 5510 The IKEv2 specification does not specify how exactly IP address 5511 assignment using configuration payloads interacts with the PAD. Our 5512 interpretation is that when a security gateway assigns an address 5513 using configuration payloads, it also creates a temporary PAD entry 5514 linking the authenticated peer identity and the newly allocated inner 5515 address. 5517 It has been recognized that configuring the PAD correctly may be 5518 difficult in some environments. For instance, if IPsec is used 5519 between a pair of hosts whose addresses are allocated dynamically 5520 using DHCP, it is extremely difficult to ensure that the PAD 5521 specifies the correct "owner" for each IP address. This would 5522 require a mechanism to securely convey address assignments from the 5523 DHCP server, and link them to identities authenticated using IKEv2. 5525 Due to this limitation, some vendors have been known to configure 5526 their PADs to allow an authenticated peer to create IPsec SAs with 5527 traffic selectors containing the same address that was used for the 5528 IKEv2 packets. In environments where IP spoofing is possible (i.e., 5529 almost everywhere) this essentially allows any peer to create IPsec 5530 SAs with any traffic selectors. This is not an appropriate or secure 5531 configuration in most circumstances. See [H2HIPSEC] for an extensive 5532 discussion about this issue, and the limitations of host-to-host 5533 IPsec in general. 5535 6. IANA Considerations 5537 [IKEV2] defined many field types and values. IANA has already 5538 registered those types and values, so the are not listed here again. 5539 No new types or values are registered in this document. However, 5540 IANA should update all references to RFC 4306 to point to this 5541 document. 5543 7. Acknowledgements 5545 Many individuals in the IPsecME Working Group were very helpful in 5546 contributing ideas and text for this document, as well as in 5547 reviewing the clarifications suggested by others. 5549 The acknowledgements from the IKEv2 document were: 5551 This document is a collaborative effort of the entire IPsec WG. If 5552 there were no limit to the number of authors that could appear on an 5553 RFC, the following, in alphabetical order, would have been listed: 5554 Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt 5555 Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John 5556 Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero 5557 Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer 5558 Reingold, and Michael Richardson. Many other people contributed to 5559 the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, 5560 each of which has its own list of authors. Hugh Daniel suggested the 5561 feature of having the initiator, in message 3, specify a name for the 5562 responder, and gave the feature the cute name "You Tarzan, Me Jane". 5563 David Faucher and Valery Smyzlov helped refine the design of the 5564 traffic selector negotiation. 5566 This paragraph lists references that appear only in figures. The 5567 section is only here to keep the 'xml2rfc' program happy, and needs 5568 to be removed when the document is published. The RFC Editor will 5569 remove it before publication. [AEAD] [EAI] [DES] [IDEA] [MD5] 5570 [X.501] [X.509] 5572 8. References 5574 8.1. Normative References 5576 [ADDGROUP] 5577 Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 5578 Diffie-Hellman groups for Internet Key Exchange (IKE)", 5579 RFC 3526, May 2003. 5581 [ADDRIPV6] 5582 Hinden, R. and S. Deering, "Internet Protocol Version 6 5583 (IPv6) Addressing Architecture", RFC 4291, February 2006. 5585 [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 5586 Levkowetz, "Extensible Authentication Protocol (EAP)", 5587 RFC 3748, June 2004. 5589 [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 5590 of Explicit Congestion Notification (ECN) to IP", 5591 RFC 3168, September 2001. 5593 [ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 5594 Algorithms", RFC 2451, November 1998. 5596 [IPSECARCH] 5597 Kent, S. and K. Seo, "Security Architecture for the 5598 Internet Protocol", RFC 4301, December 2005. 5600 [MUSTSHOULD] 5601 Bradner, S., "Key Words for use in RFCs to indicate 5602 Requirement Levels", BCP 14, RFC 2119, March 1997. 5604 [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 5605 Standards (PKCS) #1: RSA Cryptography Specifications 5606 Version 2.1", RFC 3447, February 2003. 5608 [PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 5609 X.509 Public Key Infrastructure Certificate and 5610 Certificate Revocation List (CRL) Profile", RFC 3280, 5611 April 2002. 5613 [RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the 5614 Internet Key Exchange Protocol (IKE)", RFC 4434, 5615 February 2006. 5617 [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 5618 Advanced Encryption Standard-Cipher-based Message 5619 Authentication Code-Pseudo-Random Function-128 (AES-CMAC- 5620 PRF-128) Algorithm for the Internet Key Exchange Protocol 5621 (IKE)", RFC 4615, August 2006. 5623 [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption 5624 Algorithms with the Encrypted Payload of the Internet Key 5625 Exchange version 2 (IKEv2) Protocol", RFC 5282, 5626 August 2008. 5628 [UDPENCAPS] 5629 Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 5630 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 5631 RFC 3948, January 2005. 5633 8.2. Informative References 5635 [AEAD] McGrew, D., "An Interface and Algorithms for Authenticated 5636 Encryption", RFC 5116, January 2008. 5638 [AH] Kent, S., "IP Authentication Header", RFC 4302, 5639 December 2005. 5641 [ARCHGUIDEPHIL] 5642 Bush, R. and D. Meyer, "Some Internet Architectural 5643 Guidelines and Philosophy", RFC 3439, December 2002. 5645 [ARCHPRINC] 5646 Carpenter, B., "Architectural Principles of the Internet", 5647 RFC 1958, June 1996. 5649 [Clarif] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 5650 Implementation Guidelines", RFC 4718, October 2006. 5652 [DES] American National Standards Institute, "American National 5653 Standard for Information Systems-Data Link Encryption", 5654 ANSI X3.106, 1983. 5656 [DH] Diffie, W. and M. Hellman, "New Directions in 5657 Cryptography", IEEE Transactions on Information Theory, 5658 V.IT-22 n. 6, June 1977. 5660 [DIFFSERVARCH] 5661 Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 5662 and W. Weiss, "An Architecture for Differentiated 5663 Services", RFC 2475. 5665 [DIFFSERVFIELD] 5666 Nichols, K., Blake, S., Baker, F., and D. Black, 5667 "Definition of the Differentiated Services Field (DS 5668 Field) in the IPv4 and IPv6 Headers", RFC 2474, 5669 December 1998. 5671 [DIFFTUNNEL] 5672 Black, D., "Differentiated Services and Tunnels", 5673 RFC 2983, October 2000. 5675 [DOI] Piper, D., "The Internet IP Security Domain of 5676 Interpretation for ISAKMP", RFC 2407, November 1998. 5678 [DOSUDPPROT] 5679 C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection 5680 for UDP-based protocols", ACM Conference on Computer and 5681 Communications Security , October 2003. 5683 [DSS] National Institute of Standards and Technology, U.S. 5684 Department of Commerce, "Digital Signature Standard", 5685 Draft FIPS 186-3, June 2008. 5687 [EAI] Abel, Y., "Internationalized Email Headers", RFC 5335, 5688 September 2008. 5690 [EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, "Man-in-the-Middle in 5691 Tunneled Authentication Protocols", November 2002, 5692 . 5694 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 5695 RFC 4303, December 2005. 5697 [EXCHANGEANALYSIS] 5698 R. Perlman and C. Kaufman, "Analysis of the IPsec key 5699 exchange Standard", WET-ICE Security Conference, MIT , 5700 2001, 5701 . 5703 [H2HIPSEC] 5704 Aura, T., Roe, M., and A. Mohammed, "Experiences with 5705 Host-to-Host IPsec", 13th International Workshop on 5706 Security Protocols, Cambridge, UK, April 2005. 5708 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 5709 Hashing for Message Authentication", RFC 2104, 5710 February 1997. 5712 [IDEA] X. Lai, "On the Design and Security of Block Ciphers", ETH 5713 Series in Information Processing, v. 1, Konstanz: Hartung- 5714 Gorre Verlag, 1992. 5716 [IDNA] Faltstrom, P., Hoffman, P., and A. Costello, 5717 "Internationalizing Domain Names in Applications (IDNA)", 5718 RFC 3490, March 2003. 5720 [IKEV1] Harkins, D. and D. Carrel, "The Internet Key Exchange 5721 (IKE)", RFC 2409, November 1998. 5723 [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 5724 RFC 4306, December 2005. 5726 [IP-COMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP 5727 Payload Compression Protocol (IPComp)", RFC 3173, 5728 September 2001. 5730 [IPSECARCH-OLD] 5731 Kent, S. and R. Atkinson, "Security Architecture for the 5732 Internet Protocol", RFC 2401, November 1998. 5734 [IPV6ADDR] 5735 Hinden, R. and S. Deering, "Internet Protocol Version 6 5736 (IPv6) Addressing Architecture", RFC 4291, February 2006. 5738 [IPV6CONFIG] 5739 Eronen, et. al., P., "IPv6 Configuration in IKEv2", 5740 draft-ietf-ipsecme-ikev2-ipv6-config (work in progress), 5741 August 2009. 5743 [ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet 5744 Security Association and Key Management Protocol 5745 (ISAKMP)", RFC 2408, November 1998. 5747 [MAILFORMAT] 5748 Resnick, P., "Internet Message Format", RFC 2822, 5749 April 2001. 5751 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 5752 April 1992. 5754 [MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 5755 in IPv6", RFC 3775, June 2004. 5757 [MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery 5758 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 5760 [MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 5761 (MOBIKE)", RFC 4555, June 2006. 5763 [MODES] National Institute of Standards and Technology, U.S. 5764 Department of Commerce, "Recommendation for Block Cipher 5765 Modes of Operation", SP 800-38A, 2001. 5767 [NAI] Aboba, B., Beadles, M., Eronen, P., and J. Arkko, "The 5768 Network Access Identifier", RFC 4282, December 2005. 5770 [NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 5771 (NAT) Compatibility Requirements", RFC 3715, March 2004. 5773 [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", 5774 RFC 2412, November 1998. 5776 [PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 5777 Management API, Version 2", RFC 2367, July 1998. 5779 [PHOTURIS] 5780 Karn, P. and W. Simpson, "Photuris: Session-Key Management 5781 Protocol", RFC 2522, March 1999. 5783 [RANDOMNESS] 5784 Eastlake, D., Schiller, J., and S. Crocker, "Randomness 5785 Requirements for Security", BCP 106, RFC 4086, June 2005. 5787 [REAUTH] Nir, Y., "Repeated Authentication in Internet Key Exchange 5788 (IKEv2) Protocol", RFC 4478, April 2006. 5790 [REUSE] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In 5791 Diffie-Hellman Key Agreement Protocols", December 2008, 5792 . 5795 [ROHCV2] Ertekin, et. al., E., "IKEv2 Extensions to Support Robust 5796 Header Compression over IPsec (ROHCoIPsec)", 5797 draft-ietf-rohc-ikev2-extensions-hcoipsec (work in 5798 progress), August 2009. 5800 [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for 5801 Obtaining Digital Signatures and Public-Key 5802 Cryptosystems", February 1978. 5804 [SHA] National Institute of Standards and Technology, U.S. 5805 Department of Commerce, "Secure Hash Standard", 5806 FIPS 180-3, October 2008. 5808 [SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to 5809 Authenticated Diffie-Hellman and its Use in the IKE 5810 Protocols", Advances in Cryptography - CRYPTO 2003 5811 Proceedings LNCS 2729, 2003, . 5815 [SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange 5816 Mechanism for Internet", IEEE Proceedings of the 1996 5817 Symposium on Network and Distributed Systems Security , 5818 1996. 5820 [TRANSPARENCY] 5821 Carpenter, B., "Internet Transparency", RFC 2775, 5822 February 2000. 5824 [X.501] ITU-T, "Recommendation X.501: Information Technology - 5825 Open Systems Interconnection - The Directory: Models", 5826 1993. 5828 [X.509] ITU-T, "Recommendation X.509 (1997 E): Information 5829 Technology - Open Systems Interconnection - The Directory: 5830 Authentication Framework", 1997. 5832 Appendix A. Summary of changes from IKEv1 5834 The goals of this revision to IKE are: 5836 1. To define the entire IKE protocol in a single document, 5837 replacing RFCs 2407, 2408, and 2409 and incorporating subsequent 5838 changes to support NAT Traversal, Extensible Authentication, and 5839 Remote Address acquisition; 5841 2. To simplify IKE by replacing the eight different initial 5842 exchanges with a single four-message exchange (with changes in 5843 authentication mechanisms affecting only a single AUTH payload 5844 rather than restructuring the entire exchange) see 5845 [EXCHANGEANALYSIS]; 5847 3. To remove the Domain of Interpretation (DOI), Situation (SIT), 5848 and Labeled Domain Identifier fields, and the Commit and 5849 Authentication only bits; 5851 4. To decrease IKE's latency in the common case by making the 5852 initial exchange be 2 round trips (4 messages), and allowing the 5853 ability to piggyback setup of a Child SA on that exchange; 5855 5. To replace the cryptographic syntax for protecting the IKE 5856 messages themselves with one based closely on ESP to simplify 5857 implementation and security analysis; 5859 6. To reduce the number of possible error states by making the 5860 protocol reliable (all messages are acknowledged) and sequenced. 5861 This allows shortening CREATE_CHILD_SA exchanges from 3 messages 5862 to 2; 5864 7. To increase robustness by allowing the responder to not do 5865 significant processing until it receives a message proving that 5866 the initiator can receive messages at its claimed IP address; 5868 8. To fix cryptographic weaknesses such as the problem with 5869 symmetries in hashes used for authentication documented by Tero 5870 Kivinen; 5872 9. To specify Traffic Selectors in their own payloads type rather 5873 than overloading ID payloads, and making more flexible the 5874 Traffic Selectors that may be specified; 5876 10. To specify required behavior under certain error conditions or 5877 when data that is not understood is received in order to make it 5878 easier to make future revisions in a way that does not break 5879 backwards compatibility; 5881 11. To simplify and clarify how shared state is maintained in the 5882 presence of network failures and Denial of Service attacks; and 5884 12. To maintain existing syntax and magic numbers to the extent 5885 possible to make it likely that implementations of IKEv1 can be 5886 enhanced to support IKEv2 with minimum effort. 5888 Appendix B. Diffie-Hellman Groups 5890 There are two Diffie-Hellman groups defined here for use in IKE. 5891 These groups were generated by Richard Schroeppel at the University 5892 of Arizona. Properties of these primes are described in [OAKLEY]. 5894 The strength supplied by group one may not be sufficient for the 5895 mandatory-to-implement encryption algorithm and is here for historic 5896 reasons. 5898 Additional Diffie-Hellman groups have been defined in [ADDGROUP]. 5900 B.1. Group 1 - 768 Bit MODP 5902 This group is assigned id 1 (one). 5904 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 5905 Its hexadecimal value is: 5907 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 5908 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 5909 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 5910 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF 5912 The generator is 2. 5914 B.2. Group 2 - 1024 Bit MODP 5916 This group is assigned id 2 (two). 5918 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 5919 Its hexadecimal value is: 5921 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 5922 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 5923 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 5924 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 5925 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 5926 FFFFFFFF FFFFFFFF 5927 The generator is 2. 5929 Appendix C. Exchanges and Payloads 5931 This appendix contains a short summary of the IKEv2 exchanges, and 5932 what payloads can appear in which message. This appendix is purely 5933 informative; if it disagrees with the body of this document, the 5934 other text is considered correct. 5936 Vendor-ID (V) payloads may be included in any place in any message. 5937 This sequence here shows what are the most logical places for them. 5939 C.1. IKE_SA_INIT Exchange 5941 request --> [N(COOKIE)], 5942 SA, KE, Ni, 5943 [N(NAT_DETECTION_SOURCE_IP)+, 5944 N(NAT_DETECTION_DESTINATION_IP)], 5945 [V+][N+] 5947 normal response <-- SA, KE, Nr, 5948 (no cookie) [N(NAT_DETECTION_SOURCE_IP), 5949 N(NAT_DETECTION_DESTINATION_IP)], 5950 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 5951 [V+][N+] 5953 cookie response <-- N(COOKIE), 5954 [V+][N+] 5956 different D-H <-- N(INVALID_KE_PAYLOAD), 5957 group wanted [V+][N+] 5959 C.2. IKE_AUTH Exchange without EAP 5961 request --> IDi, [CERT+], 5962 [N(INITIAL_CONTACT)], 5963 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 5964 [IDr], 5965 AUTH, 5966 [CP(CFG_REQUEST)], 5967 [N(IPCOMP_SUPPORTED)+], 5968 [N(USE_TRANSPORT_MODE)], 5969 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5970 [N(NON_FIRST_FRAGMENTS_ALSO)], 5971 SA, TSi, TSr, 5972 [V+][N+] 5974 response <-- IDr, [CERT+], 5975 AUTH, 5976 [CP(CFG_REPLY)], 5977 [N(IPCOMP_SUPPORTED)], 5978 [N(USE_TRANSPORT_MODE)], 5979 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5980 [N(NON_FIRST_FRAGMENTS_ALSO)], 5981 SA, TSi, TSr, 5982 [N(ADDITIONAL_TS_POSSIBLE)], 5983 [V+][N+] 5985 error in Child SA <-- IDr, [CERT+], 5986 creation AUTH, 5987 N(error), 5988 [V+][N+] 5990 C.3. IKE_AUTH Exchange with EAP 5992 first request --> IDi, 5993 [N(INITIAL_CONTACT)], 5994 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 5995 [IDr], 5996 [CP(CFG_REQUEST)], 5997 [N(IPCOMP_SUPPORTED)+], 5998 [N(USE_TRANSPORT_MODE)], 5999 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 6000 [N(NON_FIRST_FRAGMENTS_ALSO)], 6001 SA, TSi, TSr, 6002 [V+][N+] 6004 first response <-- IDr, [CERT+], AUTH, 6005 EAP, 6006 [V+][N+] 6008 / --> EAP 6009 repeat 1..N times | 6010 \ <-- EAP 6012 last request --> AUTH 6014 last response <-- AUTH, 6015 [CP(CFG_REPLY)], 6016 [N(IPCOMP_SUPPORTED)], 6017 [N(USE_TRANSPORT_MODE)], 6018 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 6019 [N(NON_FIRST_FRAGMENTS_ALSO)], 6020 SA, TSi, TSr, 6021 [N(ADDITIONAL_TS_POSSIBLE)], 6022 [V+][N+] 6024 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying Child SAs 6026 request --> [N(REKEY_SA)], 6027 [CP(CFG_REQUEST)], 6028 [N(IPCOMP_SUPPORTED)+], 6029 [N(USE_TRANSPORT_MODE)], 6030 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 6031 [N(NON_FIRST_FRAGMENTS_ALSO)], 6032 SA, Ni, [KEi], TSi, TSr 6033 [V+][N+] 6035 normal <-- [CP(CFG_REPLY)], 6036 response [N(IPCOMP_SUPPORTED)], 6037 [N(USE_TRANSPORT_MODE)], 6038 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 6039 [N(NON_FIRST_FRAGMENTS_ALSO)], 6040 SA, Nr, [KEr], TSi, TSr, 6041 [N(ADDITIONAL_TS_POSSIBLE)] 6042 [V+][N+] 6044 error case <-- N(error) 6046 different D-H <-- N(INVALID_KE_PAYLOAD), 6047 group wanted [V+][N+] 6049 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA 6051 request --> SA, Ni, [KEi] 6052 [V+][N+] 6054 response <-- SA, Nr, [KEr] 6055 [V+][N+] 6057 C.6. INFORMATIONAL Exchange 6059 request --> [N+], 6060 [D+], 6061 [CP(CFG_REQUEST)] 6063 response <-- [N+], 6064 [D+], 6065 [CP(CFG_REPLY)] 6067 Appendix D. Significant Changes from RFC 4306 6069 This is a placeholder that will be filled in. The WG needs to decide 6070 what level of specificity is most useful here. For example, it might 6071 only be changes that involve SHOULD-level or MUST-level requirements, 6072 or it might also include additional "significant" advice that was 6073 added. 6075 Appendix E. Changes Between Internet Draft Versions 6077 This section will be removed before publication as an RFC, but should 6078 be left intact until then so that reviewers can follow what has 6079 changed. 6081 E.1. Changes from IKEv2 to draft -00 6083 There were a zillion additions from RFC 4718. These are noted with 6084 "{{ Clarif-nn }}". 6086 Cleaned up many of the figures. Made the table headings consistent. 6087 Made some tables easier to read by removing blank spaces. Removed 6088 the "reserved to IANA" and "private use" text wording and moved it 6089 into the tables. 6091 Changed many SHOULD requirements to better match RFC 2119. These are 6092 also marked with comments such as "{{ Demoted the SHOULD }}". 6094 In Section 2.16, changed the MUST requirement of authenticating the 6095 responder from "public key signature based" to "strong" because that 6096 is what most current IKEv2 implementations do, and it better matches 6097 the actual security requirement. 6099 E.2. Changes from draft -00 to draft -01 6101 The most significant technical change was to make KE optional but 6102 strongly recommended in Section 1.3.2. 6104 Updated all references to the IKEv2 Clarifications document to RFC 6105 4718. 6107 Moved a lot of the protocol description out of the long tables in 6108 Section 3.10.1 into the body of the document. These are noted with 6109 "{{ 3.10.1-nnnn }}", where "nnnn" is the notification type number. 6111 Made some table changes based on suggestions from Alfred Hoenes. 6113 Changed "byte" to "octet" in many places. 6115 Removed discussion of ESP+AH bundles in many places, and added a 6116 paragraph about it in Section 1.7. 6118 Removed the discussion of INTERNAL_ADDRESS_EXPIRY in many places, and 6119 added a paragraph about it in Section 1.7. 6121 Moved Clarif-7.10 from Section 1.2 to Section 3.2. 6123 In the figure in Section 1.3.2, made KEi optional, and added text 6124 saying "The KEi payload SHOULD be included." 6126 In the figure in Section 1.3.2, maked KEr optional, and removed text 6127 saying "KEi and KEr are required for rekeying an IKE SA." 6129 In Section 1.4, clarified that the half-closed connections being 6130 discussed are AH and ESP. 6132 Rearranged the end of Section 1.7, and added the new notation for 6133 moving text out of 3.10.1. 6135 Clarified the wording in the second paragraph of Section 2.2. This 6136 allowd the removal of the fourth paragraph, which previously had 6137 Clarif-2.2 in it. 6139 In section 2.5, removed "or later" from "version 2.0". 6141 Added the question for implementers about payload order at the end of 6142 Section 2.5. 6144 Corrected Section 2.7 based on Clarif-7-13 to say that you can't do 6145 ESP and AH at one time. 6147 In Section 2.8, clarified the wording about how to replace an IKE SA. 6149 Clarified the text in the last many paragraphs in Section 2.9. Also 6150 moved some text from near the beginning of 2.9 to the beginning of 6151 2.9.1. 6153 Removed some redundant text in Section 2.9 concerning creating a 6154 Child SA pair not in response to an arriving packet. 6156 Added the following to the end of the first paragraph of Section 6157 2.14: "The lengths of SK_d, SK_pi, and SK_pr are the key length of 6158 the agreed-to PRF." 6160 Added the restriction in Section 2.15 that all PRFs used with IKEv2 6161 MUST take variable-sized keys. 6163 In Section 2.17, removed "If multiple IPsec protocols are negotiated, 6164 keying material is taken in the order in which the protocol headers 6165 will appear in the encapsulated packet" because multiple IPsec 6166 protocols cannot be negotiated at one time. 6168 Added the material from Clarif-5.12 to Section 2.18. 6170 Changed "hash of" to "expected value of" in Section 2.23. 6172 In the bulleted list in Section 2.23, replaced "this end" with a 6173 clearer description of which system is being discussed. 6175 Added the paragraph at the beginning of Section 3 about 6176 interoperability and UNSPECIFIED values ("In the tables in this 6177 section..."). 6179 Fixed Section 3.3 to not include proposal that include both AH and 6180 ESP. Ditto for the "Proposal #" bullet in Section 3.3.1. 6182 In the description of ID_FQDN in Section 3.5, added "All characters 6183 in the ID_FQDN are ASCII; this follows that for an "internationalized 6184 domain name" as defined in [IDNA]." 6186 In Section 3.8, shortened and clarified the description of "RSA 6187 Digital Signature". 6189 In Section 3.10, shortened and clarified the description of "Protocol 6190 ID". 6192 In Section 3.15, "The requested address is valid until the expiry 6193 time defined with the INTERNAL_ADDRESS_EXPIRY attribute or there are 6194 no IKE SAs between the peers" is shortened to just "The requested 6195 address is valid until there are no IKE SAs between the peers." 6197 In Section 3.15.1, changed "INTERNAL_IP6_NBNS" to unspecified. 6199 Made [ADDRIPV6] an informative reference instead of a normative 6200 reference and updated it. 6202 Made [PKCS1] a normative reference instead of an informative 6203 reference and changed the pointer to RFC 3447. 6205 E.3. Changes from draft -00 to draft -01 6207 In Section 1.5, added "request" to first sentence to make it "If an 6208 encrypted IKE request packet arrives on port 500 or 4500 with an 6209 unrecognized SPI...". 6211 In Section 3.3, fifth paragraph, upped the number of transforms for 6212 AH and ESP by one each to account for ESN, which is now mandatory. 6214 In Section 2.1, added "or equal to" in "The responder MUST remember 6215 each response until it receives a request whose sequence number is 6216 larger than or equal to the sequence number in the response plus its 6217 window size." 6219 In Section 2.18, removed " Note that this may not work if the new IKE 6220 SA's PRF has a fixed key size because the output of the PRF may not 6221 be of the correct size." because it is no longer relevant. 6223 E.4. Changes from draft -01 to draft -02 6225 Many grammatical fixes. 6227 In Section 1.2, reworded Clarif-4.3 to be clearer. 6229 In Section 1.3.3, reworded 3.10.1-16393 and Clarif-5.4 to remove 6230 redundant text. 6232 In Section 2.13, replaced text about variable length keys with 6233 clearer explanation and requirement on non-HMAC PRFs. Also added 6234 "preferred" to Section 2.14 for the key length, and removed redundant 6235 text. 6237 In Section 2.14, removed the "half and half" description and replaced 6238 it with exceptions for RFC4434 and RFC4615. 6240 Removed the now-redundant "All PRFs used with IKEv2 MUST take 6241 variable-sized keys" from Section 2.15. 6243 In Section 2.15, added "(IKE_SA_INIT response)" after "of the second 6244 message" and "(IKE_SA_INIT request)" after "the first message". 6246 In Section 2.17, simplified because there are no more bundles. "A 6247 single Child SA negotiation may result in multiple security 6248 associations. ESP and AH SAs exist in pairs (one in each 6249 direction)." becomes "For ESP and AH, a single Child SA negotiation 6250 results in two security associations (one in each direction)." 6252 In section 3.3, made the example of combinations of algorithms and 6253 the contents of the first proposal clearer. 6255 Added Clarif-4.4 to the end of Section 3.3.2. 6257 Reordered Section 3.3.5 and added Clarif-7.11. 6259 Clarified Section 3.3.6 about choosing a single proposal. Also added 6260 second paragraph about transforms not understood, and clarified third 6261 paragraph about picking D-H groups. 6263 Moved 3.10.1-16392 from Section 3.6 to 3.7. 6265 In Section 3.10, clarified 3.10.1-16394. 6267 Updated Section 6 to indicate that there is nothing new for IANA in 6268 this spec. Also removed the definition of "Expert Review" from 6269 Section 1.6 for the same reason. 6271 In Appendix A, removed "and not commit any state to an exchange until 6272 the initiator can be cryptographically authenticated" because that 6273 was only true in an earlier version of IKEv2. 6275 E.5. Changes from draft -02 to draft -03 6277 In Section 1.3, changed "If the responder rejects the Diffie-Hellman 6278 group of the KEi payload, the responder MUST reject the request and 6279 indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD 6280 Notification payload." to "If the responder selects a proposal using 6281 a different Diffie-Hellman group (other than NONE), the responder 6282 MUST reject the request and indicate its preferred Diffie-Hellman 6283 group in the INVALID_KE_PAYLOAD Notification payload. 6285 In Section 2.3, added the last two paragraphs covering why you 6286 initiator's SPI and/or IP to differentiate if this is a "half-open" 6287 IKE SA or a new request. Also removed similar text from Section 2.2. 6289 In Section 2.5, added "Payloads sent in IKE response messages MUST 6290 NOT have the critical flag set. Note that the critical flag applies 6291 only to the payload type, not the contents. If the payload type is 6292 recognized, but the payload contains something which is not (such as 6293 an unknown transform inside an SA payload, or an unknown Notify 6294 Message Type inside a Notify payload), the critical flag is ignored." 6296 In Section 2.6, moved the text about {{ 3.10.1-16390 }} later in the 6297 section. Also reworded the text to make it clearer what the COOKIE 6298 is for. 6300 Moved text from Clarif-2.1 from Section 2.6 to Section 2.7. 6302 In Section 2.13, added "(see Section 3.3.5 for the defintion of the 6303 Key Length transform attribute)". 6305 In Section 2.17, change the description of the keying material from 6306 the list with two bullets to a clearer list. 6308 In Section 2.23, added "Implementations MUST process received UDP- 6309 encapsulated ESP packets even when no NAT was detected." 6310 In Section 3.3, changed "Each proposal may contain a" to "Each 6311 proposal contains a". 6313 Added the asterisks to the transform type table in Section 3.3.2 and 6314 the types table in 3.3.3 to foreshadow future developments. 6316 In Section 3.3.2, changed the following algorithms to (UNSPECIFIED) 6317 because the RFCs listed didn't really specify how to implement them 6318 in an interoperable fashion: 6320 Encryption Algorithms 6321 ENCR_DES_IV64 1 (RFC1827) 6322 ENCR_3IDEA 8 (RFC2451) 6323 ENCR_DES_IV32 9 6324 Pseudo-random Functions 6325 PRF_HMAC_TIGER 3 (RFC2104) 6326 Integrity Algorithms 6327 AUTH_DES_MAC 3 6328 AUTH_KPDK_MD5 4 (RFC1826) 6330 In Section 3.4, added "(other than NONE)" to the second-to-last 6331 paragraph. 6333 Rewrote the third paragraph of Section 3.14 to talk about other 6334 modes, and to clarify which encryption and integrity protection we 6335 are talking about. 6337 Changed the "Initialization Vector" bullet in Section 3.14 to specify 6338 better what is needed for the IV. Upgraded the SHOULDs to MUSTs. 6339 Also added the reference for [MODES]. 6341 In Section 5, in the second-to-last paragraph, changed "a public-key- 6342 based" to "strong" to match the wording in Section 2.16. 6344 E.6. Changes from draft -03 to draft-ietf-ipsecme-ikev2bis-00 6346 Changed the document's filename to draft-ietf-ipsecme-ikev2bis-00. 6347 Added Yoav Nir as a co-author. 6349 In many places in the document, changed "and/or" to "or" when talking 6350 about combinations of ESP and AH SAs. For example, in the intro, it 6351 said "can be used to efficiently establish SAs for Encapsulating 6352 Security Payload (ESP) and/or Authentication Header (AH)". This is 6353 changed to "or" to indicate that you can only establish one type of 6354 SA at a time. 6356 In Section 1, clarified that RFC 4306 already replaced IKEv1, and 6357 that this document replaces RFC 4306. Also fixed Section 2.5 for 6358 similar issue. Also updated the Abstract to cover this. 6360 In Section 2.15, in the responder's signed octets, changed: 6362 RestOfRespIDPayload = IDType | RESERVED | InitIDData 6363 to 6364 RestOfRespIDPayload = IDType | RESERVED | RespIDData 6366 In 2.16, changed "strong" back to "public key signature based" to 6367 make it the same as 4306. 6369 In section 3.10, added "and the field must be empty" to make it clear 6370 that a zero-length SPI is really empty. 6372 E.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to 6373 draft-ietf-ipsecme-ikev2bis-01 6375 Throughout, changed "IKE_SA" to "IKE SA", and changed "CHILD_SA" to 6376 "Child SA" (except left "CREATE_CHILD_SA" alone). 6378 Added the middle sentence in the Abstract to say what IKE actually 6379 does. 6381 Added in section 1 "(unless there is failure setting up the AH or ESP 6382 Child SA, in which case the IKE SA is still established without IPsec 6383 SA)". 6385 Clarified the titles of 1.1.1, 1.1.2, and 1.1.3. 6387 In 1.1.2, changed "If there is an inner IP header, the inner 6388 addresses will be the same as the outer addresses." because we are 6389 talking about transport mode here. 6391 Added reference to section 2.14 to setion 1.2 and 1.3. 6393 In 1.2, clarified what is and isn't encrypted in a message. 6395 Added the following to 1.2: "If the IDr proposed by the initiator is 6396 not acceptable to the responder, the responder might use some other 6397 IDr to finish the exchange. If the initiator then does not accept 6398 that fact that responder used different IDr than the one that was 6399 requested, the initiator can close the SA after noticing the fact." 6401 Moved the paragraph beginning "All messages following..." from 1.3 up 6402 to 1.2, and reworded it to apply to all the cases it covers. 6404 At the end of section 1.3.1, clarified that the responder is the one 6405 who controls whether non-first-fragments will be sent, and reworded 6406 the paragraph. 6408 In section 1.3.3, added "The Protocol ID field of the REKEY_SA 6409 notification is set to match the protocol of the SA we are rekeying, 6410 for example, 3 for ESP and 2 for AH." [Issue #10] 6412 In 1.3.2, added "of the SA payload" to "New initiator and responder 6413 SPIs are supplied in the SPI fields." 6415 In 1.3.3, fixed the art. 6417 <-- HDR, SK {SA, Nr, [KEr], 6418 Si, TSr} 6419 becomes 6420 <-- HDR, SK {SA, Nr, [KEr], 6421 TSi, TSr} 6423 In 1.4 and 2.18, changed "replaced for the purpose of rekeying" to 6424 "rekeyed". 6426 Split out the SA deletion material from section 1.4 into its own 6427 subsection, 1.4.1. 6429 Clarified which bits are set at the end of Section 1.5. 6431 In 1.7, added "That is, the version number is *not* changed from RFC 6432 4306.". 6434 In 2.1, added wording about retransmissions needing to be identical. 6436 In 2.2, added "or rekeyed" to "In the unlikely event that Message IDs 6437 grow too large to fit in 32 bits, the IKE SA MUST be closed" 6439 In 2.2, moved the sentence "Rekeying an IKE SA resets the sequence 6440 numbers." up higher so it would be more likely to be seen. [Issue 6441 #15] 6443 Moved the definition of "original initiator" from 2.8 into 2.2 6444 because that is where it is first used. 6446 In 2.4, added "fresh (i.e., not retransmitted)" to "If a 6447 cryptographically protected message has been received from the other 6448 side recently". Also added the sentence saying that liveness checks 6449 are sometimes call dead peer detection. 6451 Removed the question to implementers about payload order in 2.5. 6453 Changed the title of 2.6 to "IKE SA SPIs and Cookies". Also, in the 6454 paragraph that describes how to implement the responder, changed the 6455 lower-case "should" to "can" to emphasize that this is a choice. 6457 Added the second paragraph in 2.6 to make it clear that the SPI is 6458 used for mapping. 6460 In section 2.6, upgraded "needs to choose them so as to be unique 6461 identifiers of an IKE_SA" to a MUST. 6463 Added sentences at the end of 2.6 eplaining wny the initiator should 6464 limit the number of responses it sends out. 6466 In 2.6.1, added the example of the shorter exchange; this is copied 6467 from RFC 4718 but was dropped in early drafts of this document. 6469 Added the paragraph to 2.7 that describes needing two proposals if 6470 you are having both normal ciphers and combined-mode ciphers. [Issue 6471 #20]. 6473 In section 2.8, added "Note that, when rekeying, the new Child SA MAY 6474 have different traffic selectors and algorithms than the old one." 6476 Added a note in 2.9 that PFKEY applies only to IKEv1. Also added 6477 that unknown traffic selector types are not returned in narrowed 6478 responses. 6480 Added note in the first paragraph of Setion 2.9.1 about decorrelated 6481 policies preventing the problem mentioned. 6483 In 2.12, removed "In particular, it MUST forget the secrets used in 6484 the Diffie-Hellman calculation and any state that may persist in the 6485 state of a pseudo-random number generator that could be used to 6486 recompute the Diffie-Hellman secrets." 6488 In 2.15, noted that the retry could happen multiple times for 6489 different reasons. 6491 In section 2.16, changed "This shared key generated during an IKE 6492 exchange" to "This key". 6494 At the end of 2.19, added statement that FAILED_CP_REQUIRED is not 6495 fatal to the IKE SA. 6497 Added the reference to ROHCV2 to the end of 2.22. 6499 In 2.23, changed "can negotiate" to "will use". for UDP 6500 encapsulation. Added "or 4500" to "...MUST be sent from and to UDP 6501 port 500". Also removed the text about why not to do NAT-traversal 6502 over port 500 because we later say you can't do that anyway. [Issue 6503 #27] Also removed the last paragraph, which obliquely pointed to 6504 MOBIKE. More will be added later on MOBIKE. 6506 In 3.1, removed "and orderings of messages" from "Exchange type". 6507 [Issue #29] 6509 In 3.1, added "This bit changes to reflect who initiated the last 6510 rekey of the IKE SA." to the description of the Initiator bit. 6512 In 3.3, added a long example of why you might use a Proposal 6513 structure because of combined-mode algorithms. [Issue #42] 6515 In 3.3.2, changed "is unnecessary because the last Proposal could be 6516 identified from the length of the SA" to "is unnecessary because the 6517 last transform could be identified from the length of the proposal." 6519 Added reference to AEAD to 3.3.2 and 3.3.3. 6521 Added the reference to RFC 2104 back for PRF_HMAC_TIGER in 3.3.2. 6522 [Issue #33] 6524 Added note at the bottom of 3.3.2 to see the IANA registry. 6526 In 3.3.4, removed all the "this could happen in the future" stuff 6527 because it already happened. 6529 Added a reference to email address internationalization to 3.5, 6530 making the address binary (not ASCII). 6532 In the table in 3.6, made "Authority Revocation List (ARL) 8" and 6533 "X.509 Certificate - Attribute 10" unspecified. 6535 In 3.7, changed the last sentence of the first paragraph to eliminate 6536 the non-protocol SHOULD. 6538 In 3.13.1, added "(including protocol 0)" for the start port and end 6539 port. 6541 In 3.14, updated the discussion of initialization modes to reflect 6542 that it is only about CBC, and that other specs have to specify their 6543 own IVs. 6545 In 3.15.1, added a pointer to 3.15.3. In the entries for 6546 INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET, added a pointer to 6547 3.15.2. 6549 In 3.15.4, added "The IKE SA is still created even if the initial 6550 Child SA cannot be created because of this failure." 6552 Changed "EAP exchange" to "EAP authentication" in 5. 6554 Removed "In particular, these exponents MUST NOT be derived from 6555 long-lived secrets like the seed to a pseudo-random generator that is 6556 not erased after use." from section 5 because it is not possible in 6557 most implementations to do so. 6559 Updated a bunch of reference to their newer versions. 6561 Added "[V+]" to the end of the exchanges in C.4 and C.5. 6563 Added two more response templates to Appendix C.1. Added another 6564 response template in Appendix C.2. Added two more responses in 6565 Appendix C.4. 6567 E.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to 6568 draft-ietf-ipsecme-ikev2bis-02 6570 In section 1.3.1, added "Failure of an attempt to create a CHILD SA 6571 SHOULD NOT tear down the IKE SA: there is no reason to lose the work 6572 done to set up the IKE SA. When an IKE SA is not created, the error 6573 message return SHOULD NOT be encrypted because the other party will 6574 not be able to authenticate that message." This may be changed again 6575 in the future. [Issue #9] 6577 In section 1.3.2, changed "The KEi payload SHOULD be included" to be 6578 "The KEi payload MUST be included". This also lead to changes in 6579 section 2.18. The square brackets around "g^ir (new)" in the 6580 SKEYSEED calculation are eliminated, and the requirement language in 6581 the paragraph starting "The main rekeying" is changed from SHOULD to 6582 MUST. [Issue #50] 6584 In section 1.3.2, changed "The window size starts at 1 for any new 6585 IKE SA." to "The first IKE requests from both sides on the new IKE SA 6586 will have message ID 0. The old IKE SA retains its numbering, so any 6587 further requests (for example, to delete the IKE SA) will have 6588 consecutive numbering. The new IKE SA also has its window size reset 6589 to 1, and the initiator in this rekey exchange is the new "original 6590 initiator" of the new IKE SA." [Issue #65] 6592 Added to section 1.5: For a one-way INVALID_IKE_SPI notification for 6593 an unrecognized SPI, the responder SHOULD copy the Exchange Type from 6594 the request. [Issue #46] 6596 In 2.1, at the end of the paragraph about retransmission timers, 6597 added "In order to allow saving memory, responders are allowed to 6598 forget response after a timeout of several minutes. If the responder 6599 receives a retransmitted request for which it has already forgotten 6600 the response, it MUST ignore the request (and not, for example, 6601 attempt constructing a new response)." [Issue #14] 6603 In 2.6, added: "Also, incorporating Ni in the hash prevents an 6604 attacker from fetching one one cookie from the other end, and then 6605 initiating many IKE_SA_INIT exchanges all with different initiator 6606 SPIs (and perhaps port numbers) so that the responder thinks that 6607 there are lots of machines behind one NAT box who are all trying to 6608 connect." [Issue #19] 6610 Added text for the new 2.8.2, and bumped the section number of the 6611 old 2.8.2 to 2.8.3. [Issue #22] 6613 Added a reference to the end of 2.12 on key reuse. 6615 Added to the end of the first paragraph in 2.19: Note, however, it is 6616 usual to only assign one IP address during the IKE_AUTH exchange. 6617 That address persists at least until the deletion of the IKE SA. 6618 [Issue #79] 6620 Added the following to 2.23: An initiator can float to port 4500, 6621 regardless whether or not there is NAT, even at the beginning of IKE. 6622 When either side is using port 4500, sending with UDP encapsulation 6623 is not required, but understanding received packets with UDP 6624 encapsulation is required. UDP encapsulation MUST NOT be done on 6625 port 500. If NAT-T is supported (that is, if NAT_DETECTION_*_IP 6626 payloads were exchanged during IKE_SA_INIT), all devices MUST be able 6627 to receive and process both UDP encapsulated and non-UDP encapsulated 6628 packets at any time. Either side can decide whether or not to use 6629 UDP encapsulation irrespective of the choice made by the other side. 6630 However, if a NAT is detected, both devices MUST send UDP 6631 encapsulated packets. [Issue #40] 6633 The second-to-last paragraph in section 3.4 is changed to: The DH 6634 Group # identifies the Diffie-Hellman group in which the Key Exchange 6635 Data was computed (see Section 3.3.2. This Group # MUST match a DH 6636 Group specified in a proposal in the SA payload that is sent in the 6637 same message, and SHOULD match the DH group in the first group in the 6638 first proposal, if such exists. If none of the proposals in that SA 6639 payload specifies a DH Group, the KE payload MUST NOT be present. If 6640 the selected proposal uses a different Diffie-Hellman group (other 6641 than NONE), the message MUST be rejected with a Notify payload of 6642 type INVALID_KE_PAYLOAD. [Issue #30] 6644 In 3.10.1, changed the definition of NO_PROPOSAL_CHOSEN, 14, to: None 6645 of the proposed crypto suites was acceptable. This can be sent in 6646 any case where the offered proposal (including but not limited to SA 6647 payload values, USE_TRANSPORT_MODE notify, IPCOMP_SUPPORTED notify) 6648 are not acceptable for the responder. This can also be used as 6649 "generic" Child SA error when Child SA cannot be created for some 6650 other reason. See also Section 2.7. [Issue #81] 6652 In the description of IVs in 3.14, reorganized the text a bit to 6653 emphasize when we are and are not talking about CBC. [Issue #68] 6655 Added the following to section 5 (Security Considerations): "The 6656 IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator has 6657 been authenticated. As a result, an implementation of this protocol 6658 needs to be completely robust when deployed on any insecure network. 6659 Implementation vulnerabilities, particularly denial-of-service 6660 attacks, can be exploited by unauthenticated peers. This issue is 6661 particularly worrisome because of the unlimited number of messages in 6662 EAP-based authentication." [Issue #62] 6664 Added new Appendix D, "Significant Changes from RFC 4306", as a 6665 placeholder for now. [Issue #3] 6667 E.9. Changes from draft-ietf-ipsecme-ikev2bis-01 to 6668 draft-ietf-ipsecme-ikev2bis-02 6670 Near the end of 1.3, changed "If the guess turns out to be wrong, the 6671 responder will indicate the correct group in the response and the 6672 initiator SHOULD pick an element of that group for its KE value when 6673 retrying the first message." to "If the responder selects a proposal 6674 using a different Diffie-Hellman group (other than NONE), the 6675 responder will indicate the correct group in the response and the 6676 initiator SHOULD pick an element of that group for its KE value when 6677 retrying the first message." [Issue #6] 6679 In the figures in 1.3.2, changed the diagrams from "HDR, SK {SA, Ni, 6680 [KEi]}" to "HDR, SK {SA, Ni, KEi}", and "HDR, SK {SA, Nr,[KEr]}" to 6681 "HDR, SK {SA, Nr,KEr}". This matches the text in the section, which 6682 was updated in the last revision. [Issue #50] 6684 Reorganized the beginning of section 2.3 and clarified some of the 6685 logic. [Issue #52] 6687 Clarified the octets to be signed in setion 2.15. Changed 6689 AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), ) 6691 to 6692 For the initiator: 6693 AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"), 6694 ) 6695 For the responder: 6696 AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"), 6697 ) 6699 [Issue #72] 6701 Changed the last bullet item in section 2.23 to discuss MOBIKE in 6702 more detail. [Issue #41] 6704 In section 3.1, the bullet about bit 4, changed "must" to "MUST". 6706 In section 3.3.6, added two sentences at the end of the second 6707 paragraph to indicate that there is an exception for when the 6708 proposal is a DH group of NONE. [Issue #6] 6710 E.10. Changes from draft-ietf-ipsecme-ikev2bis-02 to 6711 draft-ietf-ipsecme-ikev2bis-03 6713 In section 2.4, change "The INITIAL_CONTACT notification, if sent, 6714 MUST be in the first IKE_AUTH request, not as a separate exchange 6715 afterwards; however, receiving parties need to deal with it in other 6716 requests." to "The INITIAL_CONTACT notification, if sent, MUST be in 6717 the first IKE_AUTH request or response, not as a separate exchange 6718 afterwards; however, receiving parties MAY ignore it in other 6719 messages." [Issue #53] 6721 Added to the security considerations: "Admission control is critical 6722 to the security of the protocol. For example, trust anchors used for 6723 identifying IKE peers should probably be different than those used 6724 for other forms of trust, such as those used to identify public web 6725 servers. Moreover, although IKE provides a great deal of leeway in 6726 defining the security policy for a trusted peer's identity, 6727 credentials, and the correlation between them, having such security 6728 policy defined explicitly is essential to a secure implementation." 6729 [Issue #61] 6731 Changed "[V+]" to "[V+][N+]" throughout Appendix C. [Issue #63] 6733 E.11. Changes from draft-ietf-ipsecme-ikev2bis-03 to 6734 draft-ietf-ipsecme-ikev2bis-04 6736 Throughout, removed the marks that showed where text from the 6737 Clarifications RFC was inserted, or where a "SHOULD" was demoted to 6738 weaker language. 6740 In section 1, added "IKEv2 was a change to the IKE protocol that was 6741 not backward compatible. In contrast, the current document not only 6742 provides a clarification of IKEv2, but makes minimum changes to the 6743 IKE protocol." [Issue #48] 6745 In 1.5, added "The recipient of this notification cannot tell whether 6746 the SPI is for AH or ESP, but this is not important because the SPIs 6747 are supposed to be different for the two." [Issue #35] 6749 In 1.5, added "(INVALID_MAJOR_VERSION is also a one-way message which 6750 is sent outside of an IKE SA, although it is sent as a response to 6751 the incoming IKE SA creation.)" [Issue #13] 6753 Added "The Message ID is reset to zero in the new IKE SA after the 6754 IKE SA is rekeyed" in the first paragraph of 2.2. [Issue #15] 6756 In 2.5, changed "implementations MUST send the payloads defined in 6757 this specification in the order shown in the figures in Section 2; 6758 implementations are explicitly allowed to reject as invalid a message 6759 with those payloads in any other order" to "implementations SHOULD 6760 send the payloads defined in this specification in the order shown in 6761 the figures in Section 2; implementations MUST NOT reject as invalid 6762 a message with those payloads in any other order". [Issue #16] 6763 [Issue #45] 6765 In 2.9, added "Maintenance of a system's SPD is outside the scope of 6766 IKE (see [PFKEY] for an example programming interface, although it 6767 only applies to IKEv1), though some implementations might update 6768 their SPD in connection with the running of IKE (for an example 6769 scenario, see Section 1.1.3)." This was actually done in -03 but not 6770 noted in the change notes. [Issue #64] [Issue #54] 6772 In 2.18, added "using SPIi, SPIr, Ni, and Nr from the new exchange" 6773 to the last sentence. 6775 Removed INTERNAL_IP6_NBNS from 3.15.1. [Issue #44] 6777 Changed "The requested address is valid until there are no IKE_SAs 6778 between the peers" to "The requested address is valid as long as this 6779 IKE SA (or its rekeyed successors) requesting the address is valid." 6780 [Issue #43] 6782 E.12. Changes from draft-ietf-ipsecme-ikev2bis-04 to 6783 draft-ietf-ipsecme-ikev2bis-05 6785 Added the following near the end of 1.2: "If the failure is related 6786 to creating the IKE SA (for example, AUTHENTICATION_FAILED), the IKE 6787 SA is not created. Note that although the IKE_AUTH messages are 6788 encrypted and integrity protected, if the peer receiving this 6789 notification has not yet authenticated the other end (or if the peer 6790 fails to authenticate the other end for some reason), the information 6791 needs to be treated with caution. More precisely, assuming that the 6792 MAC verifies correctly, the sender of the error indication is known 6793 to be the responder of the IKE_SA_INIT exchange, but the sender's 6794 identity cannot be assured." [Issue #9] 6796 Added "Section 2.21 also covers error messages in great detail" near 6797 the beginning of 1.4. 6799 Added "Section 2.21 has been greatly expanded to cover the different 6800 cases where error responses are needed and the appropriate responses 6801 to them" to the end of 1.7. 6803 In 1.5, changed "There are two cases when such a one-way 6804 notification" to "There are two cases when a one-way notification". 6805 Also changed "notification" to "message" throughout this paragraph. 6807 In 2.8, changed "Note that, when rekeying, the new Child SA MAY have 6808 different traffic selectors and algorithms than the old one." to 6809 "Note that, when rekeying, the new Child SA SHOULD NOT have different 6810 traffic selectors and algorithms than the old one.". [Issue #12] 6812 Section 2.21 was replaced and significantly expanded to cover many 6813 different error situations. [Issue #26] 6815 Added 2.23.1, which covers how to handle NAT traversal when transport 6816 mode is requested. [Issue #28] 6818 In 3.3.2, after the table for tranform type 4, added "Although ESP 6819 and AH do not directly include a Diffie-Hellman exchange, a Diffie- 6820 Hellman group MAY be negotiated for the Child SA. This allows the 6821 peers to employ Diffie-Hellman in the CREATE_CHILD_SA exchange, 6822 providing perfect forward secrecy for the generated Child SA keys." 6823 [Issue #57] 6825 In 3.5, added "The Peer Authorization Database (PAD) as described in 6826 RFC 4301 [IPSECARCH] describes the use of the ID payload in IKEv2 and 6827 provides a formal model for the binding of identity to policy in 6828 addition to providing services that deal more specifically with the 6829 details of policy enforcement. The PAD is intended to provide a link 6830 between the SPD and the IKE security association management. See 6831 Section 4.4.3 of RFC 4301 for more details." [Issue #58] 6833 Added to the definition of "X.509 Certificate" in 3.6: "Note that 6834 with this encoding, if a chain of certificates needs to be sent, 6835 multiple CERT payloads are used, only the first of which holds the 6836 public key used to validate the sender's AUTH payload." [Issue 6837 #107]. 6839 In 3.14, added "When an authenticated encryption algorithm is used to 6840 protect the IKE SA, the construction of the encrypted payload is 6841 different that what is described here. See [RFC5282] for more 6842 information on authenticated encryption algorithms and their use in 6843 ESP." 6845 Added the last two paragraphs of 3.15 (on CFG_REQUEST and CFG_REPLY, 6846 and CFG_SET and CFG_ACK). Removed all of 2.19.1 which contained the 6847 same material and a lot of material that was duplicated from other 6848 parts of the document. [Issue #108] 6850 Added the following to 3.15.3: "Note that there is an additional 6851 document that discusses IPv6 configuration in IKEv2, [IPV6CONFIG]. 6852 At the present time, it is an experimental document, but there is a 6853 hope that with more implementation experience, it will gain the same 6854 standards treatment as this document." [Issue #47 and Issue #60] 6856 Reworded the acknowledgements to be more inclusive. 6858 Authors' Addresses 6860 Charlie Kaufman 6861 Microsoft 6862 1 Microsoft Way 6863 Redmond, WA 98052 6864 US 6866 Phone: 1-425-707-3335 6867 Email: charliek@microsoft.com 6869 Paul Hoffman 6870 VPN Consortium 6871 127 Segre Place 6872 Santa Cruz, CA 95060 6873 US 6875 Phone: 1-831-426-9827 6876 Email: paul.hoffman@vpnc.org 6877 Yoav Nir 6878 Check Point Software Technologies Ltd. 6879 5 Hasolelim St. 6880 Tel Aviv 67897 6881 Israel 6883 Email: ynir@checkpoint.com 6885 Pasi Eronen 6886 Nokia Research Center 6887 P.O. Box 407 6888 FIN-00045 Nokia Group 6889 Finland 6891 Email: pasi.eronen@nokia.com