idnits 2.17.1 draft-ietf-ipsecme-ikev2bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 6238. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 6249. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 6256. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 6262. 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 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 30, 2008) is 5650 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 2161, but not defined == Missing Reference: 'KEi' is mentioned on line 5681, but not defined == Missing Reference: 'KEr' is mentioned on line 6041, but not defined == Missing Reference: 'CP' is mentioned on line 715, but not defined -- Looks like a reference, but probably isn't: '0' on line 3732 -- Looks like a reference, but probably isn't: '1' on line 3733 == Missing Reference: 'IDr' is mentioned on line 5625, 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 (==), 26 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: May 3, 2009 Check Point 8 P. Eronen 9 Nokia 10 October 30, 2008 12 Internet Key Exchange Protocol: IKEv2 13 draft-ietf-ipsecme-ikev2bis-01 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on May 3, 2009. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 This document describes version 2 of the Internet Key Exchange (IKE) 47 protocol. IKE is a component of IPsec used for performing mutual 48 authentication and establishing and maintaining security associations 49 (SAs). It replaces and updates RFC 4306, and includes all of the 50 clarifications from RFC 4718. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 55 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6 56 1.1.1. Security Gateway to Security Gateway Tunnel Mode . . 6 57 1.1.2. Endpoint-to-Endpoint Transport Mode . . . . . . . . . 7 58 1.1.3. Endpoint to Security Gateway Tunnel Mode . . . . . . 8 59 1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 8 60 1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 9 61 1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 12 62 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA 63 Exchange . . . . . . . . . . . . . . . . . . . . . . 13 64 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange . 14 65 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA 66 Exchange . . . . . . . . . . . . . . . . . . . . . . 15 67 1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 16 68 1.4.1. Deleting an SA with INFORMATIONAL Exchanges . . . . . 16 69 1.5. Informational Messages outside of an IKE SA . . . . . . . 17 70 1.6. Requirements Terminology . . . . . . . . . . . . . . . . 18 71 1.7. Differences Between RFC 4306 and This Document . . . . . 18 72 2. IKE Protocol Details and Variations . . . . . . . . . . . . . 20 73 2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 21 74 2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 22 75 2.3. Window Size for Overlapping Requests . . . . . . . . . . 22 76 2.4. State Synchronization and Connection Timeouts . . . . . . 24 77 2.5. Version Numbers and Forward Compatibility . . . . . . . . 26 78 2.6. IKE SA SPIs and Cookies . . . . . . . . . . . . . . . . . 28 79 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 30 80 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 31 81 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 32 82 2.8.1. Simultaneous Child SA rekeying . . . . . . . . . . . 34 83 2.8.2. Rekeying the IKE SA Versus Reauthentication . . . . . 36 84 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 37 85 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 40 86 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 40 87 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 41 88 2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 41 89 2.13. Generating Keying Material . . . . . . . . . . . . . . . 42 90 2.14. Generating Keying Material for the IKE SA . . . . . . . . 43 91 2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 44 92 2.16. Extensible Authentication Protocol Methods . . . . . . . 46 93 2.17. Generating Keying Material for Child SAs . . . . . . . . 48 94 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . . 49 95 2.19. Requesting an Internal Address on a Remote Network . . . 50 96 2.19.1. Configuration Payloads . . . . . . . . . . . . . . . 51 97 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 53 98 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 53 99 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 54 100 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 55 101 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 59 102 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 59 103 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 59 104 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 62 105 3.3. Security Association Payload . . . . . . . . . . . . . . 64 106 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 66 107 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 68 108 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 71 109 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 71 110 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 72 111 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 74 112 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 75 113 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 75 114 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 78 115 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 80 116 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 82 117 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 83 118 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 84 119 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 85 120 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 88 121 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 90 122 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 91 123 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 92 124 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 94 125 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 96 126 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 97 127 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 100 128 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 102 129 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 103 130 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 103 131 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 105 132 5. Security Considerations . . . . . . . . . . . . . . . . . . . 107 133 5.1. Traffic selector authorization . . . . . . . . . . . . . 109 134 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 111 135 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 111 136 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 111 137 8.1. Normative References . . . . . . . . . . . . . . . . . . 111 138 8.2. Informative References . . . . . . . . . . . . . . . . . 113 139 Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 117 140 Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 118 141 B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 118 142 B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 118 143 Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 119 144 C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 119 145 C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 120 146 C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 121 147 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying 148 Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 122 149 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 122 150 C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 122 151 Appendix D. Changes Between Internet Draft Versions . . . . . . 122 152 D.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 123 153 D.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 123 154 D.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 125 155 D.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 126 156 D.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 127 157 D.6. Changes from draft -03 to 158 draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 128 159 D.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to 160 draft-ietf-ipsecme-ikev2bis-01 . . . . . . . . . . . . . 129 161 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 133 162 Intellectual Property and Copyright Statements . . . . . . . . . 134 164 1. Introduction 166 {{ An introduction to the differences between RFC 4306 [IKEV2] and 167 this document is given at the end of Section 1. It is put there 168 (instead of here) to preserve the section numbering of RFC 4306. }} 170 IP Security (IPsec) provides confidentiality, data integrity, access 171 control, and data source authentication to IP datagrams. These 172 services are provided by maintaining shared state between the source 173 and the sink of an IP datagram. This state defines, among other 174 things, the specific services provided to the datagram, which 175 cryptographic algorithms will be used to provide the services, and 176 the keys used as input to the cryptographic algorithms. 178 Establishing this shared state in a manual fashion does not scale 179 well. Therefore, a protocol to establish this state dynamically is 180 needed. This memo describes such a protocol -- the Internet Key 181 Exchange (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI], 182 2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 replaced all of those RFCs. 183 IKEv2 was defined in [IKEV2] (RFC 4306) and was clarified in [Clarif] 184 (RFC 4718). This document replaces and updates RFC 4306 and RFC 185 4718. 187 IKE performs mutual authentication between two parties and 188 establishes an IKE security association (SA) that includes shared 189 secret information that can be used to efficiently establish SAs for 190 Encapsulating Security Payload (ESP) [ESP] or Authentication Header 191 (AH) [AH] and a set of cryptographic algorithms to be used by the SAs 192 to protect the traffic that they carry. In this document, the term 193 "suite" or "cryptographic suite" refers to a complete set of 194 algorithms used to protect an SA. An initiator proposes one or more 195 suites by listing supported algorithms that can be combined into 196 suites in a mix-and-match fashion. IKE can also negotiate use of IP 197 Compression (IPComp) [IP-COMP] in connection with an ESP or AH SA. 198 The SAs for ESP or AH that get set up through that IKE SA we call 199 "Child SAs". 201 All IKE communications consist of pairs of messages: a request and a 202 response. The pair is called an "exchange". We call the first 203 messages establishing an IKE SA IKE_SA_INIT and IKE_AUTH exchanges 204 and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL 205 exchanges. In the common case, there is a single IKE_SA_INIT 206 exchange and a single IKE_AUTH exchange (a total of four messages) to 207 establish the IKE SA and the first Child SA. In exceptional cases, 208 there may be more than one of each of these exchanges. In all cases, 209 all IKE_SA_INIT exchanges MUST complete before any other exchange 210 type, then all IKE_AUTH exchanges MUST complete, and following that 211 any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur 212 in any order. In some scenarios, only a single Child SA is needed 213 between the IPsec endpoints, and therefore there would be no 214 additional exchanges. Subsequent exchanges MAY be used to establish 215 additional Child SAs between the same authenticated pair of endpoints 216 and to perform housekeeping functions. 218 IKE message flow always consists of a request followed by a response. 219 It is the responsibility of the requester to ensure reliability. If 220 the response is not received within a timeout interval, the requester 221 needs to retransmit the request (or abandon the connection). 223 The first request/response of an IKE session (IKE_SA_INIT) negotiates 224 security parameters for the IKE SA, sends nonces, and sends Diffie- 225 Hellman values. 227 The second request/response (IKE_AUTH) transmits identities, proves 228 knowledge of the secrets corresponding to the two identities, and 229 sets up an SA for the first (and often only) AH or ESP Child SA 230 (unless there is failure setting up the AH or ESP Child SA, in which 231 case the IKE SA is still established without IPsec SA). 233 The types of subsequent exchanges are CREATE_CHILD_SA (which creates 234 a Child SA) and INFORMATIONAL (which deletes an SA, reports error 235 conditions, or does other housekeeping). Every request requires a 236 response. An INFORMATIONAL request with no payloads (other than the 237 empty Encrypted payload required by the syntax) is commonly used as a 238 check for liveness. These subsequent exchanges cannot be used until 239 the initial exchanges have completed. 241 In the description that follows, we assume that no errors occur. 242 Modifications to the flow should errors occur are described in 243 Section 2.21. 245 1.1. Usage Scenarios 247 IKE is expected to be used to negotiate ESP or AH SAs in a number of 248 different scenarios, each with its own special requirements. 250 1.1.1. Security Gateway to Security Gateway Tunnel Mode 252 +-+-+-+-+-+ +-+-+-+-+-+ 253 | | IPsec | | 254 Protected |Tunnel | tunnel |Tunnel | Protected 255 Subnet <-->|Endpoint |<---------->|Endpoint |<--> Subnet 256 | | | | 257 +-+-+-+-+-+ +-+-+-+-+-+ 259 Figure 1: Security Gateway to Security Gateway Tunnel 261 In this scenario, neither endpoint of the IP connection implements 262 IPsec, but network nodes between them protect traffic for part of the 263 way. Protection is transparent to the endpoints, and depends on 264 ordinary routing to send packets through the tunnel endpoints for 265 processing. Each endpoint would announce the set of addresses 266 "behind" it, and packets would be sent in tunnel mode where the inner 267 IP header would contain the IP addresses of the actual endpoints. 269 1.1.2. Endpoint-to-Endpoint Transport Mode 271 +-+-+-+-+-+ +-+-+-+-+-+ 272 | | IPsec transport | | 273 |Protected| or tunnel mode SA |Protected| 274 |Endpoint |<---------------------------------------->|Endpoint | 275 | | | | 276 +-+-+-+-+-+ +-+-+-+-+-+ 278 Figure 2: Endpoint to Endpoint 280 In this scenario, both endpoints of the IP connection implement 281 IPsec, as required of hosts in [IPSECARCH]. Transport mode will 282 commonly be used with no inner IP header. A single pair of addresses 283 will be negotiated for packets to be protected by this SA. These 284 endpoints MAY implement application layer access controls based on 285 the IPsec authenticated identities of the participants. This 286 scenario enables the end-to-end security that has been a guiding 287 principle for the Internet since [ARCHPRINC], [TRANSPARENCY], and a 288 method of limiting the inherent problems with complexity in networks 289 noted by [ARCHGUIDEPHIL]. Although this scenario may not be fully 290 applicable to the IPv4 Internet, it has been deployed successfully in 291 specific scenarios within intranets using IKEv1. It should be more 292 broadly enabled during the transition to IPv6 and with the adoption 293 of IKEv2. 295 It is possible in this scenario that one or both of the protected 296 endpoints will be behind a network address translation (NAT) node, in 297 which case the tunneled packets will have to be UDP encapsulated so 298 that port numbers in the UDP headers can be used to identify 299 individual endpoints "behind" the NAT (see Section 2.23). 301 1.1.3. Endpoint to Security Gateway Tunnel Mode 303 +-+-+-+-+-+ +-+-+-+-+-+ 304 | | IPsec | | Protected 305 |Protected| tunnel |Tunnel | Subnet 306 |Endpoint |<------------------------>|Endpoint |<--- and/or 307 | | | | Internet 308 +-+-+-+-+-+ +-+-+-+-+-+ 310 Figure 3: Endpoint to Security Gateway Tunnel 312 In this scenario, a protected endpoint (typically a portable roaming 313 computer) connects back to its corporate network through an IPsec- 314 protected tunnel. It might use this tunnel only to access 315 information on the corporate network, or it might tunnel all of its 316 traffic back through the corporate network in order to take advantage 317 of protection provided by a corporate firewall against Internet-based 318 attacks. In either case, the protected endpoint will want an IP 319 address associated with the security gateway so that packets returned 320 to it will go to the security gateway and be tunneled back. This IP 321 address may be static or may be dynamically allocated by the security 322 gateway. {{ Clarif-6.1 }} In support of the latter case, IKEv2 323 includes a mechanism (namely, configuration payloads) for the 324 initiator to request an IP address owned by the security gateway for 325 use for the duration of its SA. 327 In this scenario, packets will use tunnel mode. On each packet from 328 the protected endpoint, the outer IP header will contain the source 329 IP address associated with its current location (i.e., the address 330 that will get traffic routed to the endpoint directly), while the 331 inner IP header will contain the source IP address assigned by the 332 security gateway (i.e., the address that will get traffic routed to 333 the security gateway for forwarding to the endpoint). The outer 334 destination address will always be that of the security gateway, 335 while the inner destination address will be the ultimate destination 336 for the packet. 338 In this scenario, it is possible that the protected endpoint will be 339 behind a NAT. In that case, the IP address as seen by the security 340 gateway will not be the same as the IP address sent by the protected 341 endpoint, and packets will have to be UDP encapsulated in order to be 342 routed properly. 344 1.1.4. Other Scenarios 346 Other scenarios are possible, as are nested combinations of the 347 above. One notable example combines aspects of 1.1.1 and 1.1.3. A 348 subnet may make all external accesses through a remote security 349 gateway using an IPsec tunnel, where the addresses on the subnet are 350 routed to the security gateway by the rest of the Internet. An 351 example would be someone's home network being virtually on the 352 Internet with static IP addresses even though connectivity is 353 provided by an ISP that assigns a single dynamically assigned IP 354 address to the user's security gateway (where the static IP addresses 355 and an IPsec relay are provided by a third party located elsewhere). 357 1.2. The Initial Exchanges 359 Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH 360 exchanges (known in IKEv1 as Phase 1). These initial exchanges 361 normally consist of four messages, though in some scenarios that 362 number can grow. All communications using IKE consist of request/ 363 response pairs. We'll describe the base exchange first, followed by 364 variations. The first pair of messages (IKE_SA_INIT) negotiate 365 cryptographic algorithms, exchange nonces, and do a Diffie-Hellman 366 exchange [DH]. 368 The second pair of messages (IKE_AUTH) authenticate the previous 369 messages, exchange identities and certificates, and establish the 370 first Child SA. Parts of these messages are encrypted and integrity 371 protected with keys established through the IKE_SA_INIT exchange, so 372 the identities are hidden from eavesdroppers and all fields in all 373 the messages are authenticated. (See Section 2.14 for information on 374 how the encyrption keys are generated.) 376 All messages following the initial exchange are cryptographically 377 protected using the cryptographic algorithms and keys negotiated in 378 the the IKE_SA_INIT exchange. These subsequent messages use the 379 syntax of the Encrypted Payload described in Section 3.14, encrypted 380 with keys that are derived as described in Section 2.14. All 381 subsequent messages include an Encrypted Payload, even if they are 382 referred to in the text as "empty". For the CREATE_CHILD_SA, 383 IKE_AUTH, or IKE_INFORMATIONAL exchanges, the message following the 384 header is encrypted and the message including the header is integrity 385 protected using the cryptographic algorithms negotiated for the IKE 386 SA. 388 In the following descriptions, the payloads contained in the message 389 are indicated by names as listed below. 391 Notation Payload 392 ----------------------------------------- 393 AUTH Authentication 394 CERT Certificate 395 CERTREQ Certificate Request 396 CP Configuration 397 D Delete 398 E Encrypted 399 EAP Extensible Authentication 400 HDR IKE Header 401 IDi Identification - Initiator 402 IDr Identification - Responder 403 KE Key Exchange 404 Ni, Nr Nonce 405 N Notify 406 SA Security Association 407 TSi Traffic Selector - Initiator 408 TSr Traffic Selector - Responder 409 V Vendor ID 411 The details of the contents of each payload are described in section 412 3. Payloads that may optionally appear will be shown in brackets, 413 such as [CERTREQ], indicate that optionally a certificate request 414 payload can be included. 416 The initial exchanges are as follows: 418 Initiator Responder 419 ------------------------------------------------------------------- 420 HDR, SAi1, KEi, Ni --> 422 HDR contains the Security Parameter Indexes (SPIs), version numbers, 423 and flags of various sorts. The SAi1 payload states the 424 cryptographic algorithms the initiator supports for the IKE SA. The 425 KE payload sends the initiator's Diffie-Hellman value. Ni is the 426 initiator's nonce. 428 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 430 The responder chooses a cryptographic suite from the initiator's 431 offered choices and expresses that choice in the SAr1 payload, 432 completes the Diffie-Hellman exchange with the KEr payload, and sends 433 its nonce in the Nr payload. 435 At this point in the negotiation, each party can generate SKEYSEED, 436 from which all keys are derived for that IKE SA. The messages that 437 follow are encrypted and integrity protected in their entirety, with 438 the exception of the message headers. The keys used for the 439 encryption and integrity protection are derived from SKEYSEED and are 440 known as SK_e (encryption) and SK_a (authentication, a.k.a. integrity 441 protection). A separate SK_e and SK_a is computed for each 442 direction. In addition to the keys SK_e and SK_a derived from the DH 443 value for protection of the IKE SA, another quantity SK_d is derived 444 and used for derivation of further keying material for Child SAs. 445 The notation SK { ... } indicates that these payloads are encrypted 446 and integrity protected using that direction's SK_e and SK_a. 448 HDR, SK {IDi, [CERT,] [CERTREQ,] 449 [IDr,] AUTH, SAi2, 450 TSi, TSr} --> 452 The initiator asserts its identity with the IDi payload, proves 453 knowledge of the secret corresponding to IDi and integrity protects 454 the contents of the first message using the AUTH payload (see 455 Section 2.15). It might also send its certificate(s) in CERT 456 payload(s) and a list of its trust anchors in CERTREQ payload(s). If 457 any CERT payloads are included, the first certificate provided MUST 458 contain the public key used to verify the AUTH field. 460 The optional payload IDr enables the initiator to specify which of 461 the responder's identities it wants to talk to. This is useful when 462 the machine on which the responder is running is hosting multiple 463 identities at the same IP address. If the IDr proposed by the 464 initiator is not acceptable to the responder, the responder might use 465 some other IDr to finish the exchange. If the initiator then does 466 not accept that fact that responder used different IDr than the one 467 that was requested, the initiator can close the SA after noticing the 468 fact. 470 The initiator begins negotiation of a Child SA using the SAi2 471 payload. The final fields (starting with SAi2) are described in the 472 description of the CREATE_CHILD_SA exchange. 474 <-- HDR, SK {IDr, [CERT,] AUTH, 475 SAr2, TSi, TSr} 477 The responder asserts its identity with the IDr payload, optionally 478 sends one or more certificates (again with the certificate containing 479 the public key used to verify AUTH listed first), authenticates its 480 identity and protects the integrity of the second message with the 481 AUTH payload, and completes negotiation of a Child SA with the 482 additional fields described below in the CREATE_CHILD_SA exchange. 484 The recipients of messages 3 and 4 MUST verify that all signatures 485 and MACs are computed correctly and that the names in the ID payloads 486 correspond to the keys used to generate the AUTH payload. 488 {{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH exchange 489 fails for some reason, the IKE SA is still created as usual. The 490 list of responses in the IKE_AUTH exchange that do not prevent an IKE 491 SA from being set up include at least the following: 492 NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, 493 INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. 495 {{ Clarif-4.3 }} Note that IKE_AUTH messages do not contain KEi/KEr 496 or Ni/Nr payloads. Thus, the SA payloads in the IKE_AUTH exchange 497 cannot contain Transform Type 4 (Diffie-Hellman Group) with any value 498 other than NONE. Implementations SHOULD omit the whole transform 499 substructure instead of sending value NONE. 501 1.3. The CREATE_CHILD_SA Exchange 503 {{ This is a heavy rewrite of most of this section. The major 504 organization changes are described in Clarif-4.1 and Clarif-5.1. }} 506 The CREATE_CHILD_SA exchange is used to create new Child SAs and to 507 rekey both IKE SAs and Child SAs. This exchange consists of a single 508 request/response pair, and some of its function was referred to as a 509 phase 2 exchange in IKEv1. It MAY be initiated by either end of the 510 IKE SA after the initial exchanges are completed. 512 All messages following the initial exchange are cryptographically 513 protected using the cryptographic algorithms and keys negotiated in 514 the first two messages of the IKE exchange. These subsequent 515 messages use the syntax of the Encrypted Payload described in 516 Section 3.14, encrypted with keys that are derived as described in 517 Section 2.14. All subsequent messages include an Encrypted Payload, 518 even if they are referred to in the text as "empty". For both 519 messages in the CREATE_CHILD_SA, the message following the header is 520 encrypted and the message including the header is integrity protected 521 using the cryptographic algorithms negotiated for the IKE SA. 523 The CREATE_CHILD_SA is also used for rekeying IKE SAs and Child SAs. 524 An SA is rekeyed by creating a new SA and then deleting the old one. 525 This section describes the first part of rekeying, the creation of 526 new SAs; Section 2.8 covers the mechanics of rekeying, including 527 moving traffic from old to new SAs and the deletion of the old SAs. 528 The two sections must be read together to understand the entire 529 process of rekeying. 531 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this 532 section the term initiator refers to the endpoint initiating this 533 exchange. An implementation MAY refuse all CREATE_CHILD_SA requests 534 within an IKE SA. 536 The CREATE_CHILD_SA request MAY optionally contain a KE payload for 537 an additional Diffie-Hellman exchange to enable stronger guarantees 538 of forward secrecy for the Child SA. The keying material for the 539 Child SA is a function of SK_d established during the establishment 540 of the IKE SA, the nonces exchanged during the CREATE_CHILD_SA 541 exchange, and the Diffie-Hellman value (if KE payloads are included 542 in the CREATE_CHILD_SA exchange). 544 If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of 545 the SA offers MUST include the Diffie-Hellman group of the KEi. The 546 Diffie-Hellman group of the KEi MUST be an element of the group the 547 initiator expects the responder to accept (additional Diffie-Hellman 548 groups can be proposed). If the responder selects a proposal using a 549 different Diffie-Hellman group (other than NONE), the responder MUST 550 reject the request and indicate its preferred Diffie-Hellman group in 551 the INVALID_KE_PAYLOAD Notification payload. {{ 3.10.1-17 }} There 552 are two octets of data associated with this notification: the 553 accepted D-H Group number in big endian order. In the case of such a 554 rejection, the CREATE_CHILD_SA exchange fails, and the initiator will 555 probably retry the exchange with a Diffie-Hellman proposal and KEi in 556 the group that the responder gave in the INVALID_KE_PAYLOAD. 558 {{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS notification 559 to indicate that a CREATE_CHILD_SA request is unacceptable because 560 the responder is unwilling to accept any more Child SAs on this IKE 561 SA. Some minimal implementations may only accept a single Child SA 562 setup in the context of an initial IKE exchange and reject any 563 subsequent attempts to add more. 565 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA Exchange 567 A Child SA may be created by sending a CREATE_CHILD_SA request. The 568 CREATE_CHILD_SA request for creating a new Child SA is: 570 Initiator Responder 571 ------------------------------------------------------------------- 572 HDR, SK {SA, Ni, [KEi], 573 TSi, TSr} --> 575 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 576 payload, optionally a Diffie-Hellman value in the KEi payload, and 577 the proposed traffic selectors for the proposed Child SA in the TSi 578 and TSr payloads. 580 The CREATE_CHILD_SA response for creating a new Child SA is: 582 <-- HDR, SK {SA, Nr, [KEr], 583 TSi, TSr} 585 The responder replies (using the same Message ID to respond) with the 586 accepted offer in an SA payload, and a Diffie-Hellman value in the 587 KEr payload if KEi was included in the request and the selected 588 cryptographic suite includes that group. 590 The traffic selectors for traffic to be sent on that SA are specified 591 in the TS payloads in the response, which may be a subset of what the 592 initiator of the Child SA proposed. 594 {{ 3.10.1-16391 }} The USE_TRANSPORT_MODE notification MAY be 595 included in a request message that also includes an SA payload 596 requesting a Child SA. It requests that the Child SA use transport 597 mode rather than tunnel mode for the SA created. If the request is 598 accepted, the response MUST also include a notification of type 599 USE_TRANSPORT_MODE. If the responder declines the request, the Child 600 SA will be established in tunnel mode. If this is unacceptable to 601 the initiator, the initiator MUST delete the SA. Note: Except when 602 using this option to negotiate transport mode, all Child SAs will use 603 tunnel mode. 605 {{ 3.10.1-16394 }} The ESP_TFC_PADDING_NOT_SUPPORTED notification 606 asserts that the sending endpoint will NOT accept packets that 607 contain Traffic Flow Confidentiality (TFC) padding over the Child SA 608 being negotiated. {{ Clarif-4.5 }} If neither endpoint accepts TFC 609 padding, this notification is included in both the request and the 610 response. If this notification is included in only one of the 611 messages, TFC padding can still be sent in the other direction. 613 {{ 3.10.1-16395 }} The NON_FIRST_FRAGMENTS_ALSO notification is used 614 for fragmentation control. See [IPSECARCH] for a fuller explanation. 615 {{ Clarif-4.6 }} Both parties need to agree to sending non-first 616 fragments before either party does so. It is enabled only if 617 NON_FIRST_FRAGMENTS_ALSO notification is included in both the request 618 proposing an SA and the response accepting it. If the responder does 619 not want to send or receive non-first fragments, it only omits 620 NON_FIRST_FRAGMENTS_ALSO notification from its response, but does not 621 reject the whole Child SA creation. 623 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange 625 The CREATE_CHILD_SA request for rekeying an IKE SA is: 627 Initiator Responder 628 ------------------------------------------------------------------- 629 HDR, SK {SA, Ni, [KEi]} --> 631 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 632 payload, and a Diffie-Hellman value in the KEi payload. The KEi 633 payload SHOULD be included. New initiator and responder SPIs are 634 supplied in the SPI fields of the SA payload. 636 The CREATE_CHILD_SA response for rekeying an IKE SA is: 638 <-- HDR, SK {SA, Nr,[KEr]} 640 The responder replies (using the same Message ID to respond) with the 641 accepted offer in an SA payload, and a Diffie-Hellman value in the 642 KEr payload if the selected cryptographic suite includes that group. 644 The new IKE SA has its message counters set to 0, regardless of what 645 they were in the earlier IKE SA. The window size starts at 1 for any 646 new IKE SA. 648 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange 650 The CREATE_CHILD_SA request for rekeying a Child SA is: 652 Initiator Responder 653 ------------------------------------------------------------------- 654 HDR, SK {N, SA, Ni, [KEi], 655 TSi, TSr} --> 657 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni 658 payload, optionally a Diffie-Hellman value in the KEi payload, and 659 the proposed traffic selectors for the proposed Child SA in the TSi 660 and TSr payloads. 662 {{ 3.10.1-16393 }} The REKEY_SA notification MUST be included in a 663 CREATE_CHILD_SA exchange if the purpose of the exchange is to replace 664 an existing ESP or AH SA. {{ Clarif-5.4 }} The SA being rekeyed is 665 identified by the SPI field in the Notify payload; this is the SPI 666 the exchange initiator would expect in inbound ESP or AH packets. 667 There is no data associated with this Notify type. The Protocol ID 668 field of the REKEY_SA notification is set to match the protocol of 669 the SA we are rekeying, for example, 3 for ESP and 2 for AH. 671 The CREATE_CHILD_SA response for rekeying a Child SA is: 673 <-- HDR, SK {SA, Nr, [KEr], 674 TSi, TSr} 676 The responder replies (using the same Message ID to respond) with the 677 accepted offer in an SA payload, and a Diffie-Hellman value in the 678 KEr payload if KEi was included in the request and the selected 679 cryptographic suite includes that group. 681 The traffic selectors for traffic to be sent on that SA are specified 682 in the TS payloads in the response, which may be a subset of what the 683 initiator of the Child SA proposed. 685 1.4. The INFORMATIONAL Exchange 687 At various points during the operation of an IKE SA, peers may desire 688 to convey control messages to each other regarding errors or 689 notifications of certain events. To accomplish this, IKE defines an 690 INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur 691 after the initial exchanges and are cryptographically protected with 692 the negotiated keys. 694 Control messages that pertain to an IKE SA MUST be sent under that 695 IKE SA. Control messages that pertain to Child SAs MUST be sent 696 under the protection of the IKE SA which generated them (or its 697 successor if the IKE SA was rekeyed). 699 Messages in an INFORMATIONAL exchange contain zero or more 700 Notification, Delete, and Configuration payloads. The Recipient of 701 an INFORMATIONAL exchange request MUST send some response (else the 702 Sender will assume the message was lost in the network and will 703 retransmit it). That response MAY be a message with no payloads. 704 The request message in an INFORMATIONAL exchange MAY also contain no 705 payloads. This is the expected way an endpoint can ask the other 706 endpoint to verify that it is alive. 708 The INFORMATIONAL exchange is defined as: 710 Initiator Responder 711 ------------------------------------------------------------------- 712 HDR, SK {[N,] [D,] 713 [CP,] ...} --> 714 <-- HDR, SK {[N,] [D,] 715 [CP], ...} 717 The processing of an INFORMATIONAL exchange is determined by its 718 component payloads. 720 1.4.1. Deleting an SA with INFORMATIONAL Exchanges 722 {{ Clarif-5.6 }} ESP and AH SAs always exist in pairs, with one SA in 723 each direction. When an SA is closed, both members of the pair MUST 724 be closed (that is, deleted). Each endpoint MUST close its incoming 725 SAs and allow the other endpoint to close the other SA in each pair. 726 To delete an SA, an INFORMATIONAL exchange with one or more delete 727 payloads is sent listing the SPIs (as they would be expected in the 728 headers of inbound packets) of the SAs to be deleted. The recipient 729 MUST close the designated SAs. {{ Clarif-5.7 }} Note that one never 730 sends delete payloads for the two sides of an SA in a single message. 731 If there are many SAs to delete at the same time, one includes delete 732 payloads for the inbound half of each SA pair in your Informational 733 exchange. 735 Normally, the reply in the INFORMATIONAL exchange will contain delete 736 payloads for the paired SAs going in the other direction. There is 737 one exception. If by chance both ends of a set of SAs independently 738 decide to close them, each may send a delete payload and the two 739 requests may cross in the network. If a node receives a delete 740 request for SAs for which it has already issued a delete request, it 741 MUST delete the outgoing SAs while processing the request and the 742 incoming SAs while processing the response. In that case, the 743 responses MUST NOT include delete payloads for the deleted SAs, since 744 that would result in duplicate deletion and could in theory delete 745 the wrong SA. 747 {{ Demoted the SHOULD }} Half-closed ESP or AH connections are 748 anomalous, and a node with auditing capability should probably audit 749 their existence if they persist. Note that this specification 750 nowhere specifies time periods, so it is up to individual endpoints 751 to decide how long to wait. A node MAY refuse to accept incoming 752 data on half-closed connections but MUST NOT unilaterally close them 753 and reuse the SPIs. If connection state becomes sufficiently messed 754 up, a node MAY close the IKE SA; doing so will implicitly close all 755 SAs negotiated under it. It can then rebuild the SAs it needs on a 756 clean base under a new IKE SA. {{ Clarif-5.8 }} The response to a 757 request that deletes the IKE SA is an empty Informational response. 759 1.5. Informational Messages outside of an IKE SA 761 If an encrypted IKE request packet arrives on port 500 or 4500 with 762 an unrecognized SPI, it could be because the receiving node has 763 recently crashed and lost state or because of some other system 764 malfunction or attack. If the receiving node has an active IKE SA to 765 the IP address from whence the packet came, it MAY send a 766 notification of the wayward packet over that IKE SA in an 767 INFORMATIONAL exchange. If it does not have such an IKE SA, it MAY 768 send an Informational message without cryptographic protection to the 769 source IP address. Such a message is not part of an informational 770 exchange, and the receiving node MUST NOT respond to it. Doing so 771 could cause a message loop. 773 {{ 3.10.1-11 }} The INVALID_SPI notification MAY be sent in an IKE 774 INFORMATIONAL exchange when a node receives an ESP or AH packet with 775 an invalid SPI. The Notification Data contains the SPI of the 776 invalid packet. This usually indicates a node has rebooted and 777 forgotten an SA. If this Informational Message is sent outside the 778 context of an IKE SA, it should only be used by the recipient as a 779 "hint" that something might be wrong (because it could easily be 780 forged). 782 {{ Clarif-7.7 }} There are two cases when such a one-way notification 783 is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are 784 sent outside of an IKE SA. Note that such notifications are 785 explicitly not Informational exchanges; these are one-way messages 786 that must not be responded to. 788 In case of INVALID_IKE_SPI, the message sent is a response message, 789 and thus it is sent to the IP address and port from whence it came 790 with the same IKE SPIs and the Message ID is copied. The Response 791 bit is set to 1, and the version flags are set in the normal fashion. 793 In case of INVALID_SPI, however, there are no IKE SPI values that 794 would be meaningful to the recipient of such a notification. Using 795 zero values or random values are both acceptable. The Initiator flag 796 is set, the Response bit is set to 0, and the version flags are set 797 in the normal fashion. 799 1.6. Requirements Terminology 801 Definitions of the primitive terms in this document (such as Security 802 Association or SA) can be found in [IPSECARCH]. {{ Clarif-7.2 }} It 803 should be noted that parts of IKEv2 rely on some of the processing 804 rules in [IPSECARCH], as described in various sections of this 805 document. 807 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 808 "MAY" that appear in this document are to be interpreted as described 809 in [MUSTSHOULD]. 811 1.7. Differences Between RFC 4306 and This Document 813 {{ Added this entire section, including this recursive remark. }} 815 This document contains clarifications and amplifications to IKEv2 816 [IKEV2]. The clarifications are mostly based on [Clarif]. The 817 changes listed in that document were discussed in the IPsec Working 818 Group and, after the Working Group was disbanded, on the IPsec 819 mailing list. That document contains detailed explanations of areas 820 that were unclear in IKEv2, and is thus useful to implementers of 821 IKEv2. 823 The protocol described in this document retains the same major 824 version number (2) and minor version number (0) as was used in RFC 825 4306. That is, the version number is *not* changed from RFC 4306. 827 This document makes the figures and references a bit more regular 828 than in [IKEV2]. 830 IKEv2 developers have noted that the SHOULD-level requirements are 831 often unclear in that they don't say when it is OK to not obey the 832 requirements. They also have noted that there are MUST-level 833 requirements that are not related to interoperability. This document 834 has more explanation of some of these requirements. All non- 835 capitalized uses of the words SHOULD and MUST now mean their normal 836 English sense, not the interoperability sense of [MUSTSHOULD]. 838 IKEv2 (and IKEv1) developers have noted that there is a great deal of 839 material in the tables of codes in Section 3.10.1. This leads to 840 implementers not having all the needed information in the main body 841 of the document. Much of the material from those tables has been 842 moved into the associated parts of the main body of the document. 844 In the body of this document, notes that are enclosed in double curly 845 braces {{ such as this }} point out changes from IKEv2. Changes that 846 come from [Clarif] are marked with the section from that document, 847 such as "{{ Clarif-2.10 }}". Changes that come from moving 848 descriptive text out of the tables in Section 3.10.1 are marked with 849 that number and the message type that contained the text, such as "{{ 850 3.10.1-16384 }}". 852 This document removes discussion of nesting AH and ESP. This was a 853 mistake in RFC 4306 caused by the lag between finishing RFC 4306 and 854 RFC 4301. Basically, IKEv2 is based on RFC 4301, which does not 855 include "SA bundles" that were part of RFC 2401. While a single 856 packet can go through IPsec processing multiple times, each of these 857 passes uses a separate SA, and the passes are coordinated by the 858 forwarding tables. In IKEv2, each of these SAs has to be created 859 using a separate CREATE_CHILD_SA exchange. 861 This document removes discussion of the INTERNAL_ADDRESS_EXPIRY 862 configuration attribute because its implementation was very 863 problematic. Implementations that conform to this document MUST 864 ignore proposals that have configuration attribute type 5, the old 865 value for INTERNAL_ADDRESS_EXPIRY. 867 This document adds the restriction in Section 2.13 that all PRFs used 868 with IKEv2 MUST take variable-sized keys. This should not affect any 869 implementations because there were no standardized PRFs that have 870 fixed-size keys. 872 A later version of this document may have all the {{ }} comments 873 removed from the body of the document and instead appear in an 874 appendix. 876 2. IKE Protocol Details and Variations 878 IKE normally listens and sends on UDP port 500, though IKE messages 879 may also be received on UDP port 4500 with a slightly different 880 format (see Section 2.23). Since UDP is a datagram (unreliable) 881 protocol, IKE includes in its definition recovery from transmission 882 errors, including packet loss, packet replay, and packet forgery. 883 IKE is designed to function so long as (1) at least one of a series 884 of retransmitted packets reaches its destination before timing out; 885 and (2) the channel is not so full of forged and replayed packets so 886 as to exhaust the network or CPU capacities of either endpoint. Even 887 in the absence of those minimum performance requirements, IKE is 888 designed to fail cleanly (as though the network were broken). 890 Although IKEv2 messages are intended to be short, they contain 891 structures with no hard upper bound on size (in particular, X.509 892 certificates), and IKEv2 itself does not have a mechanism for 893 fragmenting large messages. IP defines a mechanism for fragmentation 894 of oversize UDP messages, but implementations vary in the maximum 895 message size supported. Furthermore, use of IP fragmentation opens 896 an implementation to denial of service attacks [DOSUDPPROT]. 897 Finally, some NAT and/or firewall implementations may block IP 898 fragments. 900 All IKEv2 implementations MUST be able to send, receive, and process 901 IKE messages that are up to 1280 octets long, and they SHOULD be able 902 to send, receive, and process messages that are up to 3000 octets 903 long. {{ Demoted the SHOULD }} IKEv2 implementations need to be aware 904 of the maximum UDP message size supported and MAY shorten messages by 905 leaving out some certificates or cryptographic suite proposals if 906 that will keep messages below the maximum. Use of the "Hash and URL" 907 formats rather than including certificates in exchanges where 908 possible can avoid most problems. {{ Demoted the SHOULD }} 909 Implementations and configuration need to keep in mind, however, that 910 if the URL lookups are possible only after the IPsec SA is 911 established, recursion issues could prevent this technique from 912 working. 914 {{ Clarif-7.5 }} The UDP payload of all packets containing IKE 915 messages sent on port 4500 MUST begin with the prefix of four zeros; 916 otherwise, the receiver won't know how to handle them. 918 2.1. Use of Retransmission Timers 920 All messages in IKE exist in pairs: a request and a response. The 921 setup of an IKE SA normally consists of two request/response pairs. 922 Once the IKE SA is set up, either end of the security association may 923 initiate requests at any time, and there can be many requests and 924 responses "in flight" at any given moment. But each message is 925 labeled as either a request or a response, and for each request/ 926 response pair one end of the security association is the initiator 927 and the other is the responder. 929 For every pair of IKE messages, the initiator is responsible for 930 retransmission in the event of a timeout. The responder MUST never 931 retransmit a response unless it receives a retransmission of the 932 request. In that event, the responder MUST ignore the retransmitted 933 request except insofar as it triggers a retransmission of the 934 response. The initiator MUST remember each request until it receives 935 the corresponding response. The responder MUST remember each 936 response until it receives a request whose sequence number is larger 937 than or equal to the sequence number in the response plus its window 938 size (see Section 2.3). 940 IKE is a reliable protocol, in the sense that the initiator MUST 941 retransmit a request until either it receives a corresponding reply 942 OR it deems the IKE security association to have failed and it 943 discards all state associated with the IKE SA and any Child SAs 944 negotiated using that IKE SA. A retransmission from the initiator 945 MUST be bitwise identical to the original request. That is, 946 everything starting from the IKE Header (the IKE SA Initiator's SPI 947 onwards) must be bitwise identical; items before it (such as the IP 948 and UDP headers, and the zero non-ESP marker) do not have to be 949 identical. 951 {{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require 952 some special handling. When a responder receives an IKE_SA_INIT 953 request, it has to determine whether the packet is retransmission 954 belonging to an existing "half-open" IKE SA (in which case the 955 responder retransmits the same response), or a new request (in which 956 case the responder creates a new IKE SA and sends a fresh response), 957 or it belongs to an existing IKE SA where the IKE_AUTH request has 958 been already received (in which case the responder ignores it). 960 It is not sufficient to use the initiator's SPI and/or IP address to 961 differentiate between these three cases because two different peers 962 behind a single NAT could choose the same initiator SPI. Instead, a 963 robust responder will do the IKE SA lookup using the whole packet, 964 its hash, or the Ni payload. 966 2.2. Use of Sequence Numbers for Message ID 968 Every IKE message contains a Message ID as part of its fixed header. 969 This Message ID is used to match up requests and responses, and to 970 identify retransmissions of messages. 972 The Message ID is a 32-bit quantity, which is zero for the 973 IKE_SA_INIT messages (including retries of the message due to 974 responses such as COOKIE and INVALID_KE_PAYLOAD {{ Clarif-2.2 }}), 975 and incremented for each subsequent exchange. Rekeying an IKE SA 976 resets the sequence numbers. Thus, the first pair of IKE_AUTH 977 messages will have ID of 1, the second (when EAP is used) will be 2, 978 and so on. {{ Clarif-3.10 }} 980 Each endpoint in the IKE Security Association maintains two "current" 981 Message IDs: the next one to be used for a request it initiates and 982 the next one it expects to see in a request from the other end. 983 These counters increment as requests are generated and received. 984 Responses always contain the same message ID as the corresponding 985 request. That means that after the initial exchange, each integer n 986 may appear as the message ID in four distinct messages: the nth 987 request from the original IKE initiator, the corresponding response, 988 the nth request from the original IKE responder, and the 989 corresponding response. If the two ends make very different numbers 990 of requests, the Message IDs in the two directions can be very 991 different. There is no ambiguity in the messages, however, because 992 the (I)nitiator and (R)esponse bits in the message header specify 993 which of the four messages a particular one is. 995 {{ Clarif-5.9 }} Throughout this document, "initiator" refers to the 996 party who initiated the exchange being described, and "original 997 initiator" refers to the party who initiated the whole IKE SA. The 998 "original initiator" always refers to the party who initiated the 999 exchange which resulted in the current IKE SA. In other words, if 1000 the "original responder" starts rekeying the IKE SA, that party 1001 becomes the "original initiator" of the new IKE SA. 1003 Note that Message IDs are cryptographically protected and provide 1004 protection against message replays. In the unlikely event that 1005 Message IDs grow too large to fit in 32 bits, the IKE SA MUST be 1006 closed or rekeyed. 1008 2.3. Window Size for Overlapping Requests 1010 In order to maximize IKE throughput, an IKE endpoint MAY issue 1011 multiple requests before getting a response to any of them if the 1012 other endpoint has indicated its ability to handle such requests. 1013 For simplicity, an IKE implementation MAY choose to process requests 1014 strictly in order and/or wait for a response to one request before 1015 issuing another. Certain rules must be followed to ensure 1016 interoperability between implementations using different strategies. 1018 After an IKE SA is set up, either end can initiate one or more 1019 requests. These requests may pass one another over the network. An 1020 IKE endpoint MUST be prepared to accept and process a request while 1021 it has a request outstanding in order to avoid a deadlock in this 1022 situation. {{ Downgraded the SHOULD }} An IKE endpoint may also 1023 accept and process multiple requests while it has a request 1024 outstanding. 1026 {{ 3.10.1-16385 }} The SET_WINDOW_SIZE notification asserts that the 1027 sending endpoint is capable of keeping state for multiple outstanding 1028 exchanges, permitting the recipient to send multiple requests before 1029 getting a response to the first. The data associated with a 1030 SET_WINDOW_SIZE notification MUST be 4 octets long and contain the 1031 big endian representation of the number of messages the sender 1032 promises to keep. The window size is always one until the initial 1033 exchanges complete. 1035 An IKE endpoint MUST wait for a response to each of its messages 1036 before sending a subsequent message unless it has received a 1037 SET_WINDOW_SIZE Notify message from its peer informing it that the 1038 peer is prepared to maintain state for multiple outstanding messages 1039 in order to allow greater throughput. 1041 An IKE endpoint MUST NOT exceed the peer's stated window size for 1042 transmitted IKE requests. In other words, if the responder stated 1043 its window size is N, then when the initiator needs to make a request 1044 X, it MUST wait until it has received responses to all requests up 1045 through request X-N. An IKE endpoint MUST keep a copy of (or be able 1046 to regenerate exactly) each request it has sent until it receives the 1047 corresponding response. An IKE endpoint MUST keep a copy of (or be 1048 able to regenerate exactly) the number of previous responses equal to 1049 its declared window size in case its response was lost and the 1050 initiator requests its retransmission by retransmitting the request. 1052 An IKE endpoint supporting a window size greater than one ought to be 1053 capable of processing incoming requests out of order to maximize 1054 performance in the event of network failures or packet reordering. 1056 {{ Clarif-7.3 }} The window size is normally a (possibly 1057 configurable) property of a particular implementation, and is not 1058 related to congestion control (unlike the window size in TCP, for 1059 example). In particular, it is not defined what the responder should 1060 do when it receives a SET_WINDOW_SIZE notification containing a 1061 smaller value than is currently in effect. Thus, there is currently 1062 no way to reduce the window size of an existing IKE SA; you can only 1063 increase it. When rekeying an IKE SA, the new IKE SA starts with 1064 window size 1 until it is explicitly increased by sending a new 1065 SET_WINDOW_SIZE notification. 1067 {{ 3.10.1-9 }}The INVALID_MESSAGE_ID notification is sent when an IKE 1068 message ID outside the supported window is received. This Notify 1069 MUST NOT be sent in a response; the invalid request MUST NOT be 1070 acknowledged. Instead, inform the other side by initiating an 1071 INFORMATIONAL exchange with Notification data containing the four 1072 octet invalid message ID. Sending this notification is optional, and 1073 notifications of this type MUST be rate limited. 1075 2.4. State Synchronization and Connection Timeouts 1077 An IKE endpoint is allowed to forget all of its state associated with 1078 an IKE SA and the collection of corresponding Child SAs at any time. 1079 This is the anticipated behavior in the event of an endpoint crash 1080 and restart. It is important when an endpoint either fails or 1081 reinitializes its state that the other endpoint detect those 1082 conditions and not continue to waste network bandwidth by sending 1083 packets over discarded SAs and having them fall into a black hole. 1085 {{ 3.10.1-16384 }} The INITIAL_CONTACT notification asserts that this 1086 IKE SA is the only IKE SA currently active between the authenticated 1087 identities. It MAY be sent when an IKE SA is established after a 1088 crash, and the recipient MAY use this information to delete any other 1089 IKE SAs it has to the same authenticated identity without waiting for 1090 a timeout. This notification MUST NOT be sent by an entity that may 1091 be replicated (e.g., a roaming user's credentials where the user is 1092 allowed to connect to the corporate firewall from two remote systems 1093 at the same time). {{ Clarif-7.9 }} The INITIAL_CONTACT notification, 1094 if sent, MUST be in the first IKE_AUTH request, not as a separate 1095 exchange afterwards; however, receiving parties need to deal with it 1096 in other requests. 1098 Since IKE is designed to operate in spite of Denial of Service (DoS) 1099 attacks from the network, an endpoint MUST NOT conclude that the 1100 other endpoint has failed based on any routing information (e.g., 1101 ICMP messages) or IKE messages that arrive without cryptographic 1102 protection (e.g., Notify messages complaining about unknown SPIs). 1103 An endpoint MUST conclude that the other endpoint has failed only 1104 when repeated attempts to contact it have gone unanswered for a 1105 timeout period or when a cryptographically protected INITIAL_CONTACT 1106 notification is received on a different IKE SA to the same 1107 authenticated identity. {{ Demoted the SHOULD }} An endpoint should 1108 suspect that the other endpoint has failed based on routing 1109 information and initiate a request to see whether the other endpoint 1110 is alive. To check whether the other side is alive, IKE specifies an 1111 empty INFORMATIONAL message that (like all IKE requests) requires an 1112 acknowledgement (note that within the context of an IKE SA, an 1113 "empty" message consists of an IKE header followed by an Encrypted 1114 payload that contains no payloads). If a cryptographically protected 1115 (fresh, i.e. not retransmitted) message has been received from the 1116 other side recently, unprotected notifications MAY be ignored. 1117 Implementations MUST limit the rate at which they take actions based 1118 on unprotected messages. 1120 Numbers of retries and lengths of timeouts are not covered in this 1121 specification because they do not affect interoperability. It is 1122 suggested that messages be retransmitted at least a dozen times over 1123 a period of at least several minutes before giving up on an SA, but 1124 different environments may require different rules. To be a good 1125 network citizen, retranmission times MUST increase exponentially to 1126 avoid flooding the network and making an existing congestion 1127 situation worse. If there has only been outgoing traffic on all of 1128 the SAs associated with an IKE SA, it is essential to confirm 1129 liveness of the other endpoint to avoid black holes. If no 1130 cryptographically protected messages have been received on an IKE SA 1131 or any of its Child SAs recently, the system needs to perform a 1132 liveness check in order to prevent sending messages to a dead peer. 1133 (This is sometimes called "dead peer detection" or "DPD", although it 1134 is really detecting live peers, not dead ones.) Receipt of a fresh 1135 cryptographically protected message on an IKE SA or any of its Child 1136 SAs ensures liveness of the IKE SA and all of its Child SAs. Note 1137 that this places requirements on the failure modes of an IKE 1138 endpoint. An implementation MUST NOT continue sending on any SA if 1139 some failure prevents it from receiving on all of the associated SAs. 1140 If Child SAs can fail independently from one another without the 1141 associated IKE SA being able to send a delete message, then they MUST 1142 be negotiated by separate IKE SAs. 1144 There is a Denial of Service attack on the initiator of an IKE SA 1145 that can be avoided if the initiator takes the proper care. Since 1146 the first two messages of an SA setup are not cryptographically 1147 protected, an attacker could respond to the initiator's message 1148 before the genuine responder and poison the connection setup attempt. 1149 To prevent this, the initiator MAY be willing to accept multiple 1150 responses to its first message, treat each as potentially legitimate, 1151 respond to it, and then discard all the invalid half-open connections 1152 when it receives a valid cryptographically protected response to any 1153 one of its requests. Once a cryptographically valid response is 1154 received, all subsequent responses should be ignored whether or not 1155 they are cryptographically valid. 1157 Note that with these rules, there is no reason to negotiate and agree 1158 upon an SA lifetime. If IKE presumes the partner is dead, based on 1159 repeated lack of acknowledgement to an IKE message, then the IKE SA 1160 and all Child SAs set up through that IKE SA are deleted. 1162 An IKE endpoint may at any time delete inactive Child SAs to recover 1163 resources used to hold their state. If an IKE endpoint chooses to 1164 delete Child SAs, it MUST send Delete payloads to the other end 1165 notifying it of the deletion. It MAY similarly time out the IKE SA. 1166 {{ Clarified the SHOULD }} Closing the IKE SA implicitly closes all 1167 associated Child SAs. In this case, an IKE endpoint SHOULD send a 1168 Delete payload indicating that it has closed the IKE SA unless the 1169 other endpoint is no longer responding. 1171 2.5. Version Numbers and Forward Compatibility 1173 This document describes version 2.0 of IKE, meaning the major version 1174 number is 2 and the minor version number is 0. {{ Restated the 1175 relationship to RFC 4306 }} This document is a replacement for 1176 [IKEV2]. It is likely that some implementations will want to support 1177 version 1.0 and version 2.0, and in the future, other versions. 1179 The major version number should be incremented only if the packet 1180 formats or required actions have changed so dramatically that an 1181 older version node would not be able to interoperate with a newer 1182 version node if it simply ignored the fields it did not understand 1183 and took the actions specified in the older specification. The minor 1184 version number indicates new capabilities, and MUST be ignored by a 1185 node with a smaller minor version number, but used for informational 1186 purposes by the node with the larger minor version number. For 1187 example, it might indicate the ability to process a newly defined 1188 notification message. The node with the larger minor version number 1189 would simply note that its correspondent would not be able to 1190 understand that message and therefore would not send it. 1192 {{ 3.10.1-5 }} If an endpoint receives a message with a higher major 1193 version number, it MUST drop the message and SHOULD send an 1194 unauthenticated notification message of type INVALID_MAJOR_VERSION 1195 containing the highest (closest) version number it supports. If an 1196 endpoint supports major version n, and major version m, it MUST 1197 support all versions between n and m. If it receives a message with 1198 a major version that it supports, it MUST respond with that version 1199 number. In order to prevent two nodes from being tricked into 1200 corresponding with a lower major version number than the maximum that 1201 they both support, IKE has a flag that indicates that the node is 1202 capable of speaking a higher major version number. 1204 Thus, the major version number in the IKE header indicates the 1205 version number of the message, not the highest version number that 1206 the transmitter supports. If the initiator is capable of speaking 1207 versions n, n+1, and n+2, and the responder is capable of speaking 1208 versions n and n+1, then they will negotiate speaking n+1, where the 1209 initiator will set a flag indicating its ability to speak a higher 1210 version. If they mistakenly (perhaps through an active attacker 1211 sending error messages) negotiate to version n, then both will notice 1212 that the other side can support a higher version number, and they 1213 MUST break the connection and reconnect using version n+1. 1215 Note that IKEv1 does not follow these rules, because there is no way 1216 in v1 of noting that you are capable of speaking a higher version 1217 number. So an active attacker can trick two v2-capable nodes into 1218 speaking v1. {{ Demoted the SHOULD }} When a v2-capable node 1219 negotiates down to v1, it should note that fact in its logs. 1221 Also for forward compatibility, all fields marked RESERVED MUST be 1222 set to zero by an implementation running version 2.0, and their 1223 content MUST be ignored by an implementation running version 2.0 ("Be 1224 conservative in what you send and liberal in what you receive"). In 1225 this way, future versions of the protocol can use those fields in a 1226 way that is guaranteed to be ignored by implementations that do not 1227 understand them. Similarly, payload types that are not defined are 1228 reserved for future use; implementations of a version where they are 1229 undefined MUST skip over those payloads and ignore their contents. 1231 IKEv2 adds a "critical" flag to each payload header for further 1232 flexibility for forward compatibility. If the critical flag is set 1233 and the payload type is unrecognized, the message MUST be rejected 1234 and the response to the IKE request containing that payload MUST 1235 include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an 1236 unsupported critical payload was included. {{ 3.10.1-1 }} In that 1237 Notify payload, the notification data contains the one-octet payload 1238 type. If the critical flag is not set and the payload type is 1239 unsupported, that payload MUST be ignored. Payloads sent in IKE 1240 response messages MUST NOT have the critical flag set. Note that the 1241 critical flag applies only to the payload type, not the contents. If 1242 the payload type is recognized, but the payload contains something 1243 which is not (such as an unknown transform inside an SA payload, or 1244 an unknown Notify Message Type inside a Notify payload), the critical 1245 flag is ignored. 1247 {{ Demoted the SHOULD in the second clause }}Although new payload 1248 types may be added in the future and may appear interleaved with the 1249 fields defined in this specification, implementations MUST send the 1250 payloads defined in this specification in the order shown in the 1251 figures in Section 2; implementations are explicitly allowed to 1252 reject as invalid a message with those payloads in any other order. 1254 2.6. IKE SA SPIs and Cookies 1256 The term "cookies" originates with Karn and Simpson [PHOTURIS] in 1257 Photuris, an early proposal for key management with IPsec, and it has 1258 persisted. The Internet Security Association and Key Management 1259 Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight- 1260 octet fields titled "cookies", and that syntax is used by both IKEv1 1261 and IKEv2, although in IKEv2 they are referred to as the "IKE SPI" 1262 and there is a new separate field in a Notify payload holding the 1263 cookie. The initial two eight-octet fields in the header are used as 1264 a connection identifier at the beginning of IKE packets. Each 1265 endpoint chooses one of the two SPIs and MUST choose them so as to be 1266 unique identifiers of an IKE SA. An SPI value of zero is special and 1267 indicates that the remote SPI value is not yet known by the sender. 1269 Incoming IKE packets are mapped to an IKE SA only using the packet's 1270 SPI, not using (for example) the source IP address of the packet. 1272 Unlike ESP and AH where only the recipient's SPI appears in the 1273 header of a message, in IKE the sender's SPI is also sent in every 1274 message. Since the SPI chosen by the original initiator of the IKE 1275 SA is always sent first, an endpoint with multiple IKE SAs open that 1276 wants to find the appropriate IKE SA using the SPI it assigned must 1277 look at the I(nitiator) Flag bit in the header to determine whether 1278 it assigned the first or the second eight octets. 1280 In the first message of an initial IKE exchange, the initiator will 1281 not know the responder's SPI value and will therefore set that field 1282 to zero. 1284 An expected attack against IKE is state and CPU exhaustion, where the 1285 target is flooded with session initiation requests from forged IP 1286 addresses. This attack can be made less effective if an 1287 implementation of a responder uses minimal CPU and commits no state 1288 to an SA until it knows the initiator can receive packets at the 1289 address from which it claims to be sending them. 1291 When a responder detects a large number of half-open IKE SAs, it 1292 SHOULD reply to IKE_SA_INIT requests with a response containing the 1293 COOKIE notification. {{ 3.10.1-16390 }} The data associated with this 1294 notification MUST be between 1 and 64 octets in length (inclusive), 1295 and its generation is described later in this section. If the 1296 IKE_SA_INIT response includes the COOKIE notification, the initiator 1297 MUST then retry the IKE_SA_INIT request, and include the COOKIE 1298 notification containing the received data as the first payload, and 1299 all other payloads unchanged. The initial exchange will then be as 1300 follows: 1302 Initiator Responder 1303 ------------------------------------------------------------------- 1304 HDR(A,0), SAi1, KEi, Ni --> 1305 <-- HDR(A,0), N(COOKIE) 1306 HDR(A,0), N(COOKIE), SAi1, 1307 KEi, Ni --> 1308 <-- HDR(A,B), SAr1, KEr, 1309 Nr, [CERTREQ] 1310 HDR(A,B), SK {IDi, [CERT,] 1311 [CERTREQ,] [IDr,] AUTH, 1312 SAi2, TSi, TSr} --> 1313 <-- HDR(A,B), SK {IDr, [CERT,] 1314 AUTH, SAr2, TSi, TSr} 1316 The first two messages do not affect any initiator or responder state 1317 except for communicating the cookie. In particular, the message 1318 sequence numbers in the first four messages will all be zero and the 1319 message sequence numbers in the last two messages will be one. 'A' 1320 is the SPI assigned by the initiator, while 'B' is the SPI assigned 1321 by the responder. 1323 {{ Demoted the SHOULD }} An IKE implementation can implement its 1324 responder cookie generation in such a way as to not require any saved 1325 state to recognize its valid cookie when the second IKE_SA_INIT 1326 message arrives. The exact algorithms and syntax they use to 1327 generate cookies do not affect interoperability and hence are not 1328 specified here. The following is an example of how an endpoint could 1329 use cookies to implement limited DOS protection. 1331 A good way to do this is to set the responder cookie to be: 1333 Cookie = | Hash(Ni | IPi | SPIi | ) 1335 where is a randomly generated secret known only to the 1336 responder and periodically changed and | indicates concatenation. 1337 should be changed whenever is 1338 regenerated. The cookie can be recomputed when the IKE_SA_INIT 1339 arrives the second time and compared to the cookie in the received 1340 message. If it matches, the responder knows that the cookie was 1341 generated since the last change to and that IPi must be the 1342 same as the source address it saw the first time. Incorporating SPIi 1343 into the calculation ensures that if multiple IKE SAs are being set 1344 up in parallel they will all get different cookies (assuming the 1345 initiator chooses unique SPIi's). Incorporating Ni into the hash 1346 ensures that an attacker who sees only message 2 can't successfully 1347 forge a message 3. 1349 If a new value for is chosen while there are connections in 1350 the process of being initialized, an IKE_SA_INIT might be returned 1351 with other than the current . The responder in 1352 that case MAY reject the message by sending another response with a 1353 new cookie or it MAY keep the old value of around for a 1354 short time and accept cookies computed from either one. {{ Demoted 1355 the SHOULD NOT }} The responder should not accept cookies 1356 indefinitely after is changed, since that would defeat part 1357 of the denial of service protection. {{ Demoted the SHOULD }} The 1358 responder should change the value of frequently, especially 1359 if under attack. 1361 {{ Clarif-2.1 }} In addition to cookies, there are several cases 1362 where the IKE_SA_INIT exchange does not result in the creation of an 1363 IKE SA (such as INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). In such a 1364 case, sending a zero value for the Responder's SPI is correct. If 1365 the responder sends a non-zero responder SPI, the initiator should 1366 not reject the response for only that reason. 1368 {{ Clarif-2.5 }} When one party receives an IKE_SA_INIT request 1369 containing a cookie whose contents do not match the value expected, 1370 that party MUST ignore the cookie and process the message as if no 1371 cookie had been included; usually this means sending a response 1372 containing a new cookie. The initiator should limit the number of 1373 cookie exchanges it tries before giving up. An attacker can forge 1374 multiple cookie responses to the initiator's IKE_SA_INIT message, and 1375 each of those forged cookie reply will trigger two packets: one 1376 packet from the initiator to the responder (which will reject those 1377 cookies), and one reply from responder to initiator that includes the 1378 correct cookie. 1380 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD 1382 {{ This section added by Clarif-2.4 }} 1384 There are two common reasons why the initiator may have to retry the 1385 IKE_SA_INIT exchange: the responder requests a cookie or wants a 1386 different Diffie-Hellman group than was included in the KEi payload. 1387 If the initiator receives a cookie from the responder, the initiator 1388 needs to decide whether or not to include the cookie in only the next 1389 retry of the IKE_SA_INIT request, or in all subsequent retries as 1390 well. 1392 If the initiator includes the cookie only in the next retry, one 1393 additional roundtrip may be needed in some cases. An additional 1394 roundtrip is needed also if the initiator includes the cookie in all 1395 retries, but the responder does not support this. For instance, if 1396 the responder includes the SAi1 and KEi payloads in cookie 1397 calculation, it will reject the request by sending a new cookie. 1399 If both peers support including the cookie in all retries, a slightly 1400 shorter exchange can happen. 1402 Initiator Responder 1403 ----------------------------------------------------------- 1404 HDR(A,0), SAi1, KEi, Ni --> 1405 <-- HDR(A,0), N(COOKIE) 1406 HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> 1407 <-- HDR(A,0), N(INVALID_KE_PAYLOAD) 1408 HDR(A,0), N(COOKIE), SAi1, KEi', Ni --> 1409 <-- HDR(A,B), SAr1, KEr, Nr 1411 Implementations SHOULD support this shorter exchange, but MUST NOT 1412 fail if other implementations do not support this shorter exchange. 1414 2.7. Cryptographic Algorithm Negotiation 1416 The payload type known as "SA" indicates a proposal for a set of 1417 choices of IPsec protocols (IKE, ESP, or AH) for the SA as well as 1418 cryptographic algorithms associated with each protocol. 1420 An SA payload consists of one or more proposals. {{ Clarif-7.13 }} 1421 Each proposal includes one protocol. Each protocol contains one or 1422 more transforms -- each specifying a cryptographic algorithm. Each 1423 transform contains zero or more attributes (attributes are needed 1424 only if the transform identifier does not completely specify the 1425 cryptographic algorithm). 1427 This hierarchical structure was designed to efficiently encode 1428 proposals for cryptographic suites when the number of supported 1429 suites is large because multiple values are acceptable for multiple 1430 transforms. The responder MUST choose a single suite, which may be 1431 any subset of the SA proposal following the rules below: 1433 {{ Clarif-7.13 }} Each proposal contains one protocol. If a proposal 1434 is accepted, the SA response MUST contain the same protocol. The 1435 responder MUST accept a single proposal or reject them all and return 1436 an error. {{ 3.10.1-14 }} The error is given in a notification of 1437 type NO_PROPOSAL_CHOSEN. 1439 Each IPsec protocol proposal contains one or more transforms. Each 1440 transform contains a transform type. The accepted cryptographic 1441 suite MUST contain exactly one transform of each type included in the 1442 proposal. For example: if an ESP proposal includes transforms 1443 ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, 1444 AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one 1445 of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six 1446 combinations are acceptable. 1448 If an initiator proposes both normal ciphers with integrity 1449 protection as well as combined-mode ciphers, then two proposals are 1450 needed. One of the proposals includes the normal ciphers with the 1451 integrity algoritms for them, and the other proposal includes all the 1452 combined mode ciphers without the integrity algorithms (because 1453 combined mode ciphers are not allowed to have any integrity algorithm 1454 other than "none"). 1456 Since the initiator sends its Diffie-Hellman value in the 1457 IKE_SA_INIT, it must guess the Diffie-Hellman group that the 1458 responder will select from its list of supported groups. If the 1459 initiator guesses wrong, the responder will respond with a Notify 1460 payload of type INVALID_KE_PAYLOAD indicating the selected group. In 1461 this case, the initiator MUST retry the IKE_SA_INIT with the 1462 corrected Diffie-Hellman group. The initiator MUST again propose its 1463 full set of acceptable cryptographic suites because the rejection 1464 message was unauthenticated and otherwise an active attacker could 1465 trick the endpoints into negotiating a weaker suite than a stronger 1466 one that they both prefer. 1468 {{ Clarif-2.1 }} When the IKE_SA_INIT exchange does not result in the 1469 creation of an IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, 1470 or COOKIE (see Section 2.6), the responder's SPI will be zero. 1471 However, if the responder sends a non-zero responder SPI, the 1472 initiator should not reject the response for only that reason. 1474 2.8. Rekeying 1476 {{ Demoted the SHOULD }} IKE, ESP, and AH security associations use 1477 secret keys that should be used only for a limited amount of time and 1478 to protect a limited amount of data. This limits the lifetime of the 1479 entire security association. When the lifetime of a security 1480 association expires, the security association MUST NOT be used. If 1481 there is demand, new security associations MAY be established. 1482 Reestablishment of security associations to take the place of ones 1483 that expire is referred to as "rekeying". 1485 To allow for minimal IPsec implementations, the ability to rekey SAs 1486 without restarting the entire IKE SA is optional. An implementation 1487 MAY refuse all CREATE_CHILD_SA requests within an IKE SA. If an SA 1488 has expired or is about to expire and rekeying attempts using the 1489 mechanisms described here fail, an implementation MUST close the IKE 1490 SA and any associated Child SAs and then MAY start new ones. {{ 1491 Demoted the SHOULD }} Implementations may wish to support in-place 1492 rekeying of SAs, since doing so offers better performance and is 1493 likely to reduce the number of packets lost during the transition. 1495 To rekey a Child SA within an existing IKE SA, create a new, 1496 equivalent SA (see Section 2.17 below), and when the new one is 1497 established, delete the old one. To rekey an IKE SA, establish a new 1498 equivalent IKE SA (see Section 2.18 below) with the peer to whom the 1499 old IKE SA is shared using a CREATE_CHILD_SA within the existing IKE 1500 SA. An IKE SA so created inherits all of the original IKE SA's Child 1501 SAs, and the new IKE SA is used for all control messages needed to 1502 maintain those Child SAs. The old IKE SA is then deleted, and the 1503 Delete payload to delete itself MUST be the last request sent over 1504 the old IKE SA. Note that, when rekeying, the new Child SA MAY have 1505 different traffic selectors and algorithms than the old one. 1507 {{ Demoted the SHOULD }} SAs should be rekeyed proactively, i.e., the 1508 new SA should be established before the old one expires and becomes 1509 unusable. Enough time should elapse between the time the new SA is 1510 established and the old one becomes unusable so that traffic can be 1511 switched over to the new SA. 1513 A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes 1514 were negotiated. In IKEv2, each end of the SA is responsible for 1515 enforcing its own lifetime policy on the SA and rekeying the SA when 1516 necessary. If the two ends have different lifetime policies, the end 1517 with the shorter lifetime will end up always being the one to request 1518 the rekeying. If an SA has been inactive for a long time and if an 1519 endpoint would not initiate the SA in the absence of traffic, the 1520 endpoint MAY choose to close the SA instead of rekeying it when its 1521 lifetime expires. {{ Demoted the SHOULD }} It should do so if there 1522 has been no traffic since the last time the SA was rekeyed. 1524 Note that IKEv2 deliberately allows parallel SAs with the same 1525 traffic selectors between common endpoints. One of the purposes of 1526 this is to support traffic quality of service (QoS) differences among 1527 the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and section 4.1 of 1528 [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints 1529 and the traffic selectors may not uniquely identify an SA between 1530 those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on 1531 the basis of duplicate traffic selectors SHOULD NOT be used. 1533 {{ Demoted the SHOULD }} The node that initiated the surviving 1534 rekeyed SA should delete the replaced SA after the new one is 1535 established. 1537 There are timing windows -- particularly in the presence of lost 1538 packets -- where endpoints may not agree on the state of an SA. The 1539 responder to a CREATE_CHILD_SA MUST be prepared to accept messages on 1540 an SA before sending its response to the creation request, so there 1541 is no ambiguity for the initiator. The initiator MAY begin sending 1542 on an SA as soon as it processes the response. The initiator, 1543 however, cannot receive on a newly created SA until it receives and 1544 processes the response to its CREATE_CHILD_SA request. How, then, is 1545 the responder to know when it is OK to send on the newly created SA? 1547 From a technical correctness and interoperability perspective, the 1548 responder MAY begin sending on an SA as soon as it sends its response 1549 to the CREATE_CHILD_SA request. In some situations, however, this 1550 could result in packets unnecessarily being dropped, so an 1551 implementation MAY defer such sending. 1553 The responder can be assured that the initiator is prepared to 1554 receive messages on an SA if either (1) it has received a 1555 cryptographically valid message on the new SA, or (2) the new SA 1556 rekeys an existing SA and it receives an IKE request to close the 1557 replaced SA. When rekeying an SA, the responder continues to send 1558 traffic on the old SA until one of those events occurs. When 1559 establishing a new SA, the responder MAY defer sending messages on a 1560 new SA until either it receives one or a timeout has occurred. {{ 1561 Demoted the SHOULD }} If an initiator receives a message on an SA for 1562 which it has not received a response to its CREATE_CHILD_SA request, 1563 it interprets that as a likely packet loss and retransmits the 1564 CREATE_CHILD_SA request. An initiator MAY send a dummy message on a 1565 newly created SA if it has no messages queued in order to assure the 1566 responder that the initiator is ready to receive messages. 1568 2.8.1. Simultaneous Child SA rekeying 1570 {{ The first two paragraphs were moved, and the rest was added, based 1571 on Clarif-5.11 }} 1573 If the two ends have the same lifetime policies, it is possible that 1574 both will initiate a rekeying at the same time (which will result in 1575 redundant SAs). To reduce the probability of this happening, the 1576 timing of rekeying requests SHOULD be jittered (delayed by a random 1577 amount of time after the need for rekeying is noticed). 1579 This form of rekeying may temporarily result in multiple similar SAs 1580 between the same pairs of nodes. When there are two SAs eligible to 1581 receive packets, a node MUST accept incoming packets through either 1582 SA. If redundant SAs are created though such a collision, the SA 1583 created with the lowest of the four nonces used in the two exchanges 1584 SHOULD be closed by the endpoint that created it. {{ Clarif-5.10 }} 1585 "Lowest" means an octet-by-octet, lexicographical comparison (instead 1586 of, for instance, comparing the nonces as large integers). In other 1587 words, start by comparing the first octet; if they're equal, move to 1588 the next octet, and so on. If you reach the end of one nonce, that 1589 nonce is the lower one. 1591 The following is an explanation on the impact this has on 1592 implementations. Assume that hosts A and B have an existing IPsec SA 1593 pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same 1594 time: 1596 Host A Host B 1597 ------------------------------------------------------------------- 1598 send req1: N(REKEY_SA,SPIa1), 1599 SA(..,SPIa2,..),Ni1,.. --> 1600 <-- send req2: N(REKEY_SA,SPIb1), 1601 SA(..,SPIb2,..),Ni2 1602 recv req2 <-- 1604 At this point, A knows there is a simultaneous rekeying going on. 1605 However, it cannot yet know which of the exchanges will have the 1606 lowest nonce, so it will just note the situation and respond as 1607 usual. 1609 send resp2: SA(..,SPIa3,..), 1610 Nr1,.. --> 1611 --> recv req1 1613 Now B also knows that simultaneous rekeying is going on. It responds 1614 as usual. 1616 <-- send resp1: SA(..,SPIb3,..), 1617 Nr2,.. 1618 recv resp1 <-- 1619 --> recv resp2 1621 At this point, there are three Child SA pairs between A and B (the 1622 old one and two new ones). A and B can now compare the nonces. 1623 Suppose that the lowest nonce was Nr1 in message resp2; in this case, 1624 B (the sender of req2) deletes the redundant new SA, and A (the node 1625 that initiated the surviving rekeyed SA), deletes the old one. 1627 send req3: D(SPIa1) --> 1628 <-- send req4: D(SPIb2) 1629 --> recv req3 1630 <-- send resp3: D(SPIb1) 1631 recv req4 <-- 1632 send resp4: D(SPIa3) --> 1634 The rekeying is now finished. 1636 However, there is a second possible sequence of events that can 1637 happen if some packets are lost in the network, resulting in 1638 retransmissions. The rekeying begins as usual, but A's first packet 1639 (req1) is lost. 1641 Host A Host B 1642 ------------------------------------------------------------------- 1643 send req1: N(REKEY_SA,SPIa1), 1644 SA(..,SPIa2,..), 1645 Ni1,.. --> (lost) 1646 <-- send req2: N(REKEY_SA,SPIb1), 1647 SA(..,SPIb2,..),Ni2 1648 recv req2 <-- 1649 send resp2: SA(..,SPIa3,..), 1650 Nr1,.. --> 1651 --> recv resp2 1652 <-- send req3: D(SPIb1) 1653 recv req3 <-- 1654 send resp3: D(SPIa1) --> 1655 --> recv resp3 1657 From B's point of view, the rekeying is now completed, and since it 1658 has not yet received A's req1, it does not even know that there was 1659 simultaneous rekeying. However, A will continue retransmitting the 1660 message, and eventually it will reach B. 1662 resend req1 --> 1663 --> recv req1 1665 To B, it looks like A is trying to rekey an SA that no longer exists; 1666 thus, B responds to the request with something non-fatal such as 1667 NO_PROPOSAL_CHOSEN. 1669 <-- send resp1: N(NO_PROPOSAL_CHOSEN) 1670 recv resp1 <-- 1672 When A receives this error, it already knows there was simultaneous 1673 rekeying, so it can ignore the error message. 1675 2.8.2. Rekeying the IKE SA Versus Reauthentication 1677 {{ Added this section from Clarif-5.2 }} 1679 Rekeying the IKE SA and reauthentication are different concepts in 1680 IKEv2. Rekeying the IKE SA establishes new keys for the IKE SA and 1681 resets the Message ID counters, but it does not authenticate the 1682 parties again (no AUTH or EAP payloads are involved). 1684 Although rekeying the IKE SA may be important in some environments, 1685 reauthentication (the verification that the parties still have access 1686 to the long-term credentials) is often more important. 1688 IKEv2 does not have any special support for reauthentication. 1690 Reauthentication is done by creating a new IKE SA from scratch (using 1691 IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify 1692 payloads), creating new Child SAs within the new IKE SA (without 1693 REKEY_SA notify payloads), and finally deleting the old IKE SA (which 1694 deletes the old Child SAs as well). 1696 This means that reauthentication also establishes new keys for the 1697 IKE SA and Child SAs. Therefore, while rekeying can be performed 1698 more often than reauthentication, the situation where "authentication 1699 lifetime" is shorter than "key lifetime" does not make sense. 1701 While creation of a new IKE SA can be initiated by either party 1702 (initiator or responder in the original IKE SA), the use of EAP 1703 authentication and/or configuration payloads means in practice that 1704 reauthentication has to be initiated by the same party as the 1705 original IKE SA. IKEv2 does not currently allow the responder to 1706 request reauthentication in this case; however, there are extensions 1707 that add this functionality such as [REAUTH]. 1709 2.9. Traffic Selector Negotiation 1711 {{ Clarif-7.2 }} When an RFC4301-compliant IPsec subsystem receives 1712 an IP packet that matches a "protect" selector in its Security Policy 1713 Database (SPD), the subsystem protects that packet with IPsec. When 1714 no SA exists yet, it is the task of IKE to create it. Maintenance of 1715 a system's SPD is outside the scope of IKE (see [PFKEY] for an 1716 example protocol, although it only applies to IKEv1), though some 1717 implementations might update their SPD in connection with the running 1718 of IKE (for an example scenario, see Section 1.1.3). 1720 Traffic Selector (TS) payloads allow endpoints to communicate some of 1721 the information from their SPD to their peers. TS payloads specify 1722 the selection criteria for packets that will be forwarded over the 1723 newly set up SA. This can serve as a consistency check in some 1724 scenarios to assure that the SPDs are consistent. In others, it 1725 guides the dynamic update of the SPD. 1727 Two TS payloads appear in each of the messages in the exchange that 1728 creates a Child SA pair. Each TS payload contains one or more 1729 Traffic Selectors. Each Traffic Selector consists of an address 1730 range (IPv4 or IPv6), a port range, and an IP protocol ID. 1732 The first of the two TS payloads is known as TSi (Traffic Selector- 1733 initiator). The second is known as TSr (Traffic Selector-responder). 1734 TSi specifies the source address of traffic forwarded from (or the 1735 destination address of traffic forwarded to) the initiator of the 1736 Child SA pair. TSr specifies the destination address of the traffic 1737 forwarded to (or the source address of the traffic forwarded from) 1738 the responder of the Child SA pair. For example, if the original 1739 initiator requests the creation of a Child SA pair, and wishes to 1740 tunnel all traffic from subnet 192.0.1.* on the initiator's side to 1741 subnet 192.0.2.* on the responder's side, the initiator would include 1742 a single traffic selector in each TS payload. TSi would specify the 1743 address range (192.0.1.0 - 192.0.1.255) and TSr would specify the 1744 address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was 1745 acceptable to the responder, it would send identical TS payloads 1746 back. (Note: The IP address range 192.0.2.* has been reserved for 1747 use in examples in RFCs and similar documents. This document needed 1748 two such ranges, and so also used 192.0.1.*. This should not be 1749 confused with any actual address.) 1751 IKEv2 allows the responder to choose a subset of the traffic proposed 1752 by the initiator. This could happen when the configurations of the 1753 two endpoints are being updated but only one end has received the new 1754 information. Since the two endpoints may be configured by different 1755 people, the incompatibility may persist for an extended period even 1756 in the absence of errors. It also allows for intentionally different 1757 configurations, as when one end is configured to tunnel all addresses 1758 and depends on the other end to have the up-to-date list. 1760 When the responder chooses a subset of the traffic proposed by the 1761 initiator, it narrows the traffic selectors to some subset of the 1762 initiator's proposal (provided the set does not become the null set). 1763 If the type of traffic selector proposed is unknown, the responder 1764 ignores that traffic selector, so that the unknown type is not be 1765 returned in the narrowed set. 1767 To enable the responder to choose the appropriate range in this case, 1768 if the initiator has requested the SA due to a data packet, the 1769 initiator SHOULD include as the first traffic selector in each of TSi 1770 and TSr a very specific traffic selector including the addresses in 1771 the packet triggering the request. In the example, the initiator 1772 would include in TSi two traffic selectors: the first containing the 1773 address range (192.0.1.43 - 192.0.1.43) and the source port and IP 1774 protocol from the packet and the second containing (192.0.1.0 - 1775 192.0.1.255) with all ports and IP protocols. The initiator would 1776 similarly include two traffic selectors in TSr. If the initiator 1777 creates the Child SA pair not in response to an arriving packet, but 1778 rather, say, upon startup, then there may be no specific addresses 1779 the initiator prefers for the initial tunnel over any other. In that 1780 case, the first values in TSi and TSr can be ranges rather than 1781 specific values. 1783 The responder performs the narrowing as follows: {{ Clarif-4.10 }} 1784 o If the responder's policy does not allow it to accept any part of 1785 the proposed traffic selectors, it responds with TS_UNACCEPTABLE. 1787 o If the responder's policy allows the entire set of traffic covered 1788 by TSi and TSr, no narrowing is necessary, and the responder can 1789 return the same TSi and TSr values. 1791 o If the responder's policy allows it to accept the first selector 1792 of TSi and TSr, then the responder MUST narrow the traffic 1793 selectors to a subset that includes the initiator's first choices. 1794 In this example above, the responder might respond with TSi being 1795 (192.0.1.43 - 192.0.1.43) with all ports and IP protocols. 1797 o If the responder's policy does not allow it to accept the first 1798 selector of TSi and TSr, the responder narrows to an acceptable 1799 subset of TSi and TSr. 1801 When narrowing is done, there may be several subsets that are 1802 acceptable but their union is not. In this case, the responder 1803 arbitrarily chooses one of them, and MAY include an 1804 ADDITIONAL_TS_POSSIBLE notification in the response. {{ 3.10.1-16386 1805 }} The ADDITIONAL_TS_POSSIBLE notification asserts that the responder 1806 narrowed the proposed traffic selectors but that other traffic 1807 selectors would also have been acceptable, though only in a separate 1808 SA. There is no data associated with this Notify type. This case 1809 will occur only when the initiator and responder are configured 1810 differently from one another. If the initiator and responder agree 1811 on the granularity of tunnels, the initiator will never request a 1812 tunnel wider than the responder will accept. {{ Demoted the SHOULD }} 1813 Such misconfigurations should be recorded in error logs. 1815 It is possible for the responder's policy to contain multiple smaller 1816 ranges, all encompassed by the initiator's traffic selector, and with 1817 the responder's policy being that each of those ranges should be sent 1818 over a different SA. Continuing the example above, the responder 1819 might have a policy of being willing to tunnel those addresses to and 1820 from the initiator, but might require that each address pair be on a 1821 separately negotiated Child SA. If the initiator generated its 1822 request in response to an incoming packet from 192.0.1.43 to 1823 192.0.2.123, there would be no way for the responder to determine 1824 which pair of addresses should be included in this tunnel, and it 1825 would have to make a guess or reject the request with a status of 1826 SINGLE_PAIR_REQUIRED. 1828 {{ 3.10.1-34 }} The SINGLE_PAIR_REQUIRED error indicates that a 1829 CREATE_CHILD_SA request is unacceptable because its sender is only 1830 willing to accept traffic selectors specifying a single pair of 1831 addresses. The requestor is expected to respond by requesting an SA 1832 for only the specific traffic it is trying to forward. 1834 {{ Clarif-4.11 }} Few implementations will have policies that require 1835 separate SAs for each address pair. Because of this, if only some 1836 parts of the TSi and TSr proposed by the initiator are acceptable to 1837 the responder, responders SHOULD narrow the selectors to an 1838 acceptable subset rather than use SINGLE_PAIR_REQUIRED. 1840 2.9.1. Traffic Selectors Violating Own Policy 1842 {{ Clarif-4.12 }} 1844 When creating a new SA, the initiator needs to avoid proposing 1845 traffic selectors that violate its own policy. If this rule is not 1846 followed, valid traffic may be dropped. If you use decorrelated 1847 policies from [IPSECARCH], this kind of policy violations cannot 1848 happen. 1850 This is best illustrated by an example. Suppose that host A has a 1851 policy whose effect is that traffic to 192.0.1.66 is sent via host B 1852 encrypted using AES, and traffic to all other hosts in 192.0.1.0/24 1853 is also sent via B, but must use 3DES. Suppose also that host B 1854 accepts any combination of AES and 3DES. 1856 If host A now proposes an SA that uses 3DES, and includes TSr 1857 containing (192.0.1.0-192.0.1.255), this will be accepted by host B. 1858 Now, host B can also use this SA to send traffic from 192.0.1.66, but 1859 those packets will be dropped by A since it requires the use of AES 1860 for those traffic. Even if host A creates a new SA only for 1861 192.0.1.66 that uses AES, host B may freely continue to use the first 1862 SA for the traffic. In this situation, when proposing the SA, host A 1863 should have followed its own policy, and included a TSr containing 1864 ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead. 1866 In general, if (1) the initiator makes a proposal "for traffic X 1867 (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator 1868 does not actually accept traffic X' with SA, and (3) the initiator 1869 would be willing to accept traffic X' with some SA' (!=SA), valid 1870 traffic can be unnecessarily dropped since the responder can apply 1871 either SA or SA' to traffic X'. 1873 2.10. Nonces 1875 The IKE_SA_INIT messages each contain a nonce. These nonces are used 1876 as inputs to cryptographic functions. The CREATE_CHILD_SA request 1877 and the CREATE_CHILD_SA response also contain nonces. These nonces 1878 are used to add freshness to the key derivation technique used to 1879 obtain keys for Child SA, and to ensure creation of strong pseudo- 1880 random bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST 1881 be randomly chosen, MUST be at least 128 bits in size, and MUST be at 1882 least half the key size of the negotiated prf. ("prf" refers to 1883 "pseudo-random function", one of the cryptographic algorithms 1884 negotiated in the IKE exchange.) {{ Clarif-7.4 }} However, the 1885 initiator chooses the nonce before the outcome of the negotiation is 1886 known. Because of that, the nonce has to be long enough for all the 1887 PRFs being proposed. If the same random number source is used for 1888 both keys and nonces, care must be taken to ensure that the latter 1889 use does not compromise the former. 1891 2.11. Address and Port Agility 1893 IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and 1894 AH associations for the same IP addresses it runs over. The IP 1895 addresses and ports in the outer header are, however, not themselves 1896 cryptographically protected, and IKE is designed to work even through 1897 Network Address Translation (NAT) boxes. An implementation MUST 1898 accept incoming requests even if the source port is not 500 or 4500, 1899 and MUST respond to the address and port from which the request was 1900 received. It MUST specify the address and port at which the request 1901 was received as the source address and port in the response. IKE 1902 functions identically over IPv4 or IPv6. 1904 2.12. Reuse of Diffie-Hellman Exponentials 1906 IKE generates keying material using an ephemeral Diffie-Hellman 1907 exchange in order to gain the property of "perfect forward secrecy". 1908 This means that once a connection is closed and its corresponding 1909 keys are forgotten, even someone who has recorded all of the data 1910 from the connection and gets access to all of the long-term keys of 1911 the two endpoints cannot reconstruct the keys used to protect the 1912 conversation without doing a brute force search of the session key 1913 space. 1915 Achieving perfect forward secrecy requires that when a connection is 1916 closed, each endpoint MUST forget not only the keys used by the 1917 connection but also any information that could be used to recompute 1918 those keys. 1920 Since the computing of Diffie-Hellman exponentials is computationally 1921 expensive, an endpoint may find it advantageous to reuse those 1922 exponentials for multiple connection setups. There are several 1923 reasonable strategies for doing this. An endpoint could choose a new 1924 exponential only periodically though this could result in less-than- 1925 perfect forward secrecy if some connection lasts for less than the 1926 lifetime of the exponential. Or it could keep track of which 1927 exponential was used for each connection and delete the information 1928 associated with the exponential only when some corresponding 1929 connection was closed. This would allow the exponential to be reused 1930 without losing perfect forward secrecy at the cost of maintaining 1931 more state. 1933 Decisions as to whether and when to reuse Diffie-Hellman exponentials 1934 is a private decision in the sense that it will not affect 1935 interoperability. An implementation that reuses exponentials MAY 1936 choose to remember the exponential used by the other endpoint on past 1937 exchanges and if one is reused to avoid the second half of the 1938 calculation. 1940 2.13. Generating Keying Material 1942 In the context of the IKE SA, four cryptographic algorithms are 1943 negotiated: an encryption algorithm, an integrity protection 1944 algorithm, a Diffie-Hellman group, and a pseudo-random function 1945 (prf). The pseudo-random function is used for the construction of 1946 keying material for all of the cryptographic algorithms used in both 1947 the IKE SA and the Child SAs. 1949 We assume that each encryption algorithm and integrity protection 1950 algorithm uses a fixed-size key and that any randomly chosen value of 1951 that fixed size can serve as an appropriate key. For algorithms that 1952 accept a variable length key, a fixed key size MUST be specified as 1953 part of the cryptographic transform negotiated (see Section 3.3.5 for 1954 the defintion of the Key Length transform attribute). For algorithms 1955 for which not all values are valid keys (such as DES or 3DES with key 1956 parity), the algorithm by which keys are derived from arbitrary 1957 values MUST be specified by the cryptographic transform. For 1958 integrity protection functions based on Hashed Message Authentication 1959 Code (HMAC), the fixed key size is the size of the output of the 1960 underlying hash function. 1962 It is assumed that pseudo-random functions (PRFs) accept keys of any 1963 length, but have a preferred key size. The preferred key size is 1964 used as the length of SK_d, SK_pi, and SK_pr (see Section 2.14). For 1965 PRFs based on the HMAC construction, the preferred key size is equal 1966 to the length of the output of the underlying hash function. Other 1967 types of PRFs MUST specify their preferred key size. 1969 Keying material will always be derived as the output of the 1970 negotiated prf algorithm. Since the amount of keying material needed 1971 may be greater than the size of the output of the prf algorithm, we 1972 will use the prf iteratively. We will use the terminology prf+ to 1973 describe the function that outputs a pseudo-random stream based on 1974 the inputs to a prf as follows: (where | indicates concatenation) 1975 prf+ (K,S) = T1 | T2 | T3 | T4 | ... 1977 where: 1978 T1 = prf (K, S | 0x01) 1979 T2 = prf (K, T1 | S | 0x02) 1980 T3 = prf (K, T2 | S | 0x03) 1981 T4 = prf (K, T3 | S | 0x04) 1983 continuing as needed to compute all required keys. The keys are 1984 taken from the output string without regard to boundaries (e.g., if 1985 the required keys are a 256-bit Advanced Encryption Standard (AES) 1986 key and a 160-bit HMAC key, and the prf function generates 160 bits, 1987 the AES key will come from T1 and the beginning of T2, while the HMAC 1988 key will come from the rest of T2 and the beginning of T3). 1990 The constant concatenated to the end of each string feeding the prf 1991 is a single octet. prf+ in this document is not defined beyond 255 1992 times the size of the prf output. 1994 2.14. Generating Keying Material for the IKE SA 1996 The shared keys are computed as follows. A quantity called SKEYSEED 1997 is calculated from the nonces exchanged during the IKE_SA_INIT 1998 exchange and the Diffie-Hellman shared secret established during that 1999 exchange. SKEYSEED is used to calculate seven other secrets: SK_d 2000 used for deriving new keys for the Child SAs established with this 2001 IKE SA; SK_ai and SK_ar used as a key to the integrity protection 2002 algorithm for authenticating the component messages of subsequent 2003 exchanges; SK_ei and SK_er used for encrypting (and of course 2004 decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are 2005 used when generating an AUTH payload. The lengths of SK_d, SK_pi, 2006 and SK_pr are the preferred key length of the agreed-to PRF. 2008 SKEYSEED and its derivatives are computed as follows: 2010 SKEYSEED = prf(Ni | Nr, g^ir) 2012 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } 2013 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) 2015 (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, 2016 SK_pi, and SK_pr are taken in order from the generated bits of the 2017 prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman 2018 exchange. g^ir is represented as a string of octets in big endian 2019 order padded with zeros if necessary to make it the length of the 2020 modulus. Ni and Nr are the nonces, stripped of any headers. For 2021 historical backwards-compatibility reasons, there are two PRFs that 2022 are treated specially in this calculation. If the negotiated PRF is 2023 AES-XCBC-PRF-128 [RFC4434] or AES-CMAC-PRF-128 [RFC4615], only the 2024 first 64 bits of Ni and the first 64 bits of Nr are used in the 2025 calculation. 2027 The two directions of traffic flow use different keys. The keys used 2028 to protect messages from the original initiator are SK_ai and SK_ei. 2029 The keys used to protect messages in the other direction are SK_ar 2030 and SK_er. 2032 2.15. Authentication of the IKE SA 2034 When not using extensible authentication (see Section 2.16), the 2035 peers are authenticated by having each sign (or MAC using a shared 2036 secret as the key) a block of data. For the responder, the octets to 2037 be signed start with the first octet of the first SPI in the header 2038 of the second message (IKE_SA_INIT response) and end with the last 2039 octet of the last payload in the second message. Appended to this 2040 (for purposes of computing the signature) are the initiator's nonce 2041 Ni (just the value, not the payload containing it), and the value 2042 prf(SK_pr,IDr') where IDr' is the responder's ID payload excluding 2043 the fixed header. Note that neither the nonce Ni nor the value 2044 prf(SK_pr,IDr') are transmitted. Similarly, the initiator signs the 2045 first message (IKE_SA_INIT request), starting with the first octet of 2046 the first SPI in the header and ending with the last octet of the 2047 last payload. Appended to this (for purposes of computing the 2048 signature) are the responder's nonce Nr, and the value 2049 prf(SK_pi,IDi'). In the above calculation, IDi' and IDr' are the 2050 entire ID payloads excluding the fixed header. It is critical to the 2051 security of the exchange that each side sign the other side's nonce. 2053 {{ Clarif-3.1 }} 2055 The initiator's signed octets can be described as: 2057 InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI 2058 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 2059 RealIKEHDR = SPIi | SPIr | . . . | Length 2060 RealMessage1 = RealIKEHDR | RestOfMessage1 2061 NonceRPayload = PayloadHeader | NonceRData 2062 InitiatorIDPayload = PayloadHeader | RestOfIDPayload 2063 RestOfInitIDPayload = IDType | RESERVED | InitIDData 2064 MACedIDForI = prf(SK_pi, RestOfInitIDPayload) 2066 The responder's signed octets can be described as: 2068 ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR 2069 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 2070 RealIKEHDR = SPIi | SPIr | . . . | Length 2071 RealMessage2 = RealIKEHDR | RestOfMessage2 2072 NonceIPayload = PayloadHeader | NonceIData 2073 ResponderIDPayload = PayloadHeader | RestOfIDPayload 2074 RestOfRespIDPayload = IDType | RESERVED | RespIDData 2075 MACedIDForR = prf(SK_pr, RestOfRespIDPayload) 2077 Note that all of the payloads are included under the signature, 2078 including any payload types not defined in this document. If the 2079 first message of the exchange is sent multiple times (such as with a 2080 responder cookie and/or a different Diffie-Hellman group), it is the 2081 latest version of the message that is signed. 2083 Optionally, messages 3 and 4 MAY include a certificate, or 2084 certificate chain providing evidence that the key used to compute a 2085 digital signature belongs to the name in the ID payload. The 2086 signature or MAC will be computed using algorithms dictated by the 2087 type of key used by the signer, and specified by the Auth Method 2088 field in the Authentication payload. There is no requirement that 2089 the initiator and responder sign with the same cryptographic 2090 algorithms. The choice of cryptographic algorithms depends on the 2091 type of key each has. In particular, the initiator may be using a 2092 shared key while the responder may have a public signature key and 2093 certificate. It will commonly be the case (but it is not required) 2094 that if a shared secret is used for authentication that the same key 2095 is used in both directions. 2097 Note that it is a common but typically insecure practice to have a 2098 shared key derived solely from a user-chosen password without 2099 incorporating another source of randomness. This is typically 2100 insecure because user-chosen passwords are unlikely to have 2101 sufficient unpredictability to resist dictionary attacks and these 2102 attacks are not prevented in this authentication method. 2103 (Applications using password-based authentication for bootstrapping 2104 and IKE SA should use the authentication method in Section 2.16, 2105 which is designed to prevent off-line dictionary attacks.) {{ Demoted 2106 the SHOULD }} The pre-shared key needs to contain as much 2107 unpredictability as the strongest key being negotiated. In the case 2108 of a pre-shared key, the AUTH value is computed as: 2110 AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), ) 2112 where the string "Key Pad for IKEv2" is 17 ASCII characters without 2113 null termination. The shared secret can be variable length. The pad 2114 string is added so that if the shared secret is derived from a 2115 password, the IKE implementation need not store the password in 2116 cleartext, but rather can store the value prf(Shared Secret,"Key Pad 2117 for IKEv2"), which could not be used as a password equivalent for 2118 protocols other than IKEv2. As noted above, deriving the shared 2119 secret from a password is not secure. This construction is used 2120 because it is anticipated that people will do it anyway. The 2121 management interface by which the Shared Secret is provided MUST 2122 accept ASCII strings of at least 64 octets and MUST NOT add a null 2123 terminator before using them as shared secrets. It MUST also accept 2124 a hex encoding of the Shared Secret. The management interface MAY 2125 accept other encodings if the algorithm for translating the encoding 2126 to a binary string is specified. 2128 2.16. Extensible Authentication Protocol Methods 2130 In addition to authentication using public key signatures and shared 2131 secrets, IKE supports authentication using methods defined in RFC 2132 3748 [EAP]. Typically, these methods are asymmetric (designed for a 2133 user authenticating to a server), and they may not be mutual. For 2134 this reason, these protocols are typically used to authenticate the 2135 initiator to the responder and MUST be used in conjunction with a 2136 public key signature based authentication of the responder to the 2137 initiator. These methods are often associated with mechanisms 2138 referred to as "Legacy Authentication" mechanisms. 2140 While this memo references [EAP] with the intent that new methods can 2141 be added in the future without updating this specification, some 2142 simpler variations are documented here and in Section 3.16. [EAP] 2143 defines an authentication protocol requiring a variable number of 2144 messages. Extensible Authentication is implemented in IKE as 2145 additional IKE_AUTH exchanges that MUST be completed in order to 2146 initialize the IKE SA. 2148 An initiator indicates a desire to use extensible authentication by 2149 leaving out the AUTH payload from message 3. By including an IDi 2150 payload but not an AUTH payload, the initiator has declared an 2151 identity but has not proven it. If the responder is willing to use 2152 an extensible authentication method, it will place an Extensible 2153 Authentication Protocol (EAP) payload in message 4 and defer sending 2154 SAr2, TSi, and TSr until initiator authentication is complete in a 2155 subsequent IKE_AUTH exchange. In the case of a minimal extensible 2156 authentication, the initial SA establishment will appear as follows: 2158 Initiator Responder 2159 ------------------------------------------------------------------- 2160 HDR, SAi1, KEi, Ni --> 2161 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 2162 HDR, SK {IDi, [CERTREQ,] 2163 [IDr,] SAi2, 2164 TSi, TSr} --> 2165 <-- HDR, SK {IDr, [CERT,] AUTH, 2166 EAP } 2167 HDR, SK {EAP} --> 2168 <-- HDR, SK {EAP (success)} 2169 HDR, SK {AUTH} --> 2170 <-- HDR, SK {AUTH, SAr2, TSi, TSr } 2172 {{ Clarif-3.10 }} As described in Section 2.2, when EAP is used, each 2173 pair of IKE SA initial setup messages will have their message numbers 2174 incremented; the first pair of AUTH messages will have an ID of 1, 2175 the second will be 2, and so on. 2177 For EAP methods that create a shared key as a side effect of 2178 authentication, that shared key MUST be used by both the initiator 2179 and responder to generate AUTH payloads in messages 7 and 8 using the 2180 syntax for shared secrets specified in Section 2.15. The shared key 2181 from EAP is the field from the EAP specification named MSK. This 2182 shared key generated during an IKE exchange MUST NOT be used for any 2183 other purpose. 2185 EAP methods that do not establish a shared key SHOULD NOT be used, as 2186 they are subject to a number of man-in-the-middle attacks [EAPMITM] 2187 if these EAP methods are used in other protocols that do not use a 2188 server-authenticated tunnel. Please see the Security Considerations 2189 section for more details. If EAP methods that do not generate a 2190 shared key are used, the AUTH payloads in messages 7 and 8 MUST be 2191 generated using SK_pi and SK_pr, respectively. 2193 {{ Demoted the SHOULD }} The initiator of an IKE SA using EAP needs 2194 to be capable of extending the initial protocol exchange to at least 2195 ten IKE_AUTH exchanges in the event the responder sends notification 2196 messages and/or retries the authentication prompt. Once the protocol 2197 exchange defined by the chosen EAP authentication method has 2198 successfully terminated, the responder MUST send an EAP payload 2199 containing the Success message. Similarly, if the authentication 2200 method has failed, the responder MUST send an EAP payload containing 2201 the Failure message. The responder MAY at any time terminate the IKE 2202 exchange by sending an EAP payload containing the Failure message. 2204 Following such an extended exchange, the EAP AUTH payloads MUST be 2205 included in the two messages following the one containing the EAP 2206 Success message. 2208 {{ Clarif-3.5 }} When the initiator authentication uses EAP, it is 2209 possible that the contents of the IDi payload is used only for AAA 2210 routing purposes and selecting which EAP method to use. This value 2211 may be different from the identity authenticated by the EAP method. 2212 It is important that policy lookups and access control decisions use 2213 the actual authenticated identity. Often the EAP server is 2214 implemented in a separate AAA server that communicates with the IKEv2 2215 responder. In this case, the authenticated identity has to be sent 2216 from the AAA server to the IKEv2 responder. 2218 2.17. Generating Keying Material for Child SAs 2220 A single Child SA is created by the IKE_AUTH exchange, and additional 2221 Child SAs can optionally be created in CREATE_CHILD_SA exchanges. 2222 Keying material for them is generated as follows: 2224 KEYMAT = prf+(SK_d, Ni | Nr) 2226 Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this 2227 request is the first Child SA created or the fresh Ni and Nr from the 2228 CREATE_CHILD_SA exchange if this is a subsequent creation. 2230 For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman 2231 exchange, the keying material is defined as: 2233 KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) 2235 where g^ir (new) is the shared secret from the ephemeral Diffie- 2236 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 2237 octet string in big endian order padded with zeros in the high-order 2238 bits if necessary to make it the length of the modulus). 2240 For ESP and AH, a single Child SA negotiation results in two security 2241 associations (one in each direction). Keying material MUST be taken 2242 from the expanded KEYMAT in the following order: 2244 o The encryption key (if any) for the SA carrying data from the 2245 initiator to the responder. 2247 o The authentication key (if any) for the SA carrying data from the 2248 initiator to the responder. 2250 o The encryption key (if any) for the SA carrying data from the 2251 responder to the initiator. 2253 o The authentication key (if any) for the SA carrying data from the 2254 responder to the initiator. 2256 Each cryptographic algorithm takes a fixed number of bits of keying 2257 material specified as part of the algorithm, or negotiated in SA 2258 payloads (see Section 2.13 for description of key lengths, and 2259 Section 3.3.5 for the definition of the Key Length transform 2260 attribute). 2262 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange 2264 The CREATE_CHILD_SA exchange can be used to rekey an existing IKE SA 2265 (see Section 2.8). {{ Clarif-5.3 }} New initiator and responder SPIs 2266 are supplied in the SPI fields in the Proposal structures inside the 2267 Security Association (SA) payloads (not the SPI fields in the IKE 2268 header). The TS payloads are omitted when rekeying an IKE SA. 2269 SKEYSEED for the new IKE SA is computed using SK_d from the existing 2270 IKE SA as follows: 2272 SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr) 2274 where g^ir (new) is the shared secret from the ephemeral Diffie- 2275 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 2276 octet string in big endian order padded with zeros if necessary to 2277 make it the length of the modulus) and Ni and Nr are the two nonces 2278 stripped of any headers. 2280 {{ Clarif-5.5 }} The old and new IKE SA may have selected a different 2281 PRF. Because the rekeying exchange belongs to the old IKE SA, it is 2282 the old IKE SA's PRF that is used. 2284 {{ Clarif-5.12}} The main rekeying the IKE SA is to ensure that the 2285 compromise of old keying material does not provide information about 2286 the current keys, or vice versa. Therefore, implementations SHOULD 2287 perform a new Diffie-Hellman exchange when rekeying the IKE SA. In 2288 other words, an initiator SHOULD NOT propose the value "NONE" for the 2289 D-H transform, and a responder SHOULD NOT accept such a proposal. 2290 This means that a succesful exchange rekeying the IKE SA always 2291 includes the KEi/KEr payloads. 2293 The new IKE SA MUST reset its message counters to 0. 2295 SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as 2296 specified in Section 2.14. 2298 2.19. Requesting an Internal Address on a Remote Network 2300 Most commonly occurring in the endpoint-to-security-gateway scenario, 2301 an endpoint may need an IP address in the network protected by the 2302 security gateway and may need to have that address dynamically 2303 assigned. A request for such a temporary address can be included in 2304 any request to create a Child SA (including the implicit request in 2305 message 3) by including a CP payload. 2307 This function provides address allocation to an IPsec Remote Access 2308 Client (IRAC) trying to tunnel into a network protected by an IPsec 2309 Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an 2310 IKE SA and a Child SA, the IRAC MUST request the IRAS-controlled 2311 address (and optionally other information concerning the protected 2312 network) in the IKE_AUTH exchange. The IRAS may procure an address 2313 for the IRAC from any number of sources such as a DHCP/BOOTP server 2314 or its own address pool. 2316 Initiator Responder 2317 ------------------------------------------------------------------- 2318 HDR, SK {IDi, [CERT,] 2319 [CERTREQ,] [IDr,] AUTH, 2320 CP(CFG_REQUEST), SAi2, 2321 TSi, TSr} --> 2322 <-- HDR, SK {IDr, [CERT,] AUTH, 2323 CP(CFG_REPLY), SAr2, 2324 TSi, TSr} 2326 In all cases, the CP payload MUST be inserted before the SA payload. 2327 In variations of the protocol where there are multiple IKE_AUTH 2328 exchanges, the CP payloads MUST be inserted in the messages 2329 containing the SA payloads. 2331 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute 2332 (either IPv4 or IPv6) but MAY contain any number of additional 2333 attributes the initiator wants returned in the response. 2335 For example, message from initiator to responder: 2337 CP(CFG_REQUEST)= 2338 INTERNAL_ADDRESS() 2339 TSi = (0, 0-65535,0.0.0.0-255.255.255.255) 2340 TSr = (0, 0-65535,0.0.0.0-255.255.255.255) 2342 NOTE: Traffic Selectors contain (protocol, port range, address 2343 range). 2345 Message from responder to initiator: 2347 CP(CFG_REPLY)= 2348 INTERNAL_ADDRESS(192.0.2.202) 2349 INTERNAL_NETMASK(255.255.255.0) 2350 INTERNAL_SUBNET(192.0.2.0/255.255.255.0) 2351 TSi = (0, 0-65535,192.0.2.202-192.0.2.202) 2352 TSr = (0, 0-65535,192.0.2.0-192.0.2.255) 2354 All returned values will be implementation dependent. As can be seen 2355 in the above example, the IRAS MAY also send other attributes that 2356 were not included in CP(CFG_REQUEST) and MAY ignore the non- 2357 mandatory attributes that it does not support. 2359 {{ 3.10.1-37 }} The FAILED_CP_REQUIRED notification is sent by 2360 responder in the case where CP(CFG_REQUEST) was expected but not 2361 received, and so is a conflict with locally configured policy. There 2362 is no associated data. 2364 The responder MUST NOT send a CFG_REPLY without having first received 2365 a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS 2366 to perform an unnecessary configuration lookup if the IRAC cannot 2367 process the REPLY. In the case where the IRAS's configuration 2368 requires that CP be used for a given identity IDi, but IRAC has 2369 failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and 2370 terminate the IKE exchange with a FAILED_CP_REQUIRED error. The 2371 FAILED_CP_REQUIRED is not fatal to the IKE SA; it simply causes the 2372 Child SA creation fail. The initiator can fix this by later starting 2373 a new configuration payload request. 2375 2.19.1. Configuration Payloads 2377 Editor's note: some of this sub-section is redundant and will go away 2378 in the next version of the document. 2380 In support of the scenario described in Section 1.1.3, an initiator 2381 may request that the responder assign an IP address and tell the 2382 initiator what it is. {{ Clarif-6.1 }} That request is done using 2383 configuration payloads, not traffic selectors. An address in a TSi 2384 payload in a response does not mean that the responder has assigned 2385 that address to the initiator: it only means that if packets matching 2386 these traffic selectors are sent by the initiator, IPsec processing 2387 can be performed as agreed for this SA. 2389 Configuration payloads are of type CFG_REQUEST/CFG_REPLY or CFG_SET/ 2390 CFG_ACK (see CFG Type in the payload description below). CFG_REQUEST 2391 and CFG_SET payloads may optionally be added to any IKE request. The 2392 IKE response MUST include either a corresponding CFG_REPLY or CFG_ACK 2393 or a Notify payload with an error type indicating why the request 2394 could not be honored. An exception is that a minimal implementation 2395 MAY ignore all CFG_REQUEST and CFG_SET payloads, so a response 2396 message without a corresponding CFG_REPLY or CFG_ACK MUST be accepted 2397 as an indication that the request was not supported. 2399 "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information 2400 from its peer. If an attribute in the CFG_REQUEST Configuration 2401 Payload is not zero-length, it is taken as a suggestion for that 2402 attribute. The CFG_REPLY Configuration Payload MAY return that 2403 value, or a new one. It MAY also add new attributes and not include 2404 some requested ones. Requestors MUST ignore returned attributes that 2405 they do not recognize. 2407 Some attributes MAY be multi-valued, in which case multiple attribute 2408 values of the same type are sent and/or returned. Generally, all 2409 values of an attribute are returned when the attribute is requested. 2410 For some attributes (in this version of the specification only 2411 internal addresses), multiple requests indicates a request that 2412 multiple values be assigned. For these attributes, the number of 2413 values returned SHOULD NOT exceed the number requested. 2415 If the data type requested in a CFG_REQUEST is not recognized or not 2416 supported, the responder MUST NOT return an error type but rather 2417 MUST either send a CFG_REPLY that MAY be empty or a reply not 2418 containing a CFG_REPLY payload at all. Error returns are reserved 2419 for cases where the request is recognized but cannot be performed as 2420 requested or the request is badly formatted. 2422 "CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data 2423 to its peer. In this case, the CFG_SET Configuration Payload 2424 contains attributes the initiator wants its peer to alter. The 2425 responder MUST return a Configuration Payload if it accepted any of 2426 the configuration data and it MUST contain the attributes that the 2427 responder accepted with zero-length data. Those attributes that it 2428 did not accept MUST NOT be in the CFG_ACK Configuration Payload. If 2429 no attributes were accepted, the responder MUST return either an 2430 empty CFG_ACK payload or a response message without a CFG_ACK 2431 payload. There are currently no defined uses for the CFG_SET/CFG_ACK 2432 exchange, though they may be used in connection with extensions based 2433 on Vendor IDs. An minimal implementation of this specification MAY 2434 ignore CFG_SET payloads. 2436 {{ Demoted the SHOULD }} Extensions via the CP payload should not be 2437 used for general purpose management. Its main intent is to provide a 2438 bootstrap mechanism to exchange information within IPsec from IRAS to 2439 IRAC. While it MAY be useful to use such a method to exchange 2440 information between some Security Gateways (SGW) or small networks, 2441 existing management protocols such as DHCP [DHCP], RADIUS [RADIUS], 2442 SNMP, or LDAP [LDAP] should be preferred for enterprise management as 2443 well as subsequent information exchanges. 2445 2.20. Requesting the Peer's Version 2447 An IKE peer wishing to inquire about the other peer's IKE software 2448 version information MAY use the method below. This is an example of 2449 a configuration request within an INFORMATIONAL exchange, after the 2450 IKE SA and first Child SA have been created. 2452 An IKE implementation MAY decline to give out version information 2453 prior to authentication or even after authentication to prevent 2454 trolling in case some implementation is known to have some security 2455 weakness. In that case, it MUST either return an empty string or no 2456 CP payload if CP is not supported. 2458 Initiator Responder 2459 ------------------------------------------------------------------- 2460 HDR, SK{CP(CFG_REQUEST)} --> 2461 <-- HDR, SK{CP(CFG_REPLY)} 2463 CP(CFG_REQUEST)= 2464 APPLICATION_VERSION("") 2466 CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar 2467 Inc.") 2469 2.21. Error Handling 2471 There are many kinds of errors that can occur during IKE processing. 2472 If a request is received that is badly formatted or unacceptable for 2473 reasons of policy (e.g., no matching cryptographic algorithms), the 2474 response MUST contain a Notify payload indicating the error. If an 2475 error occurs outside the context of an IKE request (e.g., the node is 2476 getting ESP messages on a nonexistent SPI), the node SHOULD initiate 2477 an INFORMATIONAL exchange with a Notify payload describing the 2478 problem. 2480 Errors that occur before a cryptographically protected IKE SA is 2481 established must be handled very carefully. There is a trade-off 2482 between wanting to be helpful in diagnosing a problem and responding 2483 to it and wanting to avoid being a dupe in a denial of service attack 2484 based on forged messages. 2486 If a node receives a message on UDP port 500 or 4500 outside the 2487 context of an IKE SA known to it (and not a request to start one), it 2488 may be the result of a recent crash of the node. If the message is 2489 marked as a response, the node MAY audit the suspicious event but 2490 MUST NOT respond. If the message is marked as a request, the node 2491 MAY audit the suspicious event and MAY send a response. If a 2492 response is sent, the response MUST be sent to the IP address and 2493 port from whence it came with the same IKE SPIs and the Message ID 2494 copied. The response MUST NOT be cryptographically protected and 2495 MUST contain a Notify payload indicating INVALID_IKE_SPI. {{ 3.10.1-4 2496 }} The INVALID_IKE_SPI notification indicates an IKE message was 2497 received with an unrecognized destination SPI; this usually indicates 2498 that the recipient has rebooted and forgotten the existence of an IKE 2499 SA. 2501 A node receiving such an unprotected Notify payload MUST NOT respond 2502 and MUST NOT change the state of any existing SAs. The message might 2503 be a forgery or might be a response the genuine correspondent was 2504 tricked into sending. {{ Demoted two SHOULDs }} A node should treat 2505 such a message (and also a network message like ICMP destination 2506 unreachable) as a hint that there might be problems with SAs to that 2507 IP address and should initiate a liveness test for any such IKE SA. 2508 An implementation SHOULD limit the frequency of such tests to avoid 2509 being tricked into participating in a denial of service attack. 2511 A node receiving a suspicious message from an IP address with which 2512 it has an IKE SA MAY send an IKE Notify payload in an IKE 2513 INFORMATIONAL exchange over that SA. {{ Demoted the SHOULD }} The 2514 recipient MUST NOT change the state of any SAs as a result, but may 2515 wish to audit the event to aid in diagnosing malfunctions. A node 2516 MUST limit the rate at which it will send messages in response to 2517 unprotected messages. 2519 2.22. IPComp 2521 Use of IP compression [IP-COMP] can be negotiated as part of the 2522 setup of a Child SA. While IP compression involves an extra header 2523 in each packet and a compression parameter index (CPI), the virtual 2524 "compression association" has no life outside the ESP or AH SA that 2525 contains it. Compression associations disappear when the 2526 corresponding ESP or AH SA goes away. It is not explicitly mentioned 2527 in any DELETE payload. 2529 Negotiation of IP compression is separate from the negotiation of 2530 cryptographic parameters associated with a Child SA. A node 2531 requesting a Child SA MAY advertise its support for one or more 2532 compression algorithms through one or more Notify payloads of type 2533 IPCOMP_SUPPORTED. This notification may be included only in a 2534 message containing an SA payload negotiating a Child SA and indicates 2535 a willingness by its sender to use IPComp on this SA. The response 2536 MAY indicate acceptance of a single compression algorithm with a 2537 Notify payload of type IPCOMP_SUPPORTED. These payloads MUST NOT 2538 occur in messages that do not contain SA payloads. 2540 {{ 3.10.1-16387 }}The data associated with this notification includes 2541 a two-octet IPComp CPI followed by a one-octet transform ID 2542 optionally followed by attributes whose length and format are defined 2543 by that transform ID. A message proposing an SA may contain multiple 2544 IPCOMP_SUPPORTED notifications to indicate multiple supported 2545 algorithms. A message accepting an SA may contain at most one. 2547 The transform IDs currently defined are: 2549 Name Number Defined In 2550 ------------------------------------- 2551 RESERVED 0 2552 IPCOMP_OUI 1 2553 IPCOMP_DEFLATE 2 RFC 2394 2554 IPCOMP_LZS 3 RFC 2395 2555 IPCOMP_LZJH 4 RFC 3051 2556 RESERVED TO IANA 5-240 2557 PRIVATE USE 241-255 2559 Although there has been discussion of allowing multiple compression 2560 algorithms to be accepted and to have different compression 2561 algorithms available for the two directions of a Child SA, 2562 implementations of this specification MUST NOT accept an IPComp 2563 algorithm that was not proposed, MUST NOT accept more than one, and 2564 MUST NOT compress using an algorithm other than one proposed and 2565 accepted in the setup of the Child SA. 2567 A side effect of separating the negotiation of IPComp from 2568 cryptographic parameters is that it is not possible to propose 2569 multiple cryptographic suites and propose IP compression with some of 2570 them but not others. 2572 In some cases, Robust Header Compression (ROHC) may be more 2573 appropriate than IP Compression. [ROHCV2] defines the use of ROHC 2574 with IKEv2 and IPsec. 2576 2.23. NAT Traversal 2578 Network Address Translation (NAT) gateways are a controversial 2579 subject. This section briefly describes what they are and how they 2580 are likely to act on IKE traffic. Many people believe that NATs are 2581 evil and that we should not design our protocols so as to make them 2582 work better. IKEv2 does specify some unintuitive processing rules in 2583 order that NATs are more likely to work. 2585 NATs exist primarily because of the shortage of IPv4 addresses, 2586 though there are other rationales. IP nodes that are "behind" a NAT 2587 have IP addresses that are not globally unique, but rather are 2588 assigned from some space that is unique within the network behind the 2589 NAT but that are likely to be reused by nodes behind other NATs. 2590 Generally, nodes behind NATs can communicate with other nodes behind 2591 the same NAT and with nodes with globally unique addresses, but not 2592 with nodes behind other NATs. There are exceptions to that rule. 2593 When those nodes make connections to nodes on the real Internet, the 2594 NAT gateway "translates" the IP source address to an address that 2595 will be routed back to the gateway. Messages to the gateway from the 2596 Internet have their destination addresses "translated" to the 2597 internal address that will route the packet to the correct endnode. 2599 NATs are designed to be "transparent" to endnodes. Neither software 2600 on the node behind the NAT nor the node on the Internet requires 2601 modification to communicate through the NAT. Achieving this 2602 transparency is more difficult with some protocols than with others. 2603 Protocols that include IP addresses of the endpoints within the 2604 payloads of the packet will fail unless the NAT gateway understands 2605 the protocol and modifies the internal references as well as those in 2606 the headers. Such knowledge is inherently unreliable, is a network 2607 layer violation, and often results in subtle problems. 2609 Opening an IPsec connection through a NAT introduces special 2610 problems. If the connection runs in transport mode, changing the IP 2611 addresses on packets will cause the checksums to fail and the NAT 2612 cannot correct the checksums because they are cryptographically 2613 protected. Even in tunnel mode, there are routing problems because 2614 transparently translating the addresses of AH and ESP packets 2615 requires special logic in the NAT and that logic is heuristic and 2616 unreliable in nature. For that reason, IKEv2 will use UDP 2617 encapsulation of IKE and ESP packets. This encoding is slightly less 2618 efficient but is easier for NATs to process. In addition, firewalls 2619 may be configured to pass IPsec traffic over UDP but not ESP/AH or 2620 vice versa. 2622 It is a common practice of NATs to translate TCP and UDP port numbers 2623 as well as addresses and use the port numbers of inbound packets to 2624 decide which internal node should get a given packet. For this 2625 reason, even though IKE packets MUST be sent from and to UDP port 500 2626 or 4500, they MUST be accepted coming from any port and responses 2627 MUST be sent to the port from whence they came. This is because the 2628 ports may be modified as the packets pass through NATs. Similarly, 2629 IP addresses of the IKE endpoints are generally not included in the 2630 IKE payloads because the payloads are cryptographically protected and 2631 could not be transparently modified by NATs. 2633 Port 4500 is reserved for UDP-encapsulated ESP and IKE. {{ Clarif-7.6 2634 }} An IPsec endpoint that discovers a NAT between it and its 2635 correspondent MUST send all subsequent traffic from port 4500, which 2636 NATs should not treat specially (as they might with port 500). 2638 The specific requirements for supporting NAT traversal [NATREQ] are 2639 listed below. Support for NAT traversal is optional. In this 2640 section only, requirements listed as MUST apply only to 2641 implementations supporting NAT traversal. 2643 o IKE MUST listen on port 4500 as well as port 500. IKE MUST 2644 respond to the IP address and port from which packets arrived. 2646 o Both IKE initiator and responder MUST include in their IKE_SA_INIT 2647 packets Notify payloads of type NAT_DETECTION_SOURCE_IP and 2648 NAT_DETECTION_DESTINATION_IP. Those payloads can be used to 2649 detect if there is NAT between the hosts, and which end is behind 2650 the NAT. The location of the payloads in the IKE_SA_INIT packets 2651 is just after the Ni and Nr payloads (before the optional CERTREQ 2652 payload). 2654 o {{ 3.10.1-16388 }} The data associated with the 2655 NAT_DETECTION_SOURCE_IP notification is a SHA-1 digest of the SPIs 2656 (in the order they appear in the header), IP address, and port on 2657 which this packet was sent. There MAY be multiple 2658 NAT_DETECTION_SOURCE_IP payloads in a message if the sender does 2659 not know which of several network attachments will be used to send 2660 the packet. 2662 o {{ 3.10.1-16389 }} The data associated with the 2663 NAT_DETECTION_DESTINATION_IP notification is a SHA-1 digest of the 2664 SPIs (in the order they appear in the header), IP address, and 2665 port to which this packet was sent. 2667 o {{ 3.10.1-16388 }} {{ 3.10.1-16389 }} The recipient of either the 2668 NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP 2669 notification MAY compare the supplied value to a SHA-1 hash of the 2670 SPIs, source IP address, and port, and if they don't match it 2671 SHOULD enable NAT traversal. In the case of a mismatching 2672 NAT_DETECTION_SOURCE_IP hash, the recipient MAY reject the 2673 connection attempt if NAT traversal is not supported. In the case 2674 of a mismatching NAT_DETECTION_DESTINATION_IP hash, it means that 2675 the system receiving the NAT_DETECTION_DESTINATION_IP payload is 2676 behind a NAT and that system SHOULD start sending keepalive 2677 packets as defined in [UDPENCAPS]; alternately, it MAY reject the 2678 connection attempt if NAT traversal is not supported. 2680 o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches 2681 the expected value of the source IP and port found from the IP 2682 header of the packet containing the payload, it means that the 2683 system sending those payloads is behind NAT (i.e., someone along 2684 the route changed the source address of the original packet to 2685 match the address of the NAT box). In this case, the system 2686 receiving the payloads should allow dynamic update of the other 2687 systems' IP address, as described later. 2689 o If the NAT_DETECTION_DESTINATION_IP payload received does not 2690 match the hash of the destination IP and port found from the IP 2691 header of the packet containing the payload, it means that the 2692 system receiving the NAT_DETECTION_DESTINATION_IP payload is 2693 behind a NAT. In this case, that system SHOULD start sending 2694 keepalive packets as explained in [UDPENCAPS]. 2696 o The IKE initiator MUST check these payloads if present and if they 2697 do not match the addresses in the outer packet MUST tunnel all 2698 future IKE and ESP packets associated with this IKE SA over UDP 2699 port 4500. 2701 o To tunnel IKE packets over UDP port 4500, the IKE header has four 2702 octets of zero prepended and the result immediately follows the 2703 UDP header. To tunnel ESP packets over UDP port 4500, the ESP 2704 header immediately follows the UDP header. Since the first four 2705 octets of the ESP header contain the SPI, and the SPI cannot 2706 validly be zero, it is always possible to distinguish ESP and IKE 2707 messages. 2709 o Implementations MUST process received UDP-encapsulated ESP packets 2710 even when no NAT was detected. 2712 o The original source and destination IP address required for the 2713 transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) 2714 are obtained from the Traffic Selectors associated with the 2715 exchange. In the case of NAT traversal, the Traffic Selectors 2716 MUST contain exactly one IP address, which is then used as the 2717 original IP address. 2719 o There are cases where a NAT box decides to remove mappings that 2720 are still alive (for example, the keepalive interval is too long, 2721 or the NAT box is rebooted). To recover in these cases, hosts 2722 that are not behind a NAT SHOULD send all packets (including 2723 retransmission packets) to the IP address and port from the last 2724 valid authenticated packet from the other end (i.e., dynamically 2725 update the address). A host behind a NAT SHOULD NOT do this 2726 because it opens a DoS attack possibility. Any authenticated IKE 2727 packet or any authenticated UDP-encapsulated ESP packet can be 2728 used to detect that the IP address or the port has changed. 2730 2.24. Explicit Congestion Notification (ECN) 2732 When IPsec tunnels behave as originally specified in [IPSECARCH-OLD], 2733 ECN usage is not appropriate for the outer IP headers because tunnel 2734 decapsulation processing discards ECN congestion indications to the 2735 detriment of the network. ECN support for IPsec tunnels for IKEv1- 2736 based IPsec requires multiple operating modes and negotiation (see 2737 [ECN]). IKEv2 simplifies this situation by requiring that ECN be 2738 usable in the outer IP headers of all tunnel-mode IPsec SAs created 2739 by IKEv2. Specifically, tunnel encapsulators and decapsulators for 2740 all tunnel-mode SAs created by IKEv2 MUST support the ECN full- 2741 functionality option for tunnels specified in [ECN] and MUST 2742 implement the tunnel encapsulation and decapsulation processing 2743 specified in [IPSECARCH] to prevent discarding of ECN congestion 2744 indications. 2746 3. Header and Payload Formats 2748 In the tables in this section, some cryptographic primitives and 2749 configuation attributes are marked as "UNSPECIFIED". These are items 2750 for which there are no known specifications and therefore 2751 interoperability is currently impossible. A future specification may 2752 describe their use, but until such specification is made, 2753 implementations SHOULD NOT attempt to use items marked as 2754 "UNSPECIFIED" in implementations that are meant to be interoperable. 2756 3.1. The IKE Header 2758 IKE messages use UDP ports 500 and/or 4500, with one IKE message per 2759 UDP datagram. Information from the beginning of the packet through 2760 the UDP header is largely ignored except that the IP addresses and 2761 UDP ports from the headers are reversed and used for return packets. 2762 When sent on UDP port 500, IKE messages begin immediately following 2763 the UDP header. When sent on UDP port 4500, IKE messages have 2764 prepended four octets of zero. These four octets of zero are not 2765 part of the IKE message and are not included in any of the length 2766 fields or checksums defined by IKE. Each IKE message begins with the 2767 IKE header, denoted HDR in this memo. Following the header are one 2768 or more IKE payloads each identified by a "Next Payload" field in the 2769 preceding payload. Payloads are processed in the order in which they 2770 appear in an IKE message by invoking the appropriate processing 2771 routine according to the "Next Payload" field in the IKE header and 2772 subsequently according to the "Next Payload" field in the IKE payload 2773 itself until a "Next Payload" field of zero indicates that no 2774 payloads follow. If a payload of type "Encrypted" is found, that 2775 payload is decrypted and its contents parsed as additional payloads. 2776 An Encrypted payload MUST be the last payload in a packet and an 2777 Encrypted payload MUST NOT contain another Encrypted payload. 2779 The Recipient SPI in the header identifies an instance of an IKE 2780 security association. It is therefore possible for a single instance 2781 of IKE to multiplex distinct sessions with multiple peers. 2783 All multi-octet fields representing integers are laid out in big 2784 endian order (also known as "most significant byte first", or 2785 "network byte order"). 2787 The format of the IKE header is shown in Figure 4. 2789 1 2 3 2790 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 2791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2792 | IKE SA Initiator's SPI | 2793 | | 2794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2795 | IKE SA Responder's SPI | 2796 | | 2797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2798 | Next Payload | MjVer | MnVer | Exchange Type | Flags | 2799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2800 | Message ID | 2801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2802 | Length | 2803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2805 Figure 4: IKE Header Format 2807 o Initiator's SPI (8 octets) - A value chosen by the initiator to 2808 identify a unique IKE security association. This value MUST NOT 2809 be zero. 2811 o Responder's SPI (8 octets) - A value chosen by the responder to 2812 identify a unique IKE security association. This value MUST be 2813 zero in the first message of an IKE Initial Exchange (including 2814 repeats of that message including a cookie). {{ The phrase "and 2815 MUST NOT be zero in any other message" was removed; Clarif-2.1 }} 2817 o Next Payload (1 octet) - Indicates the type of payload that 2818 immediately follows the header. The format and value of each 2819 payload are defined below. 2821 o Major Version (4 bits) - Indicates the major version of the IKE 2822 protocol in use. Implementations based on this version of IKE 2823 MUST set the Major Version to 2. Implementations based on 2824 previous versions of IKE and ISAKMP MUST set the Major Version to 2825 1. Implementations based on this version of IKE MUST reject or 2826 ignore messages containing a version number greater than 2 with an 2827 INVALID_MAJOR_VERSION notification message as described in Section 2828 2.5. 2830 o Minor Version (4 bits) - Indicates the minor version of the IKE 2831 protocol in use. Implementations based on this version of IKE 2832 MUST set the Minor Version to 0. They MUST ignore the minor 2833 version number of received messages. 2835 o Exchange Type (1 octet) - Indicates the type of exchange being 2836 used. This constrains the payloads sent in each message in an 2837 exchange. 2839 Exchange Type Value 2840 ---------------------------------- 2841 RESERVED 0-33 2842 IKE_SA_INIT 34 2843 IKE_AUTH 35 2844 CREATE_CHILD_SA 36 2845 INFORMATIONAL 37 2846 RESERVED TO IANA 38-239 2847 PRIVATE USE 240-255 2849 o Flags (1 octet) - Indicates specific options that are set for the 2850 message. Presence of options is indicated by the appropriate bit 2851 in the flags field being set. The bits are defined LSB first, so 2852 bit 0 would be the least significant bit of the Flags octet. In 2853 the description below, a bit being 'set' means its value is '1', 2854 while 'cleared' means its value is '0'. 2856 * X(reserved) (bits 0-2) - These bits MUST be cleared when 2857 sending and MUST be ignored on receipt. 2859 * I(nitiator) (bit 3 of Flags) - This bit MUST be set in messages 2860 sent by the original initiator of the IKE SA and MUST be 2861 cleared in messages sent by the original responder. It is used 2862 by the recipient to determine which eight octets of the SPI 2863 were generated by the recipient. This bit changes to reflect 2864 who initiated the last rekey of the IKE SA. 2866 * V(ersion) (bit 4 of Flags) - This bit indicates that the 2867 transmitter is capable of speaking a higher major version 2868 number of the protocol than the one indicated in the major 2869 version number field. Implementations of IKEv2 must clear this 2870 bit when sending and MUST ignore it in incoming messages. 2872 * R(esponse) (bit 5 of Flags) - This bit indicates that this 2873 message is a response to a message containing the same message 2874 ID. This bit MUST be cleared in all request messages and MUST 2875 be set in all responses. An IKE endpoint MUST NOT generate a 2876 response to a message that is marked as being a response. 2878 * X(reserved) (bits 6-7 of Flags) - These bits MUST be cleared 2879 when sending and MUST be ignored on receipt. 2881 o Message ID (4 octets) - Message identifier used to control 2882 retransmission of lost packets and matching of requests and 2883 responses. It is essential to the security of the protocol 2884 because it is used to prevent message replay attacks. See 2885 Section 2.1 and Section 2.2. 2887 o Length (4 octets) - Length of total message (header + payloads) in 2888 octets. 2890 3.2. Generic Payload Header 2892 Each IKE payload defined in Section 3.3 through Section 3.16 begins 2893 with a generic payload header, shown in Figure 5. Figures for each 2894 payload below will include the generic payload header, but for 2895 brevity the description of each field will be omitted. 2897 1 2 3 2898 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 2899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2900 | Next Payload |C| RESERVED | Payload Length | 2901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2903 Figure 5: Generic Payload Header 2905 The Generic Payload Header fields are defined as follows: 2907 o Next Payload (1 octet) - Identifier for the payload type of the 2908 next payload in the message. If the current payload is the last 2909 in the message, then this field will be 0. This field provides a 2910 "chaining" capability whereby additional payloads can be added to 2911 a message by appending it to the end of the message and setting 2912 the "Next Payload" field of the preceding payload to indicate the 2913 new payload's type. An Encrypted payload, which must always be 2914 the last payload of a message, is an exception. It contains data 2915 structures in the format of additional payloads. In the header of 2916 an Encrypted payload, the Next Payload field is set to the payload 2917 type of the first contained payload (instead of 0). The payload 2918 type values are: 2920 Next Payload Type Notation Value 2921 -------------------------------------------------- 2922 No Next Payload 0 2923 RESERVED 1-32 2924 Security Association SA 33 2925 Key Exchange KE 34 2926 Identification - Initiator IDi 35 2927 Identification - Responder IDr 36 2928 Certificate CERT 37 2929 Certificate Request CERTREQ 38 2930 Authentication AUTH 39 2931 Nonce Ni, Nr 40 2932 Notify N 41 2933 Delete D 42 2934 Vendor ID V 43 2935 Traffic Selector - Initiator TSi 44 2936 Traffic Selector - Responder TSr 45 2937 Encrypted E 46 2938 Configuration CP 47 2939 Extensible Authentication EAP 48 2940 RESERVED TO IANA 49-127 2941 PRIVATE USE 128-255 2943 (Payload type values 1-32 should not be assigned in the 2944 future so that there is no overlap with the code assignments 2945 for IKEv1.) 2947 o Critical (1 bit) - MUST be set to zero if the sender wants the 2948 recipient to skip this payload if it does not understand the 2949 payload type code in the Next Payload field of the previous 2950 payload. MUST be set to one if the sender wants the recipient to 2951 reject this entire message if it does not understand the payload 2952 type. MUST be ignored by the recipient if the recipient 2953 understands the payload type code. MUST be set to zero for 2954 payload types defined in this document. Note that the critical 2955 bit applies to the current payload rather than the "next" payload 2956 whose type code appears in the first octet. The reasoning behind 2957 not setting the critical bit for payloads defined in this document 2958 is that all implementations MUST understand all payload types 2959 defined in this document and therefore must ignore the Critical 2960 bit's value. Skipped payloads are expected to have valid Next 2961 Payload and Payload Length fields. 2963 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on 2964 receipt. 2966 o Payload Length (2 octets) - Length in octets of the current 2967 payload, including the generic payload header. 2969 {{ Clarif-7.10 }} Many payloads contain fields marked as "RESERVED". 2970 Some payloads in IKEv2 (and historically in IKEv1) are not aligned to 2971 4-octet boundaries. 2973 3.3. Security Association Payload 2975 The Security Association Payload, denoted SA in this memo, is used to 2976 negotiate attributes of a security association. Assembly of Security 2977 Association Payloads requires great peace of mind. An SA payload MAY 2978 contain multiple proposals. If there is more than one, they MUST be 2979 ordered from most preferred to least preferred. Each proposal 2980 contains a single IPsec protocol (where a protocol is IKE, ESP, or 2981 AH), each protocol MAY contain multiple transforms, and each 2982 transform MAY contain multiple attributes. When parsing an SA, an 2983 implementation MUST check that the total Payload Length is consistent 2984 with the payload's internal lengths and counts. Proposals, 2985 Transforms, and Attributes each have their own variable length 2986 encodings. They are nested such that the Payload Length of an SA 2987 includes the combined contents of the SA, Proposal, Transform, and 2988 Attribute information. The length of a Proposal includes the lengths 2989 of all Transforms and Attributes it contains. The length of a 2990 Transform includes the lengths of all Attributes it contains. 2992 The syntax of Security Associations, Proposals, Transforms, and 2993 Attributes is based on ISAKMP; however the semantics are somewhat 2994 different. The reason for the complexity and the hierarchy is to 2995 allow for multiple possible combinations of algorithms to be encoded 2996 in a single SA. Sometimes there is a choice of multiple algorithms, 2997 whereas other times there is a combination of algorithms. For 2998 example, an initiator might want to propose using ESP with either 2999 (3DES and HMAC_MD5) or (AES and HMAC_SHA1). 3001 One of the reasons the semantics of the SA payload has changed from 3002 ISAKMP and IKEv1 is to make the encodings more compact in common 3003 cases. 3005 The Proposal structure contains within it a Proposal # and an IPsec 3006 protocol ID. Each structure MUST have a proposal number one (1) 3007 greater than the previous structure. The first Proposal in the 3008 initiator's SA payload MUST have a Proposal # of one (1). One reason 3009 to use multiple proposals is to propose both standard crypto ciphers 3010 and combined-mode ciphers. Combined-mode ciphers include both 3011 integrity and encryption in a single encryption algorithm, and are 3012 not allowed to be offered with a separate integrity algorithm other 3013 than "none". If an initiator wants to propose both combined-mode 3014 ciphers and normal ciphers, it must include two proposals: one will 3015 have all the combined-mode ciphers, and the other will have all the 3016 normal ciphers with the integrity algorithms. For example, one such 3017 proposal would have two proposal structures: ESP with ENCR_AES-CCM_8, 3018 ENCR_AES-CCM_12, and ENCR_AES-CCM_16 as Proposal #1, and ESP with 3019 ENCR_AES_CBC, ENCR_3DES, AUTH_AES_XCBC_96, and AUTH_HMAC_SHA1_96 as 3020 Proposal #2. 3022 Each Proposal/Protocol structure is followed by one or more transform 3023 structures. The number of different transforms is generally 3024 determined by the Protocol. AH generally has two transforms: 3025 Extended Sequence Numbers (ESN) and an integrity check algorithm. 3026 ESP generally has three: ESN, an encryption algorithm and an 3027 integrity check algorithm. IKE generally has four transforms: a 3028 Diffie-Hellman group, an integrity check algorithm, a prf algorithm, 3029 and an encryption algorithm. If an algorithm that combines 3030 encryption and integrity protection is proposed, it MUST be proposed 3031 as an encryption algorithm and an integrity protection algorithm MUST 3032 NOT be proposed. For each Protocol, the set of permissible 3033 transforms is assigned transform ID numbers, which appear in the 3034 header of each transform. 3036 If there are multiple transforms with the same Transform Type, the 3037 proposal is an OR of those transforms. If there are multiple 3038 Transforms with different Transform Types, the proposal is an AND of 3039 the different groups. For example, to propose ESP with (3DES or AES- 3040 CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two 3041 Transform Type 1 candidates (one for 3DES and one for AEC-CBC) and 3042 two Transform Type 3 candidates (one for HMAC_MD5 and one for 3043 HMAC_SHA). This effectively proposes four combinations of 3044 algorithms. If the initiator wanted to propose only a subset of 3045 those, for example (3DES and HMAC_MD5) or (IDEA and HMAC_SHA), there 3046 is no way to encode that as multiple transforms within a single 3047 Proposal. Instead, the initiator would have to construct two 3048 different Proposals, each with two transforms. 3050 A given transform MAY have one or more Attributes. Attributes are 3051 necessary when the transform can be used in more than one way, as 3052 when an encryption algorithm has a variable key size. The transform 3053 would specify the algorithm and the attribute would specify the key 3054 size. Most transforms do not have attributes. A transform MUST NOT 3055 have multiple attributes of the same type. To propose alternate 3056 values for an attribute (for example, multiple key sizes for the AES 3057 encryption algorithm), and implementation MUST include multiple 3058 Transforms with the same Transform Type each with a single Attribute. 3060 Note that the semantics of Transforms and Attributes are quite 3061 different from those in IKEv1. In IKEv1, a single Transform carried 3062 multiple algorithms for a protocol with one carried in the Transform 3063 and the others carried in the Attributes. 3065 1 2 3 3066 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 3067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3068 | Next Payload |C| RESERVED | Payload Length | 3069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3070 | | 3071 ~ ~ 3072 | | 3073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3075 Figure 6: Security Association Payload 3077 o Proposals (variable) - One or more proposal substructures. 3079 The payload type for the Security Association Payload is thirty three 3080 (33). 3082 3.3.1. Proposal Substructure 3084 1 2 3 3085 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 3086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3087 | 0 (last) or 2 | RESERVED | Proposal Length | 3088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3089 | Proposal # | Protocol ID | SPI Size |# of Transforms| 3090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3091 ~ SPI (variable) ~ 3092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3093 | | 3094 ~ ~ 3095 | | 3096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3098 Figure 7: Proposal Substructure 3100 o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the 3101 last Proposal Substructure in the SA. This syntax is inherited 3102 from ISAKMP, but is unnecessary because the last Proposal could be 3103 identified from the length of the SA. The value (2) corresponds 3104 to a Payload Type of Proposal in IKEv1, and the first four octets 3105 of the Proposal structure are designed to look somewhat like the 3106 header of a Payload. 3108 o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on 3109 receipt. 3111 o Proposal Length (2 octets) - Length of this proposal, including 3112 all transforms and attributes that follow. 3114 o Proposal # (1 octet) - When a proposal is made, the first proposal 3115 in an SA payload MUST be #1, and subsequent proposals MUST be one 3116 more than the previous proposal (indicating an OR of the two 3117 proposals). When a proposal is accepted, the proposal number in 3118 the SA payload MUST match the number on the proposal sent that was 3119 accepted. 3121 o Protocol ID (1 octet) - Specifies the IPsec protocol identifier 3122 for the current negotiation. The defined values are: 3124 Protocol Protocol ID 3125 ----------------------------------- 3126 RESERVED 0 3127 IKE 1 3128 AH 2 3129 ESP 3 3130 RESERVED TO IANA 4-200 3131 PRIVATE USE 201-255 3133 o SPI Size (1 octet) - For an initial IKE SA negotiation, this field 3134 MUST be zero; the SPI is obtained from the outer header. During 3135 subsequent negotiations, it is equal to the size, in octets, of 3136 the SPI of the corresponding protocol (8 for IKE, 4 for ESP and 3137 AH). 3139 o # of Transforms (1 octet) - Specifies the number of transforms in 3140 this proposal. 3142 o SPI (variable) - The sending entity's SPI. Even if the SPI Size 3143 is not a multiple of 4 octets, there is no padding applied to the 3144 payload. When the SPI Size field is zero, this field is not 3145 present in the Security Association payload. 3147 o Transforms (variable) - One or more transform substructures. 3149 3.3.2. Transform Substructure 3151 1 2 3 3152 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 3153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3154 | 0 (last) or 3 | RESERVED | Transform Length | 3155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3156 |Transform Type | RESERVED | Transform ID | 3157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3158 | | 3159 ~ Transform Attributes ~ 3160 | | 3161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3163 Figure 8: Transform Substructure 3165 o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the 3166 last Transform Substructure in the Proposal. This syntax is 3167 inherited from ISAKMP, but is unnecessary because the last 3168 transform could be identified from the length of the proposal. 3169 The value (3) corresponds to a Payload Type of Transform in IKEv1, 3170 and the first four octets of the Transform structure are designed 3171 to look somewhat like the header of a Payload. 3173 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 3175 o Transform Length - The length (in octets) of the Transform 3176 Substructure including Header and Attributes. 3178 o Transform Type (1 octet) - The type of transform being specified 3179 in this transform. Different protocols support different 3180 transform types. For some protocols, some of the transforms may 3181 be optional. If a transform is optional and the initiator wishes 3182 to propose that the transform be omitted, no transform of the 3183 given type is included in the proposal. If the initiator wishes 3184 to make use of the transform optional to the responder, it 3185 includes a transform substructure with transform ID = 0 as one of 3186 the options. 3188 o Transform ID (2 octets) - The specific instance of the transform 3189 type being proposed. 3191 The transform type values are: 3193 Description Trans. Used In 3194 Type 3195 ------------------------------------------------------------------ 3196 RESERVED 0 3197 Encryption Algorithm (ENCR) 1 IKE and ESP 3198 Pseudo-random Function (PRF) 2 IKE 3199 Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP 3200 Diffie-Hellman Group (D-H) 4 IKE, optional in AH & ESP 3201 Extended Sequence Numbers (ESN) 5 AH and ESP 3202 RESERVED TO IANA 6-240 3203 PRIVATE USE 241-255 3205 (*) Negotiating an integrity algorithm is mandatory for the 3206 Encrypted payload format specified in this document. For example, 3207 [AEAD] specifies additional formats based on authenticated 3208 encryption, in which a separate integrity algorithm is not 3209 negotiated. 3211 For Transform Type 1 (Encryption Algorithm), defined Transform IDs 3212 are: 3214 Name Number Defined In 3215 --------------------------------------------------- 3216 RESERVED 0 3217 ENCR_DES_IV64 1 (UNSPECIFIED) 3218 ENCR_DES 2 (RFC2405), [DES] 3219 ENCR_3DES 3 (RFC2451) 3220 ENCR_RC5 4 (RFC2451) 3221 ENCR_IDEA 5 (RFC2451), [IDEA] 3222 ENCR_CAST 6 (RFC2451) 3223 ENCR_BLOWFISH 7 (RFC2451) 3224 ENCR_3IDEA 8 (UNSPECIFIED) 3225 ENCR_DES_IV32 9 (UNSPECIFIED) 3226 RESERVED 10 3227 ENCR_NULL 11 (RFC2410) 3228 ENCR_AES_CBC 12 (RFC3602) 3229 ENCR_AES_CTR 13 (RFC3686) 3230 RESERVED TO IANA 14-1023 3231 PRIVATE USE 1024-65535 3233 For Transform Type 2 (Pseudo-random Function), defined Transform IDs 3234 are: 3236 Name Number Defined In 3237 ------------------------------------------------------ 3238 RESERVED 0 3239 PRF_HMAC_MD5 1 (RFC2104), [MD5] 3240 PRF_HMAC_SHA1 2 (RFC2104), [SHA] 3241 PRF_HMAC_TIGER 3 (RFC2104) 3242 PRF_AES128_XCBC 4 (RFC4434) 3243 RESERVED TO IANA 5-1023 3244 PRIVATE USE 1024-65535 3246 For Transform Type 3 (Integrity Algorithm), defined Transform IDs 3247 are: 3249 Name Number Defined In 3250 ---------------------------------------- 3251 NONE 0 3252 AUTH_HMAC_MD5_96 1 (RFC2403) 3253 AUTH_HMAC_SHA1_96 2 (RFC2404) 3254 AUTH_DES_MAC 3 (UNSPECIFIED) 3255 AUTH_KPDK_MD5 4 (UNSPECIFIED) 3256 AUTH_AES_XCBC_96 5 (RFC3566) 3257 RESERVED TO IANA 6-1023 3258 PRIVATE USE 1024-65535 3260 For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs 3261 are: 3263 Name Number Defined in 3264 ---------------------------------------- 3265 NONE 0 3266 768 Bit MODP 1 Appendix B 3267 1024 Bit MODP 2 Appendix B 3268 RESERVED TO IANA 3-4 3269 1536-bit MODP 5 [ADDGROUP] 3270 RESERVED TO IANA 6-13 3271 2048-bit MODP 14 [ADDGROUP] 3272 3072-bit MODP 15 [ADDGROUP] 3273 4096-bit MODP 16 [ADDGROUP] 3274 6144-bit MODP 17 [ADDGROUP] 3275 8192-bit MODP 18 [ADDGROUP] 3276 RESERVED TO IANA 19-1023 3277 PRIVATE USE 1024-65535 3279 For Transform Type 5 (Extended Sequence Numbers), defined Transform 3280 IDs are: 3282 Name Number 3283 -------------------------------------------- 3284 No Extended Sequence Numbers 0 3285 Extended Sequence Numbers 1 3286 RESERVED 2 - 65535 3288 {{ Clarif-4.4 }} Note that an initiator who supports ESNs will 3289 usually include two ESN transforms, with values "0" and "1", in its 3290 proposals. A proposal containing a single ESN transform with value 3291 "1" means that using normal (non-extended) sequence numbers is not 3292 acceptable. 3294 Numerous additional transform types have been defined since the 3295 publication of RFC 4306. Please refer to the IANA IKEv2 registry for 3296 details. 3298 3.3.3. Valid Transform Types by Protocol 3300 The number and type of transforms that accompany an SA payload are 3301 dependent on the protocol in the SA itself. An SA payload proposing 3302 the establishment of an SA has the following mandatory and optional 3303 transform types. A compliant implementation MUST understand all 3304 mandatory and optional types for each protocol it supports (though it 3305 need not accept proposals with unacceptable suites). A proposal MAY 3306 omit the optional types if the only value for them it will accept is 3307 NONE. 3309 Protocol Mandatory Types Optional Types 3310 --------------------------------------------------- 3311 IKE ENCR, PRF, INTEG*, D-H 3312 ESP ENCR, ESN INTEG, D-H 3313 AH INTEG, ESN D-H 3315 (*) Negotiating an integrity algorithm is mandatory for the 3316 Encrypted payload format specified in this document. For example, 3317 [AEAD] specifies additional formats based on authenticated 3318 encryption, in which a separate integrity algorithm is not 3319 negotiated. 3321 3.3.4. Mandatory Transform IDs 3323 The specification of suites that MUST and SHOULD be supported for 3324 interoperability has been removed from this document because they are 3325 likely to change more rapidly than this document evolves. 3327 An important lesson learned from IKEv1 is that no system should only 3328 implement the mandatory algorithms and expect them to be the best 3329 choice for all customers. 3331 It is likely that IANA will add additional transforms in the future, 3332 and some users may want to use private suites, especially for IKE 3333 where implementations should be capable of supporting different 3334 parameters, up to certain size limits. In support of this goal, all 3335 implementations of IKEv2 SHOULD include a management facility that 3336 allows specification (by a user or system administrator) of Diffie- 3337 Hellman (DH) parameters (the generator, modulus, and exponent lengths 3338 and values) for new DH groups. Implementations SHOULD provide a 3339 management interface through which these parameters and the 3340 associated transform IDs may be entered (by a user or system 3341 administrator), to enable negotiating such groups. 3343 All implementations of IKEv2 MUST include a management facility that 3344 enables a user or system administrator to specify the suites that are 3345 acceptable for use with IKE. Upon receipt of a payload with a set of 3346 transform IDs, the implementation MUST compare the transmitted 3347 transform IDs against those locally configured via the management 3348 controls, to verify that the proposed suite is acceptable based on 3349 local policy. The implementation MUST reject SA proposals that are 3350 not authorized by these IKE suite controls. Note that cryptographic 3351 suites that MUST be implemented need not be configured as acceptable 3352 to local policy. 3354 3.3.5. Transform Attributes 3356 Each transform in a Security Association payload may include 3357 attributes that modify or complete the specification of the 3358 transform. The set of valid attributes depends on the transform. 3359 Currently, only a single attribute type is defined: the Key Length 3360 attribute is used by certain encryption transforms with variable- 3361 length keys (see below for details). 3363 The attributes are type/value pairs and are defined below. 3364 Attributes can have a value with a fixed two-octet length or a 3365 variable-length value. For the latter, the attribute is encoded as 3366 type/length/value. 3368 1 2 3 3369 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 3370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3371 |A| Attribute Type | AF=0 Attribute Length | 3372 |F| | AF=1 Attribute Value | 3373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3374 | AF=0 Attribute Value | 3375 | AF=1 Not Transmitted | 3376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3378 Figure 9: Data Attributes 3380 o Attribute Format (AF) (1 bit) - Indicates whether the data 3381 attribute follow the Type/Length/Value (TLV) format or a shortened 3382 Type/Value (TV) format. If the AF bit is zero (0), then the 3383 attribute uses TLV format; if the AF bit is one (1), the TV format 3384 (with two-byte value) is used. 3386 o Attribute Type (15 bits) - Unique identifier for each type of 3387 attribute (see below). 3389 o Attribute Value (variable length) - Value of the Attribute 3390 associated with the Attribute Type. If the AF bit is a zero (0), 3391 this field has a variable length defined by the Attribute Length 3392 field. If the AF bit is a one (1), the Attribute Value has a 3393 length of 2 octets. 3395 Note that the only currently defined attribute type (Key Length) is 3396 fixed length; the variable-length encoding specification is included 3397 only for future extensions. Attributes described as fixed length 3398 MUST NOT be encoded using the variable-length encoding. Variable- 3399 length attributes MUST NOT be encoded as fixed-length even if their 3400 value can fit into two octets. NOTE: This is a change from IKEv1, 3401 where increased flexibility may have simplified the composer of 3402 messages but certainly complicated the parser. 3404 Attribute Type Value Attribute Format 3405 ------------------------------------------------------------ 3406 RESERVED 0-13 3407 Key Length (in bits) 14 TV 3408 RESERVED 15-17 3409 RESERVED TO IANA 18-16383 3410 PRIVATE USE 16384-32767 3412 Values 0-13 and 15-17 were used in a similar context in IKEv1, and 3413 should not be assigned except to matching values. 3415 The Key Length attribute specifies the key length in bits (MUST use 3416 network byte order) for certain transforms as follows: {{ Clarif-7.11 3417 }} 3419 o The Key Length attribute MUST NOT be used with transforms that use 3420 a fixed length key. This includes, e.g., ENCR_DES, ENCR_IDEA, and 3421 all the Type 2 (Pseudo-random function) and Type 3 (Integrity 3422 Algorithm) transforms specified in this document. It is 3423 recommended that future Type 2 or 3 transforms do not use this 3424 attribute. 3426 o Some transforms specify that the Key Length attribute MUST be 3427 always included (omitting the attribute is not allowed, and 3428 proposals not containing it MUST be rejected). This includes, 3429 e.g., ENCR_AES_CBC and ENCR_AES_CTR. 3431 o Some transforms allow variable-length keys, but also specify a 3432 default key length if the attribute is not included. These 3433 transforms include, e.g., ENCR_RC5 and ENCR_BLOWFISH. 3435 Implementation note: To further interoperability and to support 3436 upgrading endpoints independently, implementers of this protocol 3437 SHOULD accept values that they deem to supply greater security. For 3438 instance, if a peer is configured to accept a variable-length cipher 3439 with a key length of X bits and is offered that cipher with a larger 3440 key length, the implementation SHOULD accept the offer if it supports 3441 use of the longer key. 3443 Support of this capability allows a responder to express a concept of 3444 "at least" a certain level of security -- "a key length of _at least_ 3445 X bits for cipher Y". However, as the attribute is always returned 3446 unchanged (see Section 3.3.6), an initiator willing to accept 3447 multiple key lengths has to include multiple transforms with the same 3448 Transform Type, each with different Key Length attribute. 3450 3.3.6. Attribute Negotiation 3452 During security association negotiation initiators present offers to 3453 responders. Responders MUST select a single complete set of 3454 parameters from the offers (or reject all offers if none are 3455 acceptable). If there are multiple proposals, the responder MUST 3456 choose a single proposal. If the selected proposal has multiple 3457 Transforms with the same type, the responder MUST choose a single 3458 one. Any attributes of a selected transform MUST be returned 3459 unmodified. The initiator of an exchange MUST check that the 3460 accepted offer is consistent with one of its proposals, and if not 3461 that response MUST be rejected. 3463 If the responder receives a proposal that contains a Transform Type 3464 it does not understand, or a proposal that is missing a mandatory 3465 Transform Type, it MUST consider this proposal unacceptable; however, 3466 other proposals in the same SA payload are processed as usual. 3467 Similarly, if the responder receives a transform that contains a 3468 Transform Attribute it does not understand, it MUST consider this 3469 transform unacceptable; other transforms with the same Transform Type 3470 are processed as usual. This allows new Transform Types and 3471 Transform Attributes to be defined in the future. 3473 Negotiating Diffie-Hellman groups presents some special challenges. 3474 SA offers include proposed attributes and a Diffie-Hellman public 3475 number (KE) in the same message. If in the initial exchange the 3476 initiator offers to use one of several Diffie-Hellman groups, it 3477 SHOULD pick the one the responder is most likely to accept and 3478 include a KE corresponding to that group. If the guess turns out to 3479 be wrong, the responder will indicate the correct group in the 3480 response and the initiator SHOULD pick an element of that group for 3481 its KE value when retrying the first message. It SHOULD, however, 3482 continue to propose its full supported set of groups in order to 3483 prevent a man-in-the-middle downgrade attack. 3485 3.4. Key Exchange Payload 3487 The Key Exchange Payload, denoted KE in this memo, is used to 3488 exchange Diffie-Hellman public numbers as part of a Diffie-Hellman 3489 key exchange. The Key Exchange Payload consists of the IKE generic 3490 payload header followed by the Diffie-Hellman public value itself. 3492 1 2 3 3493 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 3494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3495 | Next Payload |C| RESERVED | Payload Length | 3496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3497 | DH Group # | RESERVED | 3498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3499 | | 3500 ~ Key Exchange Data ~ 3501 | | 3502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3504 Figure 10: Key Exchange Payload Format 3506 A key exchange payload is constructed by copying one's Diffie-Hellman 3507 public value into the "Key Exchange Data" portion of the payload. 3508 The length of the Diffie-Hellman public value MUST be equal to the 3509 length of the prime modulus over which the exponentiation was 3510 performed, prepending zero bits to the value if necessary. 3512 The DH Group # identifies the Diffie-Hellman group in which the Key 3513 Exchange Data was computed (see Section 3.3.2). If the selected 3514 proposal uses a different Diffie-Hellman group (other than NONE), the 3515 message MUST be rejected with a Notify payload of type 3516 INVALID_KE_PAYLOAD. 3518 The payload type for the Key Exchange payload is thirty four (34). 3520 3.5. Identification Payloads 3522 The Identification Payloads, denoted IDi and IDr in this memo, allow 3523 peers to assert an identity to one another. This identity may be 3524 used for policy lookup, but does not necessarily have to match 3525 anything in the CERT payload; both fields may be used by an 3526 implementation to perform access control decisions. {{ Clarif-7.1 }} 3527 When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr 3528 payloads, IKEv2 does not require this address to match the address in 3529 the IP header of IKEv2 packets, or anything in the TSi/TSr payloads. 3530 The contents of IDi/IDr is used purely to fetch the policy and 3531 authentication data related to the other party. 3533 NOTE: In IKEv1, two ID payloads were used in each direction to hold 3534 Traffic Selector (TS) information for data passing over the SA. In 3535 IKEv2, this information is carried in TS payloads (see Section 3.13). 3537 The Identification Payload consists of the IKE generic payload header 3538 followed by identification fields as follows: 3540 1 2 3 3541 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 3542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3543 | Next Payload |C| RESERVED | Payload Length | 3544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3545 | ID Type | RESERVED | 3546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3547 | | 3548 ~ Identification Data ~ 3549 | | 3550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3552 Figure 11: Identification Payload Format 3554 o ID Type (1 octet) - Specifies the type of Identification being 3555 used. 3557 o RESERVED - MUST be sent as zero; MUST be ignored on receipt. 3559 o Identification Data (variable length) - Value, as indicated by the 3560 Identification Type. The length of the Identification Data is 3561 computed from the size in the ID payload header. 3563 The payload types for the Identification Payload are thirty five (35) 3564 for IDi and thirty six (36) for IDr. 3566 The following table lists the assigned values for the Identification 3567 Type field: 3569 ID Type Value 3570 ------------------------------------------------------------------- 3571 RESERVED 0 3573 ID_IPV4_ADDR 1 3574 A single four (4) octet IPv4 address. 3576 ID_FQDN 2 3577 A fully-qualified domain name string. An example of a ID_FQDN 3578 is, "example.com". The string MUST not contain any terminators 3579 (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; 3580 for an "internationalized domain name", the syntax is as defined 3581 in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net". 3583 ID_RFC822_ADDR 3 3584 A fully-qualified RFC822 email address string, An example of a 3585 ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not 3586 contain any terminators. Because of [EAI], implementations would 3587 be wise to treat this field as UTF-8 encoded text, not as 3588 pure ASCII. 3590 RESERVED TO IANA 4 3592 ID_IPV6_ADDR 5 3593 A single sixteen (16) octet IPv6 address. 3595 RESERVED TO IANA 6 - 8 3597 ID_DER_ASN1_DN 9 3598 The binary Distinguished Encoding Rules (DER) encoding of an 3599 ASN.1 X.500 Distinguished Name [X.501]. 3601 ID_DER_ASN1_GN 10 3602 The binary DER encoding of an ASN.1 X.500 GeneralName [X.509]. 3604 ID_KEY_ID 11 3605 An opaque octet stream which may be used to pass vendor- 3606 specific information necessary to do certain proprietary 3607 types of identification. 3609 RESERVED TO IANA 12-200 3611 PRIVATE USE 201-255 3613 Two implementations will interoperate only if each can generate a 3614 type of ID acceptable to the other. To assure maximum 3615 interoperability, implementations MUST be configurable to send at 3616 least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and 3617 MUST be configurable to accept all of these types. Implementations 3618 SHOULD be capable of generating and accepting all of these types. 3619 IPv6-capable implementations MUST additionally be configurable to 3620 accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable 3621 to send only ID_IPV6_ADDR. 3623 {{ Clarif-3.4 }} EAP [EAP] does not mandate the use of any particular 3624 type of identifier, but often EAP is used with Network Access 3625 Identifiers (NAIs) defined in [NAI]. Although NAIs look a bit like 3626 email addresses (e.g., "joe@example.com"), the syntax is not exactly 3627 the same as the syntax of email address in [MAILFORMAT]. For those 3628 NAIs that include the realm component, the ID_RFC822_ADDR 3629 identification type SHOULD be used. Responder implementations should 3630 not attempt to verify that the contents actually conform to the exact 3631 syntax given in [MAILFORMAT], but instead should accept any 3632 reasonable-looking NAI. For NAIs that do not include the realm 3633 component,the ID_KEY_ID identification type SHOULD be used. 3635 3.6. Certificate Payload 3637 The Certificate Payload, denoted CERT in this memo, provides a means 3638 to transport certificates or other authentication-related information 3639 via IKE. Certificate payloads SHOULD be included in an exchange if 3640 certificates are available to the sender unless the peer has 3641 indicated an ability to retrieve this information from elsewhere 3642 using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the 3643 term "Certificate Payload" is somewhat misleading, because not all 3644 authentication mechanisms use certificates and data other than 3645 certificates may be passed in this payload. 3647 The Certificate Payload is defined as follows: 3649 1 2 3 3650 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 3651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3652 | Next Payload |C| RESERVED | Payload Length | 3653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3654 | Cert Encoding | | 3655 +-+-+-+-+-+-+-+-+ | 3656 ~ Certificate Data ~ 3657 | | 3658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3660 Figure 12: Certificate Payload Format 3662 o Certificate Encoding (1 octet) - This field indicates the type of 3663 certificate or certificate-related information contained in the 3664 Certificate Data field. 3666 Certificate Encoding Value 3667 ---------------------------------------------------- 3668 RESERVED 0 3669 PKCS #7 wrapped X.509 certificate 1 UNSPECIFIED 3670 PGP Certificate 2 UNSPECIFIED 3671 DNS Signed Key 3 UNSPECIFIED 3672 X.509 Certificate - Signature 4 3673 Kerberos Token 6 UNSPECIFIED 3674 Certificate Revocation List (CRL) 7 3675 Authority Revocation List (ARL) 8 UNSPECIFIED 3676 SPKI Certificate 9 UNSPECIFIED 3677 X.509 Certificate - Attribute 10 UNSPECIFIED 3678 Raw RSA Key 11 3679 Hash and URL of X.509 certificate 12 3680 Hash and URL of X.509 bundle 13 3681 RESERVED to IANA 14 - 200 3682 PRIVATE USE 201 - 255 3684 o Certificate Data (variable length) - Actual encoding of 3685 certificate data. The type of certificate is indicated by the 3686 Certificate Encoding field. 3688 The payload type for the Certificate Payload is thirty seven (37). 3690 Specific syntax for some of the certificate type codes above is not 3691 defined in this document. The types whose syntax is defined in this 3692 document are: 3694 o X.509 Certificate - Signature (4) contains a DER encoded X.509 3695 certificate whose public key is used to validate the sender's AUTH 3696 payload. 3698 o Certificate Revocation List (7) contains a DER encoded X.509 3699 certificate revocation list. 3701 o {{ Added "DER-encoded RSAPublicKey structure" from Clarif-3.6 }} 3702 Raw RSA Key (11) contains a PKCS #1 encoded RSA key, that is, a 3703 DER-encoded RSAPublicKey structure (see [RSA] and [PKCS1]). 3705 o Hash and URL encodings (12-13) allow IKE messages to remain short 3706 by replacing long data structures with a 20 octet SHA-1 hash (see 3707 [SHA]) of the replaced value followed by a variable-length URL 3708 that resolves to the DER encoded data structure itself. This 3709 improves efficiency when the endpoints have certificate data 3710 cached and makes IKE less subject to denial of service attacks 3711 that become easier to mount when IKE messages are large enough to 3712 require IP fragmentation [DOSUDPPROT]. 3714 Use the following ASN.1 definition for an X.509 bundle: 3716 CertBundle 3717 { iso(1) identified-organization(3) dod(6) internet(1) 3718 security(5) mechanisms(5) pkix(7) id-mod(0) 3719 id-mod-cert-bundle(34) } 3721 DEFINITIONS EXPLICIT TAGS ::= 3722 BEGIN 3724 IMPORTS 3725 Certificate, CertificateList 3726 FROM PKIX1Explicit88 3727 { iso(1) identified-organization(3) dod(6) 3728 internet(1) security(5) mechanisms(5) pkix(7) 3729 id-mod(0) id-pkix1-explicit(18) } ; 3731 CertificateOrCRL ::= CHOICE { 3732 cert [0] Certificate, 3733 crl [1] CertificateList } 3735 CertificateBundle ::= SEQUENCE OF CertificateOrCRL 3737 END 3739 Implementations MUST be capable of being configured to send and 3740 accept up to four X.509 certificates in support of authentication, 3741 and also MUST be capable of being configured to send and accept the 3742 two Hash and URL formats (with HTTP URLs). Implementations SHOULD be 3743 capable of being configured to send and accept Raw RSA keys. If 3744 multiple certificates are sent, the first certificate MUST contain 3745 the public key used to sign the AUTH payload. The other certificates 3746 may be sent in any order. 3748 3.7. Certificate Request Payload 3750 The Certificate Request Payload, denoted CERTREQ in this memo, 3751 provides a means to request preferred certificates via IKE and can 3752 appear in the IKE_INIT_SA response and/or the IKE_AUTH request. 3753 Certificate Request payloads MAY be included in an exchange when the 3754 sender needs to get the certificate of the receiver. If multiple CAs 3755 are trusted and the certificate encoding does not allow a list, then 3756 multiple Certificate Request payloads would need to be transmitted. 3758 The Certificate Request Payload is defined as follows: 3760 1 2 3 3761 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 3762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3763 | Next Payload |C| RESERVED | Payload Length | 3764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3765 | Cert Encoding | | 3766 +-+-+-+-+-+-+-+-+ | 3767 ~ Certification Authority ~ 3768 | | 3769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3771 Figure 13: Certificate Request Payload Format 3773 o Certificate Encoding (1 octet) - Contains an encoding of the type 3774 or format of certificate requested. Values are listed in 3775 Section 3.6. 3777 o Certification Authority (variable length) - Contains an encoding 3778 of an acceptable certification authority for the type of 3779 certificate requested. 3781 The payload type for the Certificate Request Payload is thirty eight 3782 (38). 3784 The Certificate Encoding field has the same values as those defined 3785 in Section 3.6. The Certification Authority field contains an 3786 indicator of trusted authorities for this certificate type. The 3787 Certification Authority value is a concatenated list of SHA-1 hashes 3788 of the public keys of trusted Certification Authorities (CAs). Each 3789 is encoded as the SHA-1 hash of the Subject Public Key Info element 3790 (see section 4.1.2.7 of [PKIX]) from each Trust Anchor certificate. 3791 The twenty-octet hashes are concatenated and included with no other 3792 formatting. 3794 {{ Clarif-3.6 }} The contents of the "Certification Authority" field 3795 are defined only for X.509 certificates, which are types 4, 10, 12, 3796 and 13. Other values SHOULD NOT be used until standards-track 3797 specifications that specify their use are published. 3799 Note that the term "Certificate Request" is somewhat misleading, in 3800 that values other than certificates are defined in a "Certificate" 3801 payload and requests for those values can be present in a Certificate 3802 Request Payload. The syntax of the Certificate Request payload in 3803 such cases is not defined in this document. 3805 The Certificate Request Payload is processed by inspecting the "Cert 3806 Encoding" field to determine whether the processor has any 3807 certificates of this type. If so, the "Certification Authority" 3808 field is inspected to determine if the processor has any certificates 3809 that can be validated up to one of the specified certification 3810 authorities. This can be a chain of certificates. 3812 If an end-entity certificate exists that satisfies the criteria 3813 specified in the CERTREQ, a certificate or certificate chain SHOULD 3814 be sent back to the certificate requestor if the recipient of the 3815 CERTREQ: 3817 o is configured to use certificate authentication, 3819 o is allowed to send a CERT payload, 3821 o has matching CA trust policy governing the current negotiation, 3822 and 3824 o has at least one time-wise and usage appropriate end-entity 3825 certificate chaining to a CA provided in the CERTREQ. 3827 Certificate revocation checking must be considered during the 3828 chaining process used to select a certificate. Note that even if two 3829 peers are configured to use two different CAs, cross-certification 3830 relationships should be supported by appropriate selection logic. 3832 The intent is not to prevent communication through the strict 3833 adherence of selection of a certificate based on CERTREQ, when an 3834 alternate certificate could be selected by the sender that would 3835 still enable the recipient to successfully validate and trust it 3836 through trust conveyed by cross-certification, CRLs, or other out-of- 3837 band configured means. Thus, the processing of a CERTREQ should be 3838 seen as a suggestion for a certificate to select, not a mandated one. 3839 If no certificates exist, then the CERTREQ is ignored. This is not 3840 an error condition of the protocol. There may be cases where there 3841 is a preferred CA sent in the CERTREQ, but an alternate might be 3842 acceptable (perhaps after prompting a human operator). 3844 {{ 3.10.1-16392 }} The HTTP_CERT_LOOKUP_SUPPORTED notification MAY be 3845 included in any message that can include a CERTREQ payload and 3846 indicates that the sender is capable of looking up certificates based 3847 on an HTTP-based URL (and hence presumably would prefer to receive 3848 certificate specifications in that format). 3850 3.8. Authentication Payload 3852 The Authentication Payload, denoted AUTH in this memo, contains data 3853 used for authentication purposes. The syntax of the Authentication 3854 data varies according to the Auth Method as specified below. 3856 The Authentication Payload is defined as follows: 3858 1 2 3 3859 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 3860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3861 | Next Payload |C| RESERVED | Payload Length | 3862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3863 | Auth Method | RESERVED | 3864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3865 | | 3866 ~ Authentication Data ~ 3867 | | 3868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3870 Figure 14: Authentication Payload Format 3872 o Auth Method (1 octet) - Specifies the method of authentication 3873 used. Values defined are: 3875 * RSA Digital Signature (1) - Computed as specified in 3876 Section 2.15 using an RSA private key with RSASSA-PKCS1-v1_5 3877 signature scheme specified in [PKCS1] (implementors should note 3878 that IKEv1 used a different method for RSA signatures) {{ 3879 Clarif-3.3 }}. {{ Clarif-3.2 }} To promote interoperability, 3880 implementations that support this type SHOULD support 3881 signatures that use SHA-1 as the hash function and SHOULD use 3882 SHA-1 as the default hash function when generating signatures. 3884 * Shared Key Message Integrity Code (2) - Computed as specified 3885 in Section 2.15 using the shared key associated with the 3886 identity in the ID payload and the negotiated prf function 3888 * DSS Digital Signature (3) - Computed as specified in 3889 Section 2.15 using a DSS private key (see [DSS]) over a SHA-1 3890 hash. 3892 * The values 0 and 4-200 are reserved to IANA. The values 201- 3893 255 are available for private use. 3895 o Authentication Data (variable length) - see Section 2.15. 3897 The payload type for the Authentication Payload is thirty nine (39). 3899 3.9. Nonce Payload 3901 The Nonce Payload, denoted Ni and Nr in this memo for the initiator's 3902 and responder's nonce respectively, contains random data used to 3903 guarantee liveness during an exchange and protect against replay 3904 attacks. 3906 The Nonce Payload is defined as follows: 3908 1 2 3 3909 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 3910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3911 | Next Payload |C| RESERVED | Payload Length | 3912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3913 | | 3914 ~ Nonce Data ~ 3915 | | 3916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3918 Figure 15: Nonce Payload Format 3920 o Nonce Data (variable length) - Contains the random data generated 3921 by the transmitting entity. 3923 The payload type for the Nonce Payload is forty (40). 3925 The size of a Nonce MUST be between 16 and 256 octets inclusive. 3926 Nonce values MUST NOT be reused. 3928 3.10. Notify Payload 3930 The Notify Payload, denoted N in this document, is used to transmit 3931 informational data, such as error conditions and state transitions, 3932 to an IKE peer. A Notify Payload may appear in a response message 3933 (usually specifying why a request was rejected), in an INFORMATIONAL 3934 Exchange (to report an error not in an IKE request), or in any other 3935 message to indicate sender capabilities or to modify the meaning of 3936 the request. 3938 The Notify Payload is defined as follows: 3940 1 2 3 3941 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 3942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3943 | Next Payload |C| RESERVED | Payload Length | 3944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3945 | Protocol ID | SPI Size | Notify Message Type | 3946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3947 | | 3948 ~ Security Parameter Index (SPI) ~ 3949 | | 3950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3951 | | 3952 ~ Notification Data ~ 3953 | | 3954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3956 Figure 16: Notify Payload Format 3958 o Protocol ID (1 octet) - If this notification concerns an existing 3959 SA whose SPI is given the SPI field, this field indicates the type 3960 of that SA. For notifications concerning IPsec SAs this field 3961 MUST contain either (2) to indicate AH or (3) to indicate ESP. {{ 3962 Clarif-7.8 }} Of the notifications defined in this document, the 3963 SPI is included only with INVALID_SELECTORS and REKEY_SA. If the 3964 SPI field is empty, this field MUST be sent as zero and MUST be 3965 ignored on receipt. All other values for this field are reserved 3966 to IANA for future assignment. 3968 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 3969 IPsec protocol ID or zero if no SPI is applicable. For a 3970 notification concerning the IKE SA, the SPI Size MUST be zero and 3971 the field must be empty. 3973 o Notify Message Type (2 octets) - Specifies the type of 3974 notification message. 3976 o SPI (variable length) - Security Parameter Index. 3978 o Notification Data (variable length) - Informational or error data 3979 transmitted in addition to the Notify Message Type. Values for 3980 this field are type specific (see below). 3982 The payload type for the Notify Payload is forty one (41). 3984 3.10.1. Notify Message Types 3986 Notification information can be error messages specifying why an SA 3987 could not be established. It can also be status data that a process 3988 managing an SA database wishes to communicate with a peer process. 3989 The table below lists the Notification messages and their 3990 corresponding values. The number of different error statuses was 3991 greatly reduced from IKEv1 both for simplification and to avoid 3992 giving configuration information to probers. 3994 Types in the range 0 - 16383 are intended for reporting errors. An 3995 implementation receiving a Notify payload with one of these types 3996 that it does not recognize in a response MUST assume that the 3997 corresponding request has failed entirely. {{ Demoted the SHOULD }} 3998 Unrecognized error types in a request and status types in a request 3999 or response MUST be ignored, and they should be logged. 4001 Notify payloads with status types MAY be added to any message and 4002 MUST be ignored if not recognized. They are intended to indicate 4003 capabilities, and as part of SA negotiation are used to negotiate 4004 non-cryptographic parameters. 4006 NOTIFY messages: error types Value 4007 ------------------------------------------------------------------- 4009 RESERVED 0 4011 UNSUPPORTED_CRITICAL_PAYLOAD 1 4012 See Section 2.5. 4014 INVALID_IKE_SPI 4 4015 See Section 2.21. 4017 INVALID_MAJOR_VERSION 5 4018 See Section 2.5. 4020 INVALID_SYNTAX 7 4021 Indicates the IKE message that was received was invalid because 4022 some type, length, or value was out of range or because the 4023 request was rejected for policy reasons. To avoid a denial of 4024 service attack using forged messages, this status may only be 4025 returned for and in an encrypted packet if the message ID and 4026 cryptographic checksum were valid. To avoid leaking information 4027 to someone probing a node, this status MUST be sent in response 4028 to any error not covered by one of the other status types. 4029 {{ Demoted the SHOULD }} To aid debugging, more detailed error 4030 information should be written to a console or log. 4032 INVALID_MESSAGE_ID 9 4033 See Section 2.3. 4035 INVALID_SPI 11 4036 See Section 1.5. 4038 NO_PROPOSAL_CHOSEN 14 4039 See Section 2.7. 4041 INVALID_KE_PAYLOAD 17 4042 See Section 1.3. 4044 AUTHENTICATION_FAILED 24 4045 Sent in the response to an IKE_AUTH message when for some reason 4046 the authentication failed. There is no associated data. 4048 SINGLE_PAIR_REQUIRED 34 4049 See Section 2.9. 4051 NO_ADDITIONAL_SAS 35 4052 See Section 1.3. 4054 INTERNAL_ADDRESS_FAILURE 36 4055 See Section 3.15.4. 4057 FAILED_CP_REQUIRED 37 4058 See Section 2.19. 4060 TS_UNACCEPTABLE 38 4061 See Section 2.9. 4063 INVALID_SELECTORS 39 4064 MAY be sent in an IKE INFORMATIONAL exchange when a node receives 4065 an ESP or AH packet whose selectors do not match those of the SA 4066 on which it was delivered (and that caused the packet to be 4067 dropped). The Notification Data contains the start of the 4068 offending packet (as in ICMP messages) and the SPI field of the 4069 notification is set to match the SPI of the IPsec SA. 4071 RESERVED TO IANA 40-8191 4073 PRIVATE USE 8192-16383 4074 NOTIFY messages: status types Value 4075 ------------------------------------------------------------------- 4077 INITIAL_CONTACT 16384 4078 See Section 2.4. 4080 SET_WINDOW_SIZE 16385 4081 See Section 2.3. 4083 ADDITIONAL_TS_POSSIBLE 16386 4084 See Section 2.9. 4086 IPCOMP_SUPPORTED 16387 4087 See Section 2.22. 4089 NAT_DETECTION_SOURCE_IP 16388 4090 See Section 2.23. 4092 NAT_DETECTION_DESTINATION_IP 16389 4093 See Section 2.23. 4095 COOKIE 16390 4096 See Section 2.6. 4098 USE_TRANSPORT_MODE 16391 4099 See Section 1.3.1. 4101 HTTP_CERT_LOOKUP_SUPPORTED 16392 4102 See Section 3.6. 4104 REKEY_SA 16393 4105 See Section 1.3.3. 4107 ESP_TFC_PADDING_NOT_SUPPORTED 16394 4108 See Section 1.3.1. 4110 NON_FIRST_FRAGMENTS_ALSO 16395 4111 See Section 1.3.1. 4113 RESERVED TO IANA 16396-40959 4115 PRIVATE USE 40960-65535 4117 3.11. Delete Payload 4119 The Delete Payload, denoted D in this memo, contains a protocol 4120 specific security association identifier that the sender has removed 4121 from its security association database and is, therefore, no longer 4122 valid. Figure 17 shows the format of the Delete Payload. It is 4123 possible to send multiple SPIs in a Delete payload; however, each SPI 4124 MUST be for the same protocol. Mixing of protocol identifiers MUST 4125 NOT be performed in the Delete payload. It is permitted, however, to 4126 include multiple Delete payloads in a single INFORMATIONAL exchange 4127 where each Delete payload lists SPIs for a different protocol. 4129 Deletion of the IKE SA is indicated by a protocol ID of 1 (IKE) but 4130 no SPIs. Deletion of a Child SA, such as ESP or AH, will contain the 4131 IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI 4132 is the SPI the sending endpoint would expect in inbound ESP or AH 4133 packets. 4135 The Delete Payload is defined as follows: 4137 1 2 3 4138 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 4139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4140 | Next Payload |C| RESERVED | Payload Length | 4141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4142 | Protocol ID | SPI Size | # of SPIs | 4143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4144 | | 4145 ~ Security Parameter Index(es) (SPI) ~ 4146 | | 4147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4149 Figure 17: Delete Payload Format 4151 o Protocol ID (1 octet) - Must be 1 for an IKE SA, 2 for AH, or 3 4152 for ESP. 4154 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 4155 protocol ID. It MUST be zero for IKE (SPI is in message header) 4156 or four for AH and ESP. 4158 o # of SPIs (2 octets) - The number of SPIs contained in the Delete 4159 payload. The size of each SPI is defined by the SPI Size field. 4161 o Security Parameter Index(es) (variable length) - Identifies the 4162 specific security association(s) to delete. The length of this 4163 field is determined by the SPI Size and # of SPIs fields. 4165 The payload type for the Delete Payload is forty two (42). 4167 3.12. Vendor ID Payload 4169 The Vendor ID Payload, denoted V in this memo, contains a vendor 4170 defined constant. The constant is used by vendors to identify and 4171 recognize remote instances of their implementations. This mechanism 4172 allows a vendor to experiment with new features while maintaining 4173 backward compatibility. 4175 A Vendor ID payload MAY announce that the sender is capable of 4176 accepting certain extensions to the protocol, or it MAY simply 4177 identify the implementation as an aid in debugging. A Vendor ID 4178 payload MUST NOT change the interpretation of any information defined 4179 in this specification (i.e., the critical bit MUST be set to 0). 4180 Multiple Vendor ID payloads MAY be sent. An implementation is NOT 4181 REQUIRED to send any Vendor ID payload at all. 4183 A Vendor ID payload may be sent as part of any message. Reception of 4184 a familiar Vendor ID payload allows an implementation to make use of 4185 Private USE numbers described throughout this memo-- private 4186 payloads, private exchanges, private notifications, etc. Unfamiliar 4187 Vendor IDs MUST be ignored. 4189 Writers of Internet-Drafts who wish to extend this protocol MUST 4190 define a Vendor ID payload to announce the ability to implement the 4191 extension in the Internet-Draft. It is expected that Internet-Drafts 4192 that gain acceptance and are standardized will be given "magic 4193 numbers" out of the Future Use range by IANA, and the requirement to 4194 use a Vendor ID will go away. 4196 The Vendor ID Payload fields are defined as follows: 4198 1 2 3 4199 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 4200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4201 | Next Payload |C| RESERVED | Payload Length | 4202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4203 | | 4204 ~ Vendor ID (VID) ~ 4205 | | 4206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4208 Figure 18: Vendor ID Payload Format 4210 o Vendor ID (variable length) - It is the responsibility of the 4211 person choosing the Vendor ID to assure its uniqueness in spite of 4212 the absence of any central registry for IDs. Good practice is to 4213 include a company name, a person name, or some such. If you want 4214 to show off, you might include the latitude and longitude and time 4215 where you were when you chose the ID and some random input. A 4216 message digest of a long unique string is preferable to the long 4217 unique string itself. 4219 The payload type for the Vendor ID Payload is forty three (43). 4221 3.13. Traffic Selector Payload 4223 The Traffic Selector Payload, denoted TS in this memo, allows peers 4224 to identify packet flows for processing by IPsec security services. 4225 The Traffic Selector Payload consists of the IKE generic payload 4226 header followed by individual traffic selectors as follows: 4228 1 2 3 4229 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 4230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4231 | Next Payload |C| RESERVED | Payload Length | 4232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4233 | Number of TSs | RESERVED | 4234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4235 | | 4236 ~ ~ 4237 | | 4238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4240 Figure 19: Traffic Selectors Payload Format 4242 o Number of TSs (1 octet) - Number of traffic selectors being 4243 provided. 4245 o RESERVED - This field MUST be sent as zero and MUST be ignored on 4246 receipt. 4248 o Traffic Selectors (variable length) - One or more individual 4249 traffic selectors. 4251 The length of the Traffic Selector payload includes the TS header and 4252 all the traffic selectors. 4254 The payload type for the Traffic Selector payload is forty four (44) 4255 for addresses at the initiator's end of the SA and forty five (45) 4256 for addresses at the responder's end. 4258 {{ Clarif-4.7 }} There is no requirement that TSi and TSr contain the 4259 same number of individual traffic selectors. Thus, they are 4260 interpreted as follows: a packet matches a given TSi/TSr if it 4261 matches at least one of the individual selectors in TSi, and at least 4262 one of the individual selectors in TSr. 4264 For instance, the following traffic selectors: 4266 TSi = ((17, 100, 192.0.1.66-192.0.1.66), 4267 (17, 200, 192.0.1.66-192.0.1.66)) 4268 TSr = ((17, 300, 0.0.0.0-255.255.255.255), 4269 (17, 400, 0.0.0.0-255.255.255.255)) 4271 would match UDP packets from 192.0.1.66 to anywhere, with any of the 4272 four combinations of source/destination ports (100,300), (100,400), 4273 (200,300), and (200, 400). 4275 Thus, some types of policies may require several Child SA pairs. For 4276 instance, a policy matching only source/destination ports (100,300) 4277 and (200,400), but not the other two combinations, cannot be 4278 negotiated as a single Child SA pair. 4280 3.13.1. Traffic Selector 4282 1 2 3 4283 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 4284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4285 | TS Type |IP Protocol ID*| Selector Length | 4286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4287 | Start Port* | End Port* | 4288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4289 | | 4290 ~ Starting Address* ~ 4291 | | 4292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4293 | | 4294 ~ Ending Address* ~ 4295 | | 4296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4298 Figure 20: Traffic Selector 4300 *Note: All fields other than TS Type and Selector Length depend on 4301 the TS Type. The fields shown are for TS Types 7 and 8, the only two 4302 values currently defined. 4304 o TS Type (one octet) - Specifies the type of traffic selector. 4306 o IP protocol ID (1 octet) - Value specifying an associated IP 4307 protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that the 4308 protocol ID is not relevant to this traffic selector-- the SA can 4309 carry all protocols. 4311 o Selector Length - Specifies the length of this Traffic Selector 4312 Substructure including the header. 4314 o Start Port (2 octets) - Value specifying the smallest port number 4315 allowed by this Traffic Selector. For protocols for which port is 4316 undefined (including protocol 0), or if all ports are allowed, 4317 this field MUST be zero. For the ICMP protocol, the two one-octet 4318 fields Type and Code are treated as a single 16-bit integer (with 4319 Type in the most significant eight bits and Code in the least 4320 significant eight bits) port number for the purposes of filtering 4321 based on this field. 4323 o End Port (2 octets) - Value specifying the largest port number 4324 allowed by this Traffic Selector. For protocols for which port is 4325 undefined (including protocol 0), or if all ports are allowed, 4326 this field MUST be 65535. For the ICMP protocol, the two one- 4327 octet fields Type and Code are treated as a single 16-bit integer 4328 (with Type in the most significant eight bits and Code in the 4329 least significant eight bits) port number for the purposed of 4330 filtering based on this field. 4332 o Starting Address - The smallest address included in this Traffic 4333 Selector (length determined by TS type). 4335 o Ending Address - The largest address included in this Traffic 4336 Selector (length determined by TS type). 4338 Systems that are complying with [IPSECARCH] that wish to indicate 4339 "ANY" ports MUST set the start port to 0 and the end port to 65535; 4340 note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems 4341 working with [IPSECARCH] that wish to indicate "OPAQUE" ports, but 4342 not "ANY" ports, MUST set the start port to 65535 and the end port to 4343 0. 4345 {{ Added from Clarif-4.8 }} The traffic selector types 7 and 8 can 4346 also refer to ICMP type and code fields. Note, however, that ICMP 4347 packets do not have separate source and destination port fields. The 4348 method for specifying the traffic selectors for ICMP is shown by 4349 example in Section 4.4.1.3 of [IPSECARCH]. 4351 {{ Added from Clarif-4.9 }} Traffic selectors can use IP Protocol ID 4352 135 to match the IPv6 mobility header [MIPV6]. This document does 4353 not specify how to represent the "MH Type" field in traffic 4354 selectors, although it is likely that a different document will 4355 specify this in the future. Note that [IPSECARCH] says that the IPv6 4356 mobility header (MH) message type is placed in the most significant 4357 eight bits of the 16-bit local port selector. The direction 4358 semantics of TSi/TSr port fields are the same as for ICMP. 4360 The following table lists the assigned values for the Traffic 4361 Selector Type field and the corresponding Address Selector Data. 4363 TS Type Value 4364 ------------------------------------------------------------------- 4365 RESERVED 0-6 4367 TS_IPV4_ADDR_RANGE 7 4369 A range of IPv4 addresses, represented by two four-octet 4370 values. The first value is the beginning IPv4 address 4371 (inclusive) and the second value is the ending IPv4 address 4372 (inclusive). All addresses falling between the two specified 4373 addresses are considered to be within the list. 4375 TS_IPV6_ADDR_RANGE 8 4377 A range of IPv6 addresses, represented by two sixteen-octet 4378 values. The first value is the beginning IPv6 address 4379 (inclusive) and the second value is the ending IPv6 address 4380 (inclusive). All addresses falling between the two specified 4381 addresses are considered to be within the list. 4383 RESERVED TO IANA 9-240 4384 PRIVATE USE 241-255 4386 3.14. Encrypted Payload 4388 The Encrypted Payload, denoted SK{...} or E in this memo, contains 4389 other payloads in encrypted form. The Encrypted Payload, if present 4390 in a message, MUST be the last payload in the message. Often, it is 4391 the only payload in the message. 4393 The algorithms for encryption and integrity protection are negotiated 4394 during IKE SA setup, and the keys are computed as specified in 4395 Section 2.14 and Section 2.18. 4397 This document specifies the cryptographic processing of Encrypted 4398 payloads using a block cipher in CBC mode and an integrity check 4399 algorithm that computes a fixed-length checksum over a variable size 4400 message. The design is modeled after the ESP algorithms described in 4401 RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document 4402 completely specifies the cryptographic processing of IKE data, but 4403 those documents should be consulted for design rationale. Future 4404 documents may specify the processing of Encrypted payloads for other 4405 types of transforms, such as counter mode encryption and 4406 authenticated encryption algorithms. Peers MUST NOT negotiate 4407 transforms for which no such specification exists. 4409 The payload type for an Encrypted payload is forty six (46). The 4410 Encrypted Payload consists of the IKE generic payload header followed 4411 by individual fields as follows: 4413 1 2 3 4414 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 4415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4416 | Next Payload |C| RESERVED | Payload Length | 4417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4418 | Initialization Vector | 4419 | (length is block size for encryption algorithm) | 4420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4421 ~ Encrypted IKE Payloads ~ 4422 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4423 | | Padding (0-255 octets) | 4424 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 4425 | | Pad Length | 4426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4427 ~ Integrity Checksum Data ~ 4428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4430 Figure 21: Encrypted Payload Format 4432 o Next Payload - The payload type of the first embedded payload. 4433 Note that this is an exception in the standard header format, 4434 since the Encrypted payload is the last payload in the message and 4435 therefore the Next Payload field would normally be zero. But 4436 because the content of this payload is embedded payloads and there 4437 was no natural place to put the type of the first one, that type 4438 is placed here. 4440 o Payload Length - Includes the lengths of the header, IV, Encrypted 4441 IKE Payloads, Padding, Pad Length, and Integrity Checksum Data. 4443 o Initialization Vector - For CBC mode ciphers, the length of the 4444 initialization vector (IV) is equal to the block length of the 4445 underlying encryption algorithm. Senders MUST select a new 4446 unpredictable IV for every message; recipients MUST accept any 4447 value. For other modes than CBC, the IV format and processing is 4448 specified in the document specifying the encryption algorithm and 4449 mode. The reader is encouraged to consult [MODES] for advice on 4450 IV generation. In particular, using the final ciphertext block of 4451 the previous message is not considered unpredictable. 4453 o IKE Payloads are as specified earlier in this section. This field 4454 is encrypted with the negotiated cipher. 4456 o Padding MAY contain any value chosen by the sender, and MUST have 4457 a length that makes the combination of the Payloads, the Padding, 4458 and the Pad Length to be a multiple of the encryption block size. 4459 This field is encrypted with the negotiated cipher. 4461 o Pad Length is the length of the Padding field. The sender SHOULD 4462 set the Pad Length to the minimum value that makes the combination 4463 of the Payloads, the Padding, and the Pad Length a multiple of the 4464 block size, but the recipient MUST accept any length that results 4465 in proper alignment. This field is encrypted with the negotiated 4466 cipher. 4468 o Integrity Checksum Data is the cryptographic checksum of the 4469 entire message starting with the Fixed IKE Header through the Pad 4470 Length. The checksum MUST be computed over the encrypted message. 4471 Its length is determined by the integrity algorithm negotiated. 4473 3.15. Configuration Payload 4475 The Configuration payload, denoted CP in this document, is used to 4476 exchange configuration information between IKE peers. The exchange 4477 is for an IRAC to request an internal IP address from an IRAS and to 4478 exchange other information of the sort that one would acquire with 4479 Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly 4480 connected to a LAN. 4482 The Configuration Payload is defined as follows: 4484 1 2 3 4485 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 4486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4487 | Next Payload |C| RESERVED | Payload Length | 4488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4489 | CFG Type | RESERVED | 4490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4491 | | 4492 ~ Configuration Attributes ~ 4493 | | 4494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4496 Figure 22: Configuration Payload Format 4498 The payload type for the Configuration Payload is forty seven (47). 4500 o CFG Type (1 octet) - The type of exchange represented by the 4501 Configuration Attributes. 4503 CFG Type Value 4504 -------------------------- 4505 RESERVED 0 4506 CFG_REQUEST 1 4507 CFG_REPLY 2 4508 CFG_SET 3 4509 CFG_ACK 4 4510 RESERVED TO IANA 5-127 4511 PRIVATE USE 128-255 4513 o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on 4514 receipt. 4516 o Configuration Attributes (variable length) - These are type length 4517 values specific to the Configuration Payload and are defined 4518 below. There may be zero or more Configuration Attributes in this 4519 payload. 4521 3.15.1. Configuration Attributes 4523 1 2 3 4524 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 4525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4526 |R| Attribute Type | Length | 4527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4528 | | 4529 ~ Value ~ 4530 | | 4531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4533 Figure 23: Configuration Attribute Format 4535 o Reserved (1 bit) - This bit MUST be set to zero and MUST be 4536 ignored on receipt. 4538 o Attribute Type (15 bits) - A unique identifier for each of the 4539 Configuration Attribute Types. 4541 o Length (2 octets) - Length in octets of Value. 4543 o Value (0 or more octets) - The variable-length value of this 4544 Configuration Attribute. The following attribute types have been 4545 defined: 4547 Multi- 4548 Attribute Type Value Valued Length 4549 ------------------------------------------------------- 4550 RESERVED 0 4551 INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets 4552 INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets 4553 INTERNAL_IP4_DNS 3 YES 0 or 4 octets 4554 INTERNAL_IP4_NBNS 4 YES 0 or 4 octets 4555 RESERVED 5 4556 INTERNAL_IP4_DHCP 6 YES 0 or 4 octets 4557 APPLICATION_VERSION 7 NO 0 or more 4558 INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets 4559 RESERVED 9 4560 INTERNAL_IP6_DNS 10 YES 0 or 16 octets 4561 INTERNAL_IP6_NBNS 11 YES 0 or 16 octets 4562 INTERNAL_IP6_DHCP 12 YES 0 or 16 octets 4563 INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets 4564 SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 4565 INTERNAL_IP6_SUBNET 15 YES 17 octets 4566 RESERVED TO IANA 16-16383 4567 PRIVATE USE 16384-32767 4569 * These attributes may be multi-valued on return only if 4570 multiple values were requested. 4572 o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the 4573 internal network, sometimes called a red node address or private 4574 address and MAY be a private address on the Internet. {{ 4575 Clarif-6.2}} In a request message, the address specified is a 4576 requested address (or a zero-length address if no specific address 4577 is requested). If a specific address is requested, it likely 4578 indicates that a previous connection existed with this address and 4579 the requestor would like to reuse that address. With IPv6, a 4580 requestor MAY supply the low-order address octets it wants to use. 4581 Multiple internal addresses MAY be requested by requesting 4582 multiple internal address attributes. The responder MAY only send 4583 up to the number of addresses requested. The INTERNAL_IP6_ADDRESS 4584 is made up of two fields: the first is a 16-octet IPv6 address, 4585 and the second is a one-octet prefix-length as defined in 4586 [ADDRIPV6]. The requested address is valid until there are no IKE 4587 SAs between the peers. This is described in more detail in 4588 Section 3.15.3. 4590 o INTERNAL_IP4_NETMASK - The internal network's netmask. Only one 4591 netmask is allowed in the request and reply messages (e.g., 4592 255.255.255.0), and it MUST be used only with an 4593 INTERNAL_IP4_ADDRESS attribute. {{ Clarif-6.4 }} 4594 INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the same thing 4595 as INTERNAL_IP4_SUBNET containing the same information ("send 4596 traffic to these addresses through me"), but also implies a link 4597 boundary. For instance, the client could use its own address and 4598 the netmask to calculate the broadcast address of the link. An 4599 empty INTERNAL_IP4_NETMASK attribute can be included in a 4600 CFG_REQUEST to request this information (although the gateway can 4601 send the information even when not requested). Non-empty values 4602 for this attribute in a CFG_REQUEST do not make sense and thus 4603 MUST NOT be included. 4605 o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS 4606 server within the network. Multiple DNS servers MAY be requested. 4607 The responder MAY respond with zero or more DNS server attributes. 4609 o INTERNAL_IP4_NBNS - Specifies an address of a NetBios Name Server 4610 (WINS) within the network. Multiple NBNS servers MAY be 4611 requested. The responder MAY respond with zero or more NBNS 4612 server attributes. 4614 o INTERNAL_IP6_NBNS - {{ Clarif-6.6 }} NetBIOS is not defined for 4615 IPv6; therefore, INTERNAL_IP6_NBNS is also unspecified and is only 4616 retained for compatibility with RFC 4306. 4618 o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send 4619 any internal DHCP requests to the address contained within the 4620 attribute. Multiple DHCP servers MAY be requested. The responder 4621 MAY respond with zero or more DHCP server attributes. 4623 o APPLICATION_VERSION - The version or application information of 4624 the IPsec host. This is a string of printable ASCII characters 4625 that is NOT null terminated. 4627 o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge- 4628 device protects. This attribute is made up of two fields: the 4629 first being an IP address and the second being a netmask. 4630 Multiple sub-networks MAY be requested. The responder MAY respond 4631 with zero or more sub-network attributes. This is discussed in 4632 more detail in Section 3.15.2. 4634 o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute 4635 MUST be zero-length and specifies a query to the responder to 4636 reply back with all of the attributes that it supports. The 4637 response contains an attribute that contains a set of attribute 4638 identifiers each in 2 octets. The length divided by 2 (octets) 4639 would state the number of supported attributes contained in the 4640 response. 4642 o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge- 4643 device protects. This attribute is made up of two fields: the 4644 first is a 16-octet IPv6 address, and the second is a one-octet 4645 prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY 4646 be requested. The responder MAY respond with zero or more sub- 4647 network attributes. This is discussed in more detail in Section 4648 3.15.2. 4650 Note that no recommendations are made in this document as to how an 4651 implementation actually figures out what information to send in a 4652 reply. That is, we do not recommend any specific method of an IRAS 4653 determining which DNS server should be returned to a requesting IRAC. 4655 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET 4657 {{ Section added based on Clarif-6.3 }} 4659 INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets, 4660 ones that need one or more separate SAs, that can be reached through 4661 the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET 4662 attributes may also express the gateway's policy about what traffic 4663 should be sent through the gateway; the client can choose whether 4664 other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is 4665 sent through the gateway or directly to the destination. Thus, 4666 traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET 4667 attributes should be sent through the gateway that announces the 4668 attributes. If there are no existing IPsec SAs whose traffic 4669 selectors cover the address in question, new SAs need to be created. 4671 For instance, if there are two subnets, 192.0.1.0/26 and 4672 192.0.2.0/24, and the client's request contains the following: 4674 CP(CFG_REQUEST) = 4675 INTERNAL_IP4_ADDRESS() 4676 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) 4677 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) 4679 then a valid response could be the following (in which TSr and 4680 INTERNAL_IP4_SUBNET contain the same information): 4682 CP(CFG_REPLY) = 4683 INTERNAL_IP4_ADDRESS(192.0.1.234) 4684 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 4685 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 4686 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 4687 TSr = ((0, 0-65535, 192.0.1.0-192.0.1.63), 4688 (0, 0-65535, 192.0.2.0-192.0.2.255)) 4690 In these cases, the INTERNAL_IP4_SUBNET does not really carry any 4691 useful information. 4693 A different possible reply would have been this: 4695 CP(CFG_REPLY) = 4696 INTERNAL_IP4_ADDRESS(192.0.1.234) 4697 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 4698 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 4699 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 4700 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) 4702 That reply would mean that the client can send all its traffic 4703 through the gateway, but the gateway does not mind if the client 4704 sends traffic not included by INTERNAL_IP4_SUBNET directly to the 4705 destination (without going through the gateway). 4707 A different situation arises if the gateway has a policy that 4708 requires the traffic for the two subnets to be carried in separate 4709 SAs. Then a response like this would indicate to the client that if 4710 it wants access to the second subnet, it needs to create a separate 4711 SA: 4713 CP(CFG_REPLY) = 4714 INTERNAL_IP4_ADDRESS(192.0.1.234) 4715 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 4716 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 4717 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 4718 TSr = (0, 0-65535, 192.0.1.0-192.0.1.63) 4720 INTERNAL_IP4_SUBNET can also be useful if the client's TSr included 4721 only part of the address space. For instance, if the client requests 4722 the following: 4724 CP(CFG_REQUEST) = 4725 INTERNAL_IP4_ADDRESS() 4726 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) 4727 TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) 4729 then the gateway's reply might be: 4731 CP(CFG_REPLY) = 4732 INTERNAL_IP4_ADDRESS(192.0.1.234) 4733 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 4734 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 4735 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 4736 TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) 4737 Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET is in 4738 CFG_REQUESTs is unclear, they cannot be used reliably in 4739 CFG_REQUESTs. 4741 3.15.3. Configuration payloads for IPv6 4743 {{ Added this section from Clarif-6.5 }} 4745 The configuration payloads for IPv6 are based on the corresponding 4746 IPv4 payloads, and do not fully follow the "normal IPv6 way of doing 4747 things". In particular, IPv6 stateless autoconfiguration or router 4748 advertisement messages are not used; neither is neighbor discovery. 4750 A client can be assigned an IPv6 address using the 4751 INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange might 4752 look like this: 4754 CP(CFG_REQUEST) = 4755 INTERNAL_IP6_ADDRESS() 4756 INTERNAL_IP6_DNS() 4757 TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 4758 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 4760 CP(CFG_REPLY) = 4761 INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) 4762 INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) 4763 TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) 4764 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 4766 The client MAY send a non-empty INTERNAL_IP6_ADDRESS attribute in the 4767 CFG_REQUEST to request a specific address or interface identifier. 4768 The gateway first checks if the specified address is acceptable, and 4769 if it is, returns that one. If the address was not acceptable, the 4770 gateway attempts to use the interface identifier with some other 4771 prefix; if even that fails, the gateway selects another interface 4772 identifier. 4774 The INTERNAL_IP6_ADDRESS attribute also contains a prefix length 4775 field. When used in a CFG_REPLY, this corresponds to the 4776 INTERNAL_IP4_NETMASK attribute in the IPv4 case. 4778 Although this approach to configuring IPv6 addresses is reasonably 4779 simple, it has some limitations. IPsec tunnels configured using 4780 IKEv2 are not fully-featured "interfaces" in the IPv6 addressing 4781 architecture sense [IPV6ADDR]. In particular, they do not 4782 necessarily have link-local addresses, and this may complicate the 4783 use of protocols that assume them, such as [MLDV2]. 4785 3.15.4. Address Assignment Failures 4787 {{ Added this section from Clarif-6.8 }} 4789 If the responder encounters an error while attempting to assign an IP 4790 address to the initiator during the processing of a Configuration 4791 Payload, it responds with an INTERNAL_ADDRESS_FAILURE notification. 4792 The IKE SA is still created even if the initial Child SA cannot be 4793 created because of this failure. {{ 3.10.1-36 }} If this error is 4794 generated within an IKE_AUTH exchange, no Child SA will be created. 4795 However, there are some more complex error cases. 4797 If the responder does not support configuration payloads at all, it 4798 can simply ignore all configuration payloads. This type of 4799 implementation never sends INTERNAL_ADDRESS_FAILURE notifications. 4800 If the initiator requires the assignment of an IP address, it will 4801 treat a response without CFG_REPLY as an error. 4803 The initiator may request a particular type of address (IPv4 or IPv6) 4804 that the responder does not support, even though the responder 4805 supports configuration payloads. In this case, the responder simply 4806 ignores the type of address it does not support and processes the 4807 rest of the request as usual. 4809 If the initiator requests multiple addresses of a type that the 4810 responder supports, and some (but not all) of the requests fail, the 4811 responder replies with the successful addresses only. The responder 4812 sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned. 4814 3.16. Extensible Authentication Protocol (EAP) Payload 4816 The Extensible Authentication Protocol Payload, denoted EAP in this 4817 memo, allows IKE SAs to be authenticated using the protocol defined 4818 in RFC 3748 [EAP] and subsequent extensions to that protocol. The 4819 full set of acceptable values for the payload is defined elsewhere, 4820 but a short summary of RFC 3748 is included here to make this 4821 document stand alone in the common cases. 4823 1 2 3 4824 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 4825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4826 | Next Payload |C| RESERVED | Payload Length | 4827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4828 | | 4829 ~ EAP Message ~ 4830 | | 4831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4832 Figure 24: EAP Payload Format 4834 The payload type for an EAP Payload is forty eight (48). 4836 1 2 3 4837 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 4838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4839 | Code | Identifier | Length | 4840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4841 | Type | Type_Data... 4842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 4844 Figure 25: EAP Message Format 4846 o Code (1 octet) indicates whether this message is a Request (1), 4847 Response (2), Success (3), or Failure (4). 4849 o Identifier (1 octet) is used in PPP to distinguish replayed 4850 messages from repeated ones. Since in IKE, EAP runs over a 4851 reliable protocol, it serves no function here. In a response 4852 message, this octet MUST be set to match the identifier in the 4853 corresponding request. In other messages, this field MAY be set 4854 to any value. 4856 o Length (2 octets) is the length of the EAP message and MUST be 4857 four less than the Payload Length of the encapsulating payload. 4859 o Type (1 octet) is present only if the Code field is Request (1) or 4860 Response (2). For other codes, the EAP message length MUST be 4861 four octets and the Type and Type_Data fields MUST NOT be present. 4862 In a Request (1) message, Type indicates the data being requested. 4863 In a Response (2) message, Type MUST either be Nak or match the 4864 type of the data requested. The following types are defined in 4865 RFC 3748: 4867 1 Identity 4868 2 Notification 4869 3 Nak (Response Only) 4870 4 MD5-Challenge 4871 5 One-Time Password (OTP) 4872 6 Generic Token Card 4874 o Type_Data (Variable Length) varies with the Type of Request and 4875 the associated Response. For the documentation of the EAP 4876 methods, see [EAP]. 4878 {{ Demoted the SHOULD NOT and SHOULD }} Note that since IKE passes an 4879 indication of initiator identity in message 3 of the protocol, the 4880 responder should not send EAP Identity requests. The initiator may, 4881 however, respond to such requests if it receives them. 4883 4. Conformance Requirements 4885 In order to assure that all implementations of IKEv2 can 4886 interoperate, there are "MUST support" requirements in addition to 4887 those listed elsewhere. Of course, IKEv2 is a security protocol, and 4888 one of its major functions is to allow only authorized parties to 4889 successfully complete establishment of SAs. So a particular 4890 implementation may be configured with any of a number of restrictions 4891 concerning algorithms and trusted authorities that will prevent 4892 universal interoperability. 4894 IKEv2 is designed to permit minimal implementations that can 4895 interoperate with all compliant implementations. There are a series 4896 of optional features that can easily be ignored by a particular 4897 implementation if it does not support that feature. Those features 4898 include: 4900 o Ability to negotiate SAs through a NAT and tunnel the resulting 4901 ESP SA over UDP. 4903 o Ability to request (and respond to a request for) a temporary IP 4904 address on the remote end of a tunnel. 4906 o Ability to support various types of legacy authentication. 4908 o Ability to support window sizes greater than one. 4910 o Ability to establish multiple ESP or AH SAs within a single IKE 4911 SA. 4913 o Ability to rekey SAs. 4915 To assure interoperability, all implementations MUST be capable of 4916 parsing all payload types (if only to skip over them) and to ignore 4917 payload types that it does not support unless the critical bit is set 4918 in the payload header. If the critical bit is set in an unsupported 4919 payload header, all implementations MUST reject the messages 4920 containing those payloads. 4922 Every implementation MUST be capable of doing four-message 4923 IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, 4924 one for ESP or AH). Implementations MAY be initiate-only or respond- 4925 only if appropriate for their platform. Every implementation MUST be 4926 capable of responding to an INFORMATIONAL exchange, but a minimal 4927 implementation MAY respond to any INFORMATIONAL message with an empty 4928 INFORMATIONAL reply (note that within the context of an IKE SA, an 4929 "empty" message consists of an IKE header followed by an Encrypted 4930 payload with no payloads contained in it). A minimal implementation 4931 MAY support the CREATE_CHILD_SA exchange only in so far as to 4932 recognize requests and reject them with a Notify payload of type 4933 NO_ADDITIONAL_SAS. A minimal implementation need not be able to 4934 initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA 4935 expires (based on locally configured values of either lifetime or 4936 octets passed), and implementation MAY either try to renew it with a 4937 CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and 4938 create a new one. If the responder rejects the CREATE_CHILD_SA 4939 request with a NO_ADDITIONAL_SAS notification, the implementation 4940 MUST be capable of instead deleting the old SA and creating a new 4941 one. 4943 Implementations are not required to support requesting temporary IP 4944 addresses or responding to such requests. If an implementation does 4945 support issuing such requests, it MUST include a CP payload in 4946 message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or 4947 INTERNAL_IP6_ADDRESS. All other fields are optional. If an 4948 implementation supports responding to such requests, it MUST parse 4949 the CP payload of type CFG_REQUEST in message 3 and recognize a field 4950 of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports 4951 leasing an address of the appropriate type, it MUST return a CP 4952 payload of type CFG_REPLY containing an address of the requested 4953 type. {{ Demoted the SHOULD }} The responder may include any other 4954 related attributes. 4956 A minimal IPv4 responder implementation will ignore the contents of 4957 the CP payload except to determine that it includes an 4958 INTERNAL_IP4_ADDRESS attribute and will respond with the address and 4959 other related attributes regardless of whether the initiator 4960 requested them. 4962 A minimal IPv4 initiator will generate a CP payload containing only 4963 an INTERNAL_IP4_ADDRESS attribute and will parse the response 4964 ignoring attributes it does not know how to use. 4966 For an implementation to be called conforming to this specification, 4967 it MUST be possible to configure it to accept the following: 4969 o PKIX Certificates containing and signed by RSA keys of size 1024 4970 or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, 4971 ID_RFC822_ADDR, or ID_DER_ASN1_DN. 4973 o Shared key authentication where the ID passed is any of ID_KEY_ID, 4974 ID_FQDN, or ID_RFC822_ADDR. 4976 o Authentication where the responder is authenticated using PKIX 4977 Certificates and the initiator is authenticated using shared key 4978 authentication. 4980 5. Security Considerations 4982 While this protocol is designed to minimize disclosure of 4983 configuration information to unauthenticated peers, some such 4984 disclosure is unavoidable. One peer or the other must identify 4985 itself first and prove its identity first. To avoid probing, the 4986 initiator of an exchange is required to identify itself first, and 4987 usually is required to authenticate itself first. The initiator can, 4988 however, learn that the responder supports IKE and what cryptographic 4989 protocols it supports. The responder (or someone impersonating the 4990 responder) can probe the initiator not only for its identity, but 4991 using CERTREQ payloads may be able to determine what certificates the 4992 initiator is willing to use. 4994 Use of EAP authentication changes the probing possibilities somewhat. 4995 When EAP authentication is used, the responder proves its identity 4996 before the initiator does, so an initiator that knew the name of a 4997 valid initiator could probe the responder for both its name and 4998 certificates. 5000 Repeated rekeying using CREATE_CHILD_SA without additional Diffie- 5001 Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a 5002 single key or overrun of either endpoint. Implementers should take 5003 note of this fact and set a limit on CREATE_CHILD_SA exchanges 5004 between exponentiations. This memo does not prescribe such a limit. 5006 The strength of a key derived from a Diffie-Hellman exchange using 5007 any of the groups defined here depends on the inherent strength of 5008 the group, the size of the exponent used, and the entropy provided by 5009 the random number generator used. Due to these inputs, it is 5010 difficult to determine the strength of a key for any of the defined 5011 groups. Diffie-Hellman group number two, when used with a strong 5012 random number generator and an exponent no less than 200 bits, is 5013 common for use with 3DES. Group five provides greater security than 5014 group two. Group one is for historic purposes only and does not 5015 provide sufficient strength except for use with DES, which is also 5016 for historic use only. Implementations should make note of these 5017 estimates when establishing policy and negotiating security 5018 parameters. 5020 Note that these limitations are on the Diffie-Hellman groups 5021 themselves. There is nothing in IKE that prohibits using stronger 5022 groups nor is there anything that will dilute the strength obtained 5023 from stronger groups (limited by the strength of the other algorithms 5024 negotiated including the prf function). In fact, the extensible 5025 framework of IKE encourages the definition of more groups; use of 5026 elliptical curve groups may greatly increase strength using much 5027 smaller numbers. 5029 It is assumed that all Diffie-Hellman exponents are erased from 5030 memory after use. 5032 The strength of all keys is limited by the size of the output of the 5033 negotiated prf function. For this reason, a prf function whose 5034 output is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with 5035 this protocol. 5037 The security of this protocol is critically dependent on the 5038 randomness of the randomly chosen parameters. These should be 5039 generated by a strong random or properly seeded pseudo-random source 5040 (see [RANDOMNESS]). Implementers should take care to ensure that use 5041 of random numbers for both keys and nonces is engineered in a fashion 5042 that does not undermine the security of the keys. 5044 For information on the rationale of many of the cryptographic design 5045 choices in this protocol, see [SIGMA] and [SKEME]. Though the 5046 security of negotiated Child SAs does not depend on the strength of 5047 the encryption and integrity protection negotiated in the IKE SA, 5048 implementations MUST NOT negotiate NONE as the IKE integrity 5049 protection algorithm or ENCR_NULL as the IKE encryption algorithm. 5051 When using pre-shared keys, a critical consideration is how to assure 5052 the randomness of these secrets. The strongest practice is to ensure 5053 that any pre-shared key contain as much randomness as the strongest 5054 key being negotiated. Deriving a shared secret from a password, 5055 name, or other low-entropy source is not secure. These sources are 5056 subject to dictionary and social engineering attacks, among others. 5058 The NAT_DETECTION_*_IP notifications contain a hash of the addresses 5059 and ports in an attempt to hide internal IP addresses behind a NAT. 5060 Since the IPv4 address space is only 32 bits, and it is usually very 5061 sparse, it would be possible for an attacker to find out the internal 5062 address used behind the NAT box by trying all possible IP addresses 5063 and trying to find the matching hash. The port numbers are normally 5064 fixed to 500, and the SPIs can be extracted from the packet. This 5065 reduces the number of hash calculations to 2^32. With an educated 5066 guess of the use of private address space, the number of hash 5067 calculations is much smaller. Designers should therefore not assume 5068 that use of IKE will not leak internal address information. 5070 When using an EAP authentication method that does not generate a 5071 shared key for protecting a subsequent AUTH payload, certain man-in- 5072 the-middle and server impersonation attacks are possible [EAPMITM]. 5073 These vulnerabilities occur when EAP is also used in protocols that 5074 are not protected with a secure tunnel. Since EAP is a general- 5075 purpose authentication protocol, which is often used to provide 5076 single-signon facilities, a deployed IPsec solution that relies on an 5077 EAP authentication method that does not generate a shared key (also 5078 known as a non-key-generating EAP method) can become compromised due 5079 to the deployment of an entirely unrelated application that also 5080 happens to use the same non-key-generating EAP method, but in an 5081 unprotected fashion. Note that this vulnerability is not limited to 5082 just EAP, but can occur in other scenarios where an authentication 5083 infrastructure is reused. For example, if the EAP mechanism used by 5084 IKEv2 utilizes a token authenticator, a man-in-the-middle attacker 5085 could impersonate the web server, intercept the token authentication 5086 exchange, and use it to initiate an IKEv2 connection. For this 5087 reason, use of non-key-generating EAP methods SHOULD be avoided where 5088 possible. Where they are used, it is extremely important that all 5089 usages of these EAP methods SHOULD utilize a protected tunnel, where 5090 the initiator validates the responder's certificate before initiating 5091 the EAP authentication. {{ Demoted the SHOULD }} Implementers should 5092 describe the vulnerabilities of using non-key-generating EAP methods 5093 in the documentation of their implementations so that the 5094 administrators deploying IPsec solutions are aware of these dangers. 5096 An implementation using EAP MUST also use strong authentication of 5097 the server to the client before the EAP authentication begins, even 5098 if the EAP method offers mutual authentication. This avoids having 5099 additional IKEv2 protocol variations and protects the EAP data from 5100 active attackers. 5102 If the messages of IKEv2 are long enough that IP-level fragmentation 5103 is necessary, it is possible that attackers could prevent the 5104 exchange from completing by exhausting the reassembly buffers. The 5105 chances of this can be minimized by using the Hash and URL encodings 5106 instead of sending certificates (see Section 3.6). Additional 5107 mitigations are discussed in [DOSUDPPROT]. 5109 5.1. Traffic selector authorization 5111 {{ Added this section from Clarif-4.13 }} 5113 IKEv2 relies on information in the Peer Authorization Database (PAD) 5114 when determining what kind of IPsec SAs a peer is allowed to create. 5115 This process is described in [IPSECARCH] Section 4.4.3. When a peer 5116 requests the creation of an IPsec SA with some traffic selectors, the 5117 PAD must contain "Child SA Authorization Data" linking the identity 5118 authenticated by IKEv2 and the addresses permitted for traffic 5119 selectors. 5121 For example, the PAD might be configured so that authenticated 5122 identity "sgw23.example.com" is allowed to create IPsec SAs for 5123 192.0.2.0/24, meaning this security gateway is a valid 5124 "representative" for these addresses. Host-to-host IPsec requires 5125 similar entries, linking, for example, "fooserver4.example.com" with 5126 192.0.1.66/32, meaning this identity a valid "owner" or 5127 "representative" of the address in question. 5129 As noted in [IPSECARCH], "It is necessary to impose these constraints 5130 on creation of child SAs to prevent an authenticated peer from 5131 spoofing IDs associated with other, legitimate peers." In the 5132 example given above, a correct configuration of the PAD prevents 5133 sgw23 from creating IPsec SAs with address 192.0.1.66, and prevents 5134 fooserver4 from creating IPsec SAs with addresses from 192.0.2.0/24. 5136 It is important to note that simply sending IKEv2 packets using some 5137 particular address does not imply a permission to create IPsec SAs 5138 with that address in the traffic selectors. For example, even if 5139 sgw23 would be able to spoof its IP address as 192.0.1.66, it could 5140 not create IPsec SAs matching fooserver4's traffic. 5142 The IKEv2 specification does not specify how exactly IP address 5143 assignment using configuration payloads interacts with the PAD. Our 5144 interpretation is that when a security gateway assigns an address 5145 using configuration payloads, it also creates a temporary PAD entry 5146 linking the authenticated peer identity and the newly allocated inner 5147 address. 5149 It has been recognized that configuring the PAD correctly may be 5150 difficult in some environments. For instance, if IPsec is used 5151 between a pair of hosts whose addresses are allocated dynamically 5152 using DHCP, it is extremely difficult to ensure that the PAD 5153 specifies the correct "owner" for each IP address. This would 5154 require a mechanism to securely convey address assignments from the 5155 DHCP server, and link them to identities authenticated using IKEv2. 5157 Due to this limitation, some vendors have been known to configure 5158 their PADs to allow an authenticated peer to create IPsec SAs with 5159 traffic selectors containing the same address that was used for the 5160 IKEv2 packets. In environments where IP spoofing is possible (i.e., 5161 almost everywhere) this essentially allows any peer to create IPsec 5162 SAs with any traffic selectors. This is not an appropriate or secure 5163 configuration in most circumstances. See [H2HIPSEC] for an extensive 5164 discussion about this issue, and the limitations of host-to-host 5165 IPsec in general. 5167 6. IANA Considerations 5169 {{ This section was changed to not re-define any new IANA registries. 5170 }} 5172 [IKEV2] defined many field types and values. IANA has already 5173 registered those types and values, so the are not listed here again. 5174 No new types or values are registered in this document. However, 5175 IANA should update all references to RFC 4306 to point to this 5176 document. 5178 7. Acknowledgements 5180 The individuals on the IPsec mailing list was very helpful in both 5181 pointing out where clarifications and changes were needed, as well as 5182 in reviewing the clarifications suggested by others. 5184 The acknowledgements from the IKEv2 document were: 5186 This document is a collaborative effort of the entire IPsec WG. If 5187 there were no limit to the number of authors that could appear on an 5188 RFC, the following, in alphabetical order, would have been listed: 5189 Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt 5190 Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John 5191 Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero 5192 Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer 5193 Reingold, and Michael Richardson. Many other people contributed to 5194 the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, 5195 each of which has its own list of authors. Hugh Daniel suggested the 5196 feature of having the initiator, in message 3, specify a name for the 5197 responder, and gave the feature the cute name "You Tarzan, Me Jane". 5198 David Faucher and Valery Smyzlov helped refine the design of the 5199 traffic selector negotiation. 5201 This paragraph lists references that appear only in figures. The 5202 section is only here to keep the 'xml2rfc' program happy, and needs 5203 to be removed when the document is published. The RFC Editor will 5204 remove it before publication. [AEAD] [EAI] [DES] [IDEA] [MD5] 5205 [X.501] [X.509] 5207 8. References 5209 8.1. Normative References 5211 [ADDGROUP] 5212 Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 5213 Diffie-Hellman groups for Internet Key Exchange (IKE)", 5214 RFC 3526, May 2003. 5216 [ADDRIPV6] 5217 Hinden, R. and S. Deering, "Internet Protocol Version 6 5218 (IPv6) Addressing Architecture", RFC 4291, February 2006. 5220 [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 5221 Levkowetz, "Extensible Authentication Protocol (EAP)", 5222 RFC 3748, June 2004. 5224 [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 5225 of Explicit Congestion Notification (ECN) to IP", 5226 RFC 3168, September 2001. 5228 [ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 5229 Algorithms", RFC 2451, November 1998. 5231 [IPSECARCH] 5232 Kent, S. and K. Seo, "Security Architecture for the 5233 Internet Protocol", RFC 4301, December 2005. 5235 [MUSTSHOULD] 5236 Bradner, S., "Key Words for use in RFCs to indicate 5237 Requirement Levels", BCP 14, RFC 2119, March 1997. 5239 [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 5240 Standards (PKCS) #1: RSA Cryptography Specifications 5241 Version 2.1", RFC 3447, February 2003. 5243 [PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 5244 X.509 Public Key Infrastructure Certificate and 5245 Certificate Revocation List (CRL) Profile", RFC 3280, 5246 April 2002. 5248 [RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the 5249 Internet Key Exchange Protocol (IKE)", RFC 4434, 5250 February 2006. 5252 [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 5253 Advanced Encryption Standard-Cipher-based Message 5254 Authentication Code-Pseudo-Random Function-128 (AES-CMAC- 5255 PRF-128) Algorithm for the Internet Key Exchange Protocol 5256 (IKE)", RFC 4615, August 2006. 5258 [UDPENCAPS] 5259 Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 5260 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 5261 RFC 3948, January 2005. 5263 8.2. Informative References 5265 [AEAD] McGrew, D., "An Interface and Algorithms for Authenticated 5266 Encryption", RFC 5116, January 2008. 5268 [AH] Kent, S., "IP Authentication Header", RFC 4302, 5269 December 2005. 5271 [ARCHGUIDEPHIL] 5272 Bush, R. and D. Meyer, "Some Internet Architectural 5273 Guidelines and Philosophy", RFC 3439, December 2002. 5275 [ARCHPRINC] 5276 Carpenter, B., "Architectural Principles of the Internet", 5277 RFC 1958, June 1996. 5279 [Clarif] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 5280 Implementation Guidelines", RFC 4718, October 2006. 5282 [DES] American National Standards Institute, "American National 5283 Standard for Information Systems-Data Link Encryption", 5284 ANSI X3.106, 1983. 5286 [DH] Diffie, W. and M. Hellman, "New Directions in 5287 Cryptography", IEEE Transactions on Information Theory, 5288 V.IT-22 n. 6, June 1977. 5290 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", 5291 RFC 2131, March 1997. 5293 [DIFFSERVARCH] 5294 Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 5295 and W. Weiss, "An Architecture for Differentiated 5296 Services", RFC 2475. 5298 [DIFFSERVFIELD] 5299 Nichols, K., Blake, S., Baker, F., and D. Black, 5300 "Definition of the Differentiated Services Field (DS 5301 Field) in the IPv4 and IPv6 Headers", RFC 2474, 5302 December 1998. 5304 [DIFFTUNNEL] 5305 Black, D., "Differentiated Services and Tunnels", 5306 RFC 2983, October 2000. 5308 [DOI] Piper, D., "The Internet IP Security Domain of 5309 Interpretation for ISAKMP", RFC 2407, November 1998. 5311 [DOSUDPPROT] 5312 C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection 5313 for UDP-based protocols", ACM Conference on Computer and 5314 Communications Security , October 2003. 5316 [DSS] National Institute of Standards and Technology, U.S. 5317 Department of Commerce, "Digital Signature Standard", 5318 Draft FIPS 186-3, June 2008. 5320 [EAI] Abel, Y., "Internationalized Email Headers", RFC 5335, 5321 September 2008. 5323 [EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, "Man-in-the-Middle in 5324 Tunneled Authentication Protocols", November 2002, 5325 . 5327 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 5328 RFC 4303, December 2005. 5330 [EXCHANGEANALYSIS] 5331 R. Perlman and C. Kaufman, "Analysis of the IPsec key 5332 exchange Standard", WET-ICE Security Conference, MIT , 5333 2001, 5334 . 5336 [H2HIPSEC] 5337 Aura, T., Roe, M., and A. Mohammed, "Experiences with 5338 Host-to-Host IPsec", 13th International Workshop on 5339 Security Protocols, Cambridge, UK, April 2005. 5341 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 5342 Hashing for Message Authentication", RFC 2104, 5343 February 1997. 5345 [IDEA] X. Lai, "On the Design and Security of Block Ciphers", ETH 5346 Series in Information Processing, v. 1, Konstanz: Hartung- 5347 Gorre Verlag, 1992. 5349 [IDNA] Faltstrom, P., Hoffman, P., and A. Costello, 5350 "Internationalizing Domain Names in Applications (IDNA)", 5351 RFC 3490, March 2003. 5353 [IKEV1] Harkins, D. and D. Carrel, "The Internet Key Exchange 5354 (IKE)", RFC 2409, November 1998. 5356 [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 5357 RFC 4306, December 2005. 5359 [IP-COMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP 5360 Payload Compression Protocol (IPComp)", RFC 3173, 5361 September 2001. 5363 [IPSECARCH-OLD] 5364 Kent, S. and R. Atkinson, "Security Architecture for the 5365 Internet Protocol", RFC 2401, November 1998. 5367 [IPV6ADDR] 5368 Hinden, R. and S. Deering, "Internet Protocol Version 6 5369 (IPv6) Addressing Architecture", RFC 4291, February 2006. 5371 [ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet 5372 Security Association and Key Management Protocol 5373 (ISAKMP)", RFC 2408, November 1998. 5375 [LDAP] Sermersheim, J., "Lightweight Directory Access Protocol 5376 (v3)", RFC 4511, June 2006. 5378 [MAILFORMAT] 5379 Resnick, P., "Internet Message Format", RFC 2822, 5380 April 2001. 5382 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 5383 April 1992. 5385 [MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 5386 in IPv6", RFC 3775, June 2004. 5388 [MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery 5389 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 5391 [MODES] National Institute of Standards and Technology, U.S. 5392 Department of Commerce, "Recommendation for Block Cipher 5393 Modes of Operation", SP 800-38A, 2001. 5395 [NAI] Aboba, B., Beadles, M., Eronen, P., and J. Arkko, "The 5396 Network Access Identifier", RFC 4282, December 2005. 5398 [NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 5399 (NAT) Compatibility Requirements", RFC 3715, March 2004. 5401 [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", 5402 RFC 2412, November 1998. 5404 [PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 5405 Management API, Version 2", RFC 2367, July 1998. 5407 [PHOTURIS] 5408 Karn, P. and W. Simpson, "Photuris: Session-Key Management 5409 Protocol", RFC 2522, March 1999. 5411 [RADIUS] Rigney, C., Rubens, A., Simpson, W., and S. Willens, 5412 "Remote Authentication Dial In User Service (RADIUS)", 5413 RFC 2138, April 1997. 5415 [RANDOMNESS] 5416 Eastlake, D., Schiller, J., and S. Crocker, "Randomness 5417 Requirements for Security", BCP 106, RFC 4086, June 2005. 5419 [REAUTH] Nir, Y., "Repeated Authentication in Internet Key Exchange 5420 (IKEv2) Protocol", RFC 4478, April 2006. 5422 [ROHCV2] Ertekin, et. al., E., "IKEv2 Extensions to Support Robust 5423 Header Compression over IPsec (ROHCoIPsec)", 5424 draft-ietf-rohc-ikev2-extensions-hcoipsec (work in 5425 progress), October 2008. 5427 [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for 5428 Obtaining Digital Signatures and Public-Key 5429 Cryptosystems", February 1978. 5431 [SHA] National Institute of Standards and Technology, U.S. 5432 Department of Commerce, "Secure Hash Standard", 5433 FIPS 180-3, October 2008. 5435 [SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to 5436 Authenticated Diffie-Hellman and its Use in the IKE 5437 Protocols", Advances in Cryptography - CRYPTO 2003 5438 Proceedings LNCS 2729, 2003, . 5442 [SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange 5443 Mechanism for Internet", IEEE Proceedings of the 1996 5444 Symposium on Network and Distributed Systems Security , 5445 1996. 5447 [TRANSPARENCY] 5448 Carpenter, B., "Internet Transparency", RFC 2775, 5449 February 2000. 5451 [X.501] ITU-T, "Recommendation X.501: Information Technology - 5452 Open Systems Interconnection - The Directory: Models", 5453 1993. 5455 [X.509] ITU-T, "Recommendation X.509 (1997 E): Information 5456 Technology - Open Systems Interconnection - The Directory: 5457 Authentication Framework", 1997. 5459 Appendix A. Summary of changes from IKEv1 5461 The goals of this revision to IKE are: 5463 1. To define the entire IKE protocol in a single document, 5464 replacing RFCs 2407, 2408, and 2409 and incorporating subsequent 5465 changes to support NAT Traversal, Extensible Authentication, and 5466 Remote Address acquisition; 5468 2. To simplify IKE by replacing the eight different initial 5469 exchanges with a single four-message exchange (with changes in 5470 authentication mechanisms affecting only a single AUTH payload 5471 rather than restructuring the entire exchange) see 5472 [EXCHANGEANALYSIS]; 5474 3. To remove the Domain of Interpretation (DOI), Situation (SIT), 5475 and Labeled Domain Identifier fields, and the Commit and 5476 Authentication only bits; 5478 4. To decrease IKE's latency in the common case by making the 5479 initial exchange be 2 round trips (4 messages), and allowing the 5480 ability to piggyback setup of a Child SA on that exchange; 5482 5. To replace the cryptographic syntax for protecting the IKE 5483 messages themselves with one based closely on ESP to simplify 5484 implementation and security analysis; 5486 6. To reduce the number of possible error states by making the 5487 protocol reliable (all messages are acknowledged) and sequenced. 5488 This allows shortening CREATE_CHILD_SA exchanges from 3 messages 5489 to 2; 5491 7. To increase robustness by allowing the responder to not do 5492 significant processing until it receives a message proving that 5493 the initiator can receive messages at its claimed IP address; 5495 8. To fix cryptographic weaknesses such as the problem with 5496 symmetries in hashes used for authentication documented by Tero 5497 Kivinen; 5499 9. To specify Traffic Selectors in their own payloads type rather 5500 than overloading ID payloads, and making more flexible the 5501 Traffic Selectors that may be specified; 5503 10. To specify required behavior under certain error conditions or 5504 when data that is not understood is received in order to make it 5505 easier to make future revisions in a way that does not break 5506 backwards compatibility; 5508 11. To simplify and clarify how shared state is maintained in the 5509 presence of network failures and Denial of Service attacks; and 5511 12. To maintain existing syntax and magic numbers to the extent 5512 possible to make it likely that implementations of IKEv1 can be 5513 enhanced to support IKEv2 with minimum effort. 5515 Appendix B. Diffie-Hellman Groups 5517 There are two Diffie-Hellman groups defined here for use in IKE. 5518 These groups were generated by Richard Schroeppel at the University 5519 of Arizona. Properties of these primes are described in [OAKLEY]. 5521 The strength supplied by group one may not be sufficient for the 5522 mandatory-to-implement encryption algorithm and is here for historic 5523 reasons. 5525 Additional Diffie-Hellman groups have been defined in [ADDGROUP]. 5527 B.1. Group 1 - 768 Bit MODP 5529 This group is assigned id 1 (one). 5531 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 5532 Its hexadecimal value is: 5534 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 5535 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 5536 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 5537 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF 5539 The generator is 2. 5541 B.2. Group 2 - 1024 Bit MODP 5543 This group is assigned id 2 (two). 5545 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 5546 Its hexadecimal value is: 5548 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 5549 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 5550 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 5551 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 5552 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 5553 FFFFFFFF FFFFFFFF 5555 The generator is 2. 5557 Appendix C. Exchanges and Payloads 5559 {{ Clarif-AppA }} 5561 This appendix contains a short summary of the IKEv2 exchanges, and 5562 what payloads can appear in which message. This appendix is purely 5563 informative; if it disagrees with the body of this document, the 5564 other text is considered correct. 5566 Vendor-ID (V) payloads may be included in any place in any message. 5567 This sequence here shows what are the most logical places for them. 5569 C.1. IKE_SA_INIT Exchange 5571 request --> [N(COOKIE)], 5572 SA, KE, Ni, 5573 [N(NAT_DETECTION_SOURCE_IP)+, 5574 N(NAT_DETECTION_DESTINATION_IP)], 5575 [V+] 5577 normal response <-- SA, KE, Nr, 5578 (no cookie) [N(NAT_DETECTION_SOURCE_IP), 5579 N(NAT_DETECTION_DESTINATION_IP)], 5580 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 5581 [V+] 5583 cookie response <-- N(COOKIE), 5584 [V+] 5586 different D-H <-- N(INVALID_KE_PAYLOAD), 5587 group wanted [V+] 5589 C.2. IKE_AUTH Exchange without EAP 5591 request --> IDi, [CERT+], 5592 [N(INITIAL_CONTACT)], 5593 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 5594 [IDr], 5595 AUTH, 5596 [CP(CFG_REQUEST)], 5597 [N(IPCOMP_SUPPORTED)+], 5598 [N(USE_TRANSPORT_MODE)], 5599 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5600 [N(NON_FIRST_FRAGMENTS_ALSO)], 5601 SA, TSi, TSr, 5602 [V+] 5604 response <-- IDr, [CERT+], 5605 AUTH, 5606 [CP(CFG_REPLY)], 5607 [N(IPCOMP_SUPPORTED)], 5608 [N(USE_TRANSPORT_MODE)], 5609 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5610 [N(NON_FIRST_FRAGMENTS_ALSO)], 5611 SA, TSi, TSr, 5612 [N(ADDITIONAL_TS_POSSIBLE)], 5613 [V+] 5615 error in Child SA <-- IDr, [CERT+], 5616 creation AUTH, 5617 N(error), 5618 [V+] 5620 C.3. IKE_AUTH Exchange with EAP 5622 first request --> IDi, 5623 [N(INITIAL_CONTACT)], 5624 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 5625 [IDr], 5626 [CP(CFG_REQUEST)], 5627 [N(IPCOMP_SUPPORTED)+], 5628 [N(USE_TRANSPORT_MODE)], 5629 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5630 [N(NON_FIRST_FRAGMENTS_ALSO)], 5631 SA, TSi, TSr, 5632 [V+] 5634 first response <-- IDr, [CERT+], AUTH, 5635 EAP, 5636 [V+] 5638 / --> EAP 5639 repeat 1..N times | 5640 \ <-- EAP 5642 last request --> AUTH 5644 last response <-- AUTH, 5645 [CP(CFG_REPLY)], 5646 [N(IPCOMP_SUPPORTED)], 5647 [N(USE_TRANSPORT_MODE)], 5648 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5649 [N(NON_FIRST_FRAGMENTS_ALSO)], 5650 SA, TSi, TSr, 5651 [N(ADDITIONAL_TS_POSSIBLE)], 5652 [V+] 5654 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying Child SAs 5656 request --> [N(REKEY_SA)], 5657 [CP(CFG_REQUEST)], 5658 [N(IPCOMP_SUPPORTED)+], 5659 [N(USE_TRANSPORT_MODE)], 5660 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5661 [N(NON_FIRST_FRAGMENTS_ALSO)], 5662 SA, Ni, [KEi], TSi, TSr 5663 [V+] 5665 normal <-- [CP(CFG_REPLY)], 5666 response [N(IPCOMP_SUPPORTED)], 5667 [N(USE_TRANSPORT_MODE)], 5668 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 5669 [N(NON_FIRST_FRAGMENTS_ALSO)], 5670 SA, Nr, [KEr], TSi, TSr, 5671 [N(ADDITIONAL_TS_POSSIBLE)] 5672 [V+] 5674 error case <-- N(error) 5676 different D-H <-- N(INVALID_KE_PAYLOAD), 5677 group wanted [V+] 5679 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA 5681 request --> SA, Ni, [KEi] 5682 [V+] 5684 response <-- SA, Nr, [KEr] 5685 [V+] 5687 C.6. INFORMATIONAL Exchange 5689 request --> [N+], 5690 [D+], 5691 [CP(CFG_REQUEST)] 5693 response <-- [N+], 5694 [D+], 5695 [CP(CFG_REPLY)] 5697 Appendix D. Changes Between Internet Draft Versions 5699 This section will be removed before publication as an RFC, but should 5700 be left intact until then so that reviewers can follow what has 5701 changed. 5703 D.1. Changes from IKEv2 to draft -00 5705 There were a zillion additions from RFC 4718. These are noted with 5706 "{{ Clarif-nn }}". 5708 Cleaned up many of the figures. Made the table headings consistent. 5709 Made some tables easier to read by removing blank spaces. Removed 5710 the "reserved to IANA" and "private use" text wording and moved it 5711 into the tables. 5713 Changed many SHOULD requirements to better match RFC 2119. These are 5714 also marked with comments such as "{{ Demoted the SHOULD }}". 5716 In Section 2.16, changed the MUST requirement of authenticating the 5717 responder from "public key signature based" to "strong" because that 5718 is what most current IKEv2 implementations do, and it better matches 5719 the actual security requirement. 5721 D.2. Changes from draft -00 to draft -01 5723 The most significant technical change was to make KE optional but 5724 strongly recommended in Section 1.3.2. 5726 Updated all references to the IKEv2 Clarifications document to RFC 5727 4718. 5729 Moved a lot of the protocol description out of the long tables in 5730 Section 3.10.1 into the body of the document. These are noted with 5731 "{{ 3.10.1-nnnn }}", where "nnnn" is the notification type number. 5733 Made some table changes based on suggestions from Alfred Hoenes. 5735 Changed "byte" to "octet" in many places. 5737 Removed discussion of ESP+AH bundles in many places, and added a 5738 paragraph about it in Section 1.7. 5740 Removed the discussion of INTERNAL_ADDRESS_EXPIRY in many places, and 5741 added a paragraph about it in Section 1.7. 5743 Moved Clarif-7.10 from Section 1.2 to Section 3.2. 5745 In the figure in Section 1.3.2, made KEi optional, and added text 5746 saying "The KEi payload SHOULD be included." 5748 In the figure in Section 1.3.2, maked KEr optional, and removed text 5749 saying "KEi and KEr are required for rekeying an IKE SA." 5751 In Section 1.4, clarified that the half-closed connections being 5752 discussed are AH and ESP. 5754 Rearranged the end of Section 1.7, and added the new notation for 5755 moving text out of 3.10.1. 5757 Clarified the wording in the second paragraph of Section 2.2. This 5758 allowd the removal of the fourth paragraph, which previously had 5759 Clarif-2.2 in it. 5761 In section 2.5, removed "or later" from "version 2.0". 5763 Added the question for implementers about payload order at the end of 5764 Section 2.5. 5766 Corrected Section 2.7 based on Clarif-7-13 to say that you can't do 5767 ESP and AH at one time. 5769 In Section 2.8, clarified the wording about how to replace an IKE SA. 5771 Clarified the text in the last many paragraphs in Section 2.9. Also 5772 moved some text from near the beginning of 2.9 to the beginning of 5773 2.9.1. 5775 Removed some redundant text in Section 2.9 concerning creating a 5776 Child SA pair not in response to an arriving packet. 5778 Added the following to the end of the first paragraph of Section 5779 2.14: "The lengths of SK_d, SK_pi, and SK_pr are the key length of 5780 the agreed-to PRF." 5782 Added the restriction in Section 2.15 that all PRFs used with IKEv2 5783 MUST take variable-sized keys. 5785 In Section 2.17, removed "If multiple IPsec protocols are negotiated, 5786 keying material is taken in the order in which the protocol headers 5787 will appear in the encapsulated packet" because multiple IPsec 5788 protocols cannot be negotiated at one time. 5790 Added the material from Clarif-5.12 to Section 2.18. 5792 Changed "hash of" to "expected value of" in Section 2.23. 5794 In the bulleted list in Section 2.23, replaced "this end" with a 5795 clearer description of which system is being discussed. 5797 Added the paragraph at the beginning of Section 3 about 5798 interoperability and UNSPECIFIED values ("In the tables in this 5799 section..."). 5801 Fixed Section 3.3 to not include proposal that include both AH and 5802 ESP. Ditto for the "Proposal #" bullet in Section 3.3.1. 5804 In the description of ID_FQDN in Section 3.5, added "All characters 5805 in the ID_FQDN are ASCII; this follows that for an "internationalized 5806 domain name" as defined in [IDNA]." 5808 In Section 3.8, shortened and clarified the description of "RSA 5809 Digital Signature". 5811 In Section 3.10, shortened and clarified the description of "Protocol 5812 ID". 5814 In Section 3.15, "The requested address is valid until the expiry 5815 time defined with the INTERNAL_ADDRESS_EXPIRY attribute or there are 5816 no IKE SAs between the peers" is shortened to just "The requested 5817 address is valid until there are no IKE SAs between the peers." 5819 In Section 3.15.1, changed "INTERNAL_IP6_NBNS" to unspecified. 5821 Made [ADDRIPV6] an informative reference instead of a normative 5822 reference and updated it. 5824 Made [PKCS1] a normative reference instead of an informative 5825 reference and changed the pointer to RFC 3447. 5827 D.3. Changes from draft -00 to draft -01 5829 In Section 1.5, added "request" to first sentence to make it "If an 5830 encrypted IKE request packet arrives on port 500 or 4500 with an 5831 unrecognized SPI...". 5833 In Section 3.3, fifth paragraph, upped the number of transforms for 5834 AH and ESP by one each to account for ESN, which is now mandatory. 5836 In Section 2.1, added "or equal to" in "The responder MUST remember 5837 each response until it receives a request whose sequence number is 5838 larger than or equal to the sequence number in the response plus its 5839 window size." 5841 In Section 2.18, removed " Note that this may not work if the new IKE 5842 SA's PRF has a fixed key size because the output of the PRF may not 5843 be of the correct size." because it is no longer relevant. 5845 D.4. Changes from draft -01 to draft -02 5847 Many grammatical fixes. 5849 In Section 1.2, reworded Clarif-4.3 to be clearer. 5851 In Section 1.3.3, reworded 3.10.1-16393 and Clarif-5.4 to remove 5852 redundant text. 5854 In Section 2.13, replaced text about variable length keys with 5855 clearer explanation and requirement on non-HMAC PRFs. Also added 5856 "preferred" to Section 2.14 for the key length, and removed redundant 5857 text. 5859 In Section 2.14, removed the "half and half" description and replaced 5860 it with exceptions for RFC4434 and RFC4615. 5862 Removed the now-redundant "All PRFs used with IKEv2 MUST take 5863 variable-sized keys" from Section 2.15. 5865 In Section 2.15, added "(IKE_SA_INIT response)" after "of the second 5866 message" and "(IKE_SA_INIT request)" after "the first message". 5868 In Section 2.17, simplified because there are no more bundles. "A 5869 single Child SA negotiation may result in multiple security 5870 associations. ESP and AH SAs exist in pairs (one in each 5871 direction)." becomes "For ESP and AH, a single Child SA negotiation 5872 results in two security associations (one in each direction)." 5874 In section 3.3, made the example of combinations of algorithms and 5875 the contents of the first proposal clearer. 5877 Added Clarif-4.4 to the end of Section 3.3.2. 5879 Reordered Section 3.3.5 and added Clarif-7.11. 5881 Clarified Section 3.3.6 about choosing a single proposal. Also added 5882 second paragraph about transforms not understood, and clarified third 5883 paragraph about picking D-H groups. 5885 Moved 3.10.1-16392 from Section 3.6 to 3.7. 5887 In Section 3.10, clarified 3.10.1-16394. 5889 Updated Section 6 to indicate that there is nothing new for IANA in 5890 this spec. Also removed the definition of "Expert Review" from 5891 Section 1.6 for the same reason. 5893 In Appendix A, removed "and not commit any state to an exchange until 5894 the initiator can be cryptographically authenticated" because that 5895 was only true in an earlier version of IKEv2. 5897 D.5. Changes from draft -02 to draft -03 5899 In Section 1.3, changed "If the responder rejects the Diffie-Hellman 5900 group of the KEi payload, the responder MUST reject the request and 5901 indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD 5902 Notification payload." to "If the responder selects a proposal using 5903 a different Diffie-Hellman group (other than NONE), the responder 5904 MUST reject the request and indicate its preferred Diffie-Hellman 5905 group in the INVALID_KE_PAYLOAD Notification payload. 5907 In Section 2.3, added the last two paragraphs covering why you 5908 initiator's SPI and/or IP to differentiate if this is a "half-open" 5909 IKE SA or a new request. Also removed similar text from Section 2.2. 5911 In Section 2.5, added "Payloads sent in IKE response messages MUST 5912 NOT have the critical flag set. Note that the critical flag applies 5913 only to the payload type, not the contents. If the payload type is 5914 recognized, but the payload contains something which is not (such as 5915 an unknown transform inside an SA payload, or an unknown Notify 5916 Message Type inside a Notify payload), the critical flag is ignored." 5918 In Section 2.6, moved the text about {{ 3.10.1-16390 }} later in the 5919 section. Also reworded the text to make it clearer what the COOKIE 5920 is for. 5922 Moved text from {{ Clarif-2.1 }} from Section 2.6 to Section 2.7. 5924 In Section 2.13, added "(see Section 3.3.5 for the defintion of the 5925 Key Length transform attribute)". 5927 In Section 2.17, change the description of the keying material from 5928 the list with two bullets to a clearer list. 5930 In Section 2.23, added "Implementations MUST process received UDP- 5931 encapsulated ESP packets even when no NAT was detected." 5933 In Section 3.3, changed "Each proposal may contain a" to "Each 5934 proposal contains a". 5936 Added the asterisks to the transform type table in Section 3.3.2 and 5937 the types table in 3.3.3 to foreshadow future developments. 5939 In Section 3.3.2, changed the following algorithms to (UNSPECIFIED) 5940 because the RFCs listed didn't really specify how to implement them 5941 in an interoperable fashion: 5943 Encryption Algorithms 5944 ENCR_DES_IV64 1 (RFC1827) 5945 ENCR_3IDEA 8 (RFC2451) 5946 ENCR_DES_IV32 9 5947 Pseudo-random Functions 5948 PRF_HMAC_TIGER 3 (RFC2104) 5949 Integrity Algorithms 5950 AUTH_DES_MAC 3 5951 AUTH_KPDK_MD5 4 (RFC1826) 5953 In Section 3.4, added "(other than NONE)" to the second-to-last 5954 paragraph. 5956 Rewrote the third paragraph of Section 3.14 to talk about other 5957 modes, and to clarify which encryption and integrity protection we 5958 are talking about. 5960 Changed the "Initialization Vector" bullet in Section 3.14 to specify 5961 better what is needed for the IV. Upgraded the SHOULDs to MUSTs. 5962 Also added the reference for [MODES]. 5964 In Section 5, in the second-to-last paragraph, changed "a public-key- 5965 based" to "strong" to match the wording in Section 2.16. 5967 D.6. Changes from draft -03 to draft-ietf-ipsecme-ikev2bis-00 5969 Changed the document's filename to draft-ietf-ipsecme-ikev2bis-00. 5970 Added Yoav Nir as a co-author. 5972 In many places in the document, changed "and/or" to "or" when talking 5973 about combinations of ESP and AH SAs. For example, in the intro, it 5974 said "can be used to efficiently establish SAs for Encapsulating 5975 Security Payload (ESP) and/or Authentication Header (AH)". This is 5976 changed to "or" to indicate that you can only establish one type of 5977 SA at a time. 5979 In Section 1, clarified that RFC 4306 already replaced IKEv1, and 5980 that this document replaces RFC 4306. Also fixed Section 2.5 for 5981 similar issue. Also updated the Abstract to cover this. 5983 In Section 2.15, in the responder's signed octets, changed: 5985 RestOfRespIDPayload = IDType | RESERVED | InitIDData 5986 to 5987 RestOfRespIDPayload = IDType | RESERVED | RespIDData 5988 In 2.16, changed "strong" back to "public key signature based" to 5989 make it the same as 4306. 5991 In section 3.10, added "and the field must be empty" to make it clear 5992 that a zero-length SPI is really empty. 5994 D.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to 5995 draft-ietf-ipsecme-ikev2bis-01 5997 Throughout, changed "IKE_SA" to "IKE SA", and changed "CHILD_SA" to 5998 "Child SA" (except left "CREATE_CHILD_SA" alone). 6000 Added the middle sentence in the Abstract to say what IKE actually 6001 does. 6003 Added in section 1 "(unless there is failure setting up the AH or ESP 6004 Child SA, in which case the IKE SA is still established without IPsec 6005 SA)". 6007 Clarified the titles of 1.1.1, 1.1.2, and 1.1.3. 6009 In 1.1.2, changed "If there is an inner IP header, the inner 6010 addresses will be the same as the outer addresses." because we are 6011 talking about transport mode here. 6013 Added reference to section 2.14 to setion 1.2 and 1.3. 6015 In 1.2, clarified what is and isn't encrypted in a message. 6017 Added the following to 1.2: "If the IDr proposed by the initiator is 6018 not acceptable to the responder, the responder might use some other 6019 IDr to finish the exchange. If the initiator then does not accept 6020 that fact that responder used different IDr than the one that was 6021 requested, the initiator can close the SA after noticing the fact." 6023 Moved the paragraph beginning "All messages following..." from 1.3 up 6024 to 1.2, and reworded it to apply to all the cases it covers. 6026 At the end of section 1.3.1, clarified that the responder is the one 6027 who controls whether non-first-fragments will be sent, and reworded 6028 the paragraph. 6030 In section 1.3.3, added "The Protocol ID field of the REKEY_SA 6031 notification is set to match the protocol of the SA we are rekeying, 6032 for example, 3 for ESP and 2 for AH." [Issue #10] 6034 In 1.3.2, added "of the SA payload" to "New initiator and responder 6035 SPIs are supplied in the SPI fields." 6036 In 1.3.3, fixed the art. 6038 <-- HDR, SK {SA, Nr, [KEr], 6039 Si, TSr} 6040 becomes 6041 <-- HDR, SK {SA, Nr, [KEr], 6042 TSi, TSr} 6044 In 1.4 and 2.18, changed "replaced for the purpose of rekeying" to 6045 "rekeyed". 6047 Split out the SA deletion material from section 1.4 into its own 6048 subsection, 1.4.1. 6050 Clarified which bits are set at the end of Section 1.5. 6052 In 1.7, added "That is, the version number is *not* changed from RFC 6053 4306.". 6055 In 2.1, added wording about retransmissions needing to be identical. 6057 In 2.2, added "or rekeyed" to "In the unlikely event that Message IDs 6058 grow too large to fit in 32 bits, the IKE SA MUST be closed" 6060 In 2.2, moved the sentence "Rekeying an IKE SA resets the sequence 6061 numbers." up higher so it would be more likely to be seen. [Issue 6062 #15] 6064 Moved the definition of "original initiator" from 2.8 into 2.2 6065 because that is where it is first used. 6067 In 2.4, added "fresh (i.e., not retransmitted)" to "If a 6068 cryptographically protected message has been received from the other 6069 side recently". Also added the sentence saying that liveness checks 6070 are sometimes call dead peer detection. 6072 Removed the question to implementers about payload order in 2.5. 6074 Changed the title of 2.6 to "IKE SA SPIs and Cookies". Also, in the 6075 paragraph that describes how to implement the responder, changed the 6076 lower-case "should" to "can" to emphasize that this is a choice. 6078 Added the second paragraph in 2.6 to make it clear that the SPI is 6079 used for mapping. 6081 In section 2.6, upgraded "needs to choose them so as to be unique 6082 identifiers of an IKE_SA" to a MUST. 6084 Added sentences at the end of 2.6 eplaining wny the initiator should 6085 limit the number of responses it sends out. 6087 In 2.6.1, added the example of the shorter exchange; this is copied 6088 from RFC 4718 but was dropped in early drafts of this document. 6090 Added the paragraph to 2.7 that describes needing two proposals if 6091 you are having both normal ciphers and combined-mode ciphers. [Issue 6092 #20]. 6094 In section 2.8, added "Note that, when rekeying, the new Child SA MAY 6095 have different traffic selectors and algorithms than the old one." 6097 Added a note in 2.9 that PFKEY applies only to IKEv1. Also added 6098 that unknown traffic selector types are not returned in narrowed 6099 responses. 6101 Added note in the first paragraph of Setion 2.9.1 about decorrelated 6102 policies preventing the problem mentioned. 6104 In 2.12, removed "In particular, it MUST forget the secrets used in 6105 the Diffie-Hellman calculation and any state that may persist in the 6106 state of a pseudo-random number generator that could be used to 6107 recompute the Diffie-Hellman secrets." 6109 In 2.15, noted that the retry could happen multiple times for 6110 different reasons. 6112 In section 2.16, changed "This shared key generated during an IKE 6113 exchange" to "This key". 6115 At the end of 2.19, added statement that FAILED_CP_REQUIRED is not 6116 fatal to the IKE SA. 6118 Added the reference to ROHCV2 to the end of 2.22. 6120 In 2.23, changed "can negotiate" to "will use". for UDP 6121 encapsulation. Added "or 4500" to "...MUST be sent from and to UDP 6122 port 500". Also removed the text about why not to do NAT-traversal 6123 over port 500 because we later say you can't do that anyway. [Issue 6124 #27] Also removed the last paragraph, which obliquely pointed to 6125 MOBIKE. More will be added later on MOBIKE. 6127 In 3.1, removed "and orderings of messages" from "Exchange type". 6128 [Issue #29] 6130 In 3.1, added "This bit changes to reflect who initiated the last 6131 rekey of the IKE SA." to the description of the Initiator bit. 6133 In 3.3, added a long example of why you might use a Proposal 6134 structure because of combined-mode algorithms. [Issue #42] 6136 In 3.3.2, changed "is unnecessary because the last Proposal could be 6137 identified from the length of the SA" to "is unnecessary because the 6138 last transform could be identified from the length of the proposal." 6140 Added reference to AEAD to 3.3.2 and 3.3.3. 6142 Added the reference to RFC 2104 back for PRF_HMAC_TIGER in 3.3.2. 6143 [Issue #33] 6145 Added note at the bottom of 3.3.2 to see the IANA registry. 6147 In 3.3.4, removed all the "this could happen in the future" stuff 6148 because it already happened. 6150 Added a reference to email address internationalization to 3.5, 6151 making the address binary (not ASCII). 6153 In the table in 3.6, made "Authority Revocation List (ARL) 8" and 6154 "X.509 Certificate - Attribute 10" unspecified. 6156 In 3.7, changed the last sentence of the first paragraph to eliminate 6157 the non-protocol SHOULD. 6159 In 3.13.1, added "(including protocol 0)" for the start port and end 6160 port. 6162 In 3.14, updated the discussion of initialization modes to reflect 6163 that it is only about CBC, and that other specs have to specify their 6164 own IVs. 6166 In 3.15.1, added a pointer to 3.15.3. In the entries for 6167 INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET, added a pointer to 6168 3.15.2. 6170 In 3.15.4, added "The IKE SA is still created even if the initial 6171 Child SA cannot be created because of this failure." 6173 Changed "EAP exchange" to "EAP authentication" in 5. 6175 Removed "In particular, these exponents MUST NOT be derived from 6176 long-lived secrets like the seed to a pseudo-random generator that is 6177 not erased after use." from section 5 because it is not possible in 6178 most implementations to do so. 6180 Updated a bunch of reference to their newer versions. 6182 Added "[V+]" to the end of the exchanges in C.4 and C.5. 6184 Added two more response templates to Appendix C.1. Added another 6185 response template in Appendix C.2. Added two more responses in 6186 Appendix C.4. 6188 Authors' Addresses 6190 Charlie Kaufman 6191 Microsoft 6192 1 Microsoft Way 6193 Redmond, WA 98052 6194 US 6196 Phone: 1-425-707-3335 6197 Email: charliek@microsoft.com 6199 Paul Hoffman 6200 VPN Consortium 6201 127 Segre Place 6202 Santa Cruz, CA 95060 6203 US 6205 Phone: 1-831-426-9827 6206 Email: paul.hoffman@vpnc.org 6208 Yoav Nir 6209 Check Point Software Technologies Ltd. 6210 5 Hasolelim St. 6211 Tel Aviv 67897 6212 Israel 6214 Email: ynir@checkpoint.com 6216 Pasi Eronen 6217 Nokia Research Center 6218 P.O. Box 407 6219 FIN-00045 Nokia Group 6220 Finland 6222 Email: pasi.eronen@nokia.com 6224 Full Copyright Statement 6226 Copyright (C) The IETF Trust (2008). 6228 This document is subject to the rights, licenses and restrictions 6229 contained in BCP 78, and except as set forth therein, the authors 6230 retain all their rights. 6232 This document and the information contained herein are provided on an 6233 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 6234 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 6235 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 6236 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 6237 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 6238 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 6240 Intellectual Property 6242 The IETF takes no position regarding the validity or scope of any 6243 Intellectual Property Rights or other rights that might be claimed to 6244 pertain to the implementation or use of the technology described in 6245 this document or the extent to which any license under such rights 6246 might or might not be available; nor does it represent that it has 6247 made any independent effort to identify any such rights. Information 6248 on the procedures with respect to rights in RFC documents can be 6249 found in BCP 78 and BCP 79. 6251 Copies of IPR disclosures made to the IETF Secretariat and any 6252 assurances of licenses to be made available, or the result of an 6253 attempt made to obtain a general license or permission for the use of 6254 such proprietary rights by implementers or users of this 6255 specification can be obtained from the IETF on-line IPR repository at 6256 http://www.ietf.org/ipr. 6258 The IETF invites any interested party to bring to its attention any 6259 copyrights, patents or patent applications, or other proprietary 6260 rights that may cover technology that may be required to implement 6261 this standard. Please address the information to the IETF at 6262 ietf-ipr@ietf.org. 6264 Acknowledgment 6266 Funding for the RFC Editor function is provided by the IETF 6267 Administrative Support Activity (IASA).