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